If I've upgraded PHP on my Mac, should I now avoid all OS X Updates?

September 3, 2013 11:00 PM

If I've upgraded PHP on my Mac, should I now avoid all OS X Updates? I'm hosting a website on a Mac mini in a datacenter, and some of my software required a newer version of PHP than what's included out-of-the-box in OS X Mountain Lion. I keep getting the notification saying system updates are ready, and restart to install. But I'm scared it's going to overwrite my PHP upgrades and break everything. And it took me an insanely long time to get the PHP upgrade to work properly and play nicely with OS X Server.
posted by ferdinandcc to Technology (25 answers total)

How did you install your upgraded PHP? Some distributions may overwrite the old PHP, others will not.
posted by vasi at 11:05 PM on September 3, 2013

What vasi said. If you're using a version of PHP outside of the standard system directory trees, you should be okay unless you have symlinks within the system tree (which isn't recommended).

FWIW, /usr/bin/php on my 10.8.4 (desktop) version is an August 2012 build of 5.3.15, and it doesn't look like it's been touched since Mountain Lion's release; Apple recommends that you don't touch the system binaries in any case.
posted by holgate at 11:25 PM on September 3, 2013

I followed these steps: http://mac.tutsplus.com/tutorials/server/upgrading-the-native-php-installation-on-os-x-mountain-lion/

Along with these steps for MySQL and phpMyAdmin: http://coolestguyplanettech.com/downtown/install-and-configure-apache-mysql-php-and-phpmyadmin-osx-108-mountain-lion

(I mention that because I'm sort of curious if running a software update will screw those up as well.)

I also tinkered with a bunch of stuff to get OS X to recognize this version of PHP, since I'm running OS X Server alongside it, and the Mac seemed to want to continue hosting files with the built-in PHP rather than the just-installed PHP 5.4.17. I'm not sure what I did that ended up getting it working, however. I'm really not all that technically-minded, just persistent, and a fairly decent Googler.
posted by ferdinandcc at 11:26 PM on September 3, 2013

Sorry, it looks like that process does indeed overwrite parts of Apple's PHP. It's the bits like "--prefix=/usr" that cause that to occur.

If Apple ever does update their PHP install, it will likely overwrite your changes in turn, and things may break. Also, unless you redo your installation procedure every time there's a PHP security update, you're probably running a version of PHP with known security holes. Yippee!

For future reference, if you don't really know what you're doing when installing Unixy software, you almost certainly want to use a package manager. For PHP on OS X, you could use homebrew-php, or you could use MacPorts, or one of the various binary "MAMP" packages people distribute, or even run Ubuntu in a virtual machine (my person choice). These should all (ideally) install the new PHP such that it doesn't interfere with Apple's version, and they should provide some way to periodically update your new PHP.

I don't know why there are so many ad-hoc, slightly-broken, never-updated guides around the interwebs for things like this on OS X. You'd think it'd make more sense for folks to team together and create well-maintained processes—but I guess everyone wants hits on their blog or StackOverflow points or something, so they all roll their own solution and repeat the same old mistakes. Congratulations on a lesson learned :(
posted by vasi at 11:55 PM on September 3, 2013

Yeah, those instructions replace the system installed PHP (which is a bad idea, as you have discovered). That said, if you were having trouble with it using the system PHP, then perhaps you somehow didn't actually replace the system installed PHP. So, you should check what's actually going on.

The best way I can think of offhand is to create a phpinfo() file and then look at the extension_dir parameter. Create a PHP file somewhere in your web site with the following contents:

<?php phpinfo();

Navigate to that file in your web browser, and search for extension_dir (in the Core section). If the value reported starts with /usr/lib/ then you have a problem. If it starts with /usr/local/lib/ then you might be okay — you still have to worry about how the PHP module was installed for Apache. I suspect it's going to start with /usr/lib/, though.

Looks like the MySQL/phpMyAdmin instructions are fine.

Personally, I would use MacPorts or something like it, but it sounds like it's too late for that. (Well, personally, for a simple web server, I would go with a VPS running Linux. Way less of a headache.)
posted by Renegade Duck at 12:00 AM on September 4, 2013

While it sounds like applying OSX updates will break the PHP version you installed, you really don't want to avoid applying security updates to a server sitting out on the public internet.

I don't know why there are so many ad-hoc, slightly-broken, never-updated guides around the interwebs for things like this on OS X.

A lot of them are (in theory) "this is how I got it working on my laptop for development work" and not intended for actual production deployment. And then people go and deploy them and don't apply security updates because it'll break what they've done, and then they get their systems compromised because they're running publicly visible servers with known security issues. Fun times.
posted by russm at 12:05 AM on September 4, 2013

Crap. Yes, it's in /usr/lib/... Any advice? Is it best to keep my PHP up to date, or OS X up to date?
posted by ferdinandcc at 12:06 AM on September 4, 2013

I think your options are to either install a new version of PHP the “correct” way (e.g. with a package manager), or to reinstall the same way after doing the security upgrades.

Note that you're going to have to do this anyway if you want to install security updates for PHP. Three vulnerabilities have been fixed in PHP since version 5.4.17, but none of them are likely to affect you (two are related to checking the validity of SSL certificates, and one is a vulnerability in XML parsing). If you're accepting XML files from browsers (e.g. AJAX in it's traditional form) those might be a problem. Strictly speaking, they might be a problem if you're using web services, but that would be tricky attack and I think it's unlikely.

The OS X vulnerabilities might be more serious, but I'm not sure what they are exactly.

The problem is that next week their might be serious vulnerabilities in either OS X or PHP, and then you would really want to upgrade quickly.

I would experiment with using a package manager on your local machine (if you have a local OS X machine) and then do that on your server.
posted by Renegade Duck at 12:27 AM on September 4, 2013

The problem with package managers is, I'm also running the OS X Server app, and it seems to want to overrule any other web servers installed. If I turn off web hosting in OS X Server and then turn it on in a MAMP package or any other Apache install and then browse to the site, the site still says something like "The web server is turned off, please turn on web serving in OS X Server."
posted by ferdinandcc at 12:33 AM on September 4, 2013

Where does it say to turn on web serving? I'm trying to imagine how that would work without having a web server running… I don't have OS X server to experiment with.

You should be able to turn off the built-in OS X web server and turn on the one you installed. The instructions will vary based on the package, of course.
posted by Renegade Duck at 12:39 AM on September 4, 2013

It is a good idea to keep OS X up to date. It is also not a good idea to follow 'tutorials' by people whose credentials you cannot verify (e.g. by knowing enough to know if they know what they are talking about). A bit like not letting your Dad teach you how to drive, all they do is propagate their misunderstanding. Use sites like like superuser.com or stackoverflow for advice from savvy people.

An common convention is to place all user installed software using something similar to --prefix=/usr/local precisely so that they do not conflict with the system. I would apply the system updates, use a combo installer to improve the chances of reinstating any parts you may have overwritten (normal updates assume the system has not been interfered with).

Then install PHP again this time into /usr/local and change all your web configurations to point at it, test for any breakage and fix those breaks.

Here is a starting point for the sort of stuff you should be reading up on, maintaining multiple versions of PHP, (and maybe Apache, etc). Read around until you get guidance on your environment.

MySQL is not part of stock OS X so you can leave that alone if you wish.
posted by epo at 12:45 AM on September 4, 2013

Okay, I think I'm not supposed to ask follow-up questions in the thread, but hopefully this will be okay. Are there any resources online for finding server technicians who are familiar with OS X Server that I can contract to take care of this for me? I'm beginning to think the set-up process is beyond me. (Also, if you know anyone or ARE anyone who fits this description, please memail me :) )
posted by ferdinandcc at 2:01 AM on September 4, 2013

one way of handling OSX Server wanting to manage apache itself would be to install apache/php using some other stack and running it on some non-default port, and then using Server Admin to configure the "official" apache instance to just proxy through to your private version.

I don't work in the Apple channel any more, but it might be worth contacting a local Apple reseller who works in the business space (not a consumer box-shifter) and ask if they have or can recommend someone for server support.
posted by russm at 4:17 AM on September 4, 2013

epo - MySQL is installed in OSX server, and is (or at least used to be) used by some server components, so overwriting that with a local install would be a Bad Idea.
posted by russm at 4:22 AM on September 4, 2013

russm, Apple stopped including mySQL with 10.7 (Lion) Server nor 10.8 (Mountain Lion) Server.
posted by Wild_Eep at 5:15 AM on September 4, 2013

ferdinandcc: "Crap. Yes, it's in /usr/lib/... Any advice? Is it best to keep my PHP up to date, or OS X up to date?"

Wait. Where in /usr/lib?

Personally, I'd recommend installing PHP using Homebrew, which will put the extension inside someplace like usr/local/Cellar/php53/5.3.25/libexec/apache2/libphp5.so, which OS X shouldn't ever touch.

Really, I have no clue why that tutorial had you install Homebrew, and then compile PHP by hand... Using Homebrew for the entire process should be much, much easier.

As long as you update your Apache configuration (httpd.conf) to load the PHP from that directory, you should be good to go.
posted by schmod at 7:01 AM on September 4, 2013

schmod extension_dir: /usr/lib/php/extensions/no-debug-non-zts-20100525
posted by ferdinandcc at 7:08 AM on September 4, 2013

Hm. I don't think OS X should wipe that out, but really, you're best off just installing PHP via Homebrew.
posted by schmod at 8:31 AM on September 4, 2013

/usr/lib/php/extensions is exactly what Apple might replace if they were updating PHP. Anything under /usr/lib/ is system; /usr/local/ is for local stuff. I don't know the details of their upgrade process to be sure of how it works, though.

russam's suggestion to install separately and then proxy is good!
posted by Renegade Duck at 9:09 AM on September 4, 2013

First question is is there any particular reason you have to be hosting this stuff on OSX? I am sure the familiarity is great, but it comes joined with the fact that there is not, as you are learning, a big, solid, community knowledge-base of how to securely host web apps on OSX on the public Internet.

Second question is whether you can easily get a second IP address that you can bind a homebrew installed Apache+PHP combo to? Barring that, i think the idea of running the homebrew provided Apache+PHP on another port and reverse proxying from the OSX provided webserver is probably a good bet.

One way or the other, I don't know how well hardened the homebrew provided Apache config is. Does it run as an unprivileged user? Ideally it would be confined to a "jail," though it is beyond my own knowlege to tell you how to set one up.
posted by Good Brain at 9:18 AM on September 4, 2013

Renegade Duck: "/usr/lib/php/extensions is exactly what Apple might replace if they were updating PHP."

I seriously doubt that an OS X update would wipe an entire directory inside /usr/local during an upgrade. They might overwrite existing files in that directory, but almost definitely not the custom no-debug-non-zts-20100525 binary.

And, again, I hate to sound like a broken record, but this is exactly the problem that Homebrew was designed to solve. Everything goes into /usr/local/Cellar/, which OS X should never ever touch during an update.

The built-in PHP binary stays in place to preserve compatibility and avoid being clobbered in an update, and you use the newer binary by pointing your web server's configuration file to the new PHP installation inside /usr/local/Cellar/.

All of the OS X package managers (back to Fink, et al) have used this strategy for a very long time, and it's widely considered a best practice if you're substituting your own binaries on top of the ones that OS X provides.
posted by schmod at 10:20 AM on September 4, 2013

Even if it doesn't replace the extensions subdirectory, PHP will be installed in /usr/lib and some of those file paths will definitely be replaced by a PHP upgrade from Apple. (I'm assuming you meant /usr/lib, schmod :)

Good Brain: None of the OS X package managers are likely to set up Apache in a jail (well, I don't think jail is on OS X, I think that's a FreeBSD thing) or in a chroot. That said, none of the Linux package managers will either (at least with the default Apache packages for the major distros).

Honestly, I'm not sure if setting up Linux would be that much harder than what you're doing, ferdinandcc! (Then again, I've been setting up Linux servers for a decade and a half, so my ideas about what's “easy” may be a bit off.)
posted by Renegade Duck at 10:39 AM on September 4, 2013

Re: using Linux, that's great and all, but we can't afford a second dedicated server. And we need this one for other things that are Mac-only.
posted by ferdinandcc at 12:11 PM on September 4, 2013

It depends on what you're doing, but many people use VPS (virtual private server — a virtual chunk of a bigger server dedicated to you) hosts like Linode or Digital Ocean. I have a 1 GB VPS with Linode that I host a few personal web sites on, and mail for my domains.
posted by Renegade Duck at 12:30 PM on September 4, 2013

We've got a VPS already. But we're also using a dedicated server for another project, and I was hoping that—in order to help justify the expense of our dedicated server—I'd be able to move our web hosting over there as well. Right now we've got 23 domains hosted with Dreamhost. Anyway, if anyone else has any advice about PHP and OS X Server, and/or can recommend support people, let me know. I'll mark this question as answered tomorrow. Thanks!
posted by ferdinandcc at 1:04 PM on September 4, 2013