It would be nice if OS X machines that downloaded patches via Software Update could make those patches available to other OS X machines on the same network. Especially since some of the patches nowadays are very large (the latest Leopard patch was a whopping 180MB) and it takes time and bandwidth away to do it.
Larger sites are served by running an OS X Server somewhere on the LAN, and running Software Update Server on it. Then you can either fake DNS entries or change client settings to have all your clients use the centrally downloaded patches.
But what about a small, client-only Mac network that a lot of people have at home? e.g. an Mac Mini and a couple of MacBooks. Perhaps there is a way for Macs to play nicely together if you've got things like Bonjour turned on (I don't), but alas, I've never come across it. Please let me know if there is a way.
In the meantime, I created a centralised patch directory on my LAN file server to save all the dowloaded patches to once one machine had done the hard work (using the "Install and Keep Package" option of Software Update). When selecting this option, the package is saved to /Library/Packages on Tiger and /Library/Updates on Leopard. I then copy the files over the network (I use rsync, but you could just as easily share the directory and mount it via AFP, SMB, NFS, etc), ready for download on the next Mac. If you were really adventurous, you could even try NFS mounting the directory as /Library/Packages directly on each machine... let me know if anyone does this and it works ok. :)
A further note here; I set all my Macs to not automatically download patches in System Preferences, and on all but the "primary" Mac I disable the automatic checking to see if patches are available. The idea is that I want to know patches are available on the primary Mac, and I will then "Install and Keep Package" for each patch and make sure it is saved to the network before going on to the next one. This I learnt the hard way, in that on my Leopard MacBook it seems to want to clear out /Library/Updates between reboots for some reason... I haven't had time to look into why.
I know what packages need to be downloaded on to the second and subsequent Macs by making sure the /Library/Packages directory is cleared on the primary Mac once all the patching is done. Then when new patches are available, I just get the directory listing from /Library/Patches to know which ones to copy over to every other Mac (then delete and clear this directory again, etc). You need to do this as some patches (e.g. iTunes) are just saved as a package like "iTunesX.pkg" in the directory. Each new version of iTunes gets saved over the top of this package. The last modified time of this top level directory is usually unchanged, meaning that you can't tell a new iTunes patch is available just by looking at the date stamp.
It's also a shame that Software Update doesn't seem to look at /Library/Packages automatically for you to see if you've already downloaded the patch. It keeps it's own (per-user) cache files for downloads and ignores this central directory for some reason, even though it gives you the option of keeping the patch here after installation. Not very user-friendly, is it?
Let me know if you've got a better way of keeping your small home network of Macs patched without repeatedly downloading patches. Oh, and before you suggest just caching the patches in a small home network proxy server (also suggested in the macosxhints.com thread above), I already do. :) However, this relies on changing settings on your proxy server to accommodate some rather large files that you mightn't otherwise want to do. And it isn't fool-proof... for some reason (probably related to the delay in between patching machines) I've had Macs on my network download the same patch twice, even though the first download should have been cached. Besides, the whole "play with Squid" route to do this starts to just get too complicated, especially when it seems like it should be very easily handled via file sharing or support within OS X itself....
Monday, 25 February 2008
Tuesday, 19 February 2008
Qt and MySQL plugin issues
Lately I've been playing with a recipe management application called krecipes. I had used the FreeBSD port in the past, but I really wanted to run it locally on various Macs that I have and have them all connect back to the central recipe database on the FreeBSD server.
And so I needed to venture into the mess that is the current Mac open-source ports/packaging system. I say "system" (singular) deliberately; I well know there are many options available in this space, but there really shouldn't be. Good operating systems tend to really only have one system that everyone uses to install and manage open-source software so that effort is not duplicated unnecessarily (which is exponential due to the thousands of applications that need to be tracked in any packaging system). Any gripes with how the current system works should be sorted out within that system and let it evolve over time rather than splitting off yet another effort to do ports/packages "a better way".
Apart from the aforementioned waste of effort by port maintainers, it's just down right confusing for users (even experienced ones). The Mac is a perfect example. It has one of the best application management systems from a end-user point of view (drag and drop to install and delete - how easy is that!) and any system that provides access to open-source software should try and be that easy as well. But if you want to tread in this space you are met with a bewildering array of options; Fink, DarwinPorts, MacPorts, RPM on MacOS X, and it wouldn't surprise me if there are others as well.
I think there may be some link between DarwinPorts and MacPorts, but quite frankly, that proves my point about how confusing it is. These sites exist, various people advise using them for different reasons, and there really isn't any definitive advice on which one you should use. The web sites for these systems are universally bad as well - there just isn't clean information on any of them about why you should use their system and what the key differences are between the systems. Unless you want to spend hours and hours researching the history of these systems you're really left in the dark. And quite frankly the whole point of these systems is to save you hours and hours and not force you to waste hours and hours.
Ok, rant finished. :) For some reason in the past I had actually installed Fink on my test Mac, so I started there. As it turns out, this is the only system which has a port for krecipes anyway... *sigh* Unfortunately, it's been setup to compile and link against an older version of Qt (3.3) that compiles as multi-threaded (good), but the sub-port for the MySQL plugin compiles as single-threaded (bad). So krecipes doesn't work and spits out the following error message as expected:
Conflict in /sw/lib/qt3/plugins/sqldrivers/libqsqlmysql.so:
Plugin uses single threaded Qt library!
After no response from the port maintainer in 1-2 months (what a surprise) I decided if I had time I would wade into the mess to see if I could hack it to make it work. Just as a side note, I noted that DarwinPorts had an up to date Qt port and MySQL driver, but no krecipes port - see my note above about wasted effort.
Anyway, I found that the plugin needs
CONFIG += thread
when it's compiled. So I extracted the Qt source back into /sw/lib/qt3/src with the aim of just compiling the driver again and over-writing the one that was installed by the port. Compiling was relatively easy once instructions were found, the thread directive from above added, and some questionable advice was also found on how to get rid of a compile error I was getting about the "sql" module not being available. :)
It sounds so easy, but you have no idea how long it took to work all this out. Good news is that krecipes now works locally for me, but the bad news is that I now have to remember this custom hack as the next upgrade of Qt-MySQL driver within Fink is probably going to break things all over again.
Please send me a link if anyone has found a good page that summarises and reviews the current Mac ports and packaging systems...
And so I needed to venture into the mess that is the current Mac open-source ports/packaging system. I say "system" (singular) deliberately; I well know there are many options available in this space, but there really shouldn't be. Good operating systems tend to really only have one system that everyone uses to install and manage open-source software so that effort is not duplicated unnecessarily (which is exponential due to the thousands of applications that need to be tracked in any packaging system). Any gripes with how the current system works should be sorted out within that system and let it evolve over time rather than splitting off yet another effort to do ports/packages "a better way".
Apart from the aforementioned waste of effort by port maintainers, it's just down right confusing for users (even experienced ones). The Mac is a perfect example. It has one of the best application management systems from a end-user point of view (drag and drop to install and delete - how easy is that!) and any system that provides access to open-source software should try and be that easy as well. But if you want to tread in this space you are met with a bewildering array of options; Fink, DarwinPorts, MacPorts, RPM on MacOS X, and it wouldn't surprise me if there are others as well.
I think there may be some link between DarwinPorts and MacPorts, but quite frankly, that proves my point about how confusing it is. These sites exist, various people advise using them for different reasons, and there really isn't any definitive advice on which one you should use. The web sites for these systems are universally bad as well - there just isn't clean information on any of them about why you should use their system and what the key differences are between the systems. Unless you want to spend hours and hours researching the history of these systems you're really left in the dark. And quite frankly the whole point of these systems is to save you hours and hours and not force you to waste hours and hours.
Ok, rant finished. :) For some reason in the past I had actually installed Fink on my test Mac, so I started there. As it turns out, this is the only system which has a port for krecipes anyway... *sigh* Unfortunately, it's been setup to compile and link against an older version of Qt (3.3) that compiles as multi-threaded (good), but the sub-port for the MySQL plugin compiles as single-threaded (bad). So krecipes doesn't work and spits out the following error message as expected:
Conflict in /sw/lib/qt3/plugins/sqldrivers/libqsqlmysql.so:
Plugin uses single threaded Qt library!
After no response from the port maintainer in 1-2 months (what a surprise) I decided if I had time I would wade into the mess to see if I could hack it to make it work. Just as a side note, I noted that DarwinPorts had an up to date Qt port and MySQL driver, but no krecipes port - see my note above about wasted effort.
Anyway, I found that the plugin needs
CONFIG += thread
when it's compiled. So I extracted the Qt source back into /sw/lib/qt3/src with the aim of just compiling the driver again and over-writing the one that was installed by the port. Compiling was relatively easy once instructions were found, the thread directive from above added, and some questionable advice was also found on how to get rid of a compile error I was getting about the "sql" module not being available. :)
It sounds so easy, but you have no idea how long it took to work all this out. Good news is that krecipes now works locally for me, but the bad news is that I now have to remember this custom hack as the next upgrade of Qt-MySQL driver within Fink is probably going to break things all over again.
Please send me a link if anyone has found a good page that summarises and reviews the current Mac ports and packaging systems...
Thursday, 7 February 2008
OpenVPN on OS X
For some reason, most VPNs are approached from a user-level rather than a machine-level point of view. That is, most end-user VPN software assumes that a user has their own authentication mechanism (key, token, etc) and that they establish the virtual network over some other possibly untrusted network when they want to "connect".
But what about the concept of a machine that connects over a VPN? One that either connects on startup or when required and then all users have access to the VPN for certain traffic. It strikes me as odd that this isn't a more common requirement, as I think it has lots of uses, even to the end user. So it's a little disappointing that while you currently can set up machine-level VPNs it normally requires quite a bit of low level buggering around and tinkering. Just because I'm capable of it doesn't mean that I want to do it all the time...
Anyway, I've worked out some hacks that suit my purpose under OS X. They are available here for the enjoyment of all. Please let me know if you've got any feedback, improvements, etc. I'd love to hear from you.
But what about the concept of a machine that connects over a VPN? One that either connects on startup or when required and then all users have access to the VPN for certain traffic. It strikes me as odd that this isn't a more common requirement, as I think it has lots of uses, even to the end user. So it's a little disappointing that while you currently can set up machine-level VPNs it normally requires quite a bit of low level buggering around and tinkering. Just because I'm capable of it doesn't mean that I want to do it all the time...
Anyway, I've worked out some hacks that suit my purpose under OS X. They are available here for the enjoyment of all. Please let me know if you've got any feedback, improvements, etc. I'd love to hear from you.
Subscribe to:
Posts (Atom)