Sunny Days – Day 4

As I mentioned yesterday, the next task at hand was to get PHP running on the Sun T2000. For the guides by Mel Leter jr. had been very helpful so far, I decided to use his PHP guide, too. This proved to be not as easy as the steps before.

PHP – Preparations
To install PHP, a lot of GNU utilities is needed. So you have to install them first. This is done best using pkg-get from BlastWave – at least that’s what Mel’s guide says. On Blastwave’s site it says to download the pkg-get package to your Sun and install it from there. Easier said than done for I didn’t find any utility like curl, links, lynx or wget on the Sun and also didn’t find any real browser I could have redirected through my SSH session. So what I did was to download the file to my local machine and copy it to the Sun from there using scp.

(This is on my local Linux box)

$ wget http://www.blastwave.org/pkg_get.pkg
$ scp pkg_get.pkg stefan@sun-p1:soft/

As you can see, I was using the account stefan on the Sun. In the home directory of that account I had created a sub-directory called soft. That’s where I intended to put all the software I was going to install on the Sun so I could move it over to /root/soft for compiling and installing later.
Back on the Sun I installed pkg-get using “pkgadd -d /home/stefan/soft/pkg-get.pkg”.

Afterwards I read on through the documentation on BlastWave to learn that I would have had wget already. As many other tools it is sitting happily in /usr/sfw/bin/ – it’s just that the PATH variable for some obscure reasons doesn’t contain that very directory. This could be fixed by adding it to the $PATH variable and export that afterwards. For this would have to be done every time I’d need some tools from /usr/sfw/bin I decided to look for a more permanent solution.

Adding Pathes, Choosing Shell
Before I made those changes, I also changed the home directory for the root user from its default location at “/” to “/root”. This I did to better accommodate for building software, shell scripts and other goodies later. So first I edited /etc/passwd to change the location of root’s home directory there.

While I was already editing /etc/passwd I took the chance to get rid of the standard shell sh used by default on Solaris 10 and get back my loved Bourne Again Shell bash instead. To achieve this, I replaced the string /sbin/sh for the user root and /bin/sh for the user stefan with /bin/bash. I was able to do this because I chose to use local user authentication. In case you opted for NIS, NIS+ or LDAP, chances are you won’t be able to change your shell that easily. After saving the file I immediately created root’s new home directory manually, gave it the right permissions and copied the dot-files and directories into it:

# mkdir /root
chown root:root /root
chmod 700 /root
cd /
cp -rp .* /root/

I then went on to permanently fix the PATH variable. The easiest way to do this was to edit the file .profile in one’s home dir. I added the following lines:

if [ -d /opt/csw/bin ]
then
PATH=${PATH}:/opt/csw/bin
fi
if [ -d /usr/sfw/bin ]
then
PATH=${PATH}:/usr/sfw/bin
fi
export PATH

As you can see, these changes not only add /usr/sfw/bin to the search path but also /opt/csw/bin because that’s where pkg-get will put the binaries from BlastWave.

I also edited the profile of my normal user account. This could be found in /export/home/stefan/.profile. And to ensure that all newly created user accounts would have the expanded path information, too, I also added the lines to /etc/skel/local.profile. That’s the file that will be copied to every newly created user’s home directory as .profile. For logins from other workstations proved that the changes worked as expected, I went on installing BlastWave.

Installing GNU tools
As I already mentioned, installing PHP requires some GNU utilities, namely autoconf, automake and gsed. To get them onto my Sun, I thought I had to just follow the steps outlined in Mel’s guide. At hat point however, I realized that my Sun couldn’t connect to the outside world. It had no default gateway in the routing table. So some more reading was in order, this time in System Administration Guide: IP Services. The fix was easy to find: Just edit/create the file /etc/defaultrouter, put the address of the desired router in there and restart the networking services using „svcadm restart network/physical“. Now I could finally install the GNU tools needed.

However, the first command „pkg-get -i autoconf“ resulted in a warning. I was asked whether to overwrite or at least modify files already present on the system. After weighing my options I decided to let pkg-get do so, while praying that this was the right decision. For now I can’t tell whether it was, but so far I didn’t encounter any problems so I’m tempted to believe I made the right choice.

Actually, the commands will not only install the tools mentioned but also some support files needed for the tools to work. So don’t worry if after giving the command you see a lot of installation messages scrolling over the screen in a flurry.

I then continued by verifying the existence and versions of the other tools needed. Again, as instructed by Mel’s guide. Doing this I found that instead of having Perl 5.8.7 as his guide showed, my version was only 5.8.4. Although this isn’t a real problem I found this to be a good time to have a little look into updating the Solaris operating system itself.

Updating Solaris 10
Updating the OS usually is a pretty straightforward process and that’s not too different with Solaris 10. However, to be able to use the Software Update Service, you’ve got to register your Sun first. This can be done on the command line or by using the Sun Update Manager. I choose the latter option because it would give me some eye candy by using a graphical interface. The update manager application is started using „/usr/bin/updatemananger” on the command line.

Registration was quite easy. Since I haven’t signed up for any support plan, all I could do was choose the basic option. That would only give me access to a limited set of updates but, hey, as long as security fixes and critical updates were included, I don’t mind. The only thing that pissed me off a bit was that my favorite user name was already taken, but that’s hardly Sun’s fault ;-)

After I completed the registration process by sending the hardware info, Update Manager showed a list of 65 applicable updates, which I all selected. Then I started the installation process and waited. And waited. And waited. Went to brew some more coffee. And waited. Installed Windows Server 2003 x64 Edition on another machine, just for the fun of it. And waited. Installed SUSE Linux Enterprise Server, 64 bit Edition, on yet another machine. And waited. Finally, after roughly three hours, the update process had completed. Others fared worse.

The reason why the update took so excruciatingly long is that the connection to the update server is extremely slooooooooow. It averaged at a meager transfer rate of 40 kByte/s while the 6 Mbps line the Sun is connected to could easily do fifteen to twenty times more.

Since I had seen enough of Update Manager and also some updates had failed, I decided that after the necessary reboot I’d give the command line utility smpatch a try. This tool can be called with three different parameters: analyze, download and update. The first will tell you what updates if any are available, the second will download them and the third install them. You can just use „smpatch update” to perform all three steps in one. That’s what I did and then I waited. And waited. Ok, enough of that ;-) It took another 60 minutes and two reboots to get the rest of the updates installed.

One problem with the reboots, though. The smpatch utility was nice enough to suggest a reboot using „init 6”. After I issued that command nothing happened on the console. No message telling me that the system was going to shut down, no nothing. However, the hard disk lights started flashing, indicating activity (sometimes it pays off to work at a desk where you can actually *see* the machine). So I decided to wait a bit. Roughly five minutes later the Sun really restarted.

An aside: Some very helpful hints about system configuration can be found at Rutgers.edu.

After all the upgrading was finished, I returned back to where I initially started off: installing PHP.

Testing the compiler
As suggested by Mel’s guide, I tested the gcc compiler by compiling libxml2. While doing so I found that unpacking files could be done easier than using gunzip and pipe the result through gtar. For unpacking .tar.gz files you can use

# gtar xvzf <file_to_unpack>.tar.gz

Similarly, for .tar.bz2 you use

# gtar xvjf <file_to_unpack>.tar.bz2

Note, that on Solaris 10 it’s gtar not just tar. After libxml2 compiled successfully I however decided to not install it. That’s because while the system update ran I also used the time to check out BlastWave a bit more. By doing this I learned that I could install almost all libraries and packages needed from there – even PHP.

For I wanted to replicate the setup I had on Linux as close as possible I chose a mix: I’d install all the support libraries needed from BlastWave but would compile PHP from scratch. This forced me to make a lot of trivial changes to the configuration file I tend to use when compiling PHP: I had to give a path for every library I intended to use. So I ended up with many configure-edit runs. I have to admit that I wasn’t able to instal IMAP support on this run.

Even if I had been able to get IMAP to work it wouldn’t have helped much. For some obscure reason PHP configured fine but resisted all attempts to link against the libraries installed from BlastWave. Thus, I called it a day and decided to install the libraries manually.

Lessons learned

[ All posts about my experiences with the SunFire T2000 >>> ]