Transfer Previous Recipients and Facetime contacts between macs on Mavericks and Yosemite Mail

Recovering a trashed Mail installation from an orphaned drive or just want to transfer Recents without using VCards?

The files you’ll need to copy are:
~/Library/Containers/com.apple.corerecents.recentsd/Data/Library/Recents/
Recents
Recents-shm
Recents-wal

~/Library/Containers/com.apple.corerecents.recentsd/Data/Library/Syncedpreferences/
recentsd-com.apple.mail.recents.plist

Optionally, copy the other “recents” plists as well for facetime, maps, iCal, messages etc:
recentsd-com.apple.calendar.recents.plist
recentsd-com.apple.corerecents.map-locations.plist
recentsd-com.apple.facetime.recents.plist
recentsd-com.apple.messages.recents.plist

…and finally reboot your mac to force the operating system to reload the new plists – instead of using cached copies.

 

Workaround -fix- for missing “import” folder after attaching archives in Mac Mail 6.x

Archive folders detached and disappeared.
Re-imported them from ~/Library/Mail/V2/Mailboxes/…

and found a nice workaround for the missing “import” folder problem you hit if you try to import nested folder hierarchies in one go:

Try to import .mbox files first – if you click on through, the import will proceed, but you’ll never see any “import” folder created.  However when you next open the import dialogue and choose “Mac Mail” instead of .mbox, you’ll be able to see the contents of the nested folders, and drill down to the individual mboxes themselves.  Import them one at a time, then drag them into a coherent archive structure once you’re done.

ssh multiple identities -fix- “Too many authentication failures for { username }”

So; you regularly use ssh to connect to a few different hosts – using different private keys for each user/server combination.

Your  ~/.ssh/ directory already has a few named private keys in it – you add a couple, bring the total to 5 or more…

ls ~/.ssh/
dave_mars.id_dsa
sue_deimos.id_dsa
steve_deimos.id_dsa
irene_phobos.id_dsa
lee_phobos.id_dsa
sue_mars.id_dsa
red_deimos.id_dsa

….and try connecting:

ssh -i .ssh/sue_mars.id_dsa -l sue mars

You’re denied, with an error like:

Received disconnect from {mars' IP address} 2: Too many authentication failures for sue.

Which is confusing;  this may be the first time you’ve tried connecting to phobos with sue’s account.

Add the verbose switch to you ssh command:

ssh -v -i .ssh/sue_phobos.id_dsa -l sue phobos

You’ll see this at the end of the negotiation:

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: .ssh/dave_mars.id_dsa
debug1: Authentications that can continue: publickey
 debug1: Offering RSA public key: .ssh/sue_deimos.id_dsa
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: .ssh/steve_deimos.id_dsa
debug1: Authentications that can continue: publickey
 debug1: Offering RSA public key: .ssh/irene_phobos.id_dsa
debug1: Authentications that can continue; publickey
 debug1: Offering RSA public key: .ssh/lee_phobos.id_dsa
Received disconnect from {phobos' IP address}: 2: Too many authentication failures for sue

Your local ssh agent is offering any key it can find, pre-loaded and cached from the .ssh directory (prove this caching by moving the other named keys somewhere else on your system – they’ll still be offered). The -i flag is a more of a guideline or hint to the agent.

To force the ssh client to offer only the key specified by -i, use the

-o IdentitiesOnly=yes

option:

ssh -o IdentitiesOnly=yes -i .ssh/sue_phobos.id_dsa -l sue phobos

or:

ssh -o "IdentitiesOnly yes" -i .ssh/sue_phobos.id_dsa -l sue phobos

…you’re connected.

 

Fix for Filemaker Pro 10 on OSX 10.8.5’s inability to “remote open” databases.

Clearing up some overdue updates (10.8.4>>5) on a couple of Mountain Lion machines, I came across this:

FIlemaker 10.03 opens with no apparent problem, creates and plays fine with local databases, but dumbly refuses to list any on a server in the same subnet.

Telnet to the server’s port 5003 worked and the server itself was visible in the “open remote” dialogue, but where the databases should’ve been – pure snowy-white #fff.

cat /var/log/system.log | grep filemaker

…gave a clue;

com.filemaker.messages[579]: 2014-01-15 15:56:20.302 +0000 [AttachThread_acd0fa28] ConstructORB() caught a CORBA INITIALIZE exception

exceptions relating to CORBA – indicating, as nothing else in the app had changed, that the client wasn’t talking to the server securely any more. “Certificates” I thought. To think is to -g-o-o-g-l-e- duckduckgo.

Sure enough, the internet provided and lead me on to a similar fix for Filemaker Pro 9.x on Mountain Lion – relating to an old, ppc-only OpenSSL library. The iMacs we were using *had* worked – but the certificates in use dated back to 2003. Replacing them with more recent certs and restarting Filemaker Pro gave an instant, solid connection to the databases on the server.

TL:DR;

Show Contents of the Filemaker Pro.app in /Applications, and replace the cert(s) with those from a more recent trial version (11 onwards):

/Applications/FileMaker Pro 10/FileMaker Pro.app/Contents/MacOS/root.pem

/Applications/FileMaker Pro 10/FileMaker Pro.app/Contents/MacOS/server.pem

Restart Filemaker.

 

Dual boot OSX and Xen Server

Based (hopefully very closely) on an existing HOWTO.

I have an excellent general purpose i7 machine that usually works as a Hackintosh; for the sake of desk space I want it to function as a Citrix VDI testbed.

Update: As osx86 doesn’t like VT-d and Citrix definitely does, I’m using BIOS profiles with separate boot device orders.