‚Č° Menu


  1. Create a new builder instance
    docker buildx create --use
  2. Build for multiple platforms, tag, and push to Dockerhub
    docker buildx build --platform linux/amd64,linux/arm64 --push -t <tag_to_push> .

The backstory

A while ago I was playing around with a nifty Open Source project called speed-camera which uses Python and OpenCV to track the speed of objects.

To make it easier to deploy, I created a docker Image for version 10.22 of the project, pushed it to dockerhub, and submitted a PR to let others benefit from it as well.

Fast forward and the maintainer of speed hub is now @ version 11.22 but my docker image is still sporting 10.22. He asked me to update the image… Sure! No problem!

So I pulled the repo to my machine bumped the version, created/tagged/pushed the new image to dockerhub. A day later, someone mentioned that it was built for arm64 and not amd64. Whoops! I recently got a new M1 Mac sporting that shinny and amazingly performant Apple Silicon and this didn’t cross my mind as this was the first docker image I’d pushed with my new Mac.

So like any normal person, I headed over to Google which led me to a blog post by Jaimyn that gave me the commands needed to build the docker image for multiple platforms, linux/amd64 and linux/arm64 in my case.

Something worth noting, buildx is no longer and “Experimental Feature” so you can drive right into creating the new builder instance with docker buildx create --use


To use the fancy Xerox AltaLink C8055 Multifunction/All-in-one printer at my office, I installed the drivers from Xerox’s support site and was on my way!

A few days later, I got an obnoxious “Xerox Product Registration” popup entitled “Xerox PowerENGAGE Registration” prompting to register the product, which doesn’t even belong to me.

Screenshot of Xerox PowerENGAGE Registration: Xerox Product Registration

There weren’t any preferences and I didn’t see this application anywhere in System Preferences, so I started to dig deeper into how I could remove this parasite from my machine.

I came across an article, How to Catch and Remove Hidden LaunchDaemons and LaunchAgents on Mac, which walked me through how to search for where this application was coming from. Sure enough, in,~/Library/LaunchAgents I discovered two files:

  • com.aviatainc.powerengage.helper.XRTK.plist
  • com.aviatainc.powerengage.XRTK.plist

After deleting these two files and the installed Xerox Applications list below, I haven’t seen the popup again! ūüéČ

  • ~/Applications/Xerox PowerENGAGE
  • ~/Applications/XeroxPEInstallationCompanion


Quick resolution: Stop & Start the instance

For those interested in the whole story …

We had an instance go down and upon logging into the AWS EC2 Management Console, we were confronted with this scarry message


Naturally, we clicked “Troubleshoot”

Screenshot 2015-01-09 11.52.05

The Resolution seemed simple enough – Just Stop & Start the instance; however, stopping the instance didn’t seem to work – It just hung at and instance state of “Stopping”

Screenshot 2015-01-09 12.02.57

After waiting what seemed an eternity (~45 minute), the instance finally stopped, at which time we were able to start it back up Рeffectively clearing the issue of the instance being unreachable as well as its retirement.

{ 1 comment }

If you’ve ever wanted to update the bandwidth limit via command-line, without needing to login to WHM, this post is for you! I was surprise with how simple this was.

  1. Manually edit line beginning with “BWLIMIT=” in /var/cpanel/users/
  2. Get your modification recognized by running the script below
  3. There is no step 3!

For the impatient, simply upgrade to at least WHMCS 5.2.2!

Per WHMCS support…

In the latest version of WHMCS we introduced a new session handling class which includes a random session name per install. We also updated the standard WHMCS verify image to use this new class and not call session start itself.

Full back-story and resolution for those not running version 5.2.2, are unable to do the upgrade, or perhaps experienced trouble with this fix.

For the impatient, simply add this line to the end of your configuration.php file.


For those interested in the full story …

Since right around the time we installed WHMCS version 5.1.2 in July 2012, we had been receiving an “Invalid Token” error periodically, yet quite regularly, when¬†submitting¬†a form on WHMCS (support ticket reply, invoice, etc.).

We opened a ticket with WHMCS support in August explaining the issue, hoping for that a response that would quickly resolve the issue. Unfortunately, that didn’t happen ūüôĀ The support team kept saying the error was due to the PHP session expiring and that it was essentially an issue with the hosting provider. With¬†session.gc_maxlifetime set to 24 minutes we were surprised to see the Session ID change after only a few minutes.

In March 2013, our team finally tracked down the cause of this issue …

WHMCS by default uses the PHPSESSID cookie to track its session. If there are any other PHP applications on the domain which use the same cookie, it can cause a conflict which in WHMCS results in an “Invalid Token” error. It took us a while to track this down as the other apps on the domain gracefully recovered from the shared cookie.

To resolve the issue, we added the line of code below to our configuration.php file.


Now the session cookie is called WHMCS and does not conflict with the other PHP applications on the domain.

Did this help you? Show some love with a comment!


**UPDATED 11/13/2013 to reflect usage of Windows Azure Active Directory Module for Windows PowerShell.

  1. Download & install the Microsoft Online Services Sign-In Assistant for IT Professionals BETA
  2. Download & install the Windows Azure Active Directory Module for Windows PowerShell
    (32-Bit | 64-Bit)
  3. Launch PowerShell and ensure we have loaded the Office365 Module
    Import-Module msonline
  4. Connect to Office365 using Administrative Credentials
    $cred = Get-Credential
    Connect-MsolService -cred $cred
  5. Set all user’s passwords to never expire
    Get-MsolUser | Set-MsolUser -PasswordNeverExpires $True

    To set a single user’s password to not expire

    Set-MsolUser -UserPrincipalName user@domain.tld -PasswordNeverExpires $false
  6. Confirm users passwords are set to not expire (Optional)
    Get-MsolUser | fl UserPrincipalName,PasswordNeverExpires

Thanks to Jan Egil for her great blog post which helped me figure this out and subsequently a TechNet article for the 11/13/2013 update.


I recently encountered an issue where I was unable remove a user from a Google Analytics profile. Immediate Googling was unsuccessful so I began playing around. Turns out, you cannot remove an administrator; you must first assign the “User” role to the account you wish to remove.


I was playing around with node.js on EC2 the other day and ran into some trouble installing npm. I was getting this error

[]$ curl http://npmjs.org/install.sh | sudo sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
101  7881  101  7881    0     0  94200      0 --:--:-- --:--:-- --:--:--  148k
npm cannot be installed without nodejs.
Install node first, and then try again.
Maybe node is installed, but not in the PATH?
Note that running as sudo can change envs.

My initial attempt at finding a resolution revolved around trying to update the path env setting used by sudo. After spending some fruitless time on this I switched gears and came across Michael Dillon‘s Stack Overflow post which recommended setting up some symlinks to resolve the path issues.

sudo ln -s /usr/local/bin/node /usr/bin/node
sudo ln -s /usr/local/lib/node /usr/lib/node
sudo ln -s /usr/local/bin/npm /usr/bin/npm
sudo ln -s /usr/local/bin/node-waf /usr/bin/node-waf

Minutes later npm was up and running!


We were recently transitioned to Office365 and learned that certain settings and permissions did come across during the upgrade. This meant that some settings and permissions needed to be reconfigured via PowerShell. Back in the days of BPOS, you needed the Migration ToolKit installed in order to use any of the Microsoft Online related PowerShell Cmd-Lets. With Office365, you don’t need this! Instead, you need to open a server side connection to the cloud servers from your local machine. Below are the steps to do this.

  1. Load your Office365 credentials in a variable
    $Cred = Get-Credential
  2. Create a session variable which will configure a connection to the cloud servers
    $Sess = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $Cred -Authentication Basic -AllowRedirection
  3. Initialize the session
    Import-PSSession $Sess
  4. Run any of the Exchange Online Cmdlets found in the documentation.
  5. Once you’re done running commands, you can close the session
    Remove-PSSession $Sess

Note: The guts of this post came from a Microsoft Article which I never was able to come across in my searching, but rather was pointed to via a service request.


**NOTE** You will need to have compiler access on your shared hosting account in order for the instructions below to work. You can request your host enable this, or pass these instructions along to them and request they compile git for you.

From SSH:

wget http://git-core.googlecode.com/files/git-
tar zxvf git-
cd git-
./configure --prefix=/home/$USER
make install
echo 'PATH=$PATH:$HOME/bin' >> $HOME/.bashrc
source $HOME/.bashrc

If you get the error “bash: /usr/bin/wget: Permission denied” you can try downloading the git source with the command

curl -O http://git-core.googlecode.com/files/git-