From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Wed 27 Feb 2002 - 04:02:41 GMT
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.
> 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)
> > 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.
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).
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.
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 :-)
Using vfiles, we could do various things, such as vbackup, backuping
only what it needed.
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.
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.
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.
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.
All those funny feature could be implement using the Linux Security Module
I think.
> > 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).
---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc