Getting back to old device names in Fedora 18 (and probably others)

Updating http://major.io/2011/09/25/getting-back-to-using-eth0-in-fedora-15/, I found that in order to change the boot settings for grub2, it might be desirable to use an existing menue entry and not an extra, custom entry.

To do so, open /etc/grub.d/10_linux (make a backup first) and locate the line with

linux ${rel_dirname}/${basename}

and add

biosdevname=0

at the end of the line. Make a backup of /boot/grub2/grub.cfg, then run  

grub2-mkconfig >/boot/grub2/grub.cfg. 

(Make a backup of that file too, bevor you overwrite it :))You can now check if your new grub.cfg has the parameter biosdevname=0 appended to the kernel line. Now if you reboot, you should have access to traditional device names.

This should help to get traditional device names. The mentioned post does this for fedora 15, and I can confirm that it also works on fedora 18.

Usefull links

As I just stumbled on this very nice link about iptables and string-matching filter, I decided to start my personal link collection.

• Using iptables string-matching filter to block vulnerability scanners
• The entire Pro Git book, written by Scott Chacon and published by Apress, is available here 
• Howto: Fixing unstable clocksource in virtualised CentOS 

How to create a LVM testbed

Every once in a while I want to review/relearn a certain lvm feature. In order to do no harm, I want to create a testbed for lvm. Since I have done this a few times bevor, I now put all the commands in a little script, so that I don't have to type them again. Please note that this script does not do much checking, so please understand what it does bevor you use it, and use at your own risk :)

Migrating calendars from horde to zarafa

Recently I had to migrate a bunch of calendars from horde to zarafa. At the time of this writing (spring 2013) caldav access to horde is still just on the roadmap of horde. So basically, I had to log in for every users and export their calendars to ical files by hand. I named them username.ical.
Fortunatly, importing into zarafa can be automated. After importing a file, I realized that recurring events where off by 2 hours. In the ical files, the times were correct, but after importing them, recurring events startet and ended two hours later. So I had to modify the ical files. I did that with the following python script: Note that I used python icalendar 3.3, which exposed this issue. I made a temporary fix (see link), but with icalendar 3.4 and later this should be resolved.
So after the recurrence timing had been corrected, I imported all ical files with

Postfix: local mail only for some users

If you want to allow some users to send "local" mail only, the following postfix configuration will do the trick. With local I mean within the organisation, for which your postfix is configured to receive mail.

In your smtpd_recipient_restrictions, rather at the top of the restriction list, add

        check_sender_access hash:/etc/postfix/access-sender-local_mail_only,

where the file /etc/postfix/access-sender-local_mail_only contains a list of senders which are restricted:

usera@example.com       localmailonly
userb@example.com       localmailonly
userc@example.com       localmailonly

So here we have defined that these users are subject to the restriction class "localmailonly", which we will have to define:

smtpd_restriction_classes = localmailonly
localmailonly = permit_auth_destination,reject

Here we have defined a new restriction class, and have assinged rules to this class. Namely, we only permit authorized destinations (thats the destinations we accept mail for), and otherwise reject the message. In order for this configuration to take effect, we need to convert /etc/postfix/access-sender-local_mail_only to a .db file, and reload postfix (to read the changes to main.cf):

postmap /etc/postfix/access-sender-local_mail_only
service postfix reload

Check ssl certificates with a shell oneliner

If you want to check the details of a ssl certificate, you can do it with something like this:

for a local certificate file. If you want to check the certificate that specific services servers, use servicename should be a service which translates into a portnumer via /etc/services.

Faster ssh on virtual machines

A problem with virtual machines is that they have trouble finding entropy. Because they have no real hardware to get entropy from, the tend to have rather low entropy availabe. You can check with

 cat /proc/sys/kernel/random/entropy_avail

A typical virtual machine will be in the low hundreds. If this is the case, you will probably frequently experience unusual long waiting times when loggin in with ssh, or even hangs .... This is because the system uses entropy to for the encryption. So because there is not much, it might wait for it to be generated.

Fortunatly, there is a tweek, which will speed up things: rng-tools (props to my fellow Stephan Seitz who explained this to me). It really is meant for gathering entropy from special hardware devices, but can be tweeked to use /dev/urandom. Please note that this will increase the available entropy, but not probably decrease the strength of the encryption. If you are more knowledgeble about this, I would be happy to hear from you.

Here is my setup on a ubuntu 12.04 server: Edit /etc/default/rng-tools, so that it contains

RNGDOPTIONS="--rng-device=/dev/urandom --fill-watermark=90% --feed-interval=1"

 (only that, the rest should be comments). This will tell rng-tools to use /dev/urandom. Now the problem with this is, that the init script will check if the device is a real hardware device. So we need to edit /etc/init.d/rng-tools as well. Find the following line

START="${START} -- -r ${HRNGDEVICE} ${RNGDOPTIONS}"

and replace it with

START="${START} -- ${RNGDOPTIONS}"

Now restart rng-tools, and you should have much more entropy available:

cat /proc/sys/kernel/random/entropy_avail
3968