package alternatives - dependency spaghetti

GNU/Linux systems and similar have several package management systems, most of which do a good job.

deb and rpm packages work well, provided dependencies are crafted carefully, to avoid

dependency spaghetti (or dependency hell)

I have run Debian production systems for 7 years or so, and I rarely see aptitude struggle to find a good solution.

Right now I am testing out the latest Debian (Squeeze), and it provides an example, that I have worked through on one system, and want to document here.

During testing, I noticed that my file manager Thunar was not automatically picking up changes to the underlying directory.

File alteration monitors (fam or gamin) generally look after this functionality.

Currently the system is using fam and here is a summary from dpkg:

which says that fam rather than gamin is providing the alteration monitor for my system.

Now the logical thing to do I thought would be to switch to gamin and see if that fixed my issue (described in paragraph 4)

Here aptitude tells me that Thunar recommends gamin:

Here is a screenshot of what aptitude thinks of my attempt to switch away from using fam:

Now removing libfam0 seems like the logical thing to do...

...but a quick look at the dependencies for libfam0, caused me a moment of pause:

And the way to reassure yourself is to preview the changes after choosing (!: Apply):

The output from aptitude includes the phrase 'removing anyway as you requested', which has me wondering?

Now a dpkg summary shows my system having gamin installed rather than fam:

The key to understanding how and why this works is to realise that, in Debian Squeeze, libgamin0 has been marked as a drop in replacement for libfam0 as shown here:

Which means that you can ignore any 'removing anyway as you requested' messages, and know that your system, has not been broken by your actions.

My system has no Nautilus file manager but instead uses Thunar:

...and as thunar recommends gamin, it is a shame that gamin, rather than fam, was not on my system automatically.

Now to see if my file manager is picking up changes to the underlying files in realtime :)

Debian Squeeze - packages 'held back'

During the 'testing' phase of a Debian distribution, it is expected that you will encounter packages being 'held back' a little more frequently.

Running a stable distribution you should mostly only see 'held back' for packages which you have deliberately put on hold.

Right now Debian Squeeze is a 'testing' distribution and this has provided my example for this article.

ntpdate on Debian (which I have installed):

There are several tools for synchronising dates of your server with external clocks.
Ntpdate is one such tool, openntpd and chrony are some alternatives.

ntpdate on my system shows as being 'held back' and I explain why below.

and running dist-upgrade gives similar results:

Now at this point you can check if perhaps you deliberately placed this package on hold by typing:

aptitude search ~ahold

The last portion spaced out is tilde then a then hold
  ( hold is the action flag you are searching for )

Which on my system gave no results ( meaning I have not placed ntpdate on hold )




So what is causing my system to say ntpdate is 'held back'?

Debian package tools are fairly well behaved and will not remove packages without some intervention from yourself.

You have to instruct Debian to remove dhcp3-client and until you do then ntpdate will be 'held back'.

Knowing this server as I do, I am fairly sure that dhcp3-client is something i do not need to keep, however there is no harm in checking if anything else will be affected.

Here there is a lot of information and you can treat as less important the lines beginning with pipe (|) which are merely 'suggests'.

   ( The non piped lines are a mixture of 'depends' and 'recommends' )

Here is a graphical representation (feel free to skip the graphics if you like)

Using the --installed flag to apt-cache rdepends gives you the most important information specific to your system.

What the above tells me is that ntpdate depends on dhcp3-client and ifupdown 'suggests' dhcp3-client. My final check was that I did in fact have ifupdown installed - yes it is installed on my system.

And the nugget of this article is really how to get apt past this 'held back' situation as shown here:

So if you have a 'held back' package, and you are certain that you are okay with what apt is going to remove, then go ahead and execute...

apt-get install packagename

( where packagename is replaced by the name of your particular package )

Note: Had my system really had a need for dhcp3-client ( certainly some desktop systems make use of this package ), then I would not have proceeded, and would have considered the following options:

1. Find an alternative to ntpdate
2. Find an alternative to dhcp3-client
3. Wait a while to see if the situation fixes itself*

*As explained at the outset of this article, I am running Debian Squeeze during it's testing phase and packages and interdependencies do change fairly regularly.

For those you are interested in alternatives to ntpdate, and where ntp/ntpdate fit into the grand scheme of things, here are some extra (optional) graphics

     ...and more generally chrony, openntpd, ntpdate (below) ...

Links and further reading:

• The package aptitude-doc-en has great html documentation describing things like 'action flags' and their meaning.
• ntpdate and ntp are different packages. Ntp is for those who want a running daemon rather than just a cli tool for crontab entry happiness.
• This mailing list entry is several years old but provides some very relevant information.

Upgrading VPS to Debian Squeeze

In any graphical VPS control panel, you are unlikely to see Debian Squeeze appear in the drop down for 'Reinstall OS' just yet*.

( *Debian Squeeze is perhaps to be released late 2010 )

But in order to test out the forthcoming release, perhaps you might go ahead and manually upgrade.


Kernel 2.6.3x rather than 2.6.18:

Ideally your VPS will be running in a hosting container that is running kernel 2.6.26 or newer.

( Such newer kernels are provided in Debian Squeeze, Red Hat Enterprise 6, and Ubuntu Lucid. It really depends on your hosting company, when they installed the container, how often they update container kernels, and their technology. )

If your container is unsuitable then you might see something like this:

Here Debian Squeeze is helping you, by pointing out that your kernel, does not support everything which Debian Squeeze might want.

Seeing "udev requires a kernel >=" warning on your VPS should make you pause.

One of the things that might be an issue is signalfd() or lack of.

If you decide to ignore the advice and try and run Debian Squeeze anyway, then you will probably be looking at how to get permissions fixed on some /dev/ files.

( It would be unwise for me to recommend this kind of action by elaborating.
It certainly makes reporting bugs difficult, if you deliberately run a production system using a kernel that is known to be outdated. )



/var/log/auth.log - is logging active?:

From a security point of view auth.log is an important file.
On a properly configured system, auth.log will give a concise record of important authorisations (including ssh logins)

After your upgrade it does no harm to check /var/log/auth.log is being written to.

auth.log is sometimes used by logwatch and similar security tools.

If you upgrade (particularly to a beta or testing distribution) then check that your system logging is working as expected.

Also check, when changing your system from running rsyslog to dsyslog or syslog-ng or other system logging alternatives.

Here is a diff to overcome an issue with the testing version of dsyslog in squeeze:

( The line marked with the green cursor is the important addition, and the sections related to cron are my convenience changes, rather than to fix any issue )

Today dsyslog.conf needed to be altered as condition pattern did not seem to be working as intended:

condition pattern { facility "auth*"; }; 

The above should have dsyslog writing to auth.log , but it was not happening on my system. It will likely be fixed before squeeze is officially released later this year.

To overcome the issue, I instead use condition literal as illustrated in the screenshot [ above ].


Packages you may want to purge once upgrade to squeeze is complete:

• gcc-4.2-base
• gcc-4.3-base

Locales cleardown and removing cruft from server accounts running X:

Try localepurge for reclaiming some redundant server space.

Another tool, bleachbit, might be useful for those running X on a remote server.

Bleachbit helps clear down user files such as those left behind when running web browsers, OpenOffice, etc.

( I have not used it in a server environment and would have to do some further reading, before I would feel comfortable running a shred like tool on a production server )


I tag this article 'nonKVM' and 'oldkernel' as Xen and OpenVZ, being more widespread in 2008 and 2009, tend to run with older kernel 2.6.18 rather than the much newer 2.6.3x series such as that included in RHEL6. Dedicated KVM resource offerings will become more widespread in late 2010 and 2011, and benefit from kernel 2.6.3x by simple fact of coming later to the party.