MacPorts on Mavericks

If you found this page looking for help compiling MacPorts for OS X 10.11 El Capitan, please check out this post.

FINAL UPDATE: 2013-10-26 – The Official MacPorts installer for Maverics has been released, so there is no longer a need to jump through hoops. Please visit the MacPorts Download page to get the official version.

If you are a bleeding edge lunatic who has installed Mavericks before the first patch release, you may have realized you can’t install any new MacPorts.  You can search ports, but nothing will install.  No worries, I can help.  🙂

Note:  These instructions have evolved a bit since they were first posted, prior to the official release.  If you visited before and had problems, try again now.  These instructions assume you have already installed Mavericks.

  1. Follow steps 1, 2 & 3 of the Migration page:
  2. Follow the Uninstall instructions:
  3. Install Xcode from the App Store
  4. Launch XCode, agree to the license terms, and enter your password in the auth dialog box.
  5. Go to Preferences/Downloads
  6. Select “Check for and install updates automatically” and then click “Check and Install Now”
  7. Open a Terminal window:
    ## Reset your path, in case you have a previous install that 
    ## might bugger the configure. (Thanks Rainer)
    export PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
    ## Install Xcode CLI. Install dialog should open up and auth 
    ## the install.  (Thanks Drew, and others)
    xcode-select --install 
    ## Fetch MacPorts source code
    curl -O
    ## Uncompress source and change to the source directory
    tar jxvf MacPorts-2.2.0.tar.bz2
    cd MacPorts-2.2.0
    ## Configure the make file for MacPorts (Thanks Clemens)
    ./configure --enable-readline  
    ## Compile MacPorts
    ## Install MacPorts
    sudo make install
    ## Fix your path (Thanks Peter)
    echo 'export PATH=/opt/local/bin:/opt/local/sbin:$PATH' >> ~/.profile
    source ~/.profile
    ## Update your ports
    sudo port -dv selfupdate
  8. Re-install your ports.
  9. Post nice comments.  🙂

UPDATE: 2013-10-23 – I really appreciate the feedback I’ve been getting on this page.  If the steps above don’t work perfectly for you, please check the comments below. 

UPDATE 2: 2013-10-23 – My apologies to everyone for the site slowness and instability earlier.  This was a new VM and I hadn’t optimized my Apache config.  I was caught a little off-guard by the huge increase in traffic.  🙂

UPDATE 3: 2013-10-24 – Thanks to all of the wonderful contributors to this thread, there are new, improved and simplified instructions. The current instructions have been tested in a brand new Mavericks VM, but should also work with systems that have previous MacPorts installs. If you have any problems, please leave me feedback and I’ll try to help.

SecureCRT and a failed order of applied preferences

Update: The amazing folks at VanDyke have fixed SecureCRT so that if the session has a defined key, it is tried first; and if that key fails then agent keys are tried next.

The server has disconnected with an error. Server message reads:
A protocol error occurred. Too many authentication failures for ec2-user

Recently I was setting up EC2 instances for a client, and as such things go I wound up creating ssh keys for each of the EC2 regions in which I was working.  With each instance I created in each new region, I configured the specific connection profile in SecureCRT with the appropriate ssh key.  All was well, for a while.  And then I hit a brick wall.  I could spin up new instances, add them to SecureCRT, but I couldn’t connect to them.

Long story short, as I added each new ssh key, it was added to the “Agent Keys” that were automagically presented to each host.  What I didn’t expect, and what I consider to be a bit of a bug, is that the Agent Keys are presented first; even if the session profile specifies a key.  So, despite having configured a specific key for the session, my connections were failing because the X number of Agent Keys presented first exceeded MaxAuthTries in the sshd_config.

Many other ssh clients support Key Agent along with specified keys.  OpenSSH and PuTTY are two that come to mind.  OpenSSH will present Key Agent keys for auth, but if you specify “-i PATHtoKEYfile” that key will be presented first.

I reached out to support at VanDyke, the creators of SecureCRT.  I explained the problem, and asked if there was a configuration option for controlling the Key Agent/Session Key order; and if not I requested that this be filed as a bug.  I was told this “behavior is by design”.  Odd, since they constructed a video explaining how Session settings override Default settings; so it is obvious they understand that most specific takes precedent over less specific settings.  The same precedence should logically apply to auth keys, and it does with OpenSSH.  According to section “Using Identities” in SSH, The Secure Shell: The Definitive Guide the described behavior is host specific identities, and then agent identities.

The quickie solution I used was to got to “Tools”/”Manage Agent Keys” in SecureCRT and clear out all the extraneous keys that had accumulated.  I hated doing this, as I was stripping out some of the ‘automatic smarts’ that I love about SecureCRT.  Still, it isn’t as bad as the kludge that Todd at VanDyke support suggested.  His suggestion was that I disable “Try All Agent Keys” in the SSH2.ini file.  Todd’s suggestion makes me wonder why I pay money for SecureCRT and all of its advanced features if their only way to deal with a problem is to have me disable those features.

Despite several days of emailing back and forth, and providing documentation showing that at least two of the major ssh clients process host keys before agent keys, the folks at VanDyke stand by their odd choice of ordering.  Todd has submitted a ‘feature request’ for me, and they refuse to treat this as a bug.  Next time my license is up for renewal I just might have to write a SecureCRT->JellyfiSSH config conversion tool…