CentOS 6.x, fail2ban and proftpd

fail2ban in CentOS 6.x can sometimes be a bit troublesome, at least compared to the Debian/Ubuntu implementation (imho) .
I suspect I’ve solved the CentOS 6.x, fail2ban and proftpd integration different every time I’ve set it up so this tim ‘Ill write it down.
With this configuration I got fail2ban to ban failed proftpd ftp login’s with ‘default’ fail2ban config apart from enabling the proftpd-iptables ‘jail’ in /etc/fail2ban/jail.conf

[proftpd-iptables]

enabled  = true
filter   = proftpd
action   = iptables[name=ProFTPD, port=ftp, protocol=tcp]
           sendmail-whois[name=ProFTPD, dest=root@localhost]
logpath  = /var/log/secure
maxretry = 4

What did the trick was to have proftpd to log AUTH to /var/log/secure, in the right format.
In /etc/proftpd.conf comment out the default LogFormat auth directive and add your own:

#LogFormat                      auth    "%v [%P] %h %t \"%r\" %s"
ExtendedLog /var/log/secure AUTH auth
LogFormat auth "%v %t "%r" [%h] %s"

Partition alignment

I’ve known for a while the importance of partition alignment both for raid and for the (not so)new 4k harddrives.
Thinking about sector size of 512 bytes VS. 4k for newer drives, I’ve been a bit puzzled by the fact that 512 bytes x 4 = 4k .
I’ve read articles explaining the size of mbr causing unalignment, but I’ve yet to find an article explaining this issue more clear than http://www.thomas-krenn.com/en/wiki/Partition_Alignment .

Reload your vcl in Varnish without restart

Using varnishadm you can reload your vcl after editing it, without restarting varnish.
That means your cache is intact:

# varnishadm
varnish> vcl.load default /usr/local/varnish/etc/varnish/default.vcl
200
VCL compiled.
varnish> vcl.use default
200

varnish>

What I found really practical was that this way I also could detect and fix errors in my vcl config, without varnish going down.

varnish> vcl.load default /usr/local/varnish/etc/varnish/default.vcl
106        
Message from VCC-compiler:
Expected ')' got '{'
(program line 73), at
('input' Line 105 Pos 51)
        if ( !( req.url ~  "(login_form|manage)") {
--------------------------------------------------#

Running VCC-compiler failed, exit 1
VCL compilation failed

Ubuntu 13.10 console resolution

Switching to the binary Nvidia driver usually ‘break’ the nice boot splash and console resolution in Ubuntu. It has something to do with Linux being gpl licensed and the kernel code will be tainted if you integrate non-gpl code / or the kernel crew simply won’t integrate binary code, which I personally respect .

I’ve been using some VESA framebuffer since like for many years, and for the last 3-4 years I’ve been using the uvesafb module to get high resolution console and boot splash on my desktop.
I just noticed my ‘howto’ for getting this stuff setup in Ubuntu 13.10 no longer works, well it did actually work but I was put off when the ‘hwinfo’ package no longer was available.

I google’ed this for about 20 minutes, and tried a couple solutions that didn’t work, so I’m pasting my personal ‘howto’ on how I got this working on my 13.10.

# apt-get install v86d

Reboot, and in grub type ‘c’, then type ‘vbeinfo’ to list resolutions supported by your card.

Edit your /etc/default/grub file and make sure you use your desired resolution and bit depth listed from ‘vbeinfo’

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset video=uvesafb:mode_option=1280x800x32,mtrr=3,scroll=ywrap"

Now scroll down a bit in that file and edit this line also to match your previous change

GRUB_GFXMODE=1280x800

Now force the use of framebuffer

# echo FRAMEBUFFER=y | tee /etc/initramfs-tools/conf.d/splash

Now update grub and your initramfs image and you’re done!

# update-grub2 && update-initramfs -u

What I used to do was installing hwinfo which would show me supported console resolutions from terminal in my X session (Unity in my case), but since Ubuntu 13.10 has dropped support for HAL ( if I got it right) that package is no longer available.
I kind of solved it with vbeinfo from within grub, but that isn’t really optimal since vbeinfo listed a lot more resolutions than could fit within 1 page, and I couldn’t pipe that command to less. Luckily I saw one of the resolutions I wanted to use so that wasn’t really a problem after all.

Note that since I’m using the uvesafb, I don’t get like really hardware accelerated console, and that if I use 1920x1080x32 which my card supports as a maximum, stuff get imho a bit slow. That is, text rolling off screen is slow and a bit stuttering.
I’ve found that 1280×800 is a perfect compromise in my case.

strace to the rescue

So I’m installing the latest servicepack from HP on a proliant server running CentOS 6.4 .
Running

# ./hpsum

just died with a returncode of 127 .

Strace is just great for situations like these.

# strace ./cpsum
[...]
old_mmap(0xb30c000, 195144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb30c000
brk(0xb33c000)                          = 0xb3d9000
open("/lib/ld-linux.so.2", O_RDONLY)    = -1 ENOENT (No such file or directory)

Sooo I was missing som library. Finding the package that provides that lib is easy:

# yum provides /lib/ld-linux.so.2
[...]
glibc-2.12-1.107.el6_4.2.i686 : The GNU libc libraries
Repo        : updates
Matched from:
Filename    : /lib/ld-linux.so.2
[...]

The hpsum is ELF 32-bit, and I’m running X86-64, so I had to install several 32bit packages:

# yum install glibc.i686 libuuid.i686 libSM.i686 libXrender.i686 fontconfig.i686 zlib-1.2.3-29.el6.i686

Finding out which packages I needed was a matter of running hpsum and a mix of yum search / yum provides / yum install .

Exim and sendmail compatibility

I’ve maintained a rather large mail cluster using the Exim mta .
Configuring an MTA is something that is a lot more complicated than one would expect, until you try it. I know Exim now, and aren’t really motivated at learning sendmail or postfix, so I tend to switch to exim as the default mta for any server I administer .

I just did some debugging where a Mojolicious application didn’t send out email, and it turned out the exim ‘sendmail’ compatibility wasn’t 100% compatible with sendmail’s sendmail …
( Long story short: first there was sendmail in every Unix. Then came postfix and exim, but because a lot of Unix utilities already was programmed to using sendmail ‘they’ [postfix and exim] made a sendmail binary/wrapper that accept the same options as sendmail )

Anyway after some debugging I noticed that it seemed like the perl Mail lib was default’ing to adding -t to sendmail . And I had a look in the exim documentation and noticed that they _do_ support -t, but as they wrote:

If the command has any arguments, they specify addresses to which the message is not to be delivered. That is, the argument addresses are removed from the recipients list obtained from the headers. This is compatible with Smail 3 and in accordance with the documented behaviour of several versions of Sendmail, as described in man pages on a number of operating systems (e.g. Solaris 8, IRIX 6.5, HP-UX 11). However, some versions of Sendmail add argument addresses to those obtained from the headers, and the O’Reilly Sendmail book documents it that way. Exim can be made to add argument addresses instead of subtracting them by setting the option extract_addresses_remove_arguments false.

soooo I tried adding

extract_addresses_remove_arguments = true

to exim.conf, and it seem to have solved the problem.