The new M1 powered Apple Macs have arrived, at least the first models, and they are genuinely amazing. All the reviews have nothing but good things to say about them - the laptops have great battery life and blazing performance and the new Mac Mini runs cool and quiet while packing more punch than any Intel based Mac (so long as you only need 16GB RAM for your workload!). Not only do native arm64 apps run crazy fast but the Rosetta 2 translation environment runs x86 apps so well that most people wouldn't even notice they're not native.
I can definitely see one of these in my future, but I'm holding off just a bit while the world catches up. Not all my environments are set up for arm64 and it will take a bit of time for everything to come across and work. I don't really need more than 16GB RAM but as the later laptops and Minis are released I'm sure they'll support more so I may just end up buying a Mac with more anyway. It has got me keen to install the aarch64 (which is just a different name for the arm64 instruction set that Apple now uses) version of Linux on one of my Raspberry Pi 4's (probably Raspberry Pi OS or Ubuntu) and have a play - I'm currently compiling packages for a few apps for armhf to run on the 32 bit version of Raspbian and it would be good to play with some 64 bit arm code.
One thing that has got me excited about the new Macs are what they will do to the overall ecosystem outside of macOS - this will probably be a big kick to the Windows ARM efforts, and once Dell and HP see sales going to other OEMs who will be making faster and longer lasting laptops they'll also jump on the bandwagon. Intel will have to adapt to survive (and don't forget they're getting squeezed from the bottom by consumer ARM chips and at the top end by beastly 80 core (soon to be 128 core!!) ARM server chips) so it will be interesting to see what they manage to come up with. They've had it too good for too long so this new Apple Silicon is just the shot in the arm the industry needs to really start innovating.
The future is bright and ARM powered!
For a while I've had an issue on my OwnCloud install when I open a PDF or document the browser often sits for 15 seconds before loading the file. During this time I noticed the load going up on the server and checking running processes I could see that Apache was saving a core dump, so had obviously crashed. Checking through the apache error log I could see multiple entries at the same time as the crash occurred like this:
The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.After a bit of googling it turns out I was seeing this error due to a library being used by apache having been compiled against the Core Foundation API. Some more googling turned up the "nm" command which you can use to list the symbol table of libraries, then grep for CF to see if they use the Core Foundation API. Checking the Apache module directory (nm -go /usr/libexec/apache2/* | grep CF) turned up a few modules that use the CF API but nothing that was currently being loaded, so I turned my attention to other libraries that get used by PHP by checking all libraries passed during the --configure stage. After much searching it turns out the freetype library supplied by OS X uses the CF API and I was including this library in my PHP compilation:
$ nm -go /usr/X11/lib/libfreetype.* |grep CF /usr/X11/lib/libfreetype.6.3.16.dylib:single module: U _CFRelease /usr/X11/lib/libfreetype.6.3.16.dylib:single module: U _CFStringCreateWithCString /usr/X11/lib/libfreetype.6.dylib:single module: U _CFRelease /usr/X11/lib/libfreetype.6.dylib:single module: U _CFStringCreateWithCString /usr/X11/lib/libfreetype.dylib:single module: U _CFRelease /usr/X11/lib/libfreetype.dylib:single module: U _CFStringCreateWithCStringOne solution would be to simply omit freetype from the compilation, though I'm not sure what other implications this would have on the PHP module produced. A better solution is to compile libfreetype *without* the Core Foundation APIs, and this turns out to be very simple:
curl -O http://download.savannah.gnu.org/releases/freetype/freetype-2.5.3.tar.gz tar -zxvf freetype-2.5.3.tar.gz cd freetype-2.5.3 ./configure make sudo make installDoing this installs freetype into /usr/local so we don't mess with the system included libraries. Then we simply compile PHP following this guide but replacing the configure option "--with-freetype-dir=/usr/X11R6" with '--with-freetype-dir=/usr/local". Once the module is installed there were no longer any pauses when opening PDFs and I've yet to see that error again in the Apache error logs!
The Shell Shock bash vulnerability that has been doing the rounds lately will never be patched on OS X Leopard as it is simply too old. Luckily Matt White has posted a fix for Debian Lenny and as Leopard and Lenny use the same version of Bash (3.2) the same fix can be applied. I've tweaked his update script for Os X (as by default there is no "wget" or "seq" (sequence) so simply download it from here, mark it executable (chmod +x) and run it to upgrade the version installed to 3.2.54 which includes the needed patch.
Your old version will be saved as /bin/bash.broken and the new version will be installed into /usr/local/bin/bash and a symlink created from /bin/bash to it Updated: The script now simply overwrites the old version as having it hanging around could be considered dangerous. If you want to keep a copy then you'll need to manually copy it somewhere safe (eg /var/root/). The script also now removes /bin/sh and creates a symlink to /bin/bash. Once installed simply log out and back in again and you'll be using the new version, and any CGI-BIN scripts you use will also be safe (well, at least from that bug!).
Happy patching and let's hope that it is a long time before a vulnerability like that crops up again.
UPDATE: A few people have asked if they can have a copy of the binary as they don't have the build tools installed. The latest version can be downloaded from here (PPC ONLY! I don't have an Intel install of 10.5 sorry), once downloaded you'll need to mark it executable and copy it to /bin/bash
UPDATE 2: I've just had pointed out to me that /bin/sh on Leopard is actually a copy of /bin/bash, not a symlink so calling /bin/sh will still leave your system vulnerable. To get around this either copy /bin/bash to /bin/sh or better yet symlink /bin/bash to /bin/sh so updates to bash will also result in /bin/sh being updated. Finally, I've changed the script to simply replace /bin/bash rather than install into /usr/local/bin/bash and symlink.
UPDATE 3: And another patch is out - binary has been updated and is available here or for those with the build tools installed you can compile from source using this script. Hopefully this is the last for a while as it addresses all currently outstanding CVEs.
Since the release of the Shell Shock bug for Bash I thought I'd compile all the fixes I've done for OS X into my updating OS X Leopard for the modern world document as I'm now running a newer version of OpenSSL, PHP, ClamAV etc. The old doc (using php 5.3) can be found here though as PHP 5.3 has been discontinued you should no longer refer to that document.
As part of the modernising of my Leopard install I thought I'd upgrade to the latest ClamAV (the antivirus software that comes with Leopard Server). This isn't strictly necessary as the updates will still work with older versions of ClamAV but it is still good to have the latest version running. Thankfully this is a really easy upgrade and still works perfectly with Server Admin (so will start when starting email etc).
Firstly stop email while you install the new version (stopping email isn't strictly needed but it's a good way of unloading the running ClamAV) then grab the latest ClamAV stable release from clamav.net (0.97.8 at the time of writing) and unpack it somewhere. Thanks to the "clamconf" tool that comes with ClamAV I was able to see the configure options used by Apple to build the software, so we simply run this to set it up for our system, then make, then make install:
$ tar -zxvf clamav-0.97.8.tar.gz $ cd clamav-0.97.8 $ ./configure '--prefix=/' \ '--exec-prefix=/usr' \ '--bindir=/usr/bin' \ '--sbindir=/usr/sbin' \ '--libexecdir=/usr/libexec' \ '--datadir=/usr/share/clamav' \ '--sysconfdir=/private/etc' \ '--sharedstatedir=/private/var/clamav/share' \ '--localstatedir=/private/var/clamav/state' \ '--disable-dependency-tracking' \ '--libdir=/usr/lib/clamav' \ '--includedir=/usr/share/clamav/include' \ '--oldincludedir=/usr/share/clamav/include' \ '--infodir=/usr/share/clamav/info' \ '--mandir=/usr/share/man' \ '--with-dbdir=/private/var/clamav' \ '--disable-shared' \ '--with-user=_clamav' \ '--with-group=_clamav' \ '--with-gnu-ld' \ '--enable-static' \ '--enable-ltdl-convenience' $ make $ sudo make installThat's it! You should now have the latest ClamAV installed. To start using it simply start email, or load it from the shell:
$ sudo launchctl load /System/Library/LaunchDaemons/org.clamav.clamd.plist $ sudo launchctl load -w /System/Library/LaunchDaemons/org.clamav.freshclam.plistCheck the freshclam log (/var/log/freshclam.log) and you should see the new version being loaded.
So after finally getting PHP 5.3 compiled and installed it looks like it's being end-of-lifed:
"Please Note: This will be the last regular release of the PHP 5.3 series. All users of PHP are encouraged to upgrade to PHP 5.4 or PHP 5.5. The PHP 5.3 series will receive only security fixes for the next year."
Rather than wait for support to end I thought I'd move to the next version, 5.4. Compiling PHP 5.4 on Leopard Server isn't too much harder than 5.3 but it does seem to trip up over OpenSSL versions - 5.4 needs OpenSSL version 0.9.6 or higher and Leopard ships with version 0.9.71 so it should be fine but I found that while it passed the "./configure" stage it failed when linking, giving errors right at the end of the "make" stage:
Undefined symbols: "_EVP_sha224", referenced from: _php_openssl_get_evp_md_from_algo in openssl.o "_EVP_sha256", referenced from: _php_openssl_get_evp_md_from_algo in openssl.o "_EVP_sha384", referenced from: _php_openssl_get_evp_md_from_algo in openssl.o "_EVP_sha512", referenced from: _php_openssl_get_evp_md_from_algo in openssl.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1It seems to be because though the version of OpenSSL included is higher than needed it gets a bit confused by the version number (0.9.71 rather than 0.9.7.1 I guess?). The fix is to edit /ext/openssl/openssl.c (from the root of the php 5.4 tarball) and change the three instances of
#if OPENSSL_VERSION_NUMBER >= 0x0090708fLwith
#if OPENSSL_VERSION_NUMBER >= 0x0090808fLThe 0x0090808fL isn't super important, it can be any value as long as it's above 0x00908. This disables some features (such as certain SSL algorithms) that OpenSSL 0.9.71 doesn't support. Once that file is changed you can kick off "make" again and it should complete without errors (following the guide for 5.3 here for configure options and support libraries - note that you no longer need the "-lstdc++" fix for ICU). If you're going to use APC (which you really should!) you need to run at least version 3.1.13 to work with PHP 5.4, the same configure options as used for version 3.1.9 can be used.
UPDATE: Just realised that the version of OpenSSL shipping with Leopard is 0.9.7l (with a small "L", not a number "1") so no idea why you need to hack the source file to get it to compile.
I've written a Howto on installing and patching OS X server on an Xserve G5. I'll probably keep adding to the Howto over time as I discover new things that need updating. If you're using a newer Intel Xserve then this howto will still work of course if you're running an older version of OS X Server, but to be honest seeing as Server is so cheap in the app store you're probably better off simply updating if you can :-)
Anyway I hope you find it useful - let me know if anything doesn't work for you!
It couldn't last - I've just got rid of my last PowerPC computer (previously I've also owned a PPC Mac Mini and the mighty dual processor Quicksilver G4 PowerMac) about a month ago and I've gone and bought myself another one - this time an old G5 Xserve!
I've sorted out some very cheap colo storage for a 1U server so I needed something to put in there. It didn't have to be particularly fast as it will be mainly used for offsite rsync backups from my house and my brother's business but it did need to use SATA drives as these are way cheaper than SCSI when it comes to bulk storage. I was going to use an old HP DL360 G4 with twin SATA disks when I found the Xserve going cheap, so snatched that up.
It's a single processor 2.0GHz model with only 1GB RAM and my original plan was to put three 2TB SATA drives in it and install debian Linux across the top in a RAID 5. Turns out the server only has 2 drive caddies so I'm trying to find another one here in NZ which is proving problematic (there are a few on ebay but with shipping to NZ it gets quite expensive, nearly the same cost as a 2TB SATA disk). It also has no graphics card in it (a headless server, the graphics card was a build to order option on this model) which makes installing Linux on it a bit harder than it should be as I need to run the install over serial console.
While I scrounge around for another caddy I've installed OS X Server 10.5 on it (as OS X only supports software RAID levels 0 and 1 it doesn't really matter that I've only got two disks in it) which proved surprisingly easy as OS X is set up to start a VNC session with the machine's serial number as it's password if it detects there is no keyboard/mouse/display attached - if I can't find another caddy (or get Linux installed via serial console) I'd be tempted to leave OS X installed on there as I really only need SSH and a mirrored RAID both of which OS X provides.
And if nothing else, at the end of the day it looks pretty cool in the rack surrounded by the SuperMicros and HPs that sit above and below it :-) Now all I need to do is track down some more DDR PC3200 ECC RAM for it...
Well I've finally been dragged kicking and screaming into the new Mac era - I've gone and bought myself a 15" Retina Macbook Pro! A whole world of Intel only software is now available for me, not to mention the fact that I'm now getting security updates again for the first time since 2011 :-)
The biggest first impression (coming from a 12" PowerBook here remember!) is the size of the thing - it is super thin, yet very wide and deep when closed. Luckily my courier bag just fits it (it is designed for a 13" MacBook but the retina one is so slim it just squeaks in). The next thing you notice is how well made it is - a single smooth chunk of aluminium milled out with a glass fronted screen, this thing screams quality (and well it should for the price I paid...). Once powered on the thing that really jumps out at you is the font quality - that retina screen is *so crisp* the fonts seem to float on the surface. Seriously, I've never seen typography look so stunning! I've been using it now for about 10 hours and it still amazes me how good fonts look. Going back to anything else after this is gonna be really hard.
Mountain Lion will take a bit of getting used to after using Leopard for so many years, but I already love the gestures built into it, it actually reminds me a lot of using a cell phone swiping apps from screen to screen. Not sure I'm totally sold on the new "Mission Control" way of doing desktops in a row (I liked the old cube set up from Leopard) but it is easy enough to use so I'm sure I'll get used to it pretty quickly. Plus, with such a massive screen resolution I don't need so many virtual desktops anyway!
Anyway, I'm off to play BioShock now (been waiting a few years for this as I've not had a computer capable of running it!) so I'll report back after a few days of using it. So far I love it!
UPDATE: After using this for a few days every other monitor is now ruined for me - all font looks blocky and and you can clearly see the antialiasing. I now need to buy a thunderbolt cinema display I guess...
It's been out for a while but I've only just discovered Leopard WebKit, a modern build of the WebKit open source rendering engine for Leopard. Safari is built upon WebKit but Apple stopped updating Safari for OS X Leopard mid 2011 and with the web being what it is you'd be mad to browse using that now as many security vulnerabilities have been discovered meantime.
Well now with Leopard WebKit you can keep using Safari but with all the current security patches applied. What the devs have done is take the last PowerPC build of WebKit and selectively applied the patches written since to bring the browser up-to-date security (and feature) wise. It doesn't actually replace Safari, rather when you launch it it starts Safari but uses Leopard WebKit as the rendering engine.