I'm relatively new to system administration. I picked Debian over FreeBSD,
Ubuntu, Fedora and a few other systems for a number of reasons, one of these
being its reputation for internal consistency. This issue is making me
question that reputation.
The opportunity to avoid having to monkeypatch th
Is this bug going to be worked? Either by initscripts or chrootkit? Does it go
down as a DebianWontfixDueToInternalBickering and leave the user to hack
together a workaround?
If it's the latter, then
http://stereo.lu/chkrootkit-finds-libinitrwramfs-on-debian-etch has some
information that will
I'm here because both 'tiger' and 'chkrootkit' are reporting potential
problems. From tiger:
# Checking installed files against packages...
--WARN-- [lin001w] File `/lib/init/rw/.mdadm/md3-uevent' does not belong
to a
"chkrootkit is reporting some files and dirs as suspicious: `.packlist',
`.cvsignore', etc. These are clearly false positives. Can't you ignore
these?
Ignoring some files and dirs could impair chkrootkit's accuracy. An
attacker might use this, since he knows that chkrootkit will ignore
certain fil
Henrique de Moraes Holschuh wrote:
The bigger problem is that there's other stuff in /lib/init that
doesn't agree with the FHS.Unfortunately,
the FHS doesn't have /libexec either...
No. The big problem is that, AFAWK, the FHS doesn't have /run or anything
else that is usable for the initr
On Mon, 01 Jan 2007, Greg Kochanski wrote:
> >On Sun, 31 Dec 2006, Greg Kochanski wrote:
> >>According to that document, /lib is reserved for "shared library images
> >>needed to boot the system and run the commands in the root filesystem".
> >
> >This is a bogus description of lib *on systems wher
Henrique de Moraes Holschuh wrote:
On Sun, 31 Dec 2006, Greg Kochanski wrote:
According to that document, /lib is reserved for "shared library images
needed to boot the system and run the commands in the root filesystem".
This is a bogus description of lib *on systems where libexec is not used
On Sun, 31 Dec 2006, Greg Kochanski wrote:
> According to that document, /lib is reserved for "shared library images
> needed to boot the system and run the commands in the root filesystem".
This is a bogus description of lib *on systems where libexec is not used*.
Well, we could just add libexec
Sorry! Please note, that if I was insulting anything, it was a file,
not any person. Please don't be quite so testy!
I should have said "Probably violates the Debian rules for the
filesystem hierarchy standard, as shown on
http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#LIBESSEN
On Wed, 20 Dec 2006, Petter Reinholdtsen wrote:
> [Greg Kochanski]
> > The file /lib/init/rw/.ramfs is created, presumably by initscripts.
> > It's not in the package list, and that's not at all a good place to
> > dynamically create a file. Not to mention, putting a hidden file
> > under /lib is
[Greg Kochanski]
> The file /lib/init/rw/.ramfs is created, presumably by initscripts.
> It's not in the package list, and that's not at all a good place to
> dynamically create a file. Not to mention, putting a hidden file
> under /lib is pretty low-class.
I did not quite get what problem you ar
Package: initscripts
Version: 2.86.ds1-36
Severity: normal
The file /lib/init/rw/.ramfs is created, presumably by
initscripts. It's not in the package list, and that's
not at all a good place to dynamically create a file.
Not to mention, putting a hidden file under /lib is
pretty low-class.
--
12 matches
Mail list logo
