OpenSolaris and ddclient

 Technology  7 Responses »
Mar 192009
 

I have some minor sites run­ning on the base­ment OpenSol­ar­is box, and since our IP address changes reg­u­larly, I use ddcli­ent to noti­fy DynDNS of the changes. It was work­ing just fine on the old Debi­an box, but of course OpenSol­ar­is does things dif­fer­ently, and the ddcli­ent pack­age does­n’t come with all the bits you need to make it work.

Step one: down­load the ddcli­ent pack­age from Source­forge, and fol­low the instruc­tions 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 Sup­port Tools sec­tion of the web­site, and click on the “Update Cli­ent Con­fig­ur­at­or”. This takes you to a page that will auto­mat­ic­ally gen­er­ate the con­fig­ur­a­tion file for ddcli­ent for your account. This is one of the reas­ons I like DynDNS, by the way, they think of little use­ful tools like this. 

Step three: make the con­fig­ur­a­tion changes in the ddclient.conf file, and try run­ning the ddcli­ent Perl script to see if it works, using ddclient -daemon=0 -debug -verbose -noquiet to get all the error mes­sages. One tip: if you have spaces in your pass­word, sur­round it with single quotes, not double quotes. The lat­ter don’t work.

Step four: the hard­est for someone new to OpenSol­ar­is is to fig­ure out how to run the dae­mon. It turns out that Sol­ar­is has a “Ser­vices Man­age­ment Facil­ity” (SMF). The spe­cif­ic instruc­tions to fol­low, once you’ve figured out the basic con­cepts, are at Chris Ger­hard’s ddcli­ent meets SMF. Mind you, I did need to read the doc­u­ment­a­tion on Man­aging Ser­vices to find out where to put the file (/var/svc/manifest). Just as well Sun lets lots of people blog, it cer­tainly makes it easi­er to find inform­a­tion. I do wish they could fig­ure out how to give their stand­ard doc­u­ment­a­tion mem­or­able URIs though.

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

OpenSolaris Hostname on DHCP

 Technology  No Responses »
Feb 172009
 

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

 Technology  2 Responses »
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 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

 Technology  No Responses »
Feb 022009
 

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

 Technology  No Responses »
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 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.

Apache Virtual Hosts

 Technology  No Responses »
Jan 162009
 

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.

 Older Entries
/* ]]> */