sharealike.org

I am a big fan of the cut-and-paste howtos provided at howtoforge.com.

I’ve used something like falko’s howto on Virtual Users And Domains With Postfix, Courier, MySQL And SquirrelMail (Ubuntu 10.10) in order to get a mail server with those features working on Debian Squeeze.

Then I wanted to add mailman in order to operate mailing lists.

The closest howto for achieving this is the one by Rich Brown, How to add Mailman mailing lists to Postfix under Ubuntu Linux when using virtual domains + virtual users.

I’m going to try to recount what I had to do to go from a working mail server with virtual users and domains (having completed a howtoforge.com howto) to get to that same setup to run mailman. Perhaps some of this was unnecessary, duplicative, or even wrong. But, the mailing lists are working now, so that’s something.

List domain preparation

If the domain that will host the lists is not already served by your setup, be sure you:

• use phpmyadmin to create the domain example.com in the domains field. NOT lists.example.com!, and
• add lists.example.com to your dns entry for example.com,

Mailman

As root:

# aptitude install mailman
# newlist mailman
# vi /etc/aliases

And add the following to /etc/aliases:

## mailman mailing list mailman:              "|/var/lib/mailman/mail/mailman post mailman" mailman-admin:        "|/var/lib/mailman/mail/mailman admin mailman" mailman-bounces:      "|/var/lib/mailman/mail/mailman bounces mailman" mailman-confirm:      "|/var/lib/mailman/mail/mailman confirm mailman" mailman-join:         "|/var/lib/mailman/mail/mailman join mailman" mailman-leave:        "|/var/lib/mailman/mail/mailman leave mailman" mailman-owner:        "|/var/lib/mailman/mail/mailman owner mailman" mailman-request:      "|/var/lib/mailman/mail/mailman request mailman" mailman-subscribe:    "|/var/lib/mailman/mail/mailman subscribe mailman" mailman-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe mailman"

# vi /etc/mailman/mm_cfg.py

and uncomment and/or appropriately edit the following lines:

DEFAULT_EMAIL_HOST = 'lists.example.com' ... DEFAULT_URL_HOST   = 'lists.example.com' ... MTA=None   # Misnomer, suppresses alias output on newlist ... GLOBAL_PIPELINE.insert(1, 'SpamAssassin')

Apache2

create a new file: /etc/apache2/mods-available/mailman.conf that looks like this:

ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/ ScriptAlias /cgi-bin/mailman/ /usr/lib/cgi-bin/mailman/  <Directory /usr/lib/cgi-bin/mailman/>    AllowOverride None    Options ExecCGI    Order allow,deny    Allow from all </Directory>  Alias /pipermail/ /var/lib/mailman/archives/public/ <Directory /var/lib/mailman/archives/public>    Options Indexes MultiViews FollowSymLinks    AllowOverride None    Order allow,deny    Allow from all </Directory>  Alias /archives/ /var/lib/mailman/archives/public/ <Directory /var/lib/mailman/archives/public>    Options Indexes MultiViews FollowSymLinks    AllowOverride None    Order allow,deny    Allow from all </Directory>

Now add a symlink to this file so Apache will use your new Mailman aliases the next time it starts:

# cd /etc/apache2/mods-enabled
# ln -s /etc/apache2/mods-available/mailman.conf mailman.conf

Postfix

Create a new file, /etc/postfix/transport, which contains one line:

lists.example.com     mailman:

Then as root:

# cd /etc/postfix
# postmap transport

Finally edit /etc/postfix/main.cf – add these four lines to the end of the file:
relay_domains = lists.example.com
transport_maps = hash:/etc/postfix/transport
mailman_destination_recipient_limit = 1
unknown_local_recipient_reject_code = 550

Use phpmyadmin to add some aliases in the forwardings field:

 mailman@example.com mailman@lists.example.com mailman-admin@example.com mailman-admin@lists.example.com mailman-bounces@example.com mailman-bounces@lists.example.com mailman-confirm@example.com mailman-confirm@lists.example.com mailman-join@example.com mailman-join@lists.example.com mailman-leave@example.com mailman-leave@lists.example.com mailman-owner@example.com mailman-owner@lists.example.com mailman-request@example.com mailman-request@lists.example.com mailman-subscribe@example.com mailman-subscribe@lists.example.com mailman-unsubscribe@example.com mailman-unsubscribe@lists.example.com 

Finishing up

# newaliases
# service apache2 restart
# postfix reload
# service mailman start

After some combination of the above and hopefully not forgetting anything–note my uncertainty there–mailing lists just started working! Go to: http://lists.example.com/mailman/admin/ and get started creating a test list to confirm everything is working.

Debian announced today that Debian 6.0 “Squeeze” will be released with a completely free Linux Kernel.

Having, in the past, spent many frustrating hours trying to get some wireless card or some other piece of hardware to work with some binary firmware that cannot be examined or improved but is simply foisted on you, I’m really thankful to the team that is doing this work. Congratulations to them!

I’ve already successfully installed Squeeze numerous times with the Debian 6.0 beta installers. Give it a try!

I’ve previously used rdiff-backup to do remote backups of my Debian servers, but for whatever reason they tend to fail and I don’t learn about the problem soon enough and I needed a new solution. Enter: rsnapshot.

Install rsnapshot on both the remote machine and the backup server:

apt-get install rsnapshot

Save yourself a copy of the default config file if you ever need it:

cp /etc/rsnapshot.conf /etc/rsnapshot.conf.default

On the backup server I create an rsnapshot user:

groupadd -g 3500 rsnapshot
useradd -u 3500 -s /bin/false -d /home/rsnapshot -m -c "rsnapshot" -g rsnapshot rsnapshot

Then prepare the backup server to be able to automatically access the production server using ssh keys:

cd /home/rsnapshot
su -m rsnapshot

With the previous command you become the user rsnapshot on the shell. You could confirm this with:

whoami

The next few commands must be run as user rsnapshot!

Create the keys:

ssh-keygen -t rsa

Hit enter on all prompts. It is important that you do not enter a passphrase otherwise the backup will not work without human interaction, so again hit enter. In the end two files are created: /home/rsnapshot/.ssh/id_rsa and /home/rsnapshot/.ssh/id_rsa.pub.

Now copy over the public key you just created to your production server:

ssh-copy-id -i /home/rsnapshot/.ssh/id_rsa.pub root@yourdomainname.example.com

If your production server to be backed up happens to run Ubuntu, as one of mine did, then you should login to the production server and then do away with it’s silly refusal to have a password for root with:

sudo passwd root

and then you’ll have no trouble with the prior step which copies the public key of the user rsnapshot to the file /root/.ssh/authorized_keys on the production server yourdomainname.example.com.

You can confirm that this worked with:

ssh root@yourdomainname.example.com

That should have logged you in as root on your production server without requiring you to enter a password. Now, on the one hand, this is exactly what we were trying to do, but on the other hand, we don’t want to leave it like this or anyone who gets access to the rsnapshot user on your backup server could be root on your production server. Not good. So next we fix that by taking a look at /root/.ssh/authorized_keys. It should look similar to this:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA[...]/zkctw== rsnapshot@backupservername

Now prepend from="1.2.3.4",command="/root/validate-rsync" just before “ssh-rsa” separated only by a single space, all on a single line like so:

from="1.2.3.4",command="/root/validate-rsync" ssh-rsa AAAAB[...]/zkctw== rsnapshot@backupservername

where “1.2.3.4″ is your backup server’s numeric IP address. This change means that user rsnapshot can only login from your backup server’s IP address and can only run a single command, “validate-rsync”. We must now create the file /root/validate-rsync with the following content:

#!/bin/sh

case "$SSH_ORIGINAL_COMMAND" in
*\&*)
echo "Rejected"
;;
*\(*)
echo "Rejected"
;;
*\{*)
echo "Rejected"
;;
*\;*)
echo "Rejected"
;;
*\<*)
echo "Rejected"
;;
*\`*)
echo "Rejected"
;;
*\|*)
echo "Rejected"
;;
rsync\ --server*)
$SSH_ORIGINAL_COMMAND
;;
*)
echo "Rejected"
;;
esac

Special thanks to Troy Johnson for this script. Now make the script executable:

chmod u+x validate-rsync

You should now be setup on the production server and can logout and go back to your rsnapshot user on the backup server. Become root on the backup server so you can edit the rsnapshot configuration file, /etc/rsnapshot.conf which you can learn more about at this rsnapshot HOWTO. The main thing to know about this config file is that everything that looks like a space probably should be a TAB instead.

#I suggest the following changes: snapshot_root /home/rsnapshot/.snapshots/ logfile       /home/rsnapshot/rsnapshot.log # user rsnapshot can't write to /var lockfile      /home/rsnapshot/rsnapshot.pid # user rsnapshot can't write to /var ssh_args      -o BatchMode=yes  #Uncomment the following: cmd_cp        /bin/cp cmd_ssh       /usr/bin/ssh cmd_du        /usr/bin/du interval      monthly 3  #Choose some directories to exclude: exclude       /home/user/JunkThatIDontWant exclude       /cdrom exclude       /proc exclude       /sys exclude       /tmp  #And choose some directories to backup: backup        root@yourdomainname.example.com:/home/user/ yourdomainname.example.com/ backup        root@yourdomainname.example.com:/etc yourdomainname.example.com/ backup        root@yourdomainname.example.com:/var yourdomainname.example.com/ backup        root@yourdomainname.example.com:/usr/local yourdomainname.example.com/

Now you probably put some spaces where there were supposed to be tabs, so check your config file's syntax with this test:

rsnapshot configtest

Once it comes back with "Syntax OK" you are ready to try your first hourly snapshot. Become the rsnapshot user and give it a try with:

cd /home/rsnapshot
su -m rsnapshot
rsnapshot -V hourly

This will give verbose output so you can see that something is really happening. Once you get an hourly snapshot or two to complete successfully, you should automate this with cron. As the rsnapshot user, type:

crontab -e

and choose your schedule, something like:

0 */4 * * * /usr/bin/rsnapshot hourly 50 2 * * * /usr/bin/rsnapshot daily 40 2 * * 6 /usr/bin/rsnapshot weekly 30 2 1 * * /usr/bin/rsnapshot monthly

which would do 6 hourly backups a day (once every 4 hours, at 0,4,8,12,16,20)
1 daily backup every day, at 2:50AM
1 weekly backup every week, at 2:40AM, on Saturdays (6th day of week)
1 monthly backup every month, at 2:30AM on the 1st day of the month.

And there you have it! You have automated remote backups of your production server using rsnapshot.

One of my Debian servers had its load average pegged at 3.0 but top didn’t show anything using a lot of CPU. A little Google research revealed this approach that solved things for me:

top -b -n 1 | awk '{if (NR <=7) print; else if ($8 == "D") {print; count++} } END {print "Total status D: "count}'

top - 11:53:48 up 5 days, 18:47,  1 user,  load average: 3.00, 3.00, 3.00 Tasks: 132 total,   1 running, 131 sleeping,   0 stopped,   0 zombie Cpu(s):  0.2%us, 12.3%sy,  3.8%ni, 83.3%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st Mem:   2075620k total,  1773432k used,   302188k free,   395648k buffers Swap:  2650684k total,      716k used,  2649968k free,  1165208k cached    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND  8548 root      20   0  2296  684  576 D    0  0.0   0:00.00 find  8675 root      20   0  2296  684  576 D    0  0.0   0:00.00 find 32070 root      20   0  2296  688  576 D    0  0.0   0:00.00 find Total status D: 3 tempe:~# killall -9 find 

After that, the load average immediately began dropping back to normal.

This was harder than it should have been as the instructions could be clearer that two separate downloads are required. I’ve summarized here:

I assume you have ssh or command line access to your host. If not, you could accomplish the same thing using ftp, but you’ll have to pay attention to what directory you upload into:

1. Install Drupal 6.x
2. Download the Drupal WYSIWYG part of FCKeditor from http://drupal.org/project/fckeditor
3. Extract that in sites/all/modules (you may have to create the modules dir) with tar -zvxf fckeditor-6.x-1.4.tar.gz
4. cd to sites/all/modules/fckeditor
5. Download the FCKeditor part of FCKeditor: http://ckeditor.com/download
6. Extract that in sites/all/modules/fckeditor/fckeditor [Yes, seriously.] with tar -zvxf FCKeditor_2.6.5.tar.gz
7. Go enable the FCKeditor module in the drupal admin section, it’ll be down below all the core modules in its own section.

I don’t know why I always forget this command, or why it is so hard to discern from the man page / –help information. I just had my drives in an existing RAID array get out of sync and needed to rebuild the one that was down. This did the trick:

mdadm /dev/md0 -a /dev/sdb1

This is on a software RAID array called /dev/md0 made up of /dev/sda1 and /dev/sdb1.

The Flip Video UltraHD camcorder records files in a .mp4 format. I wanted to convert them to Ogg Theora format. How do you do that? I did far too much searching for an answer to this question for the answer to be this easy:

apt-get install ffmpeg2theora

and then:

ffmpeg2theora vid00001.mp4

That outputs a file called vid00001.ogv and you’re done. Find further information about the fabulous ffmpeg2theora at its website.

• ii.com · Procmail Quick Start: An introduction to email filtering with a focus on procmail by Nancy McGough
  (tags: procmail recipes howto)

Privacy activists rightly complained about whitehouse.gov’s use of YouTube videos for President Obama’s weekly addresses, as it allowed a private third-party company to use cookies to track visitors to a government web site. The whitehouse.gov site appears to have responded to these complaints but in so doing has adopted a flash format that is not playable using free software. See below for how it renders on a Debian Lenny GNU/Linux system using Iceweasel and gnash: The whitehouse.gov site should take one more step towards openness and privacy-preservation by using an open audio-video format such as Ogg-Theora for all its weekly addresses.

I always forget this series of commands and have trouble locating them. After setting up a RAID1 mirror set, I want to be sure I can boot off of either drive in case of a drive failure. Assume two SATA drives, /dev/sda and /dev/sdb. The first will be set up during the OS install. To be sure the second drive also has the right info in its MBR, do this as root:

grub
grub>device (hd0) /dev/sdb
grub>root (hd0,0)
grub>setup (hd0)
grub>quit