HOWTO: on vacation autoreply with Postfix/LDAP and Gnarwl

If your users are asking for an autoreply feature when they’re on vacation, and you are currently using postfix as MTA with a LDAP backend for authentication, IMO the best solution is to use Gnarwl and configure it following these simple steps:

• download the most recent Gnarwl’s tarball in a place of choice
• unpack it and install it with
  ./configure
make
make install
make perm
  this will install Gnarwl under /usr/local and do all the dirty work (creating the gnarwl local user for example, check your /etc/passwd )
• edit /usr/local/etc/gnarwl.cfg to look like this:
map_sender $sender
map_receiver $recepient
map_subject $subject
map_field $fullname cn
server your.ldap.server.com
port 389
scope sub
protocol 3
base ou=Users,dc=YOURCOMPANY,dc=com
queryfilter (&(mail=$recepient)(vacationActive=active))
result vacationInfo
blockfiles /usr/local/var/lib/gnarwl/block/
umask 0644
blockexpire 6
mta /usr/sbin/sendmail -t $recepient
maxreceivers 64
maxheader 512
charset ISO8859-15
badheaders /usr/local/var/lib/gnarwl/badheaders.db
blacklist /usr/local/var/lib/gnarwl/blacklist.db
forceheader /usr/local/var/lib/gnarwl/header.txt
forcefooter /usr/local/var/lib/gnarwl/footer.txt
recvheader To Cc

  vacationActive and vacationInfo are two attibutes that have to exist in the LDAP schema you’re using for your users. Obviously you can use whatever attribute you prefer, you simple have to literally change the vacationActive/vacationInfo in this config with your own attributes, keeping in mind that vacationActive is used to check if autoreply is enabled or not for that particular user and vacationInfo it’s the text that is being used as a reply (note: you can use CR/LF in it, to obtain a multiline text). The other parameter that deserves a comment is blockexpire: here you can put the amount of time (in hours) during wich an autoreply to the same sender will not be sent. For example, if john@foo.com tries to send a mail to duke@yourcompany.com, he will receive the vacation message. But, as in our config example, john sends another message within 3 hours, he won’t get any message at all. He has to wait 3 more hours to get notified again (blockexpire was set to 6 hours, remember)
• as the doc/INSTALL file in Gnarwl says, the quick-and-dirty way to enable Gnarwl in a postfix installation (this is the method I’m using, too :) is to edit /etc/postfix/main.cf and simply add the linealways_bcc=gnarwlThis works by delivering every message to the local gnarwl user (even if you are in a virtual environment), which has a .forward file that pipes everything to the gnarwl binary program, which takes care of everything
• Now, the final step: to activate the vacation message for one of your customer, simply edit your LDAP data, add a vacationActive attribute with an “active” value to the user you want, and add vacationInfo with the text you want. That’s all.

For more info and more detailed configuration instructions, please refer to the doc/INSTALL file in your gnarwl tarball.

Quasi-high-availability for Windows 2003 Active Directory/DNS

If you have a single AD domain controller that it’s going to be SPOF (single point of failure) for your infrastructure, you can easily add another DC to the domain and create a secondary DNS in case of failure.

DISCLAIMER: this little how to is for little/medium organizations with a simple Windows infrastructure and with a low budget (it’s plenty of more expensive tools that do a better job). Follow it at your own risk, you have been warned!!

Assuming you’ve already up&running your first DC, follow this steps to enhance yur configuration:

• Install a second copy of Windows 2003 Server on another machine (a virtual machine could be perfect for this purpose)
• Install the second domain controller following these instructions from TechNet
• Install the secondary DNS in the new machine like Microsoft tells you to do
  
• Create the same DHCP configuration in the second server as the one you have in the first Domain Controller, just let it inactive
• Configure all your clients’ DNS to point to the primary and the secondary ones
• Now, in the primary DNS, create a round robin entry pointing to the two IP’s of the two domain controllers. To do this, simply create to A entries with the same name (in the same domain, obviously), pointing to two different IP’s
• Configure all your thid-party software authenticating against Actide Directory to point to this new entry

So…? What’s happening now?

Ok, your configuration is almost finished. Now, every user validating against the AD will use both domain controllers, in round robin strategy, and both will saty perfectly synchronized all the time (AD forest and DNS as well).

And in case of disaster??

If one of the two DC fails, remember we are in a quasi-HA environment, so we have to act manually to restore a 100% working system. But all we have to do is to delete, in the working DNS, the A entry of the died DC, disabling this way the round robin trick we did, so everything will authenticate against the surviving DC.

Quick tip: execute again the last command

Here it is a quick tip for all the sudoers out there: if you have just typed your very very very long command string that needs root privileges but you’ve forgotten the sudo before it, type this:
sudo !!

and the last command will be repeated but with sudo (or whatever command you type instead) preposed, so type your password and… let’s go !!

Disable the power button event in Debian

Don’t know you, but it has already happened to me to shut down a running server by accidently pressing the power button. Linux intercepted the event and quickly started the power down procedure, sadly bringing my infrastructure to its knees.

But not anymore! In Debian it’s really easy to disable this behaviour. All you have to do is edit

/etc/acpi/powerbtn.sh

with your preferred editor and comment out the line

/sbin/shutdown -h now "Power button pressed"

That’s all. Just tested on a Debian 4.0 Etch installation.

Migrating a Linux machine to a VMWare host

Problem: migrate (or consolidate) a phisical Linux machine to a VMware virtual machine without passing through a CD/DVD.

Solution:

1. Install VMWare Server on the desired machine.
2. Create an empty virtual machine with enough disk space, selecting the OS you’re going to migrate.
3. Download a Linux live-CD ISO (for example Grml or Knoppix).
4. Burn one copy on a CD and then copy the ISO to the VMWare server (the host).
5. Reboot the original Linux box with the CD you’ve just burnt, and connect the ISO to the newly created Virtual Machine.
6. Check both live CDs have net connection correctly configured and that they can see each other.
7. In the virtual machine, type this:nc -l -p 10000|dd of=/dev/hda
8. On the machine you’re migrating, type:
   dd conv=noerror if=/dev/hda|nc $IP_OF_THE_VM 10000
9. Wait until dd finishes its job, do a clean reboot of the virtual machine and enjoy the consolidation! You may want to install VMWare tools to get everything 100% working in the new system.

A couple of notes:

• dd is used to do a physical copy of the disk
• conv=noerror is used to bypass error on the original disk. Use this option at your own risk.
• nc is used to copy the stream other the net. man lc for further info
• kill -USR1 $PID_OF_DD could be used to see dd stats

echo “Hello, world!”

input/ouput error

I think this concept resume in a pretty way the life of a typical sysadmin: you are always working on things that don’t work, and your job is to understand why and fix them. But nobody is going to thank you for this: things are supposed to just work, so…

Anyway

Hello, world! and hello blogosphere too!