Donnerstag, 15. August 2013
nagios check script for rabbitmq cluster
As part of an openstack monitoring solution, I set up a few nagios checks for rabbitmq. Most of what I wanted is allready covered by nagios-plugins-rabbitmq by James Casey. Additionally I wanted to check the cluster status of my rabbitmq cluster, so I modified one of his scripts:
If you find this usefull or or have suggestions, please let me know via comments.
Mittwoch, 14. August 2013
Restricted characters on NTFS bugging resync
When reviewing the log of my rsync backup script (which does backup to a cifs mounted NTFS network drive) I found strange error messages ("No such file or directory (2)", "Invalid argument (22)"). It turns out that there are restricted characters on NTFS formated drives, which I, growing up on linux, did not know.
So, if you happen to stumble on such errors, the only workaround it seems is to avoid theses characters in filenames: "/\*?<>|:
See here for more info on filesystem quirks.
So, if you happen to stumble on such errors, the only workaround it seems is to avoid theses characters in filenames: "/\*?<>|:
See here for more info on filesystem quirks.
Mittwoch, 3. Juli 2013
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.
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.
Dienstag, 14. Mai 2013
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.
Dienstag, 7. Mai 2013
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 :)
Freitag, 3. Mai 2013
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
Montag, 29. April 2013
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
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 localmailonlySo 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,rejectHere 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
Freitag, 26. April 2013
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.
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.
Freitag, 19. April 2013
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
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
Freitag, 22. März 2013
Switching OpenLDAP from cn=config to slapd.conf
For a project with a client I needed to set up an OpenLDAP server, configured via traditional slapd.conf. Nowadays most linux distros ship their OpenLDAP servers preconfigured with a cn=config style configuration. That is, the server config itself is stored in a seperate branch of the directory. This makes things like replication much easier, but poses a burden on the admin, who needs to learn the new way of configuring OpenLDAP. So, in order to make my client happy, I switched the config style. It took me a little to figure it out, so here I repost my solution:
service slapd stop # stop the service mv /etc/ldap/slapd.d /root # move the cn=config configuration cp /usr/share/slapd/slapd.conf /etc/ldap/ # get new sample config # make changes to sample config so that it can work sed -i "s/@BACKEND@/hdb/" /etc/ldap/slapd.conf sed -i "s/@SUFFIX@/dc=acme,dc=org/" /etc/ldap/slapd.conf sed -i "s/# rootdn/rootdn/" /etc/ldap/slapd.conf # manually execute "slappasswd" on the command line to generate a root pw # then add the following line (without "#") after rootdn # rootpw <crypted password> sed -i "s/@ADMIN@/cn=admin,dc=acme,dc=org/" /etc/ldap/slapd.conf mv /var/lib/ldap/* /root # remove old config database service slapd start # start service againFurther configuration will be nessessary, e.g. TSL configuration and server tuning (make sure to define your indexe attributes). Also, I need to remember to user fqdns in the client request, as I learned from this post.
Abonnieren
Posts (Atom)