Category Archives: Debian

Recent packaging updates 2012/09

Posted on by
Reply

What I have done (on my packages for Wheezy) in the last weeks?

imvirt

0.9.4-3 and 0.9.4-4 adds two upstream patches to remove an applicable use of /proc in Perls procfs_read() method, which fixes LXC detection and another patch to not count the dmesg lines twice within the KVM detection module.
Much thanks to Thomas Liske!

mlt

The 0.8.0-4 upload also adds two upstream patches to fix an major memory leak in the mlt_cache function and a crash with LADSPA plugins on dlclose().
And here much thanks to Dan Dennedy!
I have also uploaded 0.8.2-1 to experimental.

roaraudio

1.0~beta2-2 and 1.0~beta2-3 added a few upstream patches to fix security and major use problems. The debdiff was a bit huge so it took a bit more time to unblock/migrate.
1.0~beta5-1 is also available in experimental.
Much thanks for the patch support to Philipp Schafft!

otrs2

With the 2.4.9+dfsg1-3+squeeze3 upload (DSA-2536-1) there was an security update for otrs2 on Squeeze which fixes a cross-site scripting issue and improved the e-mail filter to detect nested tags. Those – with a few other fixes – migrated with 3.1.7+dfsg1-5 to testing, while I also uploaded 3.1.10+dfsg1-1 to experimental.
Now I can focus on the upcoming 3.2.x packaging. :)

Hide process information for other users

Posted on by
2

Debian GNU/Linux Debian 7.0 (aka Wheezy) will be a “general hardened” distribution in my eyes. Not only that it now enabled hardened building of packages (see http://wiki.debian.org/Hardening), the Kernel team also backported with 3.2.20-1 the IMO very interesting hidepid option (already available in Wheezy since some weeks)!

What is the job of “hidepid”?

hidepid is an new mount option for the procfs (/proc), with that you can hide processes and its information to other users, like other shell users and to web scripts.

hidepid accepts three different values:

  • hidepid=0 (default): This is the default setting and gives you the default behaviour.
  • hidepid=1: With this option an normal user would not see other processes but their own about ps, top etc, but he is still able to see process IDs in /proc
  • hidepid=2: Users are only able too see their own processes (like with hidepid=1), but also the other process IDs are hidden for them in /proc!

Additionaly you can specifiy an user/group ID which is still able to look up the processes with the gid option. So if you want to hide all processes to other users, except root (uid=0) and in this example gid=1001 (some semi administrative user in this example) your /etc/fstab has to look like this:

proc            /proc           proc    defaults,hidepid=2,gid=1001        0       0

It was a good descision to backport this feature IMO, but also be careful, it *may* break programs. I did not found any server related application which will break with hidepid=2, but we had to adjust our Nagios monitoring to execute some process checks with another UID, since the nagios user itself could not see anymore, if process A and B is still running.

UPDATE 1:
Since a few people asked (thanks for it) with hidepid=2 the process IDs are not invisible, they are unavailable:
$ ls /proc/1
ls: cannot access /proc/1: No such file or directory
$

Raspberry Pi B

Posted on by
Reply

And here is it, after just six weeks of waiting!
As you can see on the image it is as long as a cigarette lighter.

Now I just have to find some free time to play with the Debian image and to install my little music station :)

Logging packets with iptables and ULOG

Posted on by
4

Imagine you have got the following iptables rule set:

*filter
:INPUT ACCEPT [2:130]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [119:14185]
-A INPUT -s 127.0.0.0/8 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp –tcp-flags FIN,SYN,RST,ACK SYN -j DROP
COMMIT

This would allow all traffic from 127.0.0.0/8, on port 22 and 80. Other (TCP/IP) SYN packages (so on all the other connections) would be dropped.
Now you see, that your counter for the SYN DROP rule is increasing and you want to know what is rejected, but how?

The simple answer is ULOG – the netfilter userspace logging daemon.
In Debian you have got various implementations/variants of it, the local logging one (which I will use here, just called ulogd) and the -postgres, -mysql and -sqlite3 one (that are not the exact package names), with that you also can log everything to a (remote) database.
An special variant is the -pcap one, it will write the logs in the .pcap format, so you can analyze the full traffic.

So for our example it is enough to install the package:

apt-get install ulogd

And then add another rule BEFORE our SYN DROP:

-A INPUT -p tcp -m tcp –tcp-flags FIN,SYN,RST,ACK SYN -j ULOG
-A INPUT -p tcp -m tcp –tcp-flags FIN,SYN,RST,ACK SYN -j DROP

Now you will find in /var/log/ulog/syslogemu.log a log of all connections, which would be dropped, the log looks like this:

Aug 13 14:42:07 srv1 IN=eth0 OUT= MAC=00:0c:29:8c:2b:6c:00:d0:02:eb:e8:0a:08:00  SRC=75.125.70.194 DST=XXX.XXX.XXX.XXX LEN=40 TOS=00 PREC=0x00 TTL=54 ID=9566 PROTO=TCP SPT=57144 DPT=445 SEQ=2770468863 ACK=0 WINDOW=512 SYN URGP=0
Aug 13 14:45:29 srv1 IN=eth0 OUT= MAC=00:0c:29:8c:2b:6c:00:d0:02:eb:e8:0a:08:00  SRC=75.125.70.194 DST=XXX.XXX.XXX.XXX LEN=40 TOS=00 PREC=0x00 TTL=55 ID=13702 PROTO=TCP SPT=58528 DPT=445 SEQ=1217789951 ACK=0 WINDOW=512 SYN URGP=0

So you have got now the information about the full date, mac address (mostly it will be the one of your gateway), source and destination IP, source and destination port, length, protocol, etc.

You also could use it to log outgoing connections to port 80 and the IRC ports:

-A OUTPUT -p tcp -m tcp –dport 80 -j ULOG

-A OUTPUT -p tcp -m tcp –dport 6666:6669 -j ULOG

Whatever you want.

glusterfs Wheezy status

Posted on by
Reply

While many (german) IT magazines write about glusterfs since RedHat has taken it over, here is a short summarzy of the glusterfs Debian packaging status.

  • Debian stable/Squeeze delivers 3.0.5-1 and I just updated it on squeeze-backports to 3.2.7
  • Squeeze will come with 3.2.7, which is the latest release of the 3.2.x series. 3.3.0 was too new for me to upload it for Whezzy, also if it was released before Whezzy was frozen
  • You also could get 3.3.0 from experimental. 3.3.1 should be out soon and I will try to keep the packages up to date

If you are interested, I am still seeking for help!

OTRS updates

Posted on by
Reply

Debian Wheezy will come with otrs 3.1.7, I also backported one important upstream patch from 3.1.8 to it. Also you can get now 3.1.8+dfsg1-1 from experimental :)

With the 3.1.7 packaging I also migrated our otrs instance from 2.4.9 to 3.1.7 a few weeks ago, with some small problems:

  • We are using Apache as webserver for otrs, which requires the libapache2-reload-perl package. It is just a recommends, because if you run otrs on another webserver, it is not required. So this package was missing after the upgrade and Apache silently died. But having a look at the error.log mod_perl complains about the missing module.
  • We are using MySQL as database backend. With MySQL 5.5 Oracle changed the default storage engine from MyISAM to InnoDB, which is a good choice, but OTRS never used the ENGINE option in their installation and upgrade MySQL scripts. So if you upgrade an existing installation, some ALTER TABLE would fail, because of some FK fuck up between MyISAM and InnoDB tables. That was fixed with 3.1.5+dfsg1-2 by adding some “default storage engine” foo, but our remote MySQL cluster did not knew this option, yet, so I also had to patch out my patches on upgrading :(
    I am already interested in better fixes for the packaging!
  • Printing/Exporting tickets resulted in an “Internal server error”, fixed with 3.1.7+dfsg1-2 by adjusting the font paths. The Perl module has dropped the embedded font copies.

Now after five years of working with otrs 2.x in my company, all our agents accept the new 3.1 one and they are happy with it :-)

In the next weeks I also will check a backport of the 3.1.7 release for Squeeze.

 

Debian Wheezy status of fglrx-driver

Posted on by
1

After too much months without a working fglrx-driver for Wheezys Xserver 1.12 we have got now a fully working version!

What happened?

  • On the 14.05.2012 fglrx-driver was removed in favour of the xserver 1.12 upgrade
  • AMD decided to not publish their driver on an monthly base anymore :(
  • After some more user complaints AMD published the 12-6~beta driver with 1.12 xserver support, but it also removes support for “older” hardware (RadeonHD 2000-4000 series) and this release introduced the bug #675940 which made fglrx-driver completly unuseable on amd64 (crashing Xorg)
  • The 12-6 release also did not fix the crash bug and it was scheduled for something like october (if I remember correctly)
  • After some mail traffic with some AMD developers and another month waiting for an offical answer, AMD created a point release for Debian! Much thanks to AMD! So I have called it 12-6+point and it is working like a charm :)

Freeze exception for it is filled since > 10 days, we are now just waiting for an answer.

If you are missing support for the older RadeonHD series, Andreas (co-maint of fglrx-driver) just packaged the legacy driver, which is available in experimental.
Very much thanks to him, especially for all his very good fglrx-driver packaging work!