Q: Snow Leopard users: Turn off automatic date and time in System Preferences immediately

Anwar Shiekh wrote:

 

My problem is that the G5 PPC Mac is my main machine at home, so I can't afford to experiment on it; as a result I cannot be of much help. Hopefully you have access to a machine running 10.5

Nope.  I don't.  I was hoping that maybe when I do my final tests on my script you could test it for me on 10.5.

I'm using 10.6.7 on a 2010 Mac Pro so I have multiple internal drives available.  Since my boot drive is separate from my home directory drive and can simply switch boot to another copy of my boot drive drive for  testing without fear of any annoying disasters.

It is great how there is a PPC Bash installer for that bug, and hopefully soon also one for NTP for us still on PPC Macs. It would need universal binaries and I can compile the PPC binaries for anyone that might need them; I think the 4.2.8 NTP code is up to beta 5 of patch 1 at the moment, and this compiles without trouble on a PPC Mac running 10.5

FWIW, here's my initial summary comments from my script's "man page" (just part of the comments in the script) describing what it does (or tries to do until I complete my testing): [I had a little problem formatting this for this post -- there's a horizontal scroll bar at the end of the post -- weird]

#  build-ntp is a bash shell script to build a version ntp from the www.ntp.org archives (http://archive.ntp.org/ntp4/ntp-4.2/).
#  The specified ntp version (e.g., "ntp-4.2.8", "ntp-4.2.8p1-beta2", etc.) in the archives is downloaded and built. The choices
#  of what to do with the download include building (--build), installing a build on the host system (--install), building an
#  OS X installer package of the built ntp or a backup of ntp (--[build-]pkg), backing up (--backup) the current host ntp files,
#  or restoring (installing) a backup into the host machine (--restore).
#
#  Builds are permitted for the ppc, i386, and x86_64 architectures.  One or more may be specified to build single or universal
#  ("fat)" binaries.  The default is to build for the host machine.

Although I test on a totally expendable copy of my boot drive I sort of got a little "carried away" adding features like backup/restore.  That would let me flip various versions of ntp in and out for experimentation without having to fully dup the experimental boot drive again (at least that's the plan, I haven't rebooted to test this stuff out at the time I am writing this, not really in any hurry, have other things to do).  I also had in the back of my mind your situation where you would have to take extra steps to create a experimental boot drive so you could simply restore from a backup of the original ntp files if you weren't happy with an update (although I assume you should always have full separate backups).

Since I had to tweak it for 10.5 (i.e., not clobber the 10.5 ntpd-wrapper) I was hoping you might test on your machine when I complete this script. Now that you posted your 10.5 version of ntp-restrict.conf (thanks for doing that) I see there are no surprises with that so I think my 10.5 tweaks are complete.

---

Note, building, package creation, creating backups are all tested.  I just haven't rebooted to test restoring or using the installer packages yet.

I am setting up an external boot drive as we speak, and that should allow me to test things for you.

Thanks for that.  I'll try to complete my testing this weekend sometime.

By the way I added one extra line at the end of my last post.  Apparently I was still able to edit and add that line to that post even though you had seen it and replied while I was editing it.

I assume you have no problem generating the PPC binaries even without access to 10.5

Anwar Shiekh wrote:

 

I assume you have no problem generating the PPC binaries even without access to 10.5

Correct.  I even have a ppc, i386, x86_64 build sitting on my desktop!

I've also inspected the effect of my 10.5 tweaks for handling the ntpd-wrapper in install and restore (i.e., it simply doesn't install the modified ntpd-wrapper into a 10.5 target).  Package creation was tweaked differently in that in order to not require OS X version specific installers I tweaked it to let the installer install the modified ntpd-wrapper but the package's preflight renames the original ntpd-wrapper, lets the install to proceed, and then overwrites the now installed modified ntpd-wrapper with the original in postflight (all this only for a 10.5 target of course).  The end result is the same.  The ntpd-wrapper is still the original 10.5 version.

By the way, I did add a test option to my script to not do all this for 10.5 while I was still thinking about these changes and they were fresh in my mind.  I did that with the hope that the updated ntpd-wrapper could be experimented with on 10.5.  If it works, and I believe it should, then I wouldn't need the 10.5-specific tweaks.  I just can't seem to leave this script alone!  Not sure why.  It's just another shell script.  I keep screwing around with it which is why I haven't bothered to reboot to complete the testing.

It would be nice to install universal binaries for 10.5 so it can still be used on an Intel Mac,

but I never figured out how to automate that, and ended up using

• lipo -create <file1> <file2> <...> -output <file>

As I just described the script can create universal binaries and installers to go with them since the installer sees what version of the target OSX it is installing into at install time and dynamically handles that ntpd-wrapper accordingly.  That's what I meant about not having a OSX version-specific installer. 

It has to know what the target version is anyhow since it checks to make sure you can only install when the target is 10.5, 10.6, or 10.7.  This was why I was asking some time back about what should be the valid targets for these updaters.

My bad; I need to learn to read.

If I understand correctly (doubtful) your script builds on and for the host machine? if so then people would need the developer tools installed.

The whole idea behind making a package installer is that you (one who can use the script and has the dev tools) could build and give the installer away to others that don't have the dev. tools.

However, this now did bring up a concern of only I just thought of.  My preflight/postflight/InstallationCheck installer scripts are bash scripts that  of course use a few commands.  Since I never had a system that I didn't install the dev. tools I am not sure what is and what is not in a base system without the dev. tools.

Here's a list of the commands the scripts use (I think I caught them all).  Do you (or anyone reading this) know if these are always installed without the dev tools installed?  I would of course have to try to make adjustments to these scripts if some are not available.

/bin/ps

/usr/bin/grep

/usr/bin/fgrep

/bin/rm

/bin/launchctl (duh! we know that's got to be in there)

/usr/bin/touch

/usr/bin/sw_vers

/usr/bin/wc

/usr/bin/uname

/bin/echo

I just installed developer tools on the external boot drive (to help you with testing) so hopefully someone else can help.

Thanks.

FWIW as for my question about whether or not the tools the script's package installer uses are in a OSX installation without the xcode dev. tools, curiosity got the best of me.  But I didn't want to install a fresh system.  So I pulled out my old 10.6.4 installer dvd and started exploring it with Pacifist.  It turns out all the commands I use are in a standard installation (whew!) so no xcode dev tools would be required to use the ntp installers.

Not that anyone would really care but for future reference (in case anyone with a similar problem cares in the future and finds this thread) here's the installer packages I found the tools I use in the installer dvd (package name on the left and I reorganized my list of commands to group them by directlory):

Essentials.pkg  /usr/bin/fgrep

Essentials.pkg  /usr/bin/grep

Essentials.pkg  /usr/bin/sw_vers

BaseSystem.pkg  /usr/bin/touch

Essentials.pkg  /usr/bin/uname

BaseSystem.pkg  /usr/bin/wc

 

BaseSystem.pkg  /bin/echo

BaseSystem.pkg  /bin/launchctl

BaseSystem.pkg  /bin/mv

BaseSystem.pkg  /bin/ps

BaseSystem.pkg  /bin/rm

I don't think think these two packages are optional in a OSX install (based on their names) and I also assume this is almost certainly the same on 10.5 and 10.7.

For what it is worth, the 10.5 installer has all these files in exactly the same places

Any luck?

With what?  The testing?  If so, yes.  It all appears to be working on my test boot volume (using the ntp beta5).  Backups, restores, installs, and installer packages (for both backups and new versions) all seem to work.  Building has always worked since I didn't need a separate test boot volume to debug all that.

But as usual, I can't leave the thing alone.

After noticing how I was actually using my script's command line options in real use (as opposed to just testing all the functions).  I realized I had made the options overly and unnecessarily complicated (in their relationships to each other) and somewhat confusing.  So as we speak I am in the process of simplifying them.  This is basically "front end" stuff while the actual machinery (the code that uses the options) doesn't need changing too much.

Of course after all the option handling changes I need to go back and change all the documentation.  Hope to do that tonight.  Doing the documentation also helps me clarify my thinking on how these options relate to each other.  I sort of suspected I was making things too complicated when I documented what I had.  It just didn't "feel" right even then.

No rush;

what is it they say about "act in haste, repent at leisure"