A blog named for the muse of Astronomy containing musings by an astronomer

Archive for the ‘MacOS X Annoyances’

Fixing my PHP woes with MacPorts 2

Posted on August 14, 2008 by Juan

As I mentioned in my blog post earlier today, I have been having issues using the JpGraph graphing package for PHP with Apple’s built-in PHP under MacOS 10.5. It appears Apple’s security efforts have “secured” PHP to the point where JpGraph (and PDFLib) will not function properly under the built-in PHP. [Note added after initial post: The rest of this post describes installing Apache 2 and PHP under MacPorts and configuring it to be similar to Apple’s built-in servers.  This appeared to solve my problems, but then my Mac locked-up [possibly related] and on reboot, the new MacPorts-based PHP installation started throwing the same errors as Apple’s built-in PHP.  More information on this problem is located in my newer post on the issue.]

I had tried to alleviate the solution previously by compiling a version of PHP myself that would be compatible with Apple’s built-in Apache 2 web server. This turned out to be difficult because Apple’s Apache 2 web server is a “universal” binary, meaning it contains four seperate binaries (for 32-bit PowerPC, 64-bit PowerPC, 32-bit Intel, and 64-bit Intel processors). As such I needed to compile a “universal” PHP binary and since I wanted MySQL support, I needed a “universal” MySQL binary. This turned out to be too much for this astronomer, so I gave up on making a new PHP that was compatible with Apple’s built-in web server.

So I bit the bullet and after reviewing the options, I decided to install Apache 2 and PHP under MacPorts. If you have read the other posts on this site, you know I really like MacPorts as the quick and dirty way to get many things running on the Mac. However, despite this, I don’t like installing MacPorts for items Apple provides, instead generally preferring to use Apple’s “pre-installed” versions. Furthermore, there have been a lot of complaints on the MacPorts mailing lists about various issues compiling PHP5. So I wasn’t as quick to jump onto the MacPorts bandwagon for PHP as I am for other problems. However, since I am familiar with MacPorts, I decided this was the best approach for getting my online Finder Charts to work again.

The process proved reasonably painless, especially since I was able to review this blog post, where he lays out pretty much what to do. However, since I wanted to achieve maximum compatibility with Apple’s built-in web server and PHP setup, in case I wanted to switch back, I ended up doing things a little bit differently, so I am outlining my steps here.

  1. I started by installing the MacPorts version of Apache 2 using the command sudo port install apache2
  2. Next, I had to create the Apache 2 configuration files and edit them. I started by copying the sample configuration file
    sudo cp /opt/local/apache2/conf/httpd.conf.sample /opt/local/apache2/conf/httpd.conf
    and then editing /opt/local/apache2/conf/httpd.conf with my favorite text editor to change the configuration to match the that of the built-in Apache 2 server a closely as possible. My matching the configuration of Apple’s built-in server, I can switch back to it with relative ease if I choose to do so later. So I made the following changes to /opt/local/apache2/conf/httpd.conf:
    1. I changed DocumentRoot to "/Library/WebServer/Documents" as is the case with Apple’s built-in server.
    2. To allow index.php files to be used as directory indexes, I changed
      DirectoryIndex index.html
      DirectoryIndex index.html index.php
      (I don’t know why this isn’t necessary with Apple’s built-in server, but it was necessary here).
    3. I changed to and in that directory block of code, I added “MultiViews” to the Options line.
    4. I changed to in order to prevent the listing of .DS_Store files in directory listings by the web server.
    5. Before the ErrorLog block of code in this file, I added the following lines copied from Apple’s default Apache 2 configuration:
      # Apple specific filesystem protection.
      Order allow,deny
      Deny from all
      Satisfy All
      Order allow,deny
      Deny from all
      Satisfy All
    6. I changed ErrorLog to "/private/var/log/apache2/error_log"
    7. I changed CustomLog to "/private/var/log/apache2/access_log common"
    8. To match Apple’s Apache 2 server configuration, I changed ScriptAliasMatch to
      ^/cgi-bin/((?!(?i:webobjects)).*$) "/Library/WebServer/CGI-Executables/$1"
    9. I changed back to
    10. I added the following Handles to the “To use CGI Scripts” block of code:
      AddHandler imap-file .map
      AddHandler cgi-script .cgi
      AddHandler cgi-script .pl
    11. I uncommended the following lines near the end of the file:
      Include conf/extra/httpd-autoindex.conf
      Include conf/extra/httpd-userdir.conf
    12. [OPTIONAL] Because I use the WebDAV server on my server, I also uncommented Include conf/extra/httpd-dav.conf
    13. Finally, I added the following lines to the end of the file in order to allow loading of the PHP5 configuration
      # Load PHP5 configuration
      Include conf/extras-conf/*.conf
  3. Next, I editted /opt/local/apache2/conf/extra/httpd-userdir.conf and added the following to the end of the file
    # Users might not be in /Users/*/Sites, so use user-specific config files.
    Include /private/etc/apache2/users/*.conf
  4. [OPTIONAL] Since I use the built-in WebDAV server, I made a backup of the WebDAV configuration, then copied the Default MacOS X one, because I have spent a lot of time tweaking it previously and I didn’t want to have to reinvent the wheel. 
    sudo cp /opt/local/apache2/conf/extra/httpd-dav.conf /opt/local/apache2/conf/extra/httpd-dav.conf.orig
    sudo cp /etc/apache2/extra/httpd-dav.conf /opt/local/apache2/conf/extra/httpd-dav.conf
  5. I had to install PHP5 with MacPorts. Since I wanted to add support for Apache 2 and MySQL, I entered the command: sudo port install php5 +apache2 +mysql5 +pear which has the side effect of installing MacPorts version of MySQL as well. Assuming everything goes well, after a few minutes (this takes longer than the apache2 install earlier), the installation will end. At this point we can configure the Apache 2 mod_php module by typing: 
    cd /opt/local/apache2/modules/opt/local/apache2/bin/apxs -a -e -n "php5" libphp5.so
  6. [OPTIONAL] Next, I had to create the PHP5 configuration file and edit it. I started by copying the sample configuration file sudo cp /opt/local/etc/php.ini-dist /opt/local/etc/php.ini and then editing /opt/local/etc/php.ini to make it match /etc/php.ini (which Apple’s built-in PHP uses). All the changes I made were optional and related to the specifics of my setup. The only interesting one was that I wanted to continue to use the MySQL.com binary distribution of MySQL server, so I set the following variables in /opt/local/etc/php.ini
    1. mysql.default_port from “” to 3306
    2. mysql.default_socket from “” to /private/tmp/mysql.sock
    3. mysqli.default_socket from “” to /private/tmp/mysql.sock
  7. I deactivated Apple’s built-in web server by turning off Web Sharing in the Sharing.prefPane.
  8. Finally, I launched the new webserver (and set it up for launching on boot-up in the future) by typing
    sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist
    If this breaks anything, I can reverse the process by typing
    sudo launchctl unload -w /Library/LaunchDaemons/org.macports.apache2.plist
  9. [OPTIONAL] I like the ability to turn on and off the Apache webserver from the command line using apachectl. I can “emulate” this in /bin/tcsh (my prefered shell) by adding the following command to the ~/.tcshrc file:
    alias apache2ctl 'sudo /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper'
    After which I can bring down the server by typing apache2ctl stop and restart it by typing apache2ctl start.

PHP on Leopard … damn irritating sometimes 2

Posted on August 14, 2008 by Juan

Applying the latest MacOS X Security Update from Apple today reminded me of the problems I have had with PHP on Leopard. The Security Patch brought Leopard up to version 5.2.6. Unfortunately, it doesn’t fix a problem I have been having with PHP5 under Leopard.

While I’m sure Apple did this for security reasons, since upgrading the Leopard, I have had a problem with scripts that use the JpGraph plotting PHP library crashing. After looking in /var/logl/apache2/error_log, I see the following eror message:

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().

I’ve been trying to figure out why this has been happening for a while. Johan Persson at JpGraph and I exchanged some emails where he outlined for me how this was a problem with Apple’s pre-built version of PHP5 since JpGraph is not fork()-ing any processes. Well, today I decided to look into this again and discovered that the PDFLIb folks have documented this problem a little better, copying from their documentation here:

PHP on Mac OS X. Apple’s PHP version which is bundled with Mac OS X does not work with PDFlib DSOs. To use PHP with PDFlib on Mac OS X you need third-party PHP packages such as MAMP, XAMP[P] for Mac, or Marc Liyanage’s version from www.entropy.ch. Mac OS X 10.5 (Leopard) adds new complications. As described in developer.apple.com/releasenotes/CoreFoundation/CoreFoundation.html it is no longer possible to use CoreFoundation functions after a call to fork( ) without exec( ). However, CoreFoundation functions are required for PDFlib’s host font feature, and the critical sequence above is used in the combination of Apache and PHP. This may trigger the following error message in the Apache log (and can even crash the Apache process):

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().

In order to avoid this problem you can run PHP as a CGI on Apache, or disable the host font feature in PDFlib[.]

Sure enough, JpGraph is using host fonts. Damn.

Unfortunately, the Marc Liyanage’s version of PHP5 for Leopard from www.entropy.ch is still in beta and the last update of MAMP was quite a long time ago. And while XAMPP for MacOS X looks promising (at least it has been updated recently), I would really like to keep on using the MySQL server I already have running. So for now, I try installing Apache 2 and PHP using MacPorts.

[See my subsequent posts about getting the MacPorts version of Apache 2 and PHP going and the subsequent continuation of the problem after a reboot.  There is more information about this issue there.]

Google Calendar adds CalDAV! Still twitchy however. 0

Posted on July 28, 2008 by Juan

Finally there is a free way to synchronize your Google Calendar and you iCal! Google has added support for CalDAV! So if you are running Leopard, you can now (in theory) synchronize iCal and GCal without paying a third party or pulling out our hair for some of the private solutions The detailed instructions for getting iCal talking to GCal are here.

Unfortunately, it looks to to be as twitchy as running your own Darwin Calendar Server. I’ve been using CalDAV on my own personal server for a few months and I have to admit it has been a bit twitchy, but getting better as time rolls on. I tried to synchronize this afternoon to Google Calendar and got the following error:

The server responded with
"HTTP/1.1 500 Internal Server Error"
to operation CalDAVWriteEntityQueueableOperation.
I got this error when trying to create a new calendar in Google from iCal. This is actually a documented error, but it didn’t go away for me like Google suggested it would. I am also getting that error when I try to import items into my GCal calendar via an “import” of the ics file I “exported” from my old calendar. I saw this same error on my server some time back. I needed to update my Darwin Calendar Server source code before I could fix it. In any case, I hope this is only a temporary issues since I could be very happy with the idea that I can now drop the maintenance of Darwin Calendar Server on my own computer and hand that task over to Google.

Followup (July 30): I noticed all of the errors occurring during the import were for old classes last semester. So I forced my way through them by clicking “Revert to Server” for every one of the errors. There were probably 20 of them. Once done, I compared my calendar on my computer and Google’s Calendar, they were identical. So for now, it looks like GCal’s CalDAV server may serve my needs after all. I could have avoided all this by directly importing my ics file into Google through their web interface.

Followup (August 27): So I got an iPod Touch and discovered that CalDAV calendars are loaded on the iPod Touch as “Read-only”. If Apple really wants to back CalDAV as a standard, you would think they would support it more fully on their own products. For now, I found that BusySync works quite nicely for syncing my iCal calendars with gCal in such a way that the calendars are hosted on my Mac and the iPod Touch then can treat the calendars are read-write. This, along with the lack of native ToDo list synchronization on the iPods are about the stupidest bits of inconsistency I have seen in using the iPod Touch. Luckily the ToDo list being missing from the iPod Touch doesn’t affect me as much as I am using OmniFocus, which works very well on the Mac and iPod Touch and allows synching between both.

SAOImage DS9 5.3beta and the Leopard Firewall, Redux 0

Posted on July 23, 2008 by Juan

I can attest the Aqua version of SAOImage DS9 version 5.3beta does indeed play nice with Apple’s dopey firewall behavior (see here for notes on version 5.2’s incompatibility with the Leopard firewall). However, the command line version that uses X-windows DOES NOT play nice with the Leopard Firewall. If you run the X-windows version of “ds9” on a Mac running Leopard’s built in Firewall in “Set access for specific services and applications”, you will end up with a completely hosed ds9 executable which will not launch ever again.

As such, for now, since I prefer the X-windows version of SAOImage DS9, I am leaving the the Firewall off for now, I’m not too concerned.

Xquartz 2.2.3 released 0

Posted on June 26, 2008 by Juan

I was trying to upgrade wine within MacPorts when I realized I had forgotten to upgrade Xquartz after my upgrade to MacOS 10.5.3 on my Mac Pro. So I checked, Xquartz has been upgraded to version 2.2.3. Since version 2.2.1 (which I talked about in my blog here).

  • Upgraded the freetype library to version 2.3.6, which fixes “A bunch of potential security problems have been found [and fixed in this release”
  • Upgraded to pixman library to version 0.11.4.
  • Xquartz fixes from xorg-server-1.3.0-apple21, the key fix being support for monitor hotplugging, although several security fixes also occurred.

Again, if you upgrade MacOS (say to version 10.5.4, which is supposed to be released soon in order to support iPhone G3 and MobileMe), you will likely need to reinstall Xquartz (unless Apple has upgraded their X11 installation to match Xquartz).

Finally a way to view PDFs inline in Firefox on Intel Macs 0

Posted on June 18, 2008 by Juan

I have been an avid Firefox user for quite some time. But when I moved to Intel-based Macs, I discovered that that Schubert’s PDF Browser Plugin didn’t work on Intel Macs (except if I placed Firefox in Rosetta mode, running its PPC code in emulation). hat project appears to have died on the vine, with no updates in abut 2 years. Furthermore, Adobe has insisted on making its inline PDF plugin Safari-only. This always struck me as rather redundant, since Apple has used Mac OS X’s Quartz graphics engine to allow viewing of PDFs inline in Safari. This, combined with Firefox’s longer launch times, made me slowly shift to using Safari about 80% of the time.

Yesterday, Firefox 3 was released. I have been using the betas for the last month and have been happy with its improved speed and functionality. Its part of the reason I am back to about a 50/50 split in Safari vs. Firefox use. Today, the other show fell in the form of this posting on MacOS X Hints:

There is now a Firefox extension named firefox-mac-pdf, available for Firefox 3 under OS 10.5 that utilizes the built-in PDF support in OS X to display PDFs in-browser. In my testing, it appears to work very well. It doesn’t have the nifty fading bezel that the Safari PDF viewer does, but it supports all the same keyboard shortcuts and you get the standard Mac OS PDF contextual menu when you control-click on a displayed PDF.

Its interface is not quite as easy to use as Schubert’s plugin, but it works. I now have inline PDF viewing in Firefox and things are better in the world again.

Saving PDFs: The one issue I noticed is there was no seemingly obvious way to save the PDF once you were viewing it. Nothing in the contextual menu allowing “Save as…” for example. Turns out it was easier to save the PDF than I imagined. In the “Issues” page for firefox-max-pdf I found this exchange which included the solution:

Currently there are two ways of saving the PDF:

  1. File->Save Page As menu
  2. The apple-s (command-s) keyboard shortcut

SAOImage DS9 versus Leopard Firewall 2

Posted on April 22, 2008 by Juan

Immediately after installing SAOImage DS9 5.2, I had a major failure of the application and initially I just thought it was some sort of build bug. This is what I posted at that time:

[HOLD OFF ON THIS UPDATE! I have discovered that at least on one of my systems, this version of ds9 is refusing to run properly. It launched once, but when I attempted to check the “About SAOImage DS9”, it triggered the following error:

 “An internal error has been detected local header mismatch couldn’t open “zvfsmntpt/doc/sun.gif”: no such file.

(this occurred in both Aqua and X11 versions). Furthermore, all future attempts to launch ds9 (again, either Aqua or X11) fail with the following error:

Error in startup script: couldn’t read file “./zvfsmntpt/src/ds9.tcl”: no such file or directory  

Even removing the preferences file at ~/.ds9.prf didn’t help.]

Apparently, my problems with SAOImage DS9 in Leopard are a known issue. If you configure the built-in Firewall to “Set access for specific services and applications” so that you can approve “holes” in your firewall on an Application by Application basis, your first launch of SAOImage DS9 will irreparably damage the application!  Unfortunately, Apple implements the application firewall in part by modifying the Application package of the Application you are running by digitally signing it if it was not digitally signed by the developer (adding a file called CodeResources to the Application package). According the Apple’s documentation on this:

If you run an unsigned application not in the Application Firewall list, you will be presented with a dialog with options to Allow or Deny connections for the application. If you choose Allow, Mac OS X 10.5 will sign the application and automatically add it to the Application Firewall list. If you choose Deny, Mac OS X 10.5 will sign the application, automatically add it to the Application Firewall list and deny the connection.

So basically,Apple doesn’t warn you in the dialog box that comes up that it has whatever decision you make, it will modify the application by digitally signing it and it doesn’t give you a way to avoid this. This is, in my opinion, is an incredibly boneheaded move on Apple’s programmer’s part. They readily admit that

  Some applications check their own integrity when they are run without using code signing.

They suggest the application firewall will try to automatically detect these and avoid modifying them, but they should give you, the user, the option instead of making the decision via some internal algorithm.  MacOS X shouldn’t assume its OK to change an application. In the case of SAOImage DS9, they are irreparably damaging the application without leaving you a way to avoid the damage once you trigger the application firewall. Shame on you Apple. The only way to fix it is to reinstall the application!

So when I figured this out (a tip of the hat to this post on IRAF.net). I reinstalled the SAOImage DS9 executables (both Aqua and X11 versions) and before launching them, I set the Firewall (via the Security Pane of the System Preferences) to “Allow all incoming connections” (this is the default mode, so it is as secure as MacOS Tiger was). Everything now appears to work just fine.

Personally, I believe an application that fails its checksum should present a message indicating that is the problem instead of just crapping out, but in this case, the fault lies mostly with Apple. Apple is damaging applications by making this critical decision in the background, without user intervention!

LaTeXit Updated for Leopard Compatibility 0

Posted on April 16, 2008 by Juan
One of my favorite little programs is LaTeXit.  It allows you to typeset LaTeX equations outside of a text editor and then drag the results into programs like Keynote or Pages.  It was not fully compatible with Leopard and my fix was a kludge that could break other programs.  Pierre Chatelier has released updated LaTeXit to version 1.15.0, which restores Leopard compatibility.  Notably, you can now use the default0 /etc/profile file without fear.

XQuartz updated to version 1

Posted on April 14, 2008 by Juan

[This originally linked to version 2.2.0, but there was a security related bug in version 2.2.0, so this release has appeared to replace it.]

The Xquartz folks have updated Xquartz to version Xquartz is an effort to provide a better X11 server for Leopard than Apple provides, being proactive in providing fixes Apple will likely include later. The release notes are long and cover a bunch of updates to various items, including:

  • Added informational output when falling through to failsafe startup in X11.app
  • Unsetenv(DISPLAY) when falling through to failsafe startup in X11.app
  • Exposé now works as expected
  • X11 works better with spaces

I suspect the discussion of ‘failsafe’ startups is to provide a more informational failure than what was happening before for people like myself who transitioned from previous MacOS X installations and had been manually forcing the DISPLAY variable to point to :0.0, which is somewhat standard in the Unix world.

I’d recommend grabbing this Xquartz update and applying it if you use Leopard and astronomical software. Its a double-click install. Apple does watch this project (one of the developers is Apple’s X11 developer), and as noted on the Xquartz site:

Apple included some of the work done in this project in their 10.5.2 update and will likely include further changes in possible future updates of 10.5.x. It is suggested that you install the latest XQuartz release after updating to 10.5.2 (and any future 10.5.x or security updates).

In other words, while some of these fixes will likely end up in the official MacOS released by Apple, if you want them now, use Xquartz. Furthermore, since Xquartz does over-write Apple’s default X11 install, this means that if Apple upgrades X11 in a future patch, you could end up with a broken install if you used Xquartz. Personally, I haven’t had a problem, but I suggest you keep the Xquartz package around, and re-install it after any future MacOS X updates.

osxutils now fixed on MacPorts under Leopard 1

Posted on April 10, 2008 by Juan

I got an email today noting that osxutils now installs correctly in MacPorts under MacOS 10.5 Leopard.  I have tested it and this appears to be correct, the commands:

sudo port -d selfupdate
sudo port -d sync
sudo port install osxutils 

did indeed install osxutils as promised.   I also noticed they upgraded from version 1.6 to 1.7, maybe that was all that was necessary.  All the MacPorts packages I used in Tiger now work in Leopard. Now if I could only get a proper recompile of PHP working under Leopard.

Leopard’s path_helper seems a bit buggy 0

Posted on March 25, 2008 by Juan

I am having an interesting problem. In my last post, I noted that on some Macs with Leopard installed, deactivating the lines calling /usr/libexec/path_helper in the /etc/profile file fixed LaTeXit hanging at launch. A bit more investigation by Antonio Molins (posted in the comments to that post) revealed it was possible to add an ASCII file in the /etc/paths.d directory. We could create a file called /etc/paths.d/macports containing the only the line

and it should automatically add everything in macports to most user’s PATH variables. However, when I tried this, all my calls to /usr/libexec/path_helper -s always locked up the command.

Some further investigation revealed new user accounts on my Macs didn’t have this problem. I surmised that since I was setting up the PATH and MANPATH variables in my environment at login, that this could apparently lock up path_helper. Since I use tcsh by default (instead of Apple’s default bash shell), I issued the following two commands from the command line

unsetenv PATH
unsetenv MANPATH 

and sure enough path_helper worked without an issue. So something is buggy in path_helper, or at least hypersensitive to pre-existing PATH environmental variables. I’ll have to investigate this more later. One thing I did discover is that

/usr/libexec/path_helper -c 

will produce the commands to set up tcsh’s environment.

/usr/libexec/path_helper -s 

returns those for the default bash shell.

A fix for LaTeXit under Leopard 4

Posted on March 08, 2008 by Juan

[A better fix to this problem is to upgrade to LaTeXit 1.15, which was released on April 16, 2008.  It fixes the problems with Leopard and allows you to keep the default /etc/profile file for Leopard.]

Apparently, LaTeXIt, which I use to generate equations with Latex which can then be copied into Apple’s Keynote and Pages documents, locks up on launch a vanilla install of Leopard. This post on MacOSXHints.com provides a hack, but it wasn’t that nice, since it involves re-installing a particular version of latex. It turns out the solution was really much simpler and shows up in the comments on that page. In the comments, user Paolo Bosetti notes that

There is actually a much easier workaround: simply change your /etc/profile commenting the following lines (add the “#” at the begining):

# if [ -x /usr/libexec/path_helper ]; then
# eval `/usr/libexec/path_helper -s`
# fi

and adding the following two:
export PATH

Why so? Apple changed the Leopard way to set the PATH variable, and now it uses the /usr/libexec/path_helper command, which seems having troubles with LaTeXiT spawned bash scripts. If you make this modification to your /etc/profile, you are simply dropping the new path_helper in favour of the plain old way to set the PATH variable.

This also explains why I wasn’t seeing this on my laptop, since it kept the old /etc/profile file during the upgrade.

Another user comments that the fix could also be done without hacking the /etc/profile but instead just changing ~/.profile such that /opt/local/bin appears in the path last, since /usr/libexec/path_helper is supposed to read ~/.profile. However, I was unable to get this approach to work.

  • Translate

  • Astro Pic o' the Day

  • Archives

  • Admin

↑ Top