PGTS Humble Blog
Thread: Mac OS X, Apple
|When you have eliminated the impossible, whatever remains, however improbable, must be the truth.|
MacPorts And NTP On Mac OS X
Chronogical Blog Entries:
Date: Wed, 23 Nov 2011 22:47:16 +1100
The MacPorts Project is an open source community initiative which delivers open source software to Mac OS X under a BSD license. I have been meaning to try it out for quite a while. Finally I got round to taking it for a test drive.
The project is very easy to install. If you feel inclined to go down the source route, you can download a tarball and start the manual compilation. Alternatively, if you just want to get started straight away, you can download a .dmg package and get the binaries for Mac OS X. You can read all about it on the MacPorts Download And Installation Page.
I chose the .dmg package for Snow Leopard. After the install I found the following lines added to my profile:
# Your previous /Users/foo/.profile file was backed up as /Users/foo/.profile.macports-saved_2011-11-12_at_12:47:31
# MacPorts Installer addition on 2011-11-12_at_12:47:31: adding an appropriate PATH variable for use with MacPorts.
export PATH=/opt/local/bin:/opt/local/sbin: $PATH
# Finished adapting your PATH environment variable for use with MacPorts.
I found the best way to get information was by reading the man page (use the command man port). The default location for the system wide configuration files is /opt/local/etc/macports/.
Some sample commands:
# Get information about a port
port search ghostscript
port search w3m
# get version of port
port list w3m
# List perl packages (takes a long time)
port list category:perl
# Install a port
sudo port install w3m
sudo port install mpg123
Getting Tk/Perl to work with MacPorts
I have found that getting Tk/Perl to work can be tricky. Previously, I tried installing it on a Mac using the standard Mac distribution, and it got way too complex. I eventually opted for the Activestate version of perl, which is comes with a working version of Tk/Perl. So one of the first things I wanted to try out with MacPorts was Tk/Perl.
The key to getting it to work is fix the path for users that will be using the MacPorts collection. This includes root if you are using /usr/bin and /usr/local/bin. I prepended the folders /opt/local/bin and /opt/local/sbin to the PATH in root's profile and installed perl5. The current version in the MacPorts collection is 5.12.3.
Afer fixing the path, you should also rename the current version of /usr/bin/perl:
sudo -i # check the path echo $PATH # point /usr/bin/perl at the MacPorts version mv /usr/bin/perl /usr/bin/perl.old.111130 ln -s /opt/local/bin/perl /usr/bin/perl # start and configure cpan cpan # install the Tk/perl package port install p5-tk
Overall If you have used dpkg on BSD, Aptitude Package Manager on Ubuntu, or other open source package managers, you'll find MacPorts a snap. It's easy to use, and the command line is fairly intuitive. What you don't grok straight away you can get from the man page.
MacPorts gets you the latest versions of all those handy open source utilities which are missing from the standard install.
NTP and Mac OS X
Apple is notorious for the integration of their products. They have taken a mature robust open source OS (BSD) and integrated it with their applications. However, for some people who are already familiar with BSD sometimes you can get caught out by some Apple cleverness.
This sometimes happens to me. I might setup things in a standard manner only to discover that Apple has assumed that I am too much of an airhead to know how to setup anything and done the task for me. And some times I just can't get my head around the Apple Way of carrying out some standard tasks. For example, I never really came to fathom the Apple way of dealing with NFS mounts. I did try to use the recommended approach, but I found it obscure, hard to remember and almost impossible to maintain. Rather than try to get the traditional /etc/fstab mounts to work (as some dedictated command line veterans have done), I decided to use a background perl script with a table of mount points that manages NFS mounts, just by using the mount command.
A similar thing happened with NTP when I first setup my Mac Pro workstation with OS X 10.4, I included the ntpdate command in /etc/rc.local. Generally I call ntpdate once only at boot time. Since then, there have been two major upgrades and many minor upgrades. I haven't really paid much attention to the ntpdate process.
However, a couple of weeks ago, I started investigating the following error message in the system log file:
12 Nov 21:56:11 ntpdate: the NTP socket is in use, exiting
I discovered the culprit was the NTP daemon.
machost:~ root# ps -ef | grep ntp 0 31 1 0 0:00.06 ?? 0:00.07 /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p /var/run/ntpd.pid -f /var/db/ntp.drift
And then when I started investigating the configuration files, I discovered that /private/etc/ntp-restrict.conf included the file /private/etc/ntp.conf, and that file referenced the original NTP server that I had included in the system /etc/rc.local script so many years earlier.
A little further reading revealed that ntpdate is soon to be retired from the Mac OS X BSD collection. The man page mentions that all the functionality of ntpdate program can be found in the ntpd daemon.
It doesn't seem to be drawing too long a bow to conclude that Apple may have detected that I referenced a particular NTP server and then setup ntpd using the same server. And considering that ntpdate is soon to be obsolete, maybe they did the right thing ... Pity they didn't mention it any where obvious.
Next I went looking for the ntpd plist in the launchd configuration. Hint: To discover which plist file to look for use this command
sudo launchctl list | grep -i ntp
Or you can just go to /System/Library/LaunchDaemons and look for something with the string "ntp" in its name ... When you find it, you can inspect the plist file for NTP with this command:
sudo launchctl list org.ntp.ntpd
Or (since it is a text XML) by using the cat command:
It seems that, moving forward, my options are to comment out the call to ntpdate in /etc/rc.local ... Or to unload the org.ntp.ntpd.plist file and invoke ntpd with the -q option at startup (which emulates the behaviour of ntpdate).