Ubuntu Tutorials

I got to thinking about something the other day when I rebuilt my webserver using Debian 5.0. How does Debian/Ubuntu standardize on reloading the iptables rules at boot time?

I know that Red Hat and its variants use the /etc/sysconfig/iptables file as a save and restore point, and there is an init script, iptables, that starts at boot prior to the network script, but is there a similar standard on Debian/Ubuntu?

The solution I’ve come up with (and I’m very curious to hear what others have done) is the following:

First, I manually enter my base iptables rules…

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -s 17.88.115.150/32 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 111.70.51.51/32 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 16.10.111.177/32 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -j REJECT --reject-with icmp-host-unreachable
...etc, etc.


*(ip addresses have been scrambled to protect their identity)

I then run:

iptables-save > /etc/default/iptables


From this point forward I manually update my ruleset by editing the file directly with a text editor.

To reload these rules at boot-time I have added a line to my /etc/network/interfaces configuration as follows:

auto eth0
iface eth0 inet static
address foo
netmask bar
gateway baz
dns-search domain.tld
dns-nameservers foo
pre-up iptables-restore < /etc/default/iptables

That last line tells the machine that, before you activate these network settings, run iptables-restore and read from the file /etc/default/iptables.  This seems to work well enough so far, but I’m still curious what others have done.  Do you simply write an init script on your own and maintain the ruleset within that file?  Do you use a file similar to what I’ve done, but source it via an init script?  I’m curious, as there does not seem to be a standard that I’m aware of.

I’ve seen a few posts over here regarding problems with an unmaintained WordPress installation. It definitely can be work to manage software that is not covered within the supported repositories (WP is in the repositories, but its not updated as frequently as upstream). I thought I would cover how I maintain my installations and hopefully they can help others simplify their process.

First of all let me outline the setup that I have.  I run a number of virtual hosts on my web server.  Probably close to a dozen WP installations, plus a few other sites.  I’ve simplified the installation and updating process for these by using svn, which has been an option from WP for some time now.  Example:

To install a new WordPress blog using svn:

svn co http://svn.automattic.com/wordpress/tags/2.7.1/ .

note: You’ll, of course, want to update the “2.7.1″ tag with the current version at the time of your installation.

note: Make note of the “.” at the end of that command.  Yes, it’s required.  Yes it’ll install WordPress to the directory you run the command in.

To update your installation when word gets out that there has been a new release:

svn sw http://svn.automattic.com/wordpress/tags/2.7.x/ .

note: see notes above

Now, if you’ve got a number of virtual hosts and multiple wordpress installations installed you could do something like I’ve done and script the process.  Here is an example script I use to update all of my wordpress installations with one command:

#!/bin/bash
# wp-update.sh
# update wordpress installation(s) to $1 branch
#
# this script takes the new branch as an argument

DOMAINS="domain1.tld \
domain2.tld \
domain3.tld \
domain4.tld \
domain5.tld \
domain6.tld \
domain7.tld \
domain8.tld \
domain9.tld \
domain10.tld \
domain11.tld \
domain12.tld"

if [ $# -ne 1 ]; then
echo "EPIC FAIL: Missing new version!"
echo "Try: ./wp-upgrade x.x.x (ie; 2.7.1)
exit 1
fi

for site in ${DOMAINS}; do
echo "upgrading ${site}"
echo
cd /var/www/virtual/${site}/html/
svn sw http://svn.automattic.com/wordpress/tags/$1/ . &>/dev/null
done

The only things you’ll really need to keep in mind to use this script are:

1. You’ll need subversion installed.
2. This assumes a virtual host path of /var/www/virtual/${domain}/, and WP root of html/.  Update as necessary.
3. You’ll need to chmod +x this script.

Once you’ve saved and update the script according to your setup you’ll simply want to run the script anytime you get word of a new WordPress release:

./wp-update.sh 2.7.3

Done.  Simple.  Enjoy.

Some time ago I posted on how to simplify your dropbox URLs by using .htaccess files within Apache web server. Now that I’ve switched to Lighttpd I needed to find the equivalent. Here is what I came up with:


## dropbox redirection
server.modules += ( "mod_redirect" )


$HTTP["url"] =~ "^/dropbox/(.*)" {
url.redirect = (
"^/dropbox/(.*)" => "http://dl.getdropbox.com/u/123456/$1"
)
}


note: if you already have mod_redirect loaded elsewhere you won’t need to worry about that first line. Also note that you’ll need to update the dl.getdropbox.com URL with your unique string. Replace 123456 with your unique value. You can find this value within your Dropbox account.

Based on the comments from the previous post I wanted to offer an update. A much simpler solution is to simply activate the compositing within recent versions of Gnome.

gconftool-2 -s --type bool /apps/metacity/general/compositing_manager true


This does introduce a known bug which can break enabling compiz however. If you want to activate compiz after toggling this value, you’ll need to de-activate it first.

gconftool-2 -s --type bool /apps/metacity/general/compositing_manager false


Thanks to Christoph, Philip and Cory for this tip.

We had a DNS hiccup overnite. My apologies. There always seems to be something that gets missed when doing a server migration. Turns out, when I cut off the old server, there were still DNS entries pointed there that I had missed. I believe this problem has been solved. Again, my apologies for the downtime.

The recent release of Gnome-Do 0.8.0 has brought with it a number of interface changes and upgrades.  I won’t go into all the new “shiny” stuff in this post, but simply outline how to satisfy the new requirements.  Gnome-Do 0.8.x now requires some type of compositing support for its interface (unless you stick with “Classic”).

First of all, composite does not mean Compiz.  Let’s get that out of the way right from the start.  You do not need a flashy 3D desktop to run Gnome-Do.  You do need a basic compositing manager however, and these should work on nearly any modern system and can run with minimal resources in the background.

I am using a tool called ‘xcompmgr’ for my compositing support, but there are others available.  Ask around or leave some comments to find out what other compositing managers people use.  Here is how I got mine setup:

sudo aptitude install xcompmgr

You can then start compositing manually via the ‘xcompmgr‘ command, or you can automate the process via Sessions.

System > Preferences > Sessions : Add

• Name – Compositing Manager
• Command – xcompmgr
• Comment – Shiny!

With basic compositing enabled you should now be able to use the enhanced features of Gnome-Do 0.8.x, including the Mini Interface, Docky, Glass Interface and Nouveau.

As some of you have read, I recently switched this production web server over to Lighttpd, and so far I am very much impressed.  I have been tinkering with Lighttpd for some time, and I really feel it is a fine replacement for Apache.  It supports all the same basic modules that I need (mod_rewrite, mod_alias, mod_auth, etc) and uses far less resources.  The only difficulty in switching is migrating the configuration and little “tweaks” to get things setup just right.

One thing, for example, is that WordPress assumes an Apache server, or something that supports .htaccess files.  This is not the case with Lighttpd, but is solved very, very simply.  Early in my migration I read a number of blog posts suggesting solutions to the WordPress Permalink setup, some more complicated than others.  I have to say that I think I found the simplest solution, and it is rarely seen on other blogs.  Below is one line that will support any WordPress Permalink setup you want:

## Permalink Support:
server.error-handler-404 = "/index.php"

That’s all there is to it.  That one line in the lighttpd.conf will handle the permalinks internally and nothing more is required.  No dealing with weird regex patterns and trying to exclude this or that.  Lighttpd is smart enough to handle it internally with that line.

If you are using a more complex Permalink rewrite configuration in Lighttpd I’d be interested in hearing if this does or does not achieve the same results.

Well it appears that the server migration is complete, and so far I am very happy with the results.  First of all, I don’t think there was much downtime, if any at all.  The only oddity that I encountered was regarding DNS propogation, and there is only so much you can do about that.  Here is basically what I’ve setup:

• lighttpd + fastcgi + xcache : very efficient web server + virtual hosts
• bind9 : slave server (ns3)
• postfix + postgrey : mail relay (mx3)
• mysql + tuning-primer.sh : well tuned database backend

So far I am very impressed with the setup at linode.  They have a really nice web management tool and they are very responsive to questions and support.  The price is affordable as well–I hope the performance I’ve been seeing keeps up.  So far all four processors sit idling the majoritiy of the day, and RAM sits at about 200M/360M total.  That was unheard of with my previous setup using Apache, and I wasn’t running BIND previously either.  I think I’m sold on lighttpd!

Please let me know if you encounter any oddities with the site.  Thank you – Christer

At work we run a number of Red Hat Enterprise machines and CentOS servers.  After finding a large number of machines that were grossly outdated I decided to add a weekly cron job to notify us of available updates.  I used something along the lines of:

#!/bin/bash

yum check-update | mail -s “Weekly Errata Report for $(hostname)” admin@domain.tld

After dropping this little one-liner into /etc/cron.weekly/ we’re now notified of available package updates on a weekly basis, and our machines are keeping up to date much better!

I got to thinking this evening about how to achieve the same results on my Ubuntu and Debian servers.  There does not seem to be an equivalent command to ‘yum check-update‘, but there appears to be a similar solution.

#!/bin/bash

(apt-get update && apt-get -s safe-upgrade && apt-get -s full-upgrade) | mail -s “Weekly Errata Report for $(hostname)” admin@domain.tld

The apt-get equivalent command above is a bit more verbose but it basically does the same thing.  note: the parens are required so that the collective output of the three commands will be piped to the mail utility.

Does anyone else have any suggestions an how to accomplish this with standard Ubuntu/Debian tools?

I know many of you may think I’ve given up and stopped blogging completely. That is not entirely the case. I’ve been overloaded at work, doing over 160 hrs over two weeks in late January and continuing to work later hours than the normal 9-5.

Things appear to be slowing down a bit so I’m preparing to rebuild and migrate the web server this site runs on. Just a heads-up that there may be little bits of downtime over the next week or so.

Also, I’m planning on using lighttpd instead of apache this time around, and I’m looking at php optimizers like fastcgi or xcache. If you have any experience with those I’d love to hear from you.