geoip and geoip-database news!

Posted on by
Reply

Hi,

geoip version 1.6.2-2 and geoip-database version 20141027-1 are now available in Debian unstable/sid, with some news of more free databases available :)

geoip changes:

   * Add patch for geoip-csv-to-dat to add support for building GeoIP city DB.
     Many thanks to Andrew Moise for contributing!
   * Add and install geoip-generator-asn, which is able to build the ASN DB. It
     is a modified version from the original geoip-generator. Much thanks for
     contributing also to Aaron Gibson!
   * Bump Standards-Version to 3.9.6 (no changes required).

geoip-database changes:

   * New upstream release.
   * Add new databases GeoLite city and GeoLite ASN to the new package
     geoip-database-extra. Also bump build depends on geoip to 1.6.2-2.
   * Switch to xz compression for the orig tarball.

So much thanks to both contributors!

BASH fix Debian Lenny (5.0) CVE-2014-6271, CVE-2014-7169 aka Shellshock

Posted on by
Reply

Hello,

I have decided to create fixed bash packages for Debian Lenny. I have applied the upstream patchsets from from 052 until 057, so some other issues are also addressed in it. :-)
And here they are:

Source .dsc: http://misc.linux-dev.org/bash_shellshock/bash_3.2-4.1.dsc
amd64 package: http://misc.linux-dev.org/bash_shellshock/bash_3.2-4.1_amd64.deb
i386 package: http://misc.linux-dev.org/bash_shellshock/bash_3.2-4.1_i386.deb

Much fun with it!

Some photos of my Turkey/Belek vacation

Posted on by
Reply

Hola,

now, where I will travel again for 15 days to Fuerteventura/Corralejo from the 21.06.2013 until 07.07.2013, I remember myself, that I forget to post some images from my last vacation in Turkey/Belek.

Since my little realy cheap cam was damaged after a few days, I will post some photos of my buddy Robyn.

otrs and geoip-database updates

Posted on by
Reply

I have just uploaded the monthly update of geoip-database to Debian unstable and squeeze-backports, unblock request already filled.

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.

What an ugly (PHP) work..

Posted on by
13

We still have got some more or less webapplications which are not compatible with PHP higher than version 5.2.x, which is the only blocker for the last Lenny servers to upgrade them to Squeeze.. I do not think that I am alone with this ****** topic :)

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.

Squeeze or Wheezy for new projects?

Posted on by
1

Hi,

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?

otrs 3.1.12 in Debian experimental

Posted on by
Reply

Heyho,

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