From: Klavs Klavsen (kl_at_vsen.dk)
Date: Wed 27 Feb 2002 - 21:41:07 GMT
On Wed, 2002-02-27 at 05:02, Jacques Gelinas wrote:
> On Tue, 26 Feb 2002 09:08:27 -0500, klavs klavsen wrote
> > On Mon, 2002-02-25 at 11:32, klavs klavsen wrote:
>
> > > I'll try to gather all the information from this and earlier emailings
> > > into some additions to the FAQ, to help all new vserver users - and
> > > possible add some clever tips/usage to old users :-)
> > >
> > > I was wondering, if any of you know way I could:
> > >
> > > 1) get the disk usage of a vserver (the real one - discounting unified
> > > files).
> > I found vdu (I thought it existed, but couldn't find it in a bin
> > directory - why is it under /usr/lib/vserver/?)
>
> Because it is experimental and I was unsure if it was useful.
I believe it is. :-)
> > However it seems a little off.. my skel server, which has a bare minimum
> > of spaceusage, it says uses 325000K and that sounds like it's not
> > unified at all :-(
>
> vdu simply counts the space used by all file with a single link. It assumes that
> any file with more than one link is probably unified, which is almost true
> (very few files in a linux distribution are hard linked together)
which would mean, that my skel-server is not unified against the base system?
325mb is a lot for config files only, However a du -csh /vserver/skel
says 403mb - which means that there are some unified files. Can this
have anything to do, with the fact that I've rpm -e a lot of packages
within the skel server? (didn't use vrpm).
>
> > > 2) get a list of files, that is not unified (or a list of files that
> > > are?) - this way I could easily check for changes in a vserver - such as
> > > evidence of hackers and such.
>
> vdu could use this instead. If the file has the immutable bit on, and has
> more than one link, it must be unified.
the immutable-unlink flag, could be checked with lsattr (if so, what's the letter for it?)?
> I am thinking about a new utility called vfiles. This utility will produced
> a list of file not unified by comparing a vserver with either a reference
> vserver or a package list (a package list + versions in a text file).
sounds interesting, and definetely useful. Would be a good thing to make
some switches, just like DU so one can choose how and what the user
exactly wants. As I see, it there are a few uses for different kind of
output, which basically belongs to the unified / not-unified
question.(f.ex. the ability to find files, that are outside, the
"not-unified" dirs only, and have been un-unified etc.).I'm sure you can
think of many more.
>
> Tonight I wanted to bring a vserver home (how cool :-) ). So I tar it and compress
> it. Got 500megs. Not so bad. It fits on my notebook. But wait, 90% of the files
> in there are already available on my workstation at home. No need to bring them.
But are they the exact version? would require, that you the same version
of RH, and have applied the same updates.
> So using vfiles, I would be able to select all the file no unified (including
> added packages not found in the reference), bring that home, and then
> use vunify to bring back the vserver to life :-)
fair enough, but one would have to be able to check against the
reference of the home-server.
> Using vfiles, we could do various things, such as vbackup, backuping
> only what it needed.
kinda like rsync. sounds very useful.
> Using vfiles, it becomes very easy to backup a vserver in the root server
> and then compare that to prove the vserver has not been hacked.
One of the very interesting features. However, it should be possible to check this without
comparing against a backup - f.ex. by having a list of files that
"should be" unified - and then checking if they still are. If they have
been unlinked - something weird is up.. and if you know you updated the
vserver only, then you could just update the list of unified-files.
The list of should-be unified files, are also good to apply a
tripwire-like checksum check root against vserver, if one does not have
a checksum database installed.
> But I would like to see something else in this area. For example, a per
> vserver flag could change the meaning immutable-unlink fiag. It would
> be possible to turn the vserver flag on and off from the root server. When
> the per server flag (called it "frozen") is turned on, the ummutable-unlink
> flag is disregarded. This means, instantly, all unified files turned to immutable
> only: A vserver is not allowed to changed them anymore.
is this not possible now, by removing the immutable-unlink flag, from
the necessary vservers only? sorry if I'm a but dumb here, but what's
the extra features with the per vserver flag?
>
> By using immutable flag on other files as well (config, the rpm database), you can
> lock a vserver completly in few seconds. This way, you know an intruder can't
> do anything.
that's cool.
> Now, you can play game with that. Another per vserver flag, called "alarm" may
> be used. When on, anytime an immutable file is modified (well, anytime a
> modification is attempted), the process doing that is locked and some
> external process is triggered paging the admin. You can trap intrusion in real
> time.
sounds like a cool and inexpensive way of doing Instant IDS.
> All those funny feature could be implement using the Linux Security Module
> I think.
I would love to hear what your plans are with the LSM and vserver. I visited Openwall but couldn't find any texts about what LSM is, and what it enables.
> > > 3) I have several vservers running now, and if I add some files to my
> > > root server, how can I easily hardlink them to the vservers I want to be
> > > able to access it? ln ? (this is to save disk space).
> > can I use the vunify command?
>
> vunify operates on packages, so it won't unify anything. You can use
> hard link at any time to share a file. The best solution is often to use the
> mount --bind option. It allows you to share a directory. For example, at the
> office, when we create a vserver for a developper, we give him his home
> directory. So in the per vserver startup script, we do
> mount --bind /home/jacques /vserver/jack/home/jacques
>
> This way, jacques feels at home. He has access to his personal files and
> he has "root access". Ye!
>
> > > btw. I'm looking into how to get Samba running under a vserver, as I
> > > consider it one of the rather dangerous services to run and I would
> > > therefore like it to be run under a vserver.. any tips or experiences
> > > with this? I've heard there were some problems with the smb broadcasts?
> > > why is this? Can I do anything about it (add a capability, like what
> > > fixes the Bind issue?).
>
> Using kernel ctx-8, samba should work fine in a vserver. The only issue is
> that the vserver must be either in the DNS or you must use a WINS to reach
> it (which you probably do anyway).
Great. what change enabled this? (i'm curious by nature :-)
-- Regards, Klavs Klavsen-------------| This mail has been sent to you by: |------------ Klavs Klavsen - OpenSource Consultant kl_at_vsen.dk - http://www.vsen.dk
Get PGP key from www.keyserver.net - Key ID: 0x586D5BCA Fingerprint = A95E B57B 3CE0 9131 9D15 94DA E1CD 641E 586D 5BCA --------------------[ I believe that... ]----------------------- It is a myth that people resist change. People resist what other people make them do, not what they themselves choose to do... That's why companies that innovate successfully year after year seek their peopl's ideas, let them initiate new projects and encourage more experiments. -- Rosabeth Moss Kanter