For those of us who manage large iPad deployments (and would prefer iOS 8 to be installed by end-users), this is a problem. Potentially a multiple-terabytes-through-a-finite-pipe problem.

Thankfully the Squid hack I figured out during the iOS 7 launch works with iOS 8 too. Otherwise we’d be in trouble.

The post OS X Server doesn’t cache iOS 8 appeared first on luke arms.

Or you could just download my macOS-ready mssql.so (compiled for PHP 5.6.30 on macOS Sierra 10.12.6) and skip to the end. (18 Aug 2017)

Previous versions are available below.

Prerequisites

• Xcode with command line tools (these are installed when you first run Xcode)
• Latest autoconf source from http://ftp.gnu.org/gnu/autoconf/ (or Homebrew installed)
• Latest FreeTDS source from http://www.freetds.org/ (or Homebrew installed)
• Source for the same version of PHP that ships with macOS (5.6.30 on macOS Sierra 10.12.6; run `php -v` from a terminal if unsure)

Build and install autoconf

If you’re a Homebrew user, brew install autoconf is easier than the following.

$ tar zxf autoconf-latest.tar.gz 
$ cd autoconf-2.69
$ ./configure 
$ make
$ sudo make install

Build and install FreeTDS

FreeTDS is on Homebrew too: brew install freetds

Alternatively:

$ tar zxf freetds-patched.tar.gz
$ cd freetds-1.00.54
$ ./configure 
$ make
$ sudo make install

Build and install mssql.so

Don’t worry, unlike some of the Internets will tell you, there’s no need to rebuild PHP itself. Nor do you need to write an essay after .configure.

Update (18 Aug 2017): phpize doesn’t seem to work out-of-the box anymore. If it can’t find the files it needs (you’ll see grep errors), try adding a symbolic link like this: sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/php/ /usr/include/php. System Integrity Protection will need to be disabled first.

Here goes:

$ tar zxf php-5.6.30.tar.gz
$ cd php-5.6.30/ext/mssql
$ phpize
$ ./configure --with-php-config=/usr/bin/php-config --with-mssql=/usr/local/
$ make
$ sudo cp modules/mssql.so /usr/lib/php/extensions/no-debug-non-zts-20131226/

If you have trouble with the final step, System Integrity Protection is probably enabled. Disable it temporarily.

Finally, add this line to your php.ini (probably in /etc/php.ini):

extension=mssql.so

And restart Apache if necessary.

Done!

Previous versions

If you’re running an old version of macOS, you might find one of these binaries helpful:

• mssql.so compiled for PHP 5.4.17 on OS X Mavericks 10.9 can be downloaded here. (17 Nov 2013)
• mssql.so compiled for PHP 5.4.24 on OS X Mavericks 10.9.4 can be downloaded here. (6 Jul 2014)
• mssql.so compiled for PHP 5.5.14 on OS X Yosemite 10.10.1 can be downloaded here. (22 Dec 2014)
• mssql.so compiled for PHP 5.5.27 on OS X Yosemite 10.10.5 can be downloaded here. (16 Sep 2015)

The post PHP with FreeTDS on macOS Sierra appeared first on luke arms.

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

The post Hacking Profile Manager on Mavericks appeared first on luke arms.

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.

The post Squid authentication via OS X Profile Manager and Active Directory appeared first on luke arms.

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.

The post Under the hood: OS X Server’s Profile Manager appeared first on luke arms.