[Vserver] Capabilities and Flags
Hi, Where can I find out more about the various vserver capabilities and flags in more detail than the Vserver Paper provides? I want to know what all the available flags and capabilities are, and what they provide. Thanks, Fareha ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Errors on stopping vserver
Thanks!
-FS
Herbert Poetzl wrote:
On Wed, May 24, 2006 at 03:34:10PM -0700, Roderick A. Anderson wrote:
Fareha Shafique wrote:
Roderick A. Anderson wrote:
Fareha Shafique wrote:
Hi,
When I stop the vserver I get the following:
Stopping sshd: [FAILED]
Shutting down kernel logger: [FAILED]
Shutting down system logger: [ OK ]
Starting killall: Stopping sshd:[FAILED]
[FAILED]
I'm not sure why I this happens. Any help would be appreciated.
I'm trying to catch up on several months worth of messages (from the
latest to earlier ) and can't remember if I saw an answer to this.
FWIW I just ran into the same issue and it has to do with sshd failing
start to in your guest server. Typically becuase the IP address is
already in use somewhere else. ( The host server? ). Check the
settings in sshd_config for the host and all the guest servers. Make
sure the ListenAddress is set to/for the correct IP address/server
combination.
Thanks for the reply. I have ssh working fine now. The kernel logger
however always fails to start and hence fails to stop
Sorry I forgot about that. Typically this comes from Redhat-ian
systems. Syslogd and klogd are started and stopped from 'inside' the
same script.
/etc/rc.d/init.d/syslog
Edit the file and comment out any lines that mention klogd.
or, alternatively, enable the syslog virtualization
http://linux-vserver.org/Caps+and+Flags
best,
Herbert
In the Fedora Core 5 install I'm looking at there are these lines.
18: [ -f /sbin/klogd ] || exit 0
25: KLOGD_OPTIONS=-2
40: echo -n $Starting kernel logger:
41: daemon klogd $KLOGD_OPTIONS
42: echo
47: echo -n $Shutting down kernel logger:
48: killproc klogd
49: echo
59: status klogd
79: RETVAL=1
80: echo -n Reloading klogd...
81: klog=`cat /var/run/klogd.pid 2/dev/null`
82: if [ -n ${klog} ] [ -e /proc/${klog} ]; then
83: kill -USR2 $klog;
84: RETVAL=$?
85: fi
86: if [ $RETVAL -ne 0 ]; then
87: fail
88: else
89: success
90: fi
In the immortal words of Herbert;
HTH,
Rod
--
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Hashification
Hi, I've been struggling to fully understand how vhashify works for a while now. I want to know more about it. It would be nice if someone could answer the following questions for me or point to some document which can help me understand the vhashify and unify better: 1) What files and how does vhashify step through and compare for unification? 2) What things are compared to determine if the files can be unified? In other words, what properties of the file should be the same? 3) What is the format of an exclude file? Thanks, -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Hashification
Corey Wright wrote: I've been struggling to fully understand how vhashify works for a while now. I want to know more about it. It would be nice if someone could answer the following questions for me or point to some document which can help me understand the vhashify and unify better: isn't there a vhashify.c? ;-) I had a look at that but specifically for the answer of the first questions, unfortunately I didn't quite grasp what was going on :) The reason I asked the questions is that I have 2 identical vservers (i.e. all the files are the same except those created by the skeleton build method). However, when I hashify, one vserver ends up with a lot more unified files than the other. So I'm trying to figure out why this is happening...I have not customized the exclude list in either vserver. 1) What files and how does vhashify step through and compare for unification? dunno. i've wondered that myself, and postulated some, but the proof is in the pudding so i haven't questioned it too much. i'm guessing here, but every file in /etc/vservers/vserver/vdir not explicitly excluded by some pattern in /etc/vservers/vserver/apps/vunify/exclude or /usr/lib/util-vserver/defaults/vunify-exclude is hashed, looked up in a hash table (ie files within /etc/vservers/.defaults/apps/vunify/hash/0 named after value of hash of contents), file attributes are compared against the hardlink in the hash table, and if found equal, then the files are unified. so how close did i get? :-D herbert, daniel, somebody correct me if i'm wrong. 2) What things are compared to determine if the files can be unified? In other words, what properties of the file should be the same? all properties besides file name. at least that's my guess according to http://www.debian.org/doc/manuals/debian-tutorial/ch-advanced.html#s-advanced-files-hardlinks as unification just takes advantage of hardlinks (with the special property of being immutable but unlinkable). 3) What is the format of an exclude file? from http://linux-vserver.org/alpha+util-vserver, under Directory/vserver unification: It has rsync-like excludelists, so that you can e.g. exclude anything under /etc/ except /etc/termcap; the corresponding excludelist would be +/etc/termcap /etc further see http://samba.anu.edu.au/ftp/rsync/rsync.html, specifically the FILTER RULES and INCLUDE/EXCLUDE PATTERN RULES sections. take all the above with a grain of salt as i'm just making educated guesses. hopefully somebody will at least confirm whether i'm right or wrong. corey Thanks for your help. I really appreciate it. -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Quick question
Corey Wright wrote:
hopefully the line wrapping doesn't visually destroy the following too much.
# ls -1i /home/vservers/*/bin/bash | cut -d' ' -f1 | uniq -c
13 6751094
(all thirteen instances of /bin/bash within vservers occupy inode 6751094.)
# ls -il /home/vservers/{test,client}/bin/bash*
6751094 -rwxr-xr-x 14 root root 729640 2005-05-02
17:39 /home/vservers/client/bin/bash
6751094 -rwxr-xr-x 14 root root 729640 2005-05-02
17:39 /home/vservers/test/bin/bash
(there are 14 hardlinks: 13 belonging to vservers, and the master one
within /etc/vservers/.defaults/apps/vunify/hash/0.)
# cp -av /home/vservers/client/bin/bash{,.unlinked}
`/home/vservers/client/bin/bash' -
`/home/vservers/client/bin/bash.unlinked'
# ls -1i /home/vservers/{test,client}/bin/bash*
6751094 /home/vservers/client/bin/bash
573454 /home/vservers/client/bin/bash.unlinked
6751094 /home/vservers/test/bin/bash
# rm /home/vservers/client/bin/bash
rm: remove write-protected regular file `/home/vservers/client/bin/bash'? y
# mv /home/vservers/client/bin/bash{.unlinked,}
# ls -il /home/vservers/{test,client}/bin/bash*
573454 -rwxr-xr-x 1 root root 729640 2005-05-02
17:39 /home/vservers/client/bin/bash
6751094 -rwxr-xr-x 13 root root 729640 2005-05-02
17:39 /home/vservers/test/bin/bash
# vserver client hashify -nv
Initializing exclude-list for /home/vservers/client (client)
Starting to traverse directories...
snip
unifying '/bin/bash'
snip
# vserver client hashify
# ls -il /home/vservers/{test,client}/bin/bash
6751094 -rwxr-xr-x 14 root root 729640 2005-05-02
17:39 /home/vservers/client/bin/bash
6751094 -rwxr-xr-x 14 root root 729640 2005-05-02
17:39 /home/vservers/test/bin/bash
so, that's how it works for me.
this is how i set it up, synthesized from
http://linux-vserver.org/alpha+util-vserver under vhashify.
* mkdir -p /etc/vservers/.defaults/apps/vunify/hash
* mkdir -p /home/vservers/.hash
* ln -s /home/vservers/.hash /etc/vservers/.defaults/apps/vunify/hash/0
* mkdir -p /etc/vservers/vserver/apps/vunify
* customize exclusions (if necessary)
o cp
-av /usr/lib/util-vserver/defaults/vunify-exclude
/etc/vservers/vserver/apps/vunify/exclude
o echo '/usr/src/*' /etc/vservers/vserver/apps/vunify/exclude
* vserver vserver hashify -nv | less
* vserver vserver hashify
all but the first three steps should be repeated for each vserver.
note: /etc/vservers/.defaults/apps/vunify/hash/0,
/etc/vservers/.defaults/vdirbase,
and correspondingly /etc/vservers/*/vdir must all be (or symlink to
directories) on the same filesystem, otherwise hardlinks cannot be
created.
hth.
corey
Thanks for the detailed explanation. I have done exactly what you said,
but the two folders /etc/vservers/.defaults/aaps/vunify/hash/0 (and the
linked one /home/vservers/.hash)
contain a separate file for each file in the 2 vservers I unified (i.e.
twice as many files as there should be). So when I check my vserver
files, the number of links is 2 for the unified files: one link from the
vserver and one link from the host. But the files are not unified
between the two vservers.
Is there any configuration that might be necessary for unification and I
may have missed?
Thanks,
-FS
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Quick question
I did install from source, I used rpms. ADNET Ghislain wrote: sorry to jump on the thread, just a little test : when you make the vserver-util, do the make check worked for all tests ? i have issue on the unify test on debian, perhaps you have something related or a beecrypt issue ? Cordialement, Ghislain ADNET. Thanks for the detailed explanation. I have done exactly what you said, but the two folders /etc/vservers/.defaults/aaps/vunify/hash/0 (and the linked one /home/vservers/.hash) contain a separate file for each file in the 2 vservers I unified (i.e. twice as many files as there should be). So when I check my vserver files, the number of links is 2 for the unified files: one link from the vserver and one link from the host. But the files are not unified between the two vservers. Is there any configuration that might be necessary for unification and I may have missed? Thanks, -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Quick question
Sorry, I meant I did NOT install from source. -FS Fareha Shafique wrote: I did install from source, I used rpms. ADNET Ghislain wrote: sorry to jump on the thread, just a little test : when you make the vserver-util, do the make check worked for all tests ? i have issue on the unify test on debian, perhaps you have something related or a beecrypt issue ? Cordialement, Ghislain ADNET. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Quick question
Hi, I just wanted to make sure hashify only unifies rpm packages, right? Any other files I want to unify I will have to manually hardlink them? And vdu gives the disk space counting only files that have one hardlink, but when I do a vdu on my vserver directory I get 0...why is that? Thanks, -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Quick question
Corey Wright wrote: On Mon, 22 May 2006 10:29:20 -0400 Fareha Shafique [EMAIL PROTECTED] wrote: i assume you are following the process outlined on http://linux-vserver.org/alpha+util-vserver under vhashify. I just wanted to make sure hashify only unifies rpm packages, right? no. vhashify (the helper application called with vserver name hashify) has no knowledge of the rpm database and what files are installed by rpm and which are unique to the specific vserver (whether generated by an rpm post-installation script or manually created by the user). Any other files I want to unify I will have to manually hardlink them? no. when you run vhashify it creates hardlinks within /etc/vservers/.defaults/apps/vunify/hash/0 to all files that are not explicitly excluded within /usr/lib/util-vserver/defaults/vunify-exclude (well, that's the file within the debian package; location may vary). I checked /etc/vservers/.defaults/apps/vunify/hash/0 and it consists of a bunch of directories. At the lowest level, each directory consists of one file...the purpose of which i do not understand. Any help will be appreciated. again, all files are unified that are not explicitly excluded. here's something i had to learn the hard way: you can specify exclusions for a specific vserver, but the vserver-specific exclusions are supplementary, not complimentary. so when you create /etc/vservers/name/apps/vunify/exclude it's best to begin that file with a copy of /usr/lib/util-vserver/defaults/vunify-exclude. again, if a vserver-specific exclusion list exists, then the default exclusion list is totally disregarded, and only the vserver-specific exclusion list is consulted when running vhashify on that vserver. Thanks. -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Quick question
Daniel Hokka Zakrisson wrote: Fareha Shafique wrote: Daniel Hokka Zakrisson wrote: Fareha Shafique wrote: And vdu gives the disk space counting only files that have one hardlink, but when I do a vdu on my vserver directory I get 0...why is that? No, vdu counts the files/directories that belong to a specific context (if you have 0.30.210). Ok, so I still don't understand why I get a 0 when I do something like: vdu --xid xid --space /vservers/vserver-name for either of the 2 vservers I have built? Did you tag the files with chxid? Do the filesystem(s) they live on have tagxid enabled? I don't think I have done that. I'll look into it thanks. -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Creating from template
Hi, I built my first vserver (vs1) using the yum method and now I would like to build a few more vservers using skeleton method along with a template of vs1. I tried to build one vserver (sk1) like this and realized that there was no directory for this vserver in: /etc/vservers/.defaults/vdirbase/.pkg or /vservers/.pkg Due to the absence of these files I can hashify the vservers. Am I supposed to create these directories manually for every vserver build using the skeleton method? Thanks, -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Quick question
Corey Wright wrote: On Mon, 22 May 2006 10:29:20 -0400 Fareha Shafique [EMAIL PROTECTED] wrote: i assume you are following the process outlined on http://linux-vserver.org/alpha+util-vserver under vhashify. I just wanted to make sure hashify only unifies rpm packages, right? no. vhashify (the helper application called with vserver name hashify) has no knowledge of the rpm database and what files are installed by rpm and which are unique to the specific vserver (whether generated by an rpm post-installation script or manually created by the user). Any other files I want to unify I will have to manually hardlink them? no. when you run vhashify it creates hardlinks within /etc/vservers/.defaults/apps/vunify/hash/0 to all files that are not explicitly excluded within /usr/lib/util-vserver/defaults/vunify-exclude (well, that's the file within the debian package; location may vary). again, all files are unified that are not explicitly excluded. If hardlinks are created the inode numbers should be the same. But when I hashified 2 of my vservers (I first used the -nv option to see which files would be unified) I checked the files that were supposed to have been unified and I don't get the same inode number? I don't get any error messages, I'm not sure if my hashify is working? How can I check? Like I mentioned in another thread, I created the second vserver using a template of the first one. The number of links on most files in the template is already more than one, and hashify does not increase the number of these links. here's something i had to learn the hard way: you can specify exclusions for a specific vserver, but the vserver-specific exclusions are supplementary, not complimentary. so when you create /etc/vservers/name/apps/vunify/exclude it's best to begin that file with a copy of /usr/lib/util-vserver/defaults/vunify-exclude. I'm using FC4, I can't seem to find the vunify-exclude file again, if a vserver-specific exclusion list exists, then the default exclusion list is totally disregarded, and only the vserver-specific exclusion list is consulted when running vhashify on that vserver. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] A possible new idea
Herbert Poetzl wrote: On Fri, May 12, 2006 at 03:17:47PM -0400, Fareha Shafique wrote: Herbert Poetzl wrote: On Wed, May 10, 2006 at 05:17:55PM -0400, Fareha Shafique wrote: Herbert Poetzl wrote: On Wed, May 10, 2006 at 02:46:34PM -0400, Fareha Shafique wrote: After asking various questions about unification, I don't think vhashify quite supports what I have in mind. I wanted to get some opinions/ideas from the users of this mailing list. I am thinking if vservers can somehow be used to provide MAC (Mandatory Access Control) through containers. For example, a vserver shares the same filesystem as the host server, with read and write access to the host files being defined through a set of MAC policies. In this way, different policies can be defined for different vservers. Also, writes can be contained within a vserver (so that if a file is written to, a copy is made in the vserver's space) and integrated with the host only through explicit 'commits' to allow, for example, new configurations to be tested in an environment exactly the same as the host server and then transferred to the host using a commit. Any comments please? sounds interesting, any ideas how to realize this? Well, my first impression of vservers was that it provided a kind of containment that I have mentioned. I mean after quickly going over the short introduction, I thought that a vserver has read only access to the host server's files and CoW is used whenever the vserver modifes a file. However, after installing a vserver, I realized this was not the case. And after asking a few questions on the mailing list, I learnt that there is no direct way to do this. I was hoping to find out what some of those involved in the development of linux-vserver thought about the feasibility of this idea. well, yes, they did :) So they thought about it, but found it infeasible? or unecessary? the thing is, there are a bunch of arguments against this setup, namely: - the host system usually is a minimal setup tailored to administration and management of the guests including security stuff and backup/failover - you do not change the host system very often, you want to keep it updated in regard to security though - for security reasons, you do not 'share' the host system with any guest you give avay ... I'm not quite sure I understand what you mean by 'give away'. Can you please explain this more? - disk space is very cheap, so doing a similar approach with a 'guest template', which is shared or unified with many guests is not a big deal - different distros require different userspace, the amount of shared files is minimal across distros - CoW works fine, but reombining with a 'read-only' base which can be changed is a hard task, and usually not worth the efford ... So basically, at the moment, I don't really have much idea how to realize this, but I am hoping those more involved with vserver will some ideas to share :) aha, good, well, what would be the advantage over the currently established way to do this, i.e. have a template (some cleaned up version of your host system) and update guests either individually or at-once with the v* tools (like vrpm, vapt, vyum ...)? why would somebody want to _share_ the host files with the guest, instead of having a separate filesystem for them? It will 1) save space: Esp. in the example I gave of using vservers to provide MAC. So if we want to provide different permissions for different users/applications, the permissions can be defined per vserver. Rather than each vserver having a copy of the host filesystem, the guest and host can share filesystems...I'm thinking this method will make access policies easier to write than those of SELinux. how much will it save, 400MB or maybe 1GB? I don't think this is really an issue, except on embedded systems 2) make upgrades more manageable. For example, rather than having a test vserver to test upgrades and have a separate production vserver to which all tested upgrades have to be moved and configuration re-done, sharing a filesystem will allow a 'commit-like' functionality to automatically handle passing an upgrade from the vserver to the host. that is something which might be interesting, but I think no current filesystem/overlay/cow feature can handle 'commits' yet I'm talking to others and think that there might be a few other uses of this kind of 'isolated' filesysetm. Comments? keep thinking about it, usually the best ideas start with 'impossible' or 'useless' :) best, Herbert thanks, -FS note: I'm just trying to figure the rationale behind this suggestion ... best, Herbert ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] A possible new idea
Herbert Poetzl wrote: On Wed, May 10, 2006 at 05:17:55PM -0400, Fareha Shafique wrote: Herbert Poetzl wrote: On Wed, May 10, 2006 at 02:46:34PM -0400, Fareha Shafique wrote: After asking various questions about unification, I don't think vhashify quite supports what I have in mind. I wanted to get some opinions/ideas from the users of this mailing list. I am thinking if vservers can somehow be used to provide MAC (Mandatory Access Control) through containers. For example, a vserver shares the same filesystem as the host server, with read and write access to the host files being defined through a set of MAC policies. In this way, different policies can be defined for different vservers. Also, writes can be contained within a vserver (so that if a file is written to, a copy is made in the vserver's space) and integrated with the host only through explicit 'commits' to allow, for example, new configurations to be tested in an environment exactly the same as the host server and then transferred to the host using a commit. Any comments please? sounds interesting, any ideas how to realize this? Well, my first impression of vservers was that it provided a kind of containment that I have mentioned. I mean after quickly going over the short introduction, I thought that a vserver has read only access to the host server's files and CoW is used whenever the vserver modifes a file. However, after installing a vserver, I realized this was not the case. And after asking a few questions on the mailing list, I learnt that there is no direct way to do this. I was hoping to find out what some of those involved in the development of linux-vserver thought about the feasibility of this idea. well, yes, they did :) So they thought about it, but found it infeasible? or unecessary? So basically, at the moment, I don't really have much idea how to realize this, but I am hoping those more involved with vserver will some ideas to share :) aha, good, well, what would be the advantage over the currently established way to do this, i.e. have a template (some cleaned up version of your host system) and update guests either individually or at-once with the v* tools (like vrpm, vapt, vyum ...)? why would somebody want to _share_ the host files with the guest, instead of having a separate filesystem for them? It will 1) save space: Esp. in the example I gave of using vservers to provide MAC. So if we want to provide different permissions for different users/applications, the permissions can be defined per vserver. Rather than each vserver having a copy of the host filesystem, the guest and host can share filesystems...I'm thinking this method will make access policies easier to write than those of SELinux. 2) make upgrades more manageable. For example, rather than having a test vserver to test upgrades and have a separate production vserver to which all tested upgrades have to be moved and configuration re-done, sharing a filesystem will allow a 'commit-like' functionality to automatically handle passing an upgrade from the vserver to the host. I'm talking to others and think that there might be a few other uses of this kind of 'isolated' filesysetm. Comments? thanks, -FS note: I'm just trying to figure the rationale behind this suggestion ... best, Herbert ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] A possible new idea
After asking various questions about unification, I don't think vhashify quite supports what I have in mind. I wanted to get some opinions/ideas from the users of this mailing list. I am thinking if vservers can somehow be used to provide MAC (Mandatory Access Control) through containers. For example, a vserver shares the same filesystem as the host server, with read and write access to the host files being defined through a set of MAC policies. In this way, different policies can be defined for different vservers. Also, writes can be contained within a vserver (so that if a file is written to, a copy is made in the vserver's space) and integrated with the host only through explicit 'commits' to allow, for example, new configurations to be tested in an environment exactly the same as the host server and then transferred to the host using a commit. Any comments please? Thanks. -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] A possible new idea
Herbert Poetzl wrote: On Wed, May 10, 2006 at 02:46:34PM -0400, Fareha Shafique wrote: After asking various questions about unification, I don't think vhashify quite supports what I have in mind. I wanted to get some opinions/ideas from the users of this mailing list. I am thinking if vservers can somehow be used to provide MAC (Mandatory Access Control) through containers. For example, a vserver shares the same filesystem as the host server, with read and write access to the host files being defined through a set of MAC policies. In this way, different policies can be defined for different vservers. Also, writes can be contained within a vserver (so that if a file is written to, a copy is made in the vserver's space) and integrated with the host only through explicit 'commits' to allow, for example, new configurations to be tested in an environment exactly the same as the host server and then transferred to the host using a commit. Any comments please? sounds interesting, any ideas how to realize this? Well, my first impression of vservers was that it provided a kind of containment that I have mentioned. I mean after quickly going over the short introduction, I thought that a vserver has read only access to the host server's files and CoW is used whenever the vserver modifes a file. However, after installing a vserver, I realized this was not the case. And after asking a few questions on the mailing list, I learnt that there is no direct way to do this. I was hoping to find out what some of those involved in the development of linux-vserver thought about the feasibility of this idea. So basically, at the moment, I don't really have much idea how to realize this, but I am hoping those more involved with vserver will some ideas to share :) ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: Basic Question
Corey Wright wrote: On Mon, 08 May 2006 13:30:45 -0400 Fareha Shafique [EMAIL PROTECTED] wrote: The following is taken from the Short Introduction, can someone please explain it to me: Resource sharing: Since vservers can share binaries and libraries without interfering, a second vserver generally cost 40-100 megs of disk space only. Most of this space is a copy of the packaging database. Independent updates: Vservers are updated independently even if they share binaries with other vservers. Does this mean, that as I install programs (like sshd, and other packages) on my vserver that are already installed on my host server, the binaries will be shared? search for vhashify on http://linux-vserver.org/alpha+util-vserver for the practical how-to. the resource sharing is not automatic; you must enable it. i'll try to explain the theory briefly. storage space is conserved because files only exist in one place, but are referenced within multiple vservers though special hard links. memory space is conserved because binaries and shared libraries (and any item in the file cache, i suppose) only exist in memory once, though many vservers may be executing/using the file. the idea is to extend the concept of shared libraries to vservers, so that just as a shared library may be referenced by multiple applications and it only exists in memory once, the same is true for a shared library referenced by multiple vservers (by way of vhashify). all the examples i have seen enable vhashify for vserver guests, not the host. i presume it is possible, but it is never applicable in my case because hard links are only shared on a single filesystem (where i mount my host's executables/libraries on /usr and my vservers on /home). hth. corey Thanks, that explaination helps :) Now, is it only libraries and binaries that can be shared or can a vserver be an exact replica of the host. For example, how about if I want the filesystem of vserver vs1 to be an exact replica of the host, and only when I write/modify any file a local copy should be created for vs1 (using COW)? Is this possible? Thanks in advance. -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: Basic Question
Fareha Shafique wrote: Corey Wright wrote: storage space is conserved because files only exist in one place, but are referenced within multiple vservers though special hard links. memory space is conserved because binaries and shared libraries (and any item in the file cache, i suppose) only exist in memory once, though many vservers may be executing/using the file. the idea is to extend the concept of shared libraries to vservers, so that just as a shared library may be referenced by multiple applications and it only exists in memory once, the same is true for a shared library referenced by multiple vservers (by way of vhashify). all the examples i have seen enable vhashify for vserver guests, not the host. i presume it is possible, but it is never applicable in my case because hard links are only shared on a single filesystem (where i mount my host's executables/libraries on /usr and my vservers on /home). hth. corey Thanks, that explaination helps :) Now, is it only libraries and binaries that can be shared or can a vserver be an exact replica of the host. Oh sorry, that was already answered. I guess anything on the filesystem can be shared. How about if I want the filesystem of vserver vs1 to be an exact replica of the host, and only when I write/modify any file a local copy should be created for vs1 (using COW)? Is this possible? Let me explain this better. Say I want to upgrade some software or install new software on my host machine. Before doing this, I would like to test the upgrade in an environment that is an exact replica of the host machine. Is it possible to create a vserver identical to the host so that it can be used as the test environment? Thanks, -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Another conceptual newbie question
Hi, I read in one of the threads on the mailing list archive that Vservers use CoW. I'm having trouble understanding where, how and for what it is used? Thanks, -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: Basic Question
Thanks, its working now. But I'm not quite sure I understand the basic infrastructure of vservers. The following is taken from the Short Introduction, can someone please explain it to me: Resource sharing: Since vservers can share binaries and libraries without interfering, a second vserver generally cost 40-100 megs of disk space only. Most of this space is a copy of the packaging database. Independent updates: Vservers are updated independently even if they share binaries with other vservers. Does this mean, that as I install programs (like sshd, and other packages) on my vserver that are already installed on my host server, the binaries will be shared? Thanks in advance. -FS wrote: On Wed, May 03, 2006 at 01:13:53PM -0400, Fareha Shafique wrote: Hello, I am unable to ping any outside host. I have named the vserver testvs, dev = eth0, ip = 192.168.0.10. resolv.conf contains: nameserver 192.168.0.10 on the host try: ping -I 192.168.0.10 www.google.com if that fails, then your 192.168.0.10 IP is not able to reach the outside (properly), which is most likely related to the fact that it is a private IP and not S/DNat-ed to your public one From inside the vserver I can ping the host, but not anything on the internet. I think something is wrong with the routing tables, any help please? depends on your setup, once the ping above works, the guest will be able to reach the internet, you then might need to change the nameserver, unless your guest knows all about the internet :) HTH, Herbert Thanks, Fareha Guenther Fuchs wrote: Hi there, on Tuesday, May 2, 2006 at 7:56:15 PM there was posted: FS I have set up internal package management. However, when I try to use FS yum I get the following error: FS Setting up Install Process FS Setting up repositories FS Cannot find a valid baseurl for repo: updates-released FS Error: Cannot find a valid baseurl for repo: updates-released Possible stupid question: have you set up a proper nameserver inside the guest? (check /etc/resolv.conf inside the guest) FS I'm quite sure the urls are valid, but I'm not sure if my guest FS can access the internet. How do I check/fix this? Try to ping any host outside, for example: | ping -c5 linux-vserver.org ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Errors on stopping vserver
Hi, When I stop the vserver I get the following: Stopping sshd: [FAILED] Shutting down kernel logger: [FAILED] Shutting down system logger: [ OK ] Starting killall: Stopping sshd:[FAILED] [FAILED] I'm not sure why I this happens. Any help would be appreciated. Thanks, -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Newbie question
Hi, I'm new to vservers. I installed the vserver from rpms and built it according to the instructions on Vserver Installation Fedora Core 4. I was under the impression that a vserver has all the same files in its /etc directory as the host machine, but my vserver has fewer files. Furthermore, inside my vserver I cannot use bash commands such as less, rpm, man. Have I misunderstood the basics of vserver or did I incorrectly install my vserver? Any help would be appreciated. Thanks, -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Newbie: getting started
Hi, I wanted to know where I could find out more about RTNETLINK. When I stop my vserser, I get the message: RTNETLINK answers: Cannot assign requested address Thanks, -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Problems with internal package management
Hi, I have set up internal package management. However, when I try to use yum I get the following error: Setting up Install Process Setting up repositories Cannot find a valid baseurl for repo: updates-released Error: Cannot find a valid baseurl for repo: updates-released I'm quite sure the urls are valid, but I'm not sure if my guest can access the internet. How do I check/fix this? Thanks -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] New to vserver: need some help installing
I followed the Fedora Core 4 installation instructions (installing from rpms). Once the build is complete, I can start, enter and stop the vserver, however, I cannot find the .conf file (supposed to be located in /etc/vservers) I can't seem to figure out where i made a mistake during the installation. Any help would be appreciated. Thanks. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] New to vserver: need some help installing
Thanks, I'll take a look at that page. Guenther Fuchs wrote: Hi there, on Monday, May 1, 2006 at 9:21:39 PM there was posted: FS I followed the Fedora Core 4 installation instructions (installing FS from rpms). Once the build is complete, I can start, enter and FS stop the vserver, good to hear ;-) FS however, I cannot find the .conf file (supposed to be located FS in /etc/vservers) There is no .conf file, there are only configuration directories located at /etc/vservers/[server-name]/ - they are described at the great flower page on http://www.nongnu.org/util-vserver/doc/conf/configuration.html (for better readability change the css theme through your browser) FS I can't seem to figure out where i made a mistake during the FS installation. Obviousely nothing ;-) ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
