Category: Technology

OpenSolaris Hostname on DHCP

By default, OpenSol­ar­is does­n’t broad­cast the host­name on the loc­al net­work, just the IP address. To rec­ti­fy this, find out what net­work inter­face you have (often nge0) by run­ning ifconfig -a. It’ll be the one with the IP address giv­en 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 uncom­ment the line, and append your host­name. Find the line # REQUEST_HOSTNAME=no and change to REQUEST_HOSTNAME=yes. As doc­u­mented in that file, you also need to edit your /etc/hostname.<if> file, where <if> is your net­work inter­face (often nge0), adding the line inet hostname.

You can then either reboot the machine, or renew the DHCP lease on a con­sole on the machine (since it will dis­con­nect you from any SSH ses­sions). As root, first execute ifconfig <if> dhcp release to dis­card the cur­rent lease, then ifconfig <if> dhcp start to start DHCP on the inter­face again. Com­plete doc­u­ment­a­tion can be found through the man ifconfig and man dhcpagent pages.

Res­ult: I can see the host­name through the DHCP serv­er now, which I could­n’t before, but I still can­’t see it from the Win­dows box. So that’s anoth­er piece of the puzzle to track down.

Mind you, I need to give the Sol­ar­is box a stat­ic IP address for serving web­sites, so the DHCP nam­ing thing is moot. It would be nice to be able to ssh <hostname> from oth­er machines on the net­work rather than using the IP address though.

Re-routing

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 Pen­ti­um 3 in the base­ment to a more mod­ern solu­tion. I’ve blogged some of the jour­ney, start­ing with the motiv­a­tion and mov­ing through the todo list. Yes­ter­day was the day for the big switch.

After a couple of hours twid­dling this and that, get­ting rid of spare cables, and vacu­um­ing the backs of com­puters that sel­dom get this treat­ment, we now have a hard­ware firewall/router and some minor web sites powered by a Sun Ultra 20 OpenSol­ar­is, rather than rely­ing on an old Pen­ti­um 3 doing all of that. It’s amaz­ing how much faster the minor sites load on a sys­tem with a decent amount of memory!

In oth­er words, we’ve now gone from 

old firewall + website server
old fire­wall + web­site server
and
wires
wires
to
new website server
new web­site server
(Pho­tos by Tim Bray)

I still have to set up ddcli­ent or some­thing sim­il­ar to inform DynDNS when our IP address changes, and there are some oddit­ies, such as the Sol­ar­is box not broad­cast­ing its host­name to the router which I want to track down. For some reas­on the Sol­ar­is box did­n’t start the Eth­er­net con­nec­tion prop­erly on reboot, but I don’t yet know wheth­er that was a ran­dom occur­rence or some­thing that I have to pay atten­tion to. Still, things are work­ing, at least until our next power out­age. Wheth­er it works past that depends on wheth­er the router moves around the IP addresses it assigns, which would mean the IP-based for­ward­ing not for­ward­ing to the right place. I may end up installing dd wrt or some­thing sim­il­ar on the fire­wall (although it appears the par­tic­u­lar one I have does­n’t sup­port dd wrt itself), but for the time being I’m run­ning the ori­gin­al soft­ware and it seems to do the job.

WordPress and MySQL on OpenSolaris

The next step in the list for mov­ing my minor web­sites to OpenSol­ar­is (see the first post for the motiv­a­tion) was to set up MySQL. After I down­loaded the OpenSol­ar­is Web Stack pack­age, MySQL was installed and run­ning, so it was more a mat­ter of tweak­ing. Little things like copy­ing the /etc/mysql/5.0/my-huge.cnf to /etc/mysql/my.cnf so that the default con­fig­ur­a­tion takes advant­age of the 2 GB of RAM, for example. 

I’ve heard con­flict­ing things about wheth­er one needs a root pass­word for MySQL, giv­en that it uses the Unix root iden­tity by default. After my years in secur­ity and iden­tity I decided to set one any­way, as recom­men­ded by the MySQL post-install­a­tion setup doc­u­ment­a­tion, even if it would be hard for any­one to get into the machine to do any dam­age, since it will be behind a firewall/router.

The next step was to move the Word­Press-based sites. I decided to try the export/import facil­it­ies in Word­Press, since I haven’t tried those out before, and it meant being able to use a new MySQL data­base with no cruft in it. I set up new users for the spe­cif­ic data­bases, copied the files across with rsync, impor­ted the XML file, and voila! It all worked out pretty well, although reset­ting the vari­ous con­fig­ur­a­tion options in Word­Press took a few minutes.

Rotating Apache Logs on OpenSolaris

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 Debi­an, you use logrotate (I’ve writ­ten about set­ting it up here). On OpenSol­ar­is, you use the logadm com­mand, with the actu­al rota­tion being spe­cified in /etc/logadm.conf. When you look at that file, it warns you not to edit it by hand, which I found mildly amus­ing. Since you can make changes via the logadm com­mand itself, I figured I’d try that out. 

For Apache log files in the usu­al place, /var/apache2/2.2/logs/access_log, read­ing 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

Test­ing with logadm -p now apache seems to work just fine. I’ll know more about how reli­able it is in a month.

MacBook Migration

My laptop at Sun was a nice little Mac­Book; light­er than the Mac­Book Pro but power­ful enough for my needs. So when I left, I decided I’d buy myself a new Mac­Book, being the path of least res­ist­ance. In the­ory, Apple makes it easy to migrate your inform­a­tion from one Mac­Book to anoth­er. So I stripped the Sun inform­a­tion off the old one, bought my new one, added a couple of gig of RAM, and came home full of anticipation.

The migra­tion was­n’t quite as easy as all that. I installed the Migra­tion Assist­ant on the old laptop, con­nec­ted the new one with an Eth­er­net cable, typed in the num­ber that appears on the new one into the old one, got the mes­sage “Pre­par­ing inform­a­tion…” and waited. 15 or so minutes later, the new one says it’s lost the net­work con­nec­tion and gives me a new num­ber, while the old one pops up the dia­log to type the new num­ber into. I repeated the pro­cess a couple of times, chan­ging vari­ables (con­nect through DHCP rather than dir­ectly) with no suc­cess. So I made an appoint­ment with the Geni­us Bar in the loc­al Apple store and went in there.

The Geni­us bar per­son said that there’s a known issue that’s solved by updat­ing the Migra­tion Assist­ant to the latest ver­sion. She updated the soft­ware, but it did­n’t solve the issue; the same prob­lem crops up. She did offer to move everything by hand by pulling out the old disk but I decided I did­n’t feel like wait­ing that long in the mall. And I remembered that I had a Time Machine backup at home, which should also work to put the inform­a­tion on the disk.

Back at home I backed up to the Time Machine, then star­ted up the install­a­tion pro­ced­ure on the new laptop and chose to install set­tings and files from the Time Machine. Then I waited. Approx­im­ately six hours later (no exag­ger­a­tion; the con­stant mes­sage was “check­ing Time Machine backup”) there was some error say­ing it was­n’t an OS X disk, or some­thing like that. At this stage I gave up and decided to just rsync my user dir­ect­ory includ­ing my applic­a­tions. That worked just fine and was much quick­er (about 15 minutes start to finish).

It turns out that rsync on the Mac is a little con­tro­ver­sial. There’s more in-depth dis­cus­sion in the com­ments to one of Tim’s posts. For my pur­poses, rsync worked well; I did take the ele­ment­ary pre­cau­tion of log­ging out on the tar­get laptop first.

Apache Virtual Hosts

Notes on installing Apache’s vir­tu­al hosts on OpenSol­ar­is 2008.11; part of a series that star­ted with Installing OpenSol­ar­is.

On Debi­an, you have to set up vir­tu­al hosts using sep­ar­ate files, called sites-enabled and sites-avail­able, part of the Debi­an Way Of Doing Things, which is not doc­u­mented on the Apache site. (I’ve writ­ten about this before; the link I refer to there is no longer avail­able, so try this one if you’re on a Debi­an or Ubuntu plat­form.) For­tu­nately, OpenSol­ar­is seems to use the stand­ard Apache meth­ods, so named vir­tu­al hosts can be set up using the doc­u­ment­a­tion at Name-based Vir­tu­al Host Sup­port (the meth­od you choose when you want to run mul­tiple web sites from one IP address). It’s easy to find the httpd.conf file, it’s in the Web Stack Options applic­a­tion, under Advanced Con­fig­ur­a­tion on the Apache2 tab (and even labelled “edit httpd.conf”).

I set up a vir­tu­al host for each web site on the devel­op­ment machine. This is a little more com­plic­ated than it is if you’re start­ing from scratch with a new site, since I want to be able to set up all the soft­ware and sys­tems on each web site on a test basis, before switch­ing the old serv­er off and the new one on. In the mean­time of course, the old serv­er is still serving those web­sites with the same URLs. So I needed a sys­tem that allows the com­puter I’m devel­op­ing 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 devel­op­ment machine. In a ter­min­al win­dow, type pfexec vim /etc/hosts. After the bot­tom line, which should look some­thing 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 serv­er, which is nice. If it does­n’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 dir­ect­ive before the dns dir­ect­ive, oth­er­wise the sys­tem will ask the DNS serv­er (which will return the site the rest of the world sees) before ask­ing the hosts file on your sys­tem. One way to check which IP address you’re look­ing at to make sure you’re look­ing at your test sys­tem, not the out­side one on the net, is to use getent hosts websitename. This should tell you the IP address is 127.0.0.1. The com­mon altern­at­ive com­mand, host websitename, asks the DNS serv­er and thus will tell you what the out­side world sees.

Debug­ging the httpd.conf file is the next step, to make sure you have those vir­tu­al hosts set up cor­rectly. 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 exist­ing 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 vir­tu­al host dir­ect­ive (just above the cus­tom log line) to make Word­Press’s pret­ti­er permalinks work.

The one thing OpenSol­ar­is does that is dif­fer­ent to the Apache doc­u­ment­a­tion is put­ting things some­where dif­fer­ent, so instead of using /usr/local/apache2/bin/httpd -S to debug the vir­tu­al host con­fig­ur­a­tion, you use /usr/apache2/2.2/bin/httpd -S. I learned the hard way that if you want to use a default vir­tu­al host, you have to define a ServerName for it.