I also uploaded otrs2 in the new version 3.2.1+dfsg1-1, which is also “fixing” bug #690306, “fixing” because the upgrade will abort with a list of MySQL tables where the administrator has to fix ether the engine from MyISAM to InnoDB (or the other way, as he want to) and by fxing the default engine of his MySQL database server. Ugly issue, ugly hack, but there is no better solution..

Full changelog of otrs Debian packaging:

   * New upstream release.
     - Add new dependency libyaml-libyaml-perl.
     - Refresh patch 03-postmaster.
     - Refresh patch 05-opt.
     - Refresh patch 13-dont-chown-links.
     - Refresh patch 16-disable-DashboardProductNotify.
     - Refresh patch 19-fix-SetPermissions-to-include-some-more-dirs.
     - Rewrite patch 25-use-locale-country, since all_country_names() does not
       accept arguments.
     - Refresh patch 26-font-paths.
     - Rewrite patch 04-backup.
     - Rewrite patch 15-usable-apache-config.
     - Rewrite patch 21-use-debian-libjs-packages.
     - Rewrite patch 23-load-debian-libjs.
     - Remove old database schemas and add new 3.2 ones.
   * Monitor all releases again.
   * Drop patch 24-default-myisam and check with the new otrs.CheckDB.pl script,
     if the available tables and the used storage engine are equal. If it is not
     the case the installation should abort, so that the administrator can fix
     his MySQL server or the already created tables.
     Closes: #690306
   * Remove deprecated packaging notes from README.Debian.
   * Remove deprecated NEWS file from packaging.
   * Remove deprecated files from otrs2.examples.
   * Solve duplicate-changelog-files by not installing the CHANGES file.
   * Remove some more deprecated files from otrs2.docs.
   * Add lintian override for empty-binary package otrs.
   * Remove some old permission fixes from debian/rules.
   * Add upstream patch 01-innodb-fk-error to fix some foreign key errors if the
     tables are created with InnoDB.

So the new “masterplan” is to deploy those applications on seperated Wheezy servers, with PHP 5.2.x running as FastCGI, so that most parts of the system are “security supported”.

First; I didn’t documented my steps and I am not 100% done (something like 99%) but I have done the following to have it “as clean as possible”:

• Catch the original 5.2.17 sources and build them, urgs.. it fails at all with the new multiarch paths from Wheezy, after a few hours of patching I gave up..
• Using dotdeb Lenny sources as reference, they also have got 5.2.17 sources, but what the fuck? The orig sources of their mirror also could not build, because the patch series FAILS (not hunky, they fail!), how did they build them???
• After some sanitizing of the dotdeb packages I thought it is better to smoke some cigarette and to delete them, urgs..
• My next step was to catch the latest 5.2.12-x packaging from snapshot.debian.org, here the story continues… again…:

PHP 5.2.x is just not able to detect the new multiarch paths, it fails at most “dir” options. Since patching the whole build system would be *too* much work I decided to hack around this (ln -s /usr/lib/x86…./foo.so /usr/lib/), then some adjustions to the build dependencies, disablieng some modules, like SSL and libdb (incompatible versions), disabling merged patches and refresh the suhosin hardening patch; I get an working PHP 5.2.17 package on Wheezy.
But this is too easy!
I want packages which I could co-install with the PHP 5.4 packages from Wheezy, 5.2 should only used withing vHosts where I have enabled them..

So I rewrote the whole packaging (*burg* IMHO at all) to use “php52″ instead of “php5″ as packaging namespace and also everything is put into “/opt” as prefix. Much painfull work, but yeah it works.. :)
Some packages, like php52-dev or php-pear are broken, but those were not my goal of this action.

If someone is interested in those packages please send me an email.
Since PHP 5.2 is not supported any longer (and that this is at all a big hack) I will not publish the source and binaries at all.

I am interested in your opionions! If you would setup today an new server for a (business) project, would you use Debian Squeeze or Wheezy?

Personal – and already in most business cases – we have decided for Wheezy, because the pros are:

• Enhanced hardening
• More up to date technologies and scripting languages
• Longer security support, because..
• .. you do not have to dist-upgrade within the next year(?)

The cons:

• It is not stable yet

What is your (business) opionion about it?

I have just uploaded otrs2 version 3.1.12+dfsg1-1 to Debian experimental yesterday! It includes many bugfixes, for a full list have a look at [0].

I also would welcome help for two important tasks:
#690306: Upgrade to Wheezy fails, if InnoDB is used in (some) tables
#695664: Embedded JavaScript code copies. As usual problematic with a package which is as big as otrs..

I also will backport otrs 3.1.x to Wheezy backports, if it is released. After this step, work on the 3.2.x packaging will begin.

[0]: otrs changelog

So see you in two weeks!

3.3.1 has been released with a bunch of bugfixes, yeah! 3.3.1-1 is uploaded to experimental.

geoip-database

As usual the monthly database update, already migrated to Wheezy from Sid.

otrs2

Today 3.1.11 has been released with a few bugfixes and one security fix for a XSS vulnerability on viewing special prepared HTML e-mails, which leads to that the browser executes JavaScript code (as described in CVE-2012-4751 and OTRS security announcement OSA-2012-03).
otrs2 3.1.11+dfsg1-1 is just accepted in experimental and I also backported the patch to the Wheezy version with 3.1.7+dfsg1-6.

Installation

On Squeeze following is enough: # apt-get install libapache2-mod-geoip geoip-database/squeeze-backports

Note that you should use the geoip-database version from squeeze-backports to have got the most up to date database version, I am updating it every month.

Configuration

You can add the rules to your VirtualHost, Directory, Location directives and also to your apache2.conf (“serverwide”). So you are flexible with where to use it.

Blocking countries

On some servers I have got more than 90 percent of spam requests only from three countries, so I blocked them with:

<DirectoryMatch “^/var/www/.*/html”>
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE UA BlockCountry
Deny from env=BlockCountry
</DirectoryMatch>

Allow only specific countries

In the other way you also can allow specific countries to have got access to your website, this also may be a good idea for extranets, where you know from where your customers are:

<Directory “/var/www/my.site.com/html/login”>
SetEnvIf GEOIP_COUNTRY_CODE DE AllowCountry
SetEnvIf GEOIP_COUNTRY_CODE CH AllowCountry
Deny from all
Allow from env=AllowCountry
</Directory>

Very easy!

Rewrite Rules

You can also use it for mod_rewrite. Within a project, customers from CN and TW should be redirected to the chinese page:

RewriteCond %{ENV:GEOIP_COUNTRY_CODE} ^(CN|TW)$
RewriteRule ^(.*)$ http://some.example.cn/site.php [L]

mod_geoip with proxy frontends

Normaly mod_geoip works behinds load balancers and proxy servers, since it also take care of the HTTP_X_FORWARDED_FOR header.

But with haproxy it looks problematic, since it does not add the HTTP_X_FORWARDED_FOR header to KeepAlive’d requests :( Disabling KeepAlive is a bad idea on this cluster, so we decided to also use php5-geoip in our application, so everything is working nice now..

What mod_geoip is NOT is

mod_geoip helps you to block/allow specific countries, but it does not protect you from them.
Also keep in mind that the database is only ~ 99,8% accurate, so you may have got false positives/negatives. If you only allow german users, a german IP could be listed as russian.
This is much more problematic with mobile/satellite connections and surely you can also not access your page, if you are on vacation in another country. ;)

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. :)

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
$

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