Dear Fellow OS X Server Geeks,
Just a heads up that I have updated my earlier posts about gaining access to Apple’s Profile Manager PostgreSQL database. The commands therein now work on Mavericks.
If you’ve upgraded from OS X Server 2.0 on Mountain Lion, you’ll have to open up remote access from scratch. Data is retained (flawlessly in my case), but the PostgreSQL instance has been moved and a new database (with a new name) created beside the old one.
Virtual hugs,
Me
If you use Mail.app on OS X Mavericks, there’s a good chance you already know this, but if not: Apple have just updated it.
Much has been made of Gmail not working under Mail.app on Mavericks, but for those of us who use it with Exchange, it’s been a similar story (with less rage). I’m happy to report that the latency/timeout/crash problems I was experiencing with Mail.app and Exchange 2010 appear to be resolved with this update.
And there was much rejoicing!
It’s been a big morning for Apple punters: OS X Mavericks, new iPads, iOS 7.0.3 and a bunch of new apps.
The only downside (aside from the “later in November” ETA on the Retina iPad Mini) is the downloading involved. Mavericks is ~5.5GB, and with 4 machines to upgrade [just in my house – there are a bunch more at work], downloading through the App Store each time would be painful.
As usual, Apple haven’t made it TOO easy to download-once-install-many (you can’t just restore a DMG onto an install partition anymore), but at least there’s an install media console utility built into the Install OS X Mavericks app.
Here’s how you use it:
sudo /Applications/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia --volume /Volumes/Untitled --applicationpath /Applications/Install\ OS\ X\ Mavericks.app --nointeraction
Android: less “open” every day
Click through for a thorough and insightful commentary on Google’s move towards “closed source” with Android. There’s some eye-opening stuff on the so-called “Open Handset Alliance”, too.
Things are much more straightforward over here in Apple-land.
Update (22 December 2014): The following instructions have been updated and tested with iOS 8.
Right now, my challenge is upgrading almost 200 iPads to iOS 7 with minimal pain (read: zero device handling). Factor in less-than-ideal Internet bandwidth and Apple’s disinterest in allowing proxies to cache iOS updates, and it’s been a bit of a headache.
First, a word of advice: ask your users not to upgrade when prompted. Do this before Apple release a major update, to buy yourself some time to test it on your network and to check that the update is being cached properly.
Hopefully your iPad fleet is already using your Squid proxy. Ours is configured (via Apple’s Profile Manager) to use a PAC file when it’s on our WiFi network. The PAC file directs all but onsite requests to Squid.
Unfortunately, iOS doesn’t use the proxy for everything; system update authorizations, in particular, don’t get out unless permitted on your firewall. Here’s the relevant rule on our iptables firewall (no_proxy_ok is one of our custom chains, as is tcp_allowed):
-A no_proxy_ok -p tcp -m comment -m tcp -m multiport -d 17.0.0.0/8 -j tcp_allowed --dports 80,443,5223,2195,2196 --comment "allow Apple services (e.g. APNs, updates)"
Mercifully, the update itself is requested via the proxy, but getting it to cache is non-trivial. Obviously max_object_size needs to be big enough to accommodate a 1GB+ file. I went with 2GB:
maximum_object_size 2048000000 bytes
But this wasn’t enough to get the update to cache. A bit of sleuthing led to the first problem: Apple adds HTTP headers like these to its updates, so Squid discards them:
Cache-Control: max-age=0, no-cache, no-store Pragma: no-cache
The workaround is to break HTTP a little by adding this line above any other refresh_pattern entries in your squid.conf:
refresh_pattern -i appldnld\.apple\.com 129600 100% 129600 ignore-reload ignore-no-store override-expire override-lastmod ignore-must-revalidate refresh_pattern -i phobos\.apple\.com 129600 100% 129600 ignore-reload ignore-no-store override-expire override-lastmod ignore-must-revalidate
This forces Squid to treat objects from *.appldnld.apple.com and *.phobos.apple.com as “fresh” (i.e. cacheable) for 90 days (129600 minutes), no matter what appldnld.apple.com and phobos.apple.com say.
Finally, I made sure appldnld.apple.com requests were excluded from Squid’s delay pools and filtering ACLs; you may need to make similar tweaks. I also found that maximum_object_size wasn’t being applied correctly to cache_dir, so I defined it explicitly, i.e.:
cache_dir aufs /var/spool/squid3 256000 128 256 max-size=2048000000
iOS 7 is rolling out smoothly as I type.
I don’t do a lot of desktop publishing, but when I do, my tool of choice is Serif PagePlus. It’s affordable, fast, stable, intuitive, EPS-friendly and capable of producing press-ready output (i.e. CMYK PDFs with bleed). The usual suspects (Adobe InDesign, QuarkXPress, Microsoft Publisher) all fail to meet 2 or more of those requirements.
But PagePlus only runs on Windows, and I’m not spending much time on Windows these days. Pixelmator and iDraw are excellent for bitmap and vector editing respectively, but iStudio Publisher is still missing a few features it needs to cut the mustard as a serious DTP app.
So I’ve been experimenting with Scribus, which is open-source, cross-platform and (surprisingly) well-documented. Being Qt-based, it’s not as snappy as PagePlus, but it’s usable on slower machines and meets all of my other requirements.
I’ve only found one catch so far: when exporting to PDF, its font outlining is slightly inaccurate (text looks heavier than it should, at least when using Avenir LT’s OpenType fonts). And it can’t embed OpenType fonts. There’s a workaround, though: export from Scribus without outlining or embedding any fonts, then use Ghostscript to do the embedding afterwards. Here’s a little BASH script that looks after it on OS X:
#!/bin/bash
if [ $# -ne 1 ]; then
echo "Usage: embed_fonts.sh MyPdf.pdf"
exit 1
fi
if [ ! -f "$1" ]; then
echo "Not a file: $1"
exit 1
fi
command -v gs >/dev/null 2>&1 || { echo "Ghostscript not found."; exit 2; }
TEMPFILE="$(dirname "$1")/nofonts.$(basename "$1")"
mv -vf "$1" "$TEMPFILE"
FONTPATH=/Library/Fonts:~/Library/Fonts
gs -sDEVICE=pdfwrite -sFONTPATH=$FONTPATH -dPDFSETTINGS=/prepress -dAutoFilterColorImages=false -dAutoFilterGrayImages=false -dColorImageFilter=/FlateEncode -dDownsampleColorImages=false -dDownsampleGrayImages=false -dDownsampleMonoImages=false -dGrayImageFilter=/FlateEncode -o "$1" "$TEMPFILE"
Updated on 6-Nov-13 for OS X Server 3.0 on Mavericks
My last post was about getting access to OS X Server’s Profile Manager database; this post is about doing something useful with it.
Hypothesis: given live access to data from Profile Manager and Active Directory, it should be easy to write a Squid external_acl_type helper that maps incoming IP addresses to usernames. An optional check for group membership? Trivial. Amirite?!
I was half-right. The lookups weren’t hard, but getting the helper to terminate when Squid wanted it to, and to NOT terminate prematurely, required a little trial-and-error. Turns out Squid keeps its helpers alive by sending them empty lines, so terminating on empty input isn’t such a good idea.
Anyway, here’s the code that has our iPad fleet “authenticating” with our Squid proxy server transparently. It’s been tested on Linux (Ubuntu 12.04 LTS) and OS X. Yes, Python would have been better than PHP, but I’m more fluent in PHP, and the PHP CLI interpreter is efficient enough for this purpose.
Update 23-Dec-2014: this script is now hosted on GitHub.
To use it in squid.conf (assuming you’ve pulled it down to /opt/git/extensions/squid/external_auth.php):
external_acl_type external_auth ttl=300 negative_ttl=5 children-startup=10 children-max=40 children-idle=10 ipv4 %SRC %MYPORT /opt/git/extensions/squid/external_auth.php acl Apple_Devices external external_auth acl Staff_Apple_Devices external external_auth staff acl No_Filter_Devices external external_auth no_filter acl No_Access_Devices external external_auth no_access
The “staff”, “no_filter” and “no_access” values map to $SQUID_LDAP_GROUP_DN in the configuration file – customise as needed (many groups may be defined).
Finally, use your new acls in some access rules, e.g.:
http_access allow localnet Staff_Only_Websites Staff_Apple_Devices http_access deny localnet Staff_Only_Websites Apple_Devices
Questions? Errata? Do comment.
Updated on 6-Nov-13 for OS X Server 3.0 on Mavericks
Let’s say you’re running the MDM software Apple ship with OS X Server, Profile Manager. (You’ve chosen this because you don’t really need the fancy features of Casper and friends.)
Let’s say you’re also running other services that would benefit from live access to Profile Manager’s device metadata, e.g. a Squid proxy that implements MAC-based iOS authentication (because proper proxy authentication has been broken on iOS since forever). “An external_acl_type that could check enrolled device MAC addresses be super-awesome!” you say to yourself.
Where to start?
Turns out, Profile Manager data lives in an embedded PostgreSQL database, and opening it up for remote access is relatively straightforward.
First, you’ll need to modify /Library/Server/ProfileManager/Config/PostgreSQL_config.plist (note: this path has changed in Server 3.0) to enable access over TCP/IP (by default, postgres only listens on a UNIX socket). Edit the existing listen_addresses= entry, and add the last two lines:
<string>-c</string> <string>listen_addresses=OSX_SERVER_LAN_IP</string> <string>-c</string> <string>port=5432</string>
Note: Server 3.0 creates multiple instances of PostgreSQL, one for each service that depends on it, all on different UNIX sockets. Just in case another instance opens PostgreSQL for TCP connections on localhost, I recommend binding the Profile Manager instance to a LAN-facing IP. Alternatively, you could use a non-standard port.
Then tell postgres that any host on your network is allowed to connect with an encrypted password, by adding a line like this to /Library/Server/ProfileManager/Data/PostgreSQL/pg_hba.conf (note: changed in Server 3.0):
host all all 192.168.0.0/16 md5
Almost done! Now you just need to set up a postgres user to connect as. Start by opening a psql session:
sudo -u _devicemgr psql -h /Library/Server/ProfileManager/Config/var/PostgreSQL devicemgr_v2m0
(This entire command has changed in Server 3.0; note particularly the new database name.)
Then you’ll probably want to run a couple of commands like:
CREATE USER squid WITH PASSWORD 'XXXX'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO squid;
If you want to create a more privileged user:
CREATE USER dbadmin WITH PASSWORD 'XXXX'; GRANT ALL ON ALL TABLES IN SCHEMA public TO dbadmin; GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO dbadmin; GRANT ALL ON ALL FUNCTIONS IN SCHEMA public TO dbadmin;
Reboot the server and test with pgAdmin or some other PostgreSQL admin tool.
Oh, and don’t blame me if you break your Profile Manager, or Open Directory, or your entire OS X Server.
stratēchery on Microsoft’s restructure
Before reading this piece, I didn’t have an opinion on Microsoft’s restructure, nor did I consider it especially significant.
I still don’t have an opinion, but at least I understand why it’s probably going to damage Microsoft in the long-term.
He didn’t just have an awesome name.
He was responsible for much of the innovation and vision that saw technology become what it is today.
Vale.