4

We wanted to install the "lsscsi" package on all our Linux Servers and build a manifest for it:

# pack_lsscsi.pp

class common::pack_lsscsi  {

        case $operatingsystem {
                RedHat, CentOS, Debian: {
                        package { 'lsscsi':
                                ensure  => 'installed',
                        }
                }
        }
}

The "lsscsi" Package has only "libc6" as a dependency - so a no brainer at all. All went fine on our Red Hat and CentOS servers, but some Debian systems went crazy. Puppet removed between 10 and 180 packages, like on this one:

Sep 17 10:46:06 cacti01 puppet-agent[28008]
(/Stage[main]/Common::Pack_lsscsi/Package[lsscsi]/ensure) change from purged
to present failed: Execution of '/usr/bin/aptitude -y -o
DPkg::Options::=--force-confold install lsscsi' returned 255: Reading package
lists...#012Building dependency tree...#012Reading state information...#012Reading
extended state information...#012Initializing package states...#012Writing extended
state information...#012The following NEW packages will be installed:#012  lsscsi
#012The following packages will be REMOVED:#012  alien{u} apt-file{u} ash{u} at{u}
autopoint{u} biff{u} bin86{u} bison{u} #012  bwidget{u} checkpolicy{u} cramfsprogs{u}
curl{u} dbus{u} debhelper{u} #012  deborphan{u} dhcp-client{u} doc-linux-de{u}
dosfstools{u} dselect{u} #012  ethtool{u} fdutils{u} finger{u} flex{u} flip{u}
gcc-3.4-base{u} gdb{u} #012  gdbserver{u} gettext{u} gnu-efi{u} gnupg-doc{u}
hicolor-icon-theme{u} #012  html2text{u} hwdata{u} ifenslave{u} ifenslave-2.6{u}
intltool-debian{u} #012  iptraf{u} joe{u} kernel-package{u} language-env{u}
lgtoclnt{u} #012  libappconfig-perl{u} libapt-pkg-perl{u} libatk1.0-0{u}
libatk1.0-data{u} #012  libaudit0{u} libavahi-client3{u} libavahi-common-data{u}
#012  libavahi-common3{u} libbeecrypt6{u} libbind9-50{u} #012  libcompress-raw-zlib-
perl{u} libcompress-zlib-perl{u} #012  libconfig-file-perl{u} libcroco3{u} libcrypt-
ssleay-perl{u} libcups2{u} #012  libcurl3{u} libdb1-compat{u} libdb4.2{u} libdbus-1-
3{u} #012  libdigest-hmac-perl{u} libdigest-sha1-perl{u} libdirectfb-1.0-0{u} #012
libdns58{u} libdrm-intel1{u} libdrm-radeon1{u} libdrm2{u} libelf1{u} #012  libfam0{u}
libfam0c102{u} libfile-remove-perl{u} libfont-afm-perl{u} #012  libfs6{u} libgl1-mesa-
dri{u} libgl1-mesa-glx{u} libglade2-0{u} #012  libglu1-mesa{u} libgtk2.0-0{u}
libgtk2.0-bin{u} libgtk2.0-common{u} #012  libhtml-format-perl{u} libhtml-parser-
perl{u} libhtml-tagset-perl{u} #012  libhtml-tree-perl{u} libice6{u} libident{u}
libio-compress-base-perl{u} #012  libio-compress-zlib-perl{u} libio-stringy-perl{u}
Sep 17 10:46:09 cacti01 puppet-agent[28008]: Finished catalog run in 54.68 seconds

Any idea how that could happen?

Thomas

user190307
  • 41
  • 1
  • 1
    Which Debian release do you use? Maybe this is an older release (like lenny) which needs to be upgraded to a current release. – deagh Sep 17 '13 at 14:48
  • 1
    Or maybe the apt sources or pinning got configured incorrectly. – Zoredache Sep 17 '13 at 16:38
  • We use Debian Squeeze. /etc/apt/sources.list identical on all servers, pointing to our own Debian Mirror. This happend to about 1/10 of all our Debian servers. That's what puzzles me. – user190307 Sep 18 '13 at 05:57
  • can you show what an "apt-cache policy lsscsi" shows, as well as "cat /etc/debian_release". Also a pastbin of /var/log/dpkg.log may help show the history of package changes on the system helping to track down the cause. – Steven Williamson Dec 18 '13 at 18:49
  • I find it helps with debugging to try to the aptitude command outside of puppet with simulate/verbose to see the actual output from apt. "aptitude --verbose --simulate install lsscsi" – Chris Montanaro Jan 17 '14 at 16:36
  • Is there a reason to prefer the `aptitude` provider over `apt`? Trying the latter may be beneficial. – Felix Frank Jul 02 '14 at 11:34

1 Answers1

0

This is happening because aptitude likes to remove packages that it thinks are unused. aptitude tracks every program it installs and classifies as either "manual" or "automatic". "Manual" packages are ones that explicitly request for installation. "Automatic" packages are ones that you didn't specifically request but that were installed as dependencies. For example, aptitude install irssi will install irssi, but also a host of libraries including libncurses, lbperl, lbtinfo, libval, and others. If at some point you remove irssi and it was the only installed package that needed some of those libraries, aptitude will remove the unneeded automatically-installed libraries, too.

Unfortunately, it used to be the case that aptitude and apt-get didn't play well together and packaged installed by apt-get would often be regarded by aptitude as automatically-installed and, thus, candidates for deletion. Newer versions of apt-get work much better in concert with aptitude, but this problem manifested at a time when these problems existed.

If, for some reason, you're still getting this behavior now, there are a couple of options. The simplest would be to just change to using the apt provider for Puppet's package type. That would completely sidestep any confusion aptitude has about which packages it ought to remove.

If you need to keep using the aptitude provider, you'll need to fix aptitude's ideas about what's in use. Run aptitude dist-upgrade and look at every package it wants to remove. For each one you know you want to keep, run aptitude unmarkauto <package-name> (e.g. aptitude unmarkauto apt-file curl). Then make sure you only use aptitude for package installations from that point onwards.

In my experience, the only things that aptitude does better than current versions of apt-get are interactive: the curses interface and the ability to modify the set of package installs/removals in the middle of a command line session. Puppet doesn't need any of the interactive features, so you really should be okay just using the apt provider.

asciiphil
  • 3,086
  • 3
  • 28
  • 53