Posts Tagged ‘Mac OS X’

How-To Fix Cadaver Showing “WARNING: Untrusted server certificate presented” on Mac OS X

Tuesday, October 2nd, 2012

Here is explained how to compile Cadaver to support root CA certificates with ‘homebrew’ or Mac OS X.

Cadaver is a command line webdav client tool. It’s available on Mac through the ‘homebrew‘ subsystem for OS X.
It has the capability to connect you to webdav services via both http and https protocols, with the same ease you would use a ftp client.

While using ‘cadaver’ to connect to a webdav repository via https (SSL encrypted http), you may experience the odd request from the tool to accept the SSL certificate offered by the site you are connecting to because it is recognised as ‘Untrusted’, although the same certificate is not expired yet and is recognised as trusted by any other tool webdav client you may use (i.e. browsers or graphical tools like Cyberduck). This is the message that will be thrown “WARNING: Untrusted server certificate presented”.

This annoying behaviour prevents you to use ‘cadaver’ in system scripting because it will require a human interaction at any execution.

The reason behind this obvious error, are apparently connected to the fact that ‘cadaver’ relies on the ‘libneon’ libraries to handle the SSL encrypted connections and such libraries, in the instance of OS X, are not able to interact with Certificate Authorities Certificates installed in the system, therefore there are not able to verify the ‘trusted’ status of any certificate they come across.

On a GNU/Linux system showing the same warning,  it’s probably enough to install the ‘ca-certificates’ packager otherwise another possible solution is to recompile the ‘libneon’ libraries making sure to specify the right path to the ‘root CA certificates’ during the configuration.

On a Mac OS X the ‘libneon’ libraries are not available via ‘homebrew’, then installed version of cadaver is using it’s own copy of them. That means we will have to force ‘homebrew’ to recompile an reinstall ‘cadaver’ including a copy of the ‘root CA certificates‘. To do so we will use ‘curl’ sources and modify cadaver’s homebrew formula formula.

You may skip the stage 1 and 2 in case you have already a curl’s certificate bundle installed at/usr/share/curl/curl-ca-bundle.crt

  1. Download and unarchive the Curl sources:
    $ wget http://curl.haxx.se/download/curl-7.22.0.tar.bz2
    $ tar xvjf curl-7.22.0.tar.bz2
  2. Retrive the ‘root CA certificates’ using a script included in curl’s sources directory:
    $ cd curl-7.22.0/lib/ 
    $  ./mk-ca-bundle.pl
  3. Install the ‘root CA certificates’ :
    $ sudo mkdir -p /usr/share/curl/
    $ sudo cp ca-bundle.crt /usr/share/curl/curl-ca-bundle.crt
  4. modify cadaver’s homebrew formula to include the ‘root CA certificates’ during the compilation:
    $ brew edit cadaver

    add this  string  – “–with-ca-bundle=/usr/share/curl/curl-ca-bundle.crt”, – to the ‘def install’ section of the formula (including the double-quotes and the comma), as follow:

    def install

    system “./configure”, “–prefix=#{prefix}”,

    “–with-included-neon”,

    “–with-ca-bundle=/usr/share/curl/curl-ca-bundle.crt”,

    “–with-ssl”

     

  5. Remove the current installation of ‘cadaver’:
    $ brew remove cadaver
  6. Re-Install ‘cadaver’ that will be recompiled with a link to the ‘root CA certificates’:
    $ brew install cadaver

    Mind that the ‘root CA certificates’ will not be hard-coded in ‘cadaver’, only their path will be hardcoded, so DO NOT move the ‘curl-ca-bundle.crt’ from it’s location otherwise you will experience again the ‘WARNING: Untrusted server certificate presented’ issue.

At this point you should be able to use cadaver with https webdav repositories without been requested to accept every single SSL certificate.

 

How-To Send A Command In Background And Keep It Running using ‘nohup’

Tuesday, March 20th, 2012

The shell command ‘nohup‘ in combination with ‘&‘ will allow to send the a command-line instruction in background enabling the process to keep running after the user who issues the command has logged out.

A common use of ‘nohup’ is when you need to issue a remote command via ssh connection and then you need to close the connection but be sure that the issued command will keep running in background, i.e.:

~$ sudo nohup shutdown -r -h 1203192100

I use this ‘trick’ when I want to restart my Mac and GNU/Linux Servers during evening/night hours but I want to submit the command during my office time.
In such way I save myself the time to remotely connect from home.

The ‘nohup’ command is even used to run processes in background as daemons.

nohup is a POSIX command to ignore the HUP (hangup) signal
(cit. from Wikipedia)


How-To Fix “Some of your photos were not copied to the iPad, iPhone, iPod because they cannot be displayed on your iPad, iPhone, iPod”

Thursday, November 24th, 2011

It happens, fortunately not so frequently, that during the Photo synchronisation of my iDevices via iTunes I get an error about the copy of my pictures to my iPad or iPhone:

"Some of your photos, including the photo "IMX_xxxx",
were not copied to the ixxx because they cannot be displayed on your ixxx."

I notice that this problem comes out usually after an update or upgrade of Aperture, and having a look around the web it is not a problem isolated to Aperture but it also shows up when you use iPhoto and in rare cases also when you sync your pictures directly from the Pictures folder of your account.

The only solution that worked for me in the time and in different Macs has been to force a complete regeneration of the iPod Photo Cache (se References at the bottom).
According to what software, if any, you use to manage your pictures, you will need to remove the following folders:

  • If you synchronise from the Pictures folder:
    /Users/<username>/Pictures/iPod Photo Cache
  • If you synchronise from the Aperture Library:
    • From the Finder navigate to the Picture folder.
    • Select the Aperture Library archive.
    • Right Click on it and choose Show Package Contents.
    • delete the iPod Photo Cache folder
  • If you synchronise from the iPhoto Library:
    • From the Finder navigate to the Picture folder.
    • Select the iPhoto Library archive.
    • Right Click on it and choose Show Package Contents.
    • delete the iPod Photo Cache folder

This operation will force iTunes to analyse the entire pictures archive and to generate all new copies of the pictures suitable for your iDevice.

In a few occasions I also found useful to proceed the  Rebuild Aperture Database procedure that will force Aperture to reanalyse all the masters of you photo library and regenerate all the preview and thumbnails.

To rebuild the aperture database you need to start Aperture holding the key combination of “Alt+Command” and then confirm the operation, that could take a very long time depending on the dimension of your pictures library.

Hope that this will help you.

 

References:

iTunes: Understanding the iPod Photo Cache folder

MacRumors 

 

 

How-To configure unattended clients with TeamViewer for Mac (simulating TeamViewer Host)

Friday, February 25th, 2011

09/09/2011 – UPDATE
The TeamViewer team has recently release a new host version for Mac OS X
TeamViewer for Unattended Servers: TeamViewer Host

Despite the name it can be used in any Mac OS X installation (clients and servers)

http://www.teamviewer.com/download/TeamViewerHost.dmg

http://www.teamviewer.com/en/download/index.aspx

Original post:

Because there is not TeamViewer Host for Mac yet, I’ve been chatting with the support team at TeamViewer GmbH about an official workaround to create a TeamViewer unattended client for Mac OS X, this is what they advised to do:

  1. You would have to predefine a permanent password on TeamViewer for Mac.
  2. A standard user should be logged in.
  3. TeamViewer should be part of the auto starting programs.
  4. The Mac should not go in sleep mode.

The main glitch of this solution is that if the user logs out returning to the Login screen then the TeamViewer software is quitted and the connection is lost.

An additional workaround that would help us maintaing the connection to the Mac also when the main user is logged out is:

  1. Create an ‘autologin’ user
  2. Install and configure TeamViewer as suggested in the previous steps to be part auto starting programs for the ‘autologon’ user.
  3. Immediately auto-lock the account and return to the Login screen using Lock My Mac or MacLoc and configuring one of then as part of auto starting programs.

At this point, with a bit longer system initialization, the user of the Mac will behave like usual while an ‘hidden’ account is running TeamViewer for us.

The catchof this solution is that when the user will want to shutdown the system it will be propted with an alert message notifying him that other users are logged in the system and that if he wants to continue with the shutdown process all open documents and data will be lost. MAybe we can find a way to disable this alert…. suggestions are welcome 🙂