Category Archives: Apple

Remote SSH using Back To My Mac

Posted on
Reply

One of the less well publicised features of Apple’s iCloud service is Back To My Mac.

This service provides a private IPv6 network which you can use to securely connect all your Mac hosts.

To use BTMM you will need to upgrade all your Macs to OS X Lion and sign them all into the same Apple iCloud account. You will also need your unique BTMM account number.

When you are signed into iCloud you can discover your BTMM account number as follows:

$ dns-sd -E
Looking for recommended registration domains:
Timestamp     Recommended Registration domain
12:07:46.550  Added     (More)               local
12:07:46.550  Added                          icloud.com
                                             - > btmm
                                             - - > members
                                             - - - > 123456789

The final line shows your individual BTMM account number.

For example, if you Computer Name (set in System Preferences > Sharing) is mymac and your BTMM account number is 123456789, then the fully qualified domain name of the host is mymac.123456789.members.btmm.icloud.com.

If you have spaces in your Computer Name then replace them with dashes, e.g. “My Mac” becomes the hostname my-mac.

To test connectivity to your remote host use ping6, e.g.

ping6 mymac.123456789.members.btmm.icloud.com

To list all the SSH enabled hosts on your domain:

dns-sd -B _ssh._tcp

You would SSH into your host using this command:

ssh -2 -6 username@mymac.123456789.members.btmm.icloud.com

Note that you will only be able to communicate with the other hosts on your iCloud private network if the Mac you are using is also signed into the same iCloud account.

You can also use an open SSH connection to access your non-Apple hosts on your internal network by using SSH port forwarding. This tunnels the destination traffic over the BTMM private network via your remote Mac.

For example, if you have a web server running on a host with the IP address 192.168.1.2 then you can use this SSH command to set-up a forwarded port:

ssh -2 -6 -L 8080:192.168.1.2:80 username@mymac.123456789.members.btmm.icloud.com

To access the remote host from your local machine you would go to http://127.0.0.1:8080/

Uninstall Symantec Enterprise Vault Client on Mac OS

Posted on
Reply

Since Symantec doesn’t provide an uninstaller script for their Enterprise Vault Client, here’s how to remove it on Mac OS.

Open a Terminal window and execute these commands:

launchctl unload -D user /Library/LaunchAgents/com.symantec.ev.daemon.plist
sudo killall -m  "Enterprise Vault .*"
sudo rm -f /Library/LaunchAgents/com.symantec.ev.daemon.plist
sudo rm -rf "/Library/PreferencePanes/Enterprise Vault.prefPane"
sudo rm -rf "/Library/Application Support/Symantec Enterprise Vault"
rm -rf "~/Library/Application Support/Symantec Enterprise Vault"

Dropbox & EncFS on OS X Lion

Posted on
1

I previously wrote about a method for creating a super-secure filesystem using Dropbox’s cloud storage.

After updating to Mac OS 10.7.2 “Lion” I struggled to get the MacFusion GUI to work and so I wrote a shell script to automate the mounting and unmounting of the EncFS filesystem.

I also took the opportunity to switch from the now abandoned MacFUSE to Fuse4X, which is a properly maintained fork of MacFUSE started in June 2011.

The install procedure is much simpler than before, you install Fuse4X and EncFS, but instead of using the MacFusion GUI you just call my script instead.

To the instructions!

First download and install Fuse4X and a version of EncFS which uses the Fuse4X APIs. Thanks to Simone Lehmann for providing an EncFS Mac installer at http://www.lisanet.de/?p=128 (also mirrored here).

Next download my encfsadm archive, unzip the contents and copy the encfsadm script to a local folder, e.g. /usr/local/bin

To create a new encrypted volume (stored locally at first to prevent the EncFS key from being synchronised with Dropbox):

encfs ~/Desktop/_Encrypted ~/Documents/_DropSec

Answer ‘yes’ when prompted to create the new folders and choose ‘p’ for pre-configured paranoia mode (256-bit AES encryption). Enter a secure password when prompted and you’re done.

Now the filesystem has been created we can deal with securing the key.

umount ~/Documents/_DropSec
mkdir ~/.keys
mv ~/Desktop/_Encrypted/.encfs6.xml ~/.keys/dropsec.xml

The commands above move your key from the EncFS filesystem into a hidden folder in your (local) home directory

Now move the entire ~/Desktop/_Encrypted folder (minus your key) into your Dropbox:

mv ~/Desktop/_Encrypted ~/Dropbox/

Open the encfsadm script with a text editor and change the variables at the top of the script to match your local configuration.

For ease of use the script stores your EncFS password in your Mac OS login keychain.

To set your password:

encfsadm password

The setup is now complete.

To check the EncFS filesystem:

encfsadm status

To mount the encrypted filesystem:

encfsadm mount

To unmount the encrypted filesystem:

encfsadm unmount

Alternatively call the encfsadm script with no arguments and it will alternate between mounting and unmounting.

If you want to create a simple application to call the encfsadm script then use Mac OS Automator.

Start Automater, choose ‘Application’ and use the ‘Run Shell Script’ action. Provide the path to your script (/usr/local/bin/encfsadm) and save as an application. Drag the app to the Dock and you have a simple and secure one-click EncFS mounter/umounter.

Alternatively you can use the EncFSadm application which I have included in my encfsadm archive.

Adobe retires Flash for mobiles

Posted on
Reply

In early 2010 Apple announced the eagerly anticipated iPad and iPhone 4. They were hugely successful product launches, but at the same time Apple also came under increasing pressure from customers and developers to support Adobe Flash on their shiny new iOS devices.

In reaction to the criticism Steve Jobs delivered a scathing personal attack on Adobe Flash in an Apple article entitled “Thoughts on Flash“.

Jobs began by saying he “wanted to jot down some of our thoughts on Adobe’s Flash products so that customers and critics may better understand why we do not allow Flash on iPhones, iPods and iPads“.

In his critique Jobs went on to detail six main reasons why Apple was so staunchly against Flash, which I have paraphrased below:

  1. Open. Adobe’s Flash products are 100% proprietary. By almost any definition, Flash is a closed system.
  2. Full web. Adobe has repeatedly said that Apple mobile devices cannot access “the full web” because 75% of video on the web is in Flash. What they don’t say is that almost all this video is also available in a more modern format, H.264, and viewable on iPhones, iPods and iPads.
  3. Reliability, security and performance. Symantec recently highlighted Flash for having one of the worst security records in 2009. We also know first hand that Flash is the number one reason Macs crash.
  4. Battery life. H.264 can be decoded in hardware which doubles battery life during video playback.
  5. Touch. Flash was designed for PCs using mice, not for touch screens using fingers.
  6. Cross platform. We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform.

Reading Jobs’ article again really highlights his genius for strategic vision.

New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.

Steve Jobs
April, 2010

How prophetic that closing paragraph was in light of Adobe’s announcement just 18 months later to cease development of Flash for mobile devices, and focus on HTML5 instead.

The news of this dramatic Adobe turnaround came in an official blog post from Danny Winokur, VP & General Manager, Interactive Development at Adobe.

Flash to Focus on PC Browsing and Mobile Apps; Adobe to More Aggressively Contribute to HTML5

HTML5 is now universally supported on major mobile devices, in some cases exclusively.  This makes HTML5 the best solution for creating and deploying content in the browser across mobile platforms. We are excited about this, and will continue our work with key players in the HTML community, including Google, Apple, Microsoft and RIM, to drive HTML5 innovation they can use to advance their mobile browsers.

Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores.  We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook.

Although Jobs was undoubtedly correct to back the HTML5 open standard, I have to question whether he was merely a soothsayer or the architect of Flash’s demise. Clearly with no Flash support on Apple’s iOS products there was a massive disincentive for developers to continue using Adobe’s technology.

Either way, Jobs got his way. It’s a shame he never got to see it.

 

Google Maps API

Posted on
Reply

Google have announced that they will introduce usage limits and start billing excess usage fees for their Google Maps API from 1st January 2012.

The free usage limit has been set at 25,000 map loads per day. If you exceed this limit your choices are:

Excess usage is billed at $4 per 1,000 map loads.

What happens if you do none of these?

Your maps will continue to function. However if your application qualifies for and consistently exceeds the published Maps API usage limits, you do not have a Maps API Premier license, and you do not enroll for online purchasing of excess map loads, a warning may be shown on your map and a Maps API Premier sales manager may contact you to discuss your licensing options.

While this apparently won’t affect 99.65% of users and is aimed squarely at the high-usage ‘abusers’, one does wonder what plans Google have for widening the net of their haul by reducing the limits even further.

Fortunately developers who use the Maps External Library to embed maps in their Android or iOS apps shouldn’t be affected, but again I wonder how long before Google decide to cash-in on this lucrative revenue stream too.

Apple presumably have the same fears. Earlier this year they quietly acquired Swedish mapping technology firm C3 Technologies, so it’s probably safe to assume that they are developing an alternative maps API to challenge Google’s dominance.

While I appreciate that Google is a profit-making commercial enterprise, the manner in which these fees have been introduced is a cause for concern.

It’s akin to a drug dealer giving away free hits and then exploiting the poor addicts once they’re hooked on drugs.

Is this indicative of a new Google business model to get us all using their ‘free’ services and then bleed us dry once we’re all dependent?

Google’s “Don’t be evil” corporate motto might need to be updated soon.

" The first one's free kid ... "