So I had these two simple classes
class debian::apt::sources {
if $debian_apt_sources {
$debian_apt_sources = $debian_apt_sources
} else {
$debian_apt_sources = "#No content specified. Fix me!\n"
warning( "Warning: no content specified for
debian::apt::sources" )
}
file { '/etc/apt/sources.list':
mode => 444,
owner => root,
group => root,
content => $debian_apt_sources,
}
}
class debian::apt::update {
exec { 'apt-get update':
path => '/usr/bin',
subscribe => File['/etc/apt/sources.list'],
refreshonly => true,
}
}
Sometimes, apt-get update would fail with a generic "returned 100
instead of 0" error. Googling found that a few people had encountered
this, with no solution that i could see. I tracked it down to an error
returned by bzip2, when downloading bzipped packages lists. Moment of
revelation was when I realised that apt-get is in /usr/bin but bzip2 is
in /bin (on Debian, anyway). Changing the debian::apt::update class to
have
path => '/bin:/usr/bin'
fixed it. So apt-get obviously doesn't use a hardwired path for bzip2
and expects to find it on the PATH. Silly me. Google tells me that a
bunch of Ubuntu and Debian-based consumer devices out there have this
problem as well, doubtless because apt-get has been wrapped in some
custom front-end that makes the same mistake I did.
--
Bruce
Explota!: miles de lemmings no pueden estar equivocados.