Urania

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

Archive for the ‘Command Line Tricks’


Securing your Snow Leopard Web Server 0

Posted on April 05, 2011 by Juan

I run several blogs as well as some WebDAV servers on my MacOS X web server, all of which use passwords to authorize access.  I recently decided it would a good idea to support HTTPS (secured, encrypted HTTP) on my web server so that my passwords for accessing my blogs and webDAV server were not sent plaintext and unsecured over the internet.

Initially I had balked at this because the typical SSL Certificate, needed to encrypt and decrypt the traffic from the web server, cost on the order of $100 per year if signed by a Certificate Authority (one of the companies that all the web browsers come set up to ‘trust’ as signers of SSL certificates).  Such a digital signature is necessary if you want your https connections to be recognized as trusted by all web browsers.

However, I recently learned that it is possible to simply ‘self-sign’ your SSL certificates and so long as you only need the encryption for yourself (for example, when using a password to log in as an admin on a blog), this is a free solution that works.  The certificate will not be marked as ‘trusted’ by any authority, but if you can trust it, it will allow you to encrypt the traffic to and from your web server.

The solution I outline below is partly based on a hint provided at MacOSXHints for getting a full Certificate Authority signed certificate installed (here) and a hint from the CentOS wiki (here) for self-signing your certificates.

I’ll outline the procedure I used below, but as a warning, you need to have a familiarity with the command line and the use of sudo.  I am also assuming you are using Snow Leopard (MacOS 10.6.x).

  1. Create Directory to store certificate: Start by creating a directory you want to place the certificates in and then “cd” into that directory on the command line.  I used /etc/apache2/local_certs/ as my directory.
  2. Generate the Private Key file: Next, from the command line, generate a private key:
    openssl genrsa -out ca.key 1024
    during the command the output should look like this:
    Generating RSA private key, 1024 bit long modulus
    ........++++++
    .......................++++++
    e is 65537 (0x10001)
  3. Generate a Certificate Signing Request file: Next you need to generate a certificate signing request. You won’t ask anyone else to sign this, but you need it in order to create the public key file. So from the command line type:
    openssl req -new -key ca.key -out ca.csr
    and you will be asked a series of questions. Your answers should be as follows:
    1. For Country Name (2 letter code) answer with the two letter code for your country, for the United States it was “US”.
    2. For State or Province Name (full name) I answered “Minnesota”.
    3. For Locality Name I entered my city.
    4. For Organization Name I entered my name (Juan Cabanela) since this is a server run by my school, but not managed by my school.
    5. For Organizational Unit Name I just hit “enter” and left it blank, your answers may vary.
    6. For Common Name I entered by server’s URL iparrizar.mnstate.edu.
    7. For Email Address I used my email address. It appears in the certificate so I suppose it could lead to spam, but I figured it was better to give people stumbling across the certificate an email address they could contact for questions.
    8. For A challenge password and An optional company name, I hit enter. I don’t expect to need to get the certificate signed.
  4. Generate a Public Key file: The last step in certificate creation is you need to generate the self-signed public key which will actually be what users get when they access your server. The user uses this public key which decrypts the traffic the web server will encrypt with the private key (only accessible to the web server).  To generate the public key file, use the command line to run:
    openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt
    This will only make your public key valid for 365 days, you might want to change this if you don’t want to have to generate a new public key every year.
  5. Set up the web server: Now you have to edit your MacOS web server configuration to support encrypted HTTPS traffic.  This comes down to editing two files. ou will need ‘admin permission’ to edit both of these files, so you will either need to use sudo with a command line text editor (like vi or emacs) or you will need to use a text editor that supports editing files with ‘admin’ permission. The changes you need to make are the following:
    1. Open the main web server configuration file, /private/etc/apache2/httpd.conf, in a text editor and uncomment (remove the leading ‘#’ from) the following line (it’s line 473 in my installation):
      Include /private/etc/apache2/extra/httpd-ssl.conf
    2. Edit /private/etc/apache2/extra/httpd-ssl.conf and make sure the following lines are set as follows:
      • SSLCertificateFile points to /private/etc/apache2/iparrizar_ssl_new/ca.crt or where ever you have your ca.crt file you created in step 4. SSLCertificateKeyFile points to /private/etc/apache2/iparrizar_ssl_new/ca.key or where ever you have your key file you created in step 2.
      • Make sure the lines containing SSLCACertificateFile and SSLCARevocationPath (these are two seperate lines) are commented out (add a leading ‘#’ to each line). Since these certificates will not be signed by a certificate authority, you have no need to point people to CA certificate files or revocation paths.
  6. Restarting the web server: Now all you should have to do is restart you apache web server and see if everything works. From the command line type:
    sudo apachectl restart
    This should restart the web server.  Assuming no error messages appear, you can next test the connection.
  7. Testing the web server: See if you can go to your web server using https://your.domain.name.here/ as the URL in your web browser. You will be presented with the ‘untrusted’ certificate and asked if you want to accept it.  In Safari on the Mac, accepting the certificate adds it to the Keychain.  I am not sure about where Firefox or Chrome store the certificate, but they should hold on to it for future use, ensuring your future connections to the web server are secure (if done via “https”).
  8. Bonus Step for iOS device users: If you want to add these self-signed certificates to your iOS device, you can do this by simply ‘exporting’ the certificate as a ‘crt’ file from the Keychain (or finding the original “crt” public key file you created earlier).  Email that public key .crt file to yourself and open that email on the iOS device.  If you click on the attached certificate in that email you will be presented with the option of adding that certificate to your iOS profile.  Doing so will allow Safari and other programs on the iOS device to connect securely to your web server.

Experimenting with a little Homebrew 0

Posted on March 01, 2011 by Juan

Well, today it finally happened.  I got sick and tired of MacPorts behavior of replacing every binary already included in the Mac OS with its own version.  I don’t need two versions of perl or python installed on my Macs and I am getting tired that every time I try to install a port, it insists on installing a complete perl/python installation or its own set of libraries the MacOS already has built in,  in order to install a small utility.  I know that MacPorts has some justification for this, but it seems messy to me.

As such, I started looking for alternatives and came back to homebrew, which I had discovered a few months ago.  It is a package management system in which everything relies on already installed Mac binaries/libraries as much as possible.  By default, homebrew packages are installed into their own isolated directory (/usr/local/Library/Cellar/) and then symlinked into /usr/local/bin, /usr/local/sbin, or /usr/local/lib directories as needed. But it is flexible enough that you can install it where ever you want and it will still run.  Another nice feature, it doesn’t require you install it as root, it can run completely as the user permission level!

The negatives of homebrew:

  1. There are no where near as many packages (they call them “Formula”) are available for Homebrew as for MacPorts or Fink.
  2. For an astronomer, another big problem, there is no TeX under Homebrew.

It turned out the first negative was a bit of annoyance, but I was willing to live with it because the installation was so much cleaner and most of the important packages I needed MacPorts for were already there.  The second negative turned into a postive because I discovered here is a very easy to install MacTeX package available now that installs a complete TeXlive installation, including AASTeX, by default!  It even has some nice GUI controls included for keeping it up to date.

What follows is a description of what I did to transition from MacPorts to HomeBrew+MacTeX.

  1. Backing up MacPorts: No need to not have a way to change my mind if this blows up in my face.  I backed up my entire MacPorts installation by using the command

    tar czvf /opt_backup.tgz /opt

    and then when that was done, I had a 1.6 Gig tarball at the root level of my drive called opt_backup.tgz.

  2. Disable MacPorts: At this point, I deleted the /opt directory and commented out the commands in my ~/.tcshrc that added those directories to the PATH environmental variable.   If you use the default bash shell, you will need to edit ~/.bashrc to disable MacPorts.
  3. Install Homebrew: Following the directions on the Homebrew site. I originally wanted to place homebrew in its own custom install directory (/usr/local/homebrew).But after reviewing the Homebrew installation documentation, I came to realize that using the default /usr/local location for the install makes the most sense.

    I did this in the recommended manner, using the install script, which does some nice permission checking to make sure things will run nicely before installing. Since my default shell isn’t bash, I had to switch to it, then just run the install script from the command line:

    bash
    ruby -e "$(curl -fsSLk https://gist.github.com/raw/323731/install_homebrew.rb)"

    The first time I ran it, it failed because my permissions for /usr/local had been tweaked. So I had to run the command

    sudo chown -R root:staff /usr/local

    to get the permissions so the script could run.

  4. Activate Homebrew: Since I am not using a custom directory for the installation, there is not configuration needed in terms of setting up the environment. /usr/local/bin/ is in the default PATH, so as soon as I start up a new terminal window, homebrew is available! Otherwise, I would have to edit my default ~/.tcshrc or ~/.bashrc to add the homebrew binaries directories (bin and sbin) to the PATH environmental variable.
  5. Install my favorite packages using homebrew: Installing packages in homebrew is just a matter of making sure the Formula for the package exists (all the publicaly available Formula are here) and then typing

    brew install (formula name)

    So for example, installing CFITSIO was just a matter of typing:

    brew install cfitsio

    Actually, this was for the most part simple for my attempts to install git.  It kept crashing with an error that said:

    The current directory must be set to the ITT directory.

    Well, ITT is the vendor of IDL (a package commonly used by astronomers for data reduction) and I discovered that I had accidentally set the IDL binary directory to be in the PATH ahead of the default system directories.  This meant the IDL version of a binary called install was replacing the system default version of this.  Just the kind of problem I was trying to get away from in MacPorts.  I  changed to my ~/.tcshrc to make sure the IDL binaries directory was later in the PATH than the system directories fixed things.  The only package this affected the install of was git, all the other packages installed without a hitch thus far.  The other brew formulae I installed were installed with the following commands:

    brew install subversion  imagemagick ghostscript macvim lynx coreutils findutils plotutils

    I can get a list of all the packages I have installed using the command:

    brew list

  6. Installing MacTeX: This was extremely easy, I downloaded the MacTeX 2010 package (The version I got was dated 10 Sept 2010 and was 1.6 Gig) and then uncompressed it and double clicked it. It installs using the Mac Installer. I did make sure to customize the install to remove some of the stuff I didn’t feel I needed, but I kept the GUI tools. Turns out there is a nice TeX Live Utility installed in /Applications/TeX that lets you customize which TeX packages are installed and can automatically update things. Review of this tool also showed a very astronomer friendly decision to include AASTeX by default! The TeX installation is in the /usr/local/texlive/ directory and it installs a symlink at /usr/texbin/ to all the LaTeX binaries. I added the following lines to my ~/.tcshrc file to get the tex binaries in my PATH:

    # Set up MacTeX 2010 by including path to that installation of LaTeX
    setenv PATH ${PATH}:/usr/texbin

So there you have it, how I went from using MacPorts and the literally hundreds of packages to support the few I wanted to trimming things down to a few packages in homebrew and one double-clickable TeX installer.

[Edited on Mar. 2, 2011 11:04 am to update the instructions to the default homebrew instructions, which are cleaned and easier to implement.]

Activating SSH support in MacPorts PHP 6

Posted on December 11, 2008 by Juan

[I have made an updated version of these instructions for adding the SSH2 PHP extension to the pre-installed PHP 5.3.0 installation on MacOS 10.6 available here.]

I just upgraded the software on this blog to WordPress 2.7. The major new feature I am interested in is automatic upgrading, which could prove quite a time saver. Unfortunately, this automatic upgrading uses only FTP (which is totally insecure) or FTPS (which requires me to set up an SSL certificate).

I noticed that the WordPress code had ssh2 support built-in, so all I need to is activate SSH2 support in the MacPorts installed PHP and I should be able to use SFTP in WordPress to handle the upgrades. I poked around and found this posting outlining the process for adding ssh2 support to Ubuntu. It guided me in developing this list of hints:

  1. Start by installing libssh2 via MacPorts using the command:
    sudo port install libssh2
    
  2. Once it is activated, link the libssh and PHP together using the PECL module SSH2. Unfortunately, directly installing the module with PECL under MacPorts is troublesome, so I just used PECL to download the module.
    pecl download ssh2
    
    triggered the following error (since ssh2 is apparently beta),
    Failed to download pecl/ssh2 within preferred state "stable", latest release is version 0.11.0, stability "beta", use "channel://pecl.php.net/ssh2-0.11.0" to install
    Cannot initialize 'ssh2', invalid or missing package file
    Package "ssh2" is not valid
    download failed
    
    so I used
    pecl download channel://pecl.php.net/ssh2-0.11.0
    
    as suggested and was able to download the PHP library for SSH2. Once the download was complete, I started on the standard compilation sequence for a PHP library
    tar xzvf ssh2-0.11.0.tgz
    cd ssh2-0.11.0
    phpize
    ./configure --with-ssh2=/opt/local
    make
    sudo make install
    
    The final command informed me the ssh2.so library was placed in /opt/local/lib/php/extensions/no-debug-non-zts-20060613/
  3. Now you need to make sure PHP loads the new module, so we open the PHP configuration file /opt/local/etc/php.ini and edit the extension_dir line to point the extension directory above:
    extension_dir = "/opt/local/lib/php/extensions/no-debug-non-zts-20060613/"
    
    and then add the following line to the end of the section on “Dynamic Extensions”:
    extension=ssh2.so
    
    If you edited everything properly, a simple php -v from the command line should NOT trigger any errors.
  4. Finally, I restart the apache2 server so that the reconfigured PHP is loaded using
    sudo /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper restart
    
    At this point, I checked (via the phpinfo(); command to see if the web server was supporting SSH. Near the bottom of the phpinfo(); listing is a listed of “Registered PHP Streams”. As noted here, it should incude “ssh2.shell”, “ssh2.exec”, “ssh2.tunnel”, “ssh2.scp”, and “ssh2.sftp”. If it does, you have enabled SSH support for Apache2 driven PHP pages under MacPorts.
  5. If you are doing this to get WordPress 2.7 automatic installation working, you will notice now when the automatic installation dialog box pops up, in addition to ftp and ftps, you now have an ssh option.
  6. Now that I got this working, I’ll just have to keep an eye out for any future MacPort updates to PHP and make sure they don’t overwrite the

    /opt/local/etc/php.ini

    file or the extensions directory where I installed ssh2.

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
      to
      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.

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

/opt/local/bin
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.

Making Leopard PHP a better PHP by adding GD support 8

Posted on March 04, 2008 by Juan
The nice thing about MacOS X 10.5 Leopard is that it comes with PHP 5.2.4 pre-installed. Unfortunately one of the features Apple choose not to compile in was support for the GD graphics library, which I use extensively. Furthermore compiling in new features has proven to be somewhat troublesome. When I tried to configure PHP 5.2.5 on my Leopard box which the following commands (a variant of the configure command I would issue under Tiger with no complaints):
./configure --prefix=/usr --mandir=/usr/share/man \
   --infodir=/usr/share/info --disable-dependency-tracking \
   --with-apxs2=/usr/sbin/apxs \ 
  --with-ldap=/usr --with-kerberos=/usr \
   --enable-cli \
   --with-zlib-dir=/usr \
   --enable-trans-sid \
   --with-xml \
   --with-dom \
   --enable-exif \
   --enable-ftp \
   --enable-mbstring \
   --enable-mbregex \
   --enable-dbx \
   --enable-sockets \ 
  --with-iodbc=/usr \
   --with-curl=/usr \
   --with-iconv=shared,/opt/local\
   --with-openssl=shared,/opt/local\
   --with-xmlrpc \
   --with-xsl=/usr \
   --with-config-file-path=/etc \
   --sysconfdir=/private/etc \
   --with-gd=/opt/local --enable-gd-native-ttf \
   --with-jpeg-dir=/opt/local \
   --with-tiff-dir=/opt/local \
   --with-png-dir=/opt/local \
   --with-freetype-dir=/usr/X11 \
   --with-xpm-dir=/usr/X11 \
   --with-pdflib=/opt/local \
   --with-gettext=/opt/local\
   --with-mysql=/usr/local/mysql \
   --with-mysqli=/usr/local/mysql/bin/mysql_config \
   --with-pdo-mysql=/usr/local/mysql \
   --without-pear
The result was a failed configure due to an error in mysql configuration. I pinned this down to a request for a library at
/usr/local/mysql/lib/mysql/libmysqlclient.15.dylib
which is actually located one directory up. This can be fixed via the command line using:
cd /usr/local/mysql/lib
mkdir mysql
cp libmysqlclient.15.dylib mysql/libmysqlclient.15.dylib
Then the ./configure worked just fine. Unfortunately, when I did a
make
make test
to compile the PHP and test it, there was no happiness. There were over 50 errors, some of them major. Crud. This is just the setup. See, all I needed was GD graphics library support in PHP for my website. Well, after googling for some time for some master hacker’s notes on getting PHP 5.2.5 to compile on Leopard, I discovered a fellow named Hill Pei had hacked GD support into the Leopard PHP without too much effort. His method simply requires some comfort with the command line and editing text files. In five minutes, I had GD support with Leopard’s built-in PHP. Excellent! [Despite a report in the comments to the contrary. This still appears to be necessary if you apply Security Update 2008-002, which installs PHP version 5.2.5. In which case, you should grab the php 5.2.5 code and work from there. I can confirm Hill Pei’s instructions do work after Security Update 20008-002 if you grab the PHP-5.2.5 code instead of 5.2.4 as he suggests.]

MacPorts getting more functional for this Astronomer 0

Posted on January 24, 2008 by Juan

About 6 weeks ago I posted about the various ports that failed to install in my first attempts at getting “my standard suite” of ports installed under MacPorts on Leopard. My standard suite until Tiger involved issuing the following command:

sudo port install aquaterm chmdump contacts coreutils curl file findutils g95 ghostscript gv ImageMagick ksh93 latex2rtf lynx macutil osxutils plotutils subversion teTeX tidy vim wget wine xterm xephem

Since then MacPorts has released version 1.6 and the various porters have been hacking at the various problems. I can now report that of the ports I reported failed to install:

  • xterm, wine, and g95 all now install without any issues.
  • teTeX can be installed, there was a bad dependency in the portfile. You just needed to install openmotif first manually. I don’t know if the bad dependency is still there, it may have been resolved.
  • subversion can be installed, it also had a bad dependency. You just needed to install nawk first. Again, I don’t know if the bad dependency is still there, it may have been resolved.
  • gv can be installed if you apply a patch. If you check that bug ticket on gv (you need to get a free MacOSForge account), you will find a new patch-setenv.c file is available there. If you download that file and replace /opt/local/var/macports/sources/rsync.macports.org/release/ports/print/gv/files/patch-setenv.c with it, gv will compile and install just fine.

This leaves just two of my standard suite of packages that don’t compile right in Leopard, osxutils (See this post) and xephem (See this post). And xephem installs just fine manually if you download the source code.

MacPorts failures under Leopard 1

Posted on December 05, 2007 by Juan
I decided I should clean up my laptop’s left over digital crap, so I went through my /usr/local directories cleaning out ancient libraries installed two OSes ago (after making a backup first). I decided I would try reinstalling MacPorts under Leopard, if only to build it clean and remove the old source code siting around from various revisions to the packages over time.First, I installed MacPorts from the disk image for Leopard. Then I attempted to install my usual suspects: sudo port install aquaterm chmdump contacts coreutils curl file findutils g95 ghostscript gv ImageMagick ksh93 latex2rtf lynx macutil osxutils plotutils subversion teTeX tidy vim wget wine xterm xephem Long story short, almost everything works but there were a few key packages that failed to build under MacOS X 10.5.1. This also reminded me that when a package fails to build, you should “port clean” the package (see examples below) before attempting to rebuild it:
  • I discovered that teTeX failed to build. This appears to be due to an undeclared dependancy on openmotif. So after the failed install, I just did ansudo port clean --work teTeX; sudo port install openmotif teTeXand teTeX installed just fine.
  • In attempting to build subversion I discovered that one of the packages subversion needs, sqlite3, fails to install on Leopard. This appears to be due to an undeclared dependancy on nawk (MacPorts Report Ticket #13500). So again, all I had to do was:sudo port clean --work sqlite3; sudo port install nawk subversionand it worked. I should note that a fairly recent version of subversion now comes with Leopard, version 1.4.4 (as opposed to 1.4.5 with MacPorts).
  • gv fails to install unless you patch it. This was reported to MacPorts (Bug Report Ticket #13095). [If you check that bug ticket, you will find a new patch-setenv.c file is available there. If you download that file and replace /opt/local/var/macports/sources/rsync.macports.org/release/ports/print/gv/files/patch-setenv.c with it, gv will compile and install just fine.]
  • osxutils fails almost immediately with a series of errors about conflicting types. Since osxutils did a lot of meta-data manipulation, I am not completely surprised it is broken under Leopard. I have submitted a bug report to MacPorts.
  • xterm fails to build. This is irritating because I haven’t had time to confirm is the old xterm Tektronix emulation bug present in the Tiger version of xterm is still present. [This appears to have been cleared up with MacPorts 1.6 if you install Xquartz over the Apple installed X11 server. Doing this is a good idea anyway.]
  • wine fails to build (already reported elsewhere [link since deleted]). This has already been reported in MacPorts Bug Report Ticket #13488. I wonder if this is related to the possibility being mentioned of Leopard having unreported support for Windows binary execution. [Wine version 0.9.51 DOES compile under Leopard just fine.]
  • I can’t build g95 because odcctools fails to compile. This has been reported in MacPorts Bug Report Ticket #13148. [This appears to have been fixed as of January 24, 2008.]
  • xephem fails to build because lesstif builds but fails to install. Actually lesstif installed fine once I moved /usr/share/aclocal/ac_find_motif.m4 out of the way. I don’t know if that file was there from my previous install of lesstif. Once lesstif was out of the way, xephem failed to build. Interestingly, MacPorts has version 3.7, I downloaded the source for xephem 3.7.2 from the Clear Sky Institute website, compiled it following the installation instructions without a hitch. I submitted a bug report as MacPorts Bug Report Ticket #13524 (turned out my bug report was a duplicate of MacPorts Bug Report Ticket #13498). This has been fixed, see this post. [This appears to have been fixed as of March 3, 2008.]
I’m actually surprised the number of packages that failed to compile seems pretty small.

HINT: What to do when Keychain-using Apps lock up 1

Posted on August 08, 2007 by Juan

Like many Macintosh users, the first few months of using MacOS X I wasn’t even aware of what the Keychain really was. After a while, you realize just what a cool little piece of security it is. It ensures many MacOS X programs can securely store passwords and other information without the programmer having to be a great cryptographic genius.

One of my favorite programs which exploits this is 1Passwd. 1Passwd stores all your web form passwords (and any other data you care to secure, like credit card numbers or software serial numbers) in a Keychain, so the cryptography is managed by Apple’s Keychain. Recently, on my iMac at home, 1Passwd started locking up whenever it tried to access it’s keychain. Specifically, I have updated 1Passwd so it presented me with a dialog to allow the updated version access to the Keychain. When I clicked continue, the dreaded rainbox beachball of doom showed up and would not go away. From that point on, logins to the machine failed and most Apps using the keychain were unable to use the keychain.

I checked the system usage from the command line

top -u -s 5

and discovered a program called securityd was eating up CPU cycles and RAM. I called up the manual page on securityd via the command line:
man securityd

and discovered:

securityd maintains security contexts and arbitrates cryptographic operations and Security Authorizations. Access to keychain items is routed through securityd to enforce access controls and to keep private keys out of user process address space. Authorization calls also communicate with securityd to enforce rules contained in the /etc/authorization database. All user interaction with securityd is mediated through the Security Agent.

So by locking up securityd, I was messing up all the cryptographic operations that ran through it. Great. I figured there had to be a corrupted file on my computer that was mucking up the works, but where. My first thought was a corrupted keychain file, so I checked out my keychains using the “Keychain First Aid” item in the Keychain Access (in /Applications/Utilities) [shown in the figure below].

Keychain Access Example

The files all checked out as intact, so that wasn’t it. Something was corrupted on my computer, but what.

Just a Google search on “securityd” later, I found the solution on the Unsanity programmers blog in an article titled “Fix for securityd hogging RAM when reauthorizing apps’ Keychain access“. In a nutshell, the corrupted file is a cryptographic database at /var/db/CodeEquivalenceDatabase. In order to fix this problem they suggest:

just open the Terminal (/Applications/Utilities/Terminal) and type:

sudo mv /var/db/CodeEquivalenceDatabase /var/db/CodeEquivalenceDatabase.old

Upon rebooting, God should be in His Heaven and all should be well with the keychain.

And I verified this worked to fix my iMac and all the Keychain apps are happy again. Excellent!

Annoyance: IRAF in Scisoft OSX mkpkg glitches 1

Posted on August 08, 2007 by Juan

Update: I have updated this blog entry to reflect some updated information from Nor Pirzkal regarding the best way to fix this glitch.  This problem has been fixed in Scisoft OSX MacIntel version (2007.9.1).

During my adventures compiling the hectospec-related IRAF packages, I was using Scisoft OSX and discovered there were a couple of issues with the symbolic links for the mkpkg command necessary for compiling new IRAF packages.

  • In the Scisoft OSX PPC Beta (2006.11.1b) mkpkg appears to be mis-linked, so it can’t be executed. So I did the following in the terminal:
    cd /scisoft/binsudo rm mkpkgsudo ln -s ../iraf/iraf/unix/bin.macosx/mkpkg.e mkpkg
  • In the Scisoft OSX MacIntel version (2007.1.1) and Scisoft OSX MacIntel version (2007.7.1), there are some missing symbolic links to mkpkg and xc in the directory for MacIntel binaries.  As a result, both mkpkg and xc were instead pointing to PowerPC binaries. I fixed this as follows (again, from the command line):
    cd /scisoft/i386/bin/sudo ln -s /scisoft/all/packages/iraf/iraf/unix/bin.macintel/mkpkg.e mkpkgsudo ln -s /scisoft/all/packages/iraf/iraf/unix/bin.macintel/xc.e xc
    This mis-linking certainly didn’t help getting things to compile under MacIntel, since IRAF was attempting to compile MacIntel code using PowerPC versions of mkpkg and xc.

Thanks for Nor Pirzkal for giving me some feedback on fixing this problem.  He tells me he has made the appropriate changes so that the next version of Scisoft OSX will not have this  issue.By the way, my complaint here should in no way be construed as a critique of the efforts of Francesco Pierfedericki and Nor Pirzkal in putting together Scisoft OSX. They have done a great deal of work to put together an awesome package. For two people to track over 2 GB of software and not expect some glitches is unrealistic. And I for one am extremely grateful that his efforts have saved me a lot of time.

HINTS: X11 on MacOS X 0

Posted on August 01, 2007 by Juan

On the Mac, X11 is part of the optional install. To quote Apple’s X11 Developer Note on Installing and Configuring X11 Applications on MacOS X on the Mac:

X11 is available as an optional install on the […] Mac OS X v10.4 Tiger install disks. Run the Installer, select the X11 option, and follow the instructions.

Once you have installed X11, you can launch X11 by going to the /Applications/Utilities/ directory and double clicking X11.app (this may display in the Finder as “X11” depending on your settings for showing File Extensions). And now some hints for better X11 usage (these are not in any particular order):

  1. If you are an astronomer, you probably use a lot of programs like IRAF, AIPS, or XEphemthat need X11. So it probably makes a lot of sense to set it up so that X11 automatically launches when you login. To do this:
    • Open your “Accounts” preference pane in the System Preferences.
    • Choose the “Login Items” tab within the Accounts pane and then you will see a list of login items (possibly empty).
    • You can add X11 to this list by pressing “+” at the bottom of the list of login items. This will bring up a dialog to select the file, work your way to the /Applications/Utilities/ directory and select X11 and you are done. NOTE: On MacOS X Tiger, there is no ability to control the order in which items are launched, so its position on the list is somewhat meaningless.
  2. There are many hidden preferences in X11 just like in many Mac Applications. You can see a list of the hidden (and not hidden) preferences using the command line tool defaults. To see the available X11 preferences, type:
    defaults read com.apple.x11
    
    In addition to “reading” the preferences, you can write to them. From the command line you can type:

    • defaults write com.apple.x11 no_quit_alert true

      This allows X11 to quit without an alert box. Useful if you find it irritating like I do that X11 will prevent me from logging out or the computer from restarting due to that dialog box. However, this does mean you can accidentally quit X11.app pretty easily if you hit cmd-Q at the wrong time.

    • defaults write com.apple.x11 wm_ffm true

      Allows which X11 window is selected to follow the mouse, which is the way X11 behaves under most *nix systems by default.

    • defaults write com.apple.x11 wm_click_through -bool true

      This activates click_thorough events in the Quartz window manager, which allows clicks to pinned windows, another behavior common to *nix X11 installations.

  3. On the Mac X11 launches the quartz-wm Window Manager and while you can run any other window manager of your choosing, I like it. However, if you modify your ~/.xinitrc file, you can control which window manager is launched. If you don’t have a ~/.xinitrc file, copy the default one:
    cp /private/etc/X11/xinit/xinitrc ~/.xinitc
    
    and then manipulate it with any text editor.

  4. You can launch an X11 application from the Terminal directly if you have set the DISPLAY environmental variable properly or by using the open-x11 command, for example:
    xclock &
    

    will launch the xclock in the background if I have already set the >DISPLAY variable.

    open-x11 /usr/X11R6/bin/xclock &
    
    will do the same without DISPLAY being set.

  5. BIG LAPTOP USER HINT: Because X11 on the Macintosh uses authentication to prevent connections from unauthorized sources to the X11 client, something interesting happens when you change IP address, you will discover you can’t use X11.app from the MacOS X Terminal until you quite and relaunch X11.app. This happens to me all the time on my laptop when I travel and the IP address changes. I recommend either using the Xterm as your terminal or just get used to restarting X11 if you have problems connecting to the terminal.
  6. You can run X11 remotely on your Mac, if you can ssh into your Mac, then just use

    ssh -Y youraccount@yourcomputer.com

    the -Y flag should allow you to run X11 remotely as long as X11.app is running on your machine before the connection is made. If your ssh on the remote machine doesn’t support X11 connections and you have admin access, you can edit the file /etc/sshd_config on the remote machine and make sure X11 Forwarding is turned on by looking for the following lines and making sure they are uncommented and that all “no”’s are set to “yes”:

    X11Forwarding yes<br />X11DisplayOffset 10<br />X11UseLocalhost yes
    
  7. The X11 Dock icon on the Mac can let you select specific X11 windows when X11 apps are running.X11 Menu
  8. Tektronix emulation in xterm is broken under MacOS X (at least in Tiger). To get it functional again, see my previous posting about this.

And that is it for the hints for now.

Annoyance: ksh doesn’t work on MacOS X Tiger 0

Posted on July 19, 2007 by Juan

After several days of trying to get the Hectospec folk’s data reduction packages working on my Mac, I realized one of the major problems was that ksh on the Macintosh had a major problem. Normally, in ksh (korn shell), you can set up a loop to read through a list of objects via a read command within a while..do loop. For example, to echo a list of files your ksh script could contain

#!/bin/ksh
ls -1 . | while read fname; do
  echo $fname
done

where the read filename bit reads a line from the piped input and assigns the first block of text (before a space) to the variable fname. Try this script on MacOS X and it produces no output. “read” fails. This has been documented elsewhere at least twice that I have been able to find with Google, here and here. So clearly, there is a serious bug in the installed version of ksh on MacOS X. I fixed it by updating my ksh using MacPorts, a simple
sudo port install ksh93

followed by changes in the Hectospec scripts to point to/opt/local/bin/ksh instead of /bin/ksh and I was done.

  • Translate

  • Astro Pic o' the Day

  • Archives

  • Admin



↑ Top