PDTY Tech Notes

The following is a picture of a frog:

I recently had to install Crypt-SSLeay on Solaris 8 and the process was not exactly straightforward. The following assumes an installation of OpenSSL in /usr/local/ssl. This can either be compiled from source or via the sunfreeware package.

$ gzip -dc Crypt-SSLeay-0.57.tar.gz | tar xvf -
$ cd Crypt-SSLeay-0.57
$ perl Makefile.PL 
=======================================================

Only one OpenSSL installation found at /usr/local/ssl

Consider running 'perl Makefile.PL --default' the next

time Crypt::SSLeay is upgraded to select this directory

automatically thereby avoiding the following prompt.

=======================================================

Which SSL install path do you want to use? [/usr/local/ssl] 

BUILD INFORMATION

================================================

ssl library: OpenSSL 0.9.8 in /usr/local/ssl

ssl header:  openssl/ssl.h

libraries:   -L/usr/local/ssl/lib -lssl -lcrypto -lgcc

include dir: -I/usr/local/ssl/include/openssl

================================================

Checking if your kit is complete...

Looks good

Note (probably harmless): No library found for -lgcc

Writing Makefile for Crypt::SSLeay

The test suite can attempt to connect to public servers

to ensure that the code is working properly. If you are

behind a strict firewall or have no network connectivity,

these tests may fail (through no fault of the code).

Do you want to run the live tests (y/N) ? [N] y

At this point, you will have to edit the Makefile by modifying the INC line. You will take out the trailing "openssl" as this will be added by other code and if it is there, the path will be incorrect and the build will fail.

$ vi Makefile

Do this so you end up with the following diff:

$ diff Makefile.orig Makefile
117c117
< INC = -I/usr/local/ssl/include/openssl
---
> INC = -I/usr/local/ssl/include

Finally, finish the build:

$ make
# make install

Test with this (modified from http://www.perl.com/pub/a/2002/08/20/perlandlwp.html?page=5 ):

#!/usr/bin/perl

use LWP;

  my $url = 'https://www.uni.edu/';   # Yes, HTTPS!

  my $browser = LWP::UserAgent->new;

  my $response = $browser->get($url);

  die "Error at $url\n ", $response->status_line, "\n Aborting"

   unless $response->is_success;

  print "Whee, it worked!  I got that ",

   $response->content_type, " document!\n";

Helpful sites:

http://www.cpanforum.com/threads/6051

I noticed a problem mounting all dmg files on my 12" Powerbook G4/1.33Ghz after doing the latest security updates for Mac OS X 10.4.9. I use
dmg files on a daily basis so this was rather disruptive to my work flow. The following outlines how I resolved the situation.

The initial patch was done under the following conditions:

• Updated via Software Update in the Apple menu




• All user applications were closed when doing the updates




• Quicksilver β51 (3800) installed and running

After ruling out corrupted downloads, trying downloads from both Firefox and Safari, I did a bit of googling and found some others with
similar problems.

The following is what I did to fix my system. Please note that I realize there are ways to do all this via the command line, but I wanted to document exactly what I did for complete accuracy.

1. Download the standalone installer for PPC from http://www.apple.com/downloads/macosx/apple/




2. Mount the standalone installer dmg file on another mac




3. In a terminal window on my second mac go to the Volumes folder: cd /Volumes




4. Copy the Update file, SecUpd2007-004Ti.pkg, to my desktop on the second mac: cp -Rp SecUpd2007-004Ti.pkg ~/Desktop




5. Right click on the SecUpd2007-004Ti.pkg file and "Create Archive"




6. Move the resulting zip file back to the first mac. I used scp, but any file transfer method will be fine.




7. Back on the first mac, unzip the file you just moved. You should now have a copy of SecUpd2007-004Ti.pkg on the problem mac.




8. Close out of everything. For me this included closing out of Quicksilver and all running applications.




9. Double click on SecUpd2007-004Ti.pkg and follow all instructions




10. Reboot when the installer asks you to do so

At this point, for me at least, the problem was solved. Your millage may vary.

Due to a recent security flaw in mod_rewrite, I needed to recompile Apache 1.3.37, mod_ssl 2.8.28, and mod_perl 1.29 on various Linux, Mac OS X and Solaris 9 servers. I also took this opportunity to move us from openssl 0.9.7 to openssl 0.9.8b, which has been on my mid-priority list for a while now.

All was fine on Linux and Mac OS X. Then came Solaris 9.....

I'll cut to the chase and simply outline the recipe for making this work. It's not exactly pretty, but it will allow you to make a custom install of apache on Solaris 9. This appears to be similar to an older problem.

Note: Some of the commands and output may be truncated when viewed on the main page of this site. You may need to view it on the permanent link to see all the relevant details.

1. Compile openssl 0.9.7j or 0.9.8b. I tried both to see if it was a compatibility problem with openssl, and found that it wasn't and I confirmed that the rest of these instructions work for both versions.

	./config --prefix=/usr/local/ssl

	make

	make test

	make install

2. Setup mod_ssl-2.8.28-1.3.37:

	./configure --with-apache=../apache_1.3.37/

3. Compile mod_perl-1.29:

	/usr/local/bin/perl Makefile.PL APACHE_SRC=../apache_1.3.37/src USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1

	make

	make install

4. Compile apache_1.3.37. Note the parts where you have to copy a particular file around. This is magic in this potion:

	export SSL_BASE=/usr/local/ssl ; ./configure --with-layout=GNU --prefix=/usr/local/apache --with-perl=/usr/local/bin/perl --server-uid=apache --server-gid=apache --enable-module=rewrite --enable-module=ssl --enable-module=so

	cp src/modules/ssl/ssl_expr_scan.c /tmp/ssl_expr_scan.c_before_make

	make

	gcc -c  -I../../os/unix -I../../include   -DSOLARIS2=290 -DMOD_SSL=208128 -DEAPI `../../apaci` -DSSL_COMPAT -	DSSL_ENGINE -I/usr/local/ssl/include -DMOD_SSL_VERSION=\"2.8.28\" ssl_expr_scan.c

	lex.ssl_expr_yy.c:1900: error: parse error before numeric constant

	lex.ssl_expr_yy.c: In function `ssl_expr_yy_scan_string':

	lex.ssl_expr_yy.c:1901: error: number of arguments doesn't match prototype

	lex.ssl_expr_yy.c:293: error: prototype declaration

	lex.ssl_expr_yy.c:1903: warning: passing arg 1 of `strlen' makes pointer from integer without a cast

	lex.ssl_expr_yy.c:1903: warning: passing arg 1 of `ssl_expr_yy_scan_bytes' makes pointer from integer without a cast

	make[4]: *** [ssl_expr_scan.o] Error 1

	make[3]: *** [all] Error 1

	make[2]: *** [subdirs] Error 1

	make[2]: Leaving directory `/export/home/updates/apache-1.3.37/apache_1.3.37/src'

	make[1]: *** [build-std] Error 2

	make[1]: Leaving directory `/export/home/updates/apache-1.3.37/apache_1.3.37'

	make: *** [build] Error 2

	cp /tmp/ssl_expr_scan.c_before_make  src/modules/ssl/ssl_expr_scan.c

	make

	make install

5. Finally setup your certs, /usr/local/apache/etc/httpd.conf file and start apache with SSL support"

	/usr/local/apache/sbin/apachectl startssl

The following lists the versions of software used for this process:

Apple Remote Desktop v2.2 allows you to connect to any system running VNC. The following outlines how to configure ARD to use an ssh tunneled VNC session.

First add a new connection to the list of available connections by clicking on File, then select Add by Address... This will pop up a window that should be filled out as follows:

You can now use ARD to connect to any VNC session you have tunneled via SSH.

For more information about VNC and SSH see my post on using x11vnc and ssh for secure remote console login on solaris.

I recently had a catastrophic hard drive failure on my powerbook. Thankfully, I had a decent backup and Applecare. So after about a week of getting everything "just right" again, I tried to play some purchased music in iTunes only to find that I wasn't authorized to play "my" music. (I promise not to rant on DRM right now, I'll save that for another day)

The iTunes music store authenticated my account, but it wouldn't actually play the music, saying that a directory was missing or that the permissions were wrong. It didn't actually say what the directory in question was, but suggested I use my psychic sysadmin powers to find it and fix the permissions. The other option was to de-authorize my computer for my account and then reauthorized. I tried that first, and it didn't work, giving me the same error.

I then consulted with a few other tech people and a suggestion was made that I run the magical "fix permissions" option in Disk Utility. I did this and one of the first things it did was recreate the /Users/Shared folder. After this, I was able to authorize my computer for "my" music again.

Checking that directory, I found that there was a directory called "SC Info" with a file called "SC Info.sidb" inside. I had accidently deleted the "Shared" directory a couple days ago, and not realizing that it was anything important, I never bothered to recreate it. This directory must there for iTunes authorization to work properly.

Live and learn...

Links:

1. Apple Information on authorizing computers for iTunes
2. Erik J. Barzeski's blog entry on iTunes authorization
3. More information about "SuperCollider" which apparently is what the "SC" stands for in the mystery file

When editing sensitive files with vim, be sure to use the following form to ensure that a swap file is not used when editing:

vi -n filename

If you do not use this flag, a swap file is created that can be used to recover your editing session if something goes wrong. However, when editing sensitive files, for instance the plaintext of an encrypted file, this is undesirable as the swap file could be recovered.

It should be noted that a secure delete program should be used to clean off the plaintext of an encrypted file after you are done editing. Mac OS X comes with "srm" which does a fine job. You can compile srm for other platforms using the source code found at:

http://srm.sourceforge.net/

It seems that there are an increasing number of cases where you need graphical access to a Solaris machine. For instance the Oracle installer is a GUI, and several management tools are GUI only, or difficult to do without the GUI.

I've used VNC for this in the past, but recently stumbled accross x11vnc, which operates similarly to VNC on windows or the mac. That is, it connects to an existing display and controls (or simply non-interactively views) that display. This works great as long as you are already logged into the remote Solaris box. But wouldn't it be nice to be able to connect to dtlogin via VNC? Yeah, I thought so too. The following outlines what I did to make this happen.

1. Download, compile and install x11vnc. Make sure you pay attention to the section on compiling for Solaris. I had good luck with the following compile line on my Solaris 9 machines:
   
   

   
   env PATH=/usr/local/bin:/usr/ccs/bin:$PATH CPPFLAGS='-I /usr/sfw/include' LDFLAGS='-L/usr/sfw/lib -R/usr/sfw/lib' sh -c './configure; make'
   
   

   
   Then install:
   
   

   
   make install
   



2. You will need to make some slight modifications to two configuration files for the X server on your Solaris box. Copy Xconfig and Xsetup from /usr/dt/config/ to /etc/dt/config/ as follows:
   
   

   
   
   cp /usr/dt/config/Xconfig /etc/dt/config/Xconfig
   
   cp /usr/dt/config/Xsetup /etc/dt/config/Xsetup
   
   
   

   
   



3. Uncomment the following line in /etc/dt/config/Xconfig:
   
   

   
   Dtlogin*grabServer: False
   
   

   
   



4. Add the following line to /etc/dt/config/Xsetup:
   
   

   
   /usr/local/bin/x11vnc -forever -o /var/log/x11vnc.log -bg
   
   

   
   



5. Restart dtlogin:
   
   

   
   /etc/init.d/dtlogin stop
   
   /etc/init.d/dtlogin start
   
   

6. VNC doesn't natively support encryption, so it's best to tunnel your connection through ssh. You can do this by typing the following on your client machine:
   
   

   
   ssh -L 5901:localhost:5901 remote_machine_name
   
   

   
   This sets up a tunnel that connects your local port 5900 to the remote port 5900. This is the port that VNC runs on.
   



7. Connect to localhost display 0 with your VNC client. Since we setup an ssh tunnel, any connections to your local port 5900 will be automatically forwarded via the encryption tunnel to the remote machine.
   
   

   
   You should now see dtlogin in your VNC client. Log in as you normally would. Note that when you log off, your VNC client will drop the connection. However, x11vnc is still running and you should be able to connect to the server again immediately.
   
   

   
   The x11vnc server should now start when the machine boots. Ideally, you would block this port to outside connections with a host based firewall to restrict access to ssh tunneled connections only. However, that will have to wait for another day. :)
   

On the client machine with OpenSSH installed, do the following to set up your keypair:

1. Create your keys by typing the following while in the .ssh directory in your home directory:
   

   
   $ ssh-keygen -b 2048 -t rsa
   
   

   
   You will be asked for a filename to save the keys in, as well as being asked for a passphrase. If you want to use this key in a script, you will likely want to provide a blank password. This process might looks something like this:
   
   

   
   
   Generating public/private rsa key pair.
   
   Enter file in which to save the key (/export/home/username/.ssh/id_rsa): 
   
   Enter passphrase (empty for no passphrase): 
   
   Enter same passphrase again: 
   
   Your identification has been saved in /export/home/username/.ssh/id_rsa.
   
   Your public key has been saved in /export/home/username/.ssh/id_rsa.pub.
   
   The key fingerprint is:
   
   7d:34:2f:59:af:a7:0e:44:55:5f:fd:05:78:61:bb:19 username@machinename

   
   
   

   
   This will create two files in your .ssh directory called id_rsa and id_rsa.pub.
   



2. Next you need to convert the key to a format that will be recognized by the commercial SSH server:
   

   
   ssh-keygen -e -f id_rsa.pub > id_rsa_username-machinename.pub

   
   



3. Next copy this file to the .ssh2 directory in your home directory on the server.


4. Next create a file called authorization and put a line in it like the following that points to the key you just copied to the server:
   

   
   Key id_rsa_username-machinename.pub
   
   

   
   This file can contain multiple lines each pointing to a different key for a different client machine.

I recently needed to add the Adobe Acrobat reader as a plugin in Firefox on Solaris. I found some instructions on doing this, but needed to make some modifications to get this to work. The following is what I did:

1. Install Acrobat with the included install script somewhere on your system. I chose /usr/local/Acrobat5


2. Issue the following command as root:
   
   crle -s /usr/lib/secure/64:/usr/lib/64


3. You need to put the acroread executable in your path. I did this with a symlink:
   
   ln -s /usr/local/Acrobat5/bin/acroread /usr/local/bin/acroread


4. You then add a symlink for the plugin to firefox:
   
   ln -s /usr/local/Acrobat5/Browsers/sparcsolaris/nppdf.so nppdf.so