Mar 192009
 

I have some minor sites running on the basement OpenSolaris box, and since our IP address changes regularly, I use ddclient to notify DynDNS of the changes. It was working just fine on the old Debian box, but of course OpenSolaris does things differently, and the ddclient package doesn’t come with all the bits you need to make it work.

Step one: download the ddclient package from Sourceforge, and follow the instructions in the README as to where to install it. Easy enough, done.

Step two: go to the DynDNS site, log in to the account, go to the Support Tools section of the website, and click on the “Update Client Configurator”. This takes you to a page that will automatically generate the configuration file for ddclient for your account. This is one of the reasons I like DynDNS, by the way, they think of little useful tools like this.

Step three: make the configuration changes in the ddclient.conf file, and try running the ddclient Perl script to see if it works, using ddclient -daemon=0 -debug -verbose -noquiet to get all the error messages. One tip: if you have spaces in your password, surround it with single quotes, not double quotes. The latter don’t work.

Step four: the hardest for someone new to OpenSolaris is to figure out how to run the daemon. It turns out that Solaris has a “Services Management Facility” (SMF). The specific instructions to follow, once you’ve figured out the basic concepts, are at Chris Gerhard’s ddclient meets SMF. Mind you, I did need to read the documentation on Managing Services to find out where to put the file (/var/svc/manifest). Just as well Sun lets lots of people blog, it certainly makes it easier to find information. I do wish they could figure out how to give their standard documentation memorable URIs though.

Now I just have to wait until our local IP address changes to see if it works. [Update: yup, it works.]

Feb 172009
 

By default, OpenSolaris doesn’t broadcast the hostname on the local network, just the IP address. To rectify this, find out what network interface you have (often nge0) by running ifconfig -a. It’ll be the one with the IP address given by the router (i.e., not 127.0.0.1).

Then, as root, edit the file /etc/default/dhcpagent. Find the line # CLIENT_ID=, delete the # to uncomment the line, and append your hostname. Find the line # REQUEST_HOSTNAME=no and change to REQUEST_HOSTNAME=yes. As documented in that file, you also need to edit your /etc/hostname.<if> file, where <if> is your network interface (often nge0), adding the line inet hostname.

You can then either reboot the machine, or renew the DHCP lease on a console on the machine (since it will disconnect you from any SSH sessions). As root, first execute ifconfig <if> dhcp release to discard the current lease, then ifconfig <if> dhcp start to start DHCP on the interface again. Complete documentation can be found through the man ifconfig and man dhcpagent pages.

Result: I can see the hostname through the DHCP server now, which I couldn’t before, but I still can’t see it from the Windows box. So that’s another piece of the puzzle to track down.

Mind you, I need to give the Solaris box a static IP address for serving websites, so the DHCP naming thing is moot. It would be nice to be able to ssh <hostname> from other machines on the network rather than using the IP address though.

Feb 092009
 

One of the things I’ve wanted to do for a while was move the firewall/router and minor web sites served from an old Pentium 3 in the basement to a more modern solution. I’ve blogged some of the journey, starting with the motivation and moving through the todo list. Yesterday was the day for the big switch.

After a couple of hours twiddling this and that, getting rid of spare cables, and vacuuming the backs of computers that seldom get this treatment, we now have a hardware firewall/router and some minor web sites powered by a Sun Ultra 20 OpenSolaris, rather than relying on an old Pentium 3 doing all of that. It’s amazing how much faster the minor sites load on a system with a decent amount of memory!

In other words, we’ve now gone from

old firewall + website server

old firewall + website server

and
wires

wires

to
new website server

new website server

(Photos by Tim Bray)

I still have to set up ddclient or something similar to inform DynDNS when our IP address changes, and there are some oddities, such as the Solaris box not broadcasting its hostname to the router which I want to track down. For some reason the Solaris box didn’t start the Ethernet connection properly on reboot, but I don’t yet know whether that was a random occurrence or something that I have to pay attention to. Still, things are working, at least until our next power outage. Whether it works past that depends on whether the router moves around the IP addresses it assigns, which would mean the IP-based forwarding not forwarding to the right place. I may end up installing dd wrt or something similar on the firewall (although it appears the particular one I have doesn’t support dd wrt itself), but for the time being I’m running the original software and it seems to do the job.

Feb 022009
 

The next step in the list for moving my minor websites to OpenSolaris (see the first post for the motivation) was to set up MySQL. After I downloaded the OpenSolaris Web Stack package, MySQL was installed and running, so it was more a matter of tweaking. Little things like copying the /etc/mysql/5.0/my-huge.cnf to /etc/mysql/my.cnf so that the default configuration takes advantage of the 2 GB of RAM, for example.

I’ve heard conflicting things about whether one needs a root password for MySQL, given that it uses the Unix root identity by default. After my years in security and identity I decided to set one anyway, as recommended by the MySQL post-installation setup documentation, even if it would be hard for anyone to get into the machine to do any damage, since it will be behind a firewall/router.

The next step was to move the WordPress-based sites. I decided to try the export/import facilities in WordPress, since I haven’t tried those out before, and it meant being able to use a new MySQL database with no cruft in it. I set up new users for the specific databases, copied the files across with rsync, imported the XML file, and voila! It all worked out pretty well, although resetting the various configuration options in WordPress took a few minutes.

Jan 292009
 

Since the Apache access logs grow with time, I like to rotate them once a month or so (for minor sites that don’t get much traffic). On Debian, you use logrotate (I’ve written about setting it up here). On OpenSolaris, you use the logadm command, with the actual rotation being specified in /etc/logadm.conf. When you look at that file, it warns you not to edit it by hand, which I found mildly amusing. Since you can make changes via the logadm command itself, I figured I’d try that out.

For Apache log files in the usual place, /var/apache2/2.2/logs/access_log, reading the man pages for logadm gives

logadm -w apache -p 1m -C 24\ 
-t '/var/apache2/2.2/old_logs/access_log.%Y-%m'\
-a '/usr/apache2/2.2/bin/apachectl graceful'\
/var/apache2/2.2/logs/access_log

Testing with logadm -p now apache seems to work just fine. I’ll know more about how reliable it is in a month.

Jan 162009
 

Notes on installing Apache’s virtual hosts on OpenSolaris 2008.11; part of a series that started with Installing OpenSolaris.

On Debian, you have to set up virtual hosts using separate files, called sites-enabled and sites-available, part of the Debian Way Of Doing Things, which is not documented on the Apache site. (I’ve written about this before; the link I refer to there is no longer available, so try this one if you’re on a Debian or Ubuntu platform.) Fortunately, OpenSolaris seems to use the standard Apache methods, so named virtual hosts can be set up using the documentation at Name-based Virtual Host Support (the method you choose when you want to run multiple web sites from one IP address). It’s easy to find the httpd.conf file, it’s in the Web Stack Options application, under Advanced Configuration on the Apache2 tab (and even labelled “edit httpd.conf“).

I set up a virtual host for each web site on the development machine. This is a little more complicated than it is if you’re starting from scratch with a new site, since I want to be able to set up all the software and systems on each web site on a test basis, before switching the old server off and the new one on. In the meantime of course, the old server is still serving those websites with the same URLs. So I needed a system that allows the computer I’m developing on to see the new sites reached from those URLs, while the rest of the world sees the old sites.

The way to do this is to edit the hosts file on the development machine. In a terminal window, type pfexec vim /etc/hosts. After the bottom line, which should look something like 127.0.0.1 machinename.local localhost loghost, add the line(s) 127.0.0.1 websitename. You don’t even need to reboot or restart the Apache server, which is nice. If it doesn’t work (you don’t see what you expect in your browser), take a look at your /etc/nsswitch.conf file and make sure that the hosts line has the files directive before the dns directive, otherwise the system will ask the DNS server (which will return the site the rest of the world sees) before asking the hosts file on your system. One way to check which IP address you’re looking at to make sure you’re looking at your test system, not the outside one on the net, is to use getent hosts websitename. This should tell you the IP address is 127.0.0.1. The common alternative command, host websitename, asks the DNS server and thus will tell you what the outside world sees.

Debugging the httpd.conf file is the next step, to make sure you have those virtual hosts set up correctly. In the end, I just added

NameVirtualHost *:80

<VirtualHost *:80>
  ServerName domainname
  ServerAlias domainname www.domainname
  DocumentRoot "/var/apache2/2.2/htdocs/domain"
  CustomLog "/var/apache2/2.2/logs/access_log" combined
</VirtualHost>

to the end of the existing httpd.conf file.

Update: I also had to add

  <Directory /var/apache2/2.2/htdocs/domain>
         Options Indexes MultiViews FollowSymLinks
          AllowOverride FileInfo
          Order allow,deny
          Allow from all
</Directory>

to the virtual host directive (just above the custom log line) to make WordPress’s prettier permalinks work.

The one thing OpenSolaris does that is different to the Apache documentation is putting things somewhere different, so instead of using /usr/local/apache2/bin/httpd -S to debug the virtual host configuration, you use /usr/apache2/2.2/bin/httpd -S. I learned the hard way that if you want to use a default virtual host, you have to define a ServerName for it.

/* ]]> */