Re: [Vserver] OCS Inventory
On 3/16/07, Daniel Hokka Zakrisson <[EMAIL PROTECTED]> wrote: Daniel W. Crompton wrote: After reading Jean-Marc's answer I thought it could also be the fact that you might just need to create /dev/mem. You absolutely never ever want to do that, if you care the least about the guest being secure... /dev/mem would give it complete access to the contents of your RAM. Seriously if you care about your guest being secure you make sure that the host doesn't have physical network access. If you want to be able to run certain programs in a guest you sometimes need rights which are available to only the host. That's the whole point of caps. I want to make it clear that I have no idea what the OCS program does, but if you want to run it in a guest then you need to be able to access /dev/mem. Making the guest insecure is the price you have to pay. Having network access for a machine means risking remote attacks it's the price you pay. I hardly run anything on my host systems besides syslog and sshd, practically everything runs in a guest. Some guests have caps that give it almost full access to the host system on other guests you don't even have write access to the disk or a compiler. (It logs to the host's syslog anyway.) The level of access you need in a guest determines who access is given to, not whether you do something or not. The only thing you "absolutely never ever" want to do is give somebody you don't trust physical access to the host, anything else is a question of need. D. blaze your trail -- redhat ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] OCS Inventory
Daniel W. Crompton wrote: > On 3/16/07, Daniel Hokka Zakrisson <[EMAIL PROTECTED]> wrote: >> Daniel W. Crompton wrote: >>> After reading Jean-Marc's answer I thought it could also be the fact >>> that you might just need to create /dev/mem. >> >> You absolutely never ever want to do that, if you care the least about >> the >> guest being secure... /dev/mem would give it complete access to the >> contents of your RAM. > > Seriously if you care about your guest being secure you make sure that > the host doesn't have physical network access. If you want to be able > to run certain programs in a guest you sometimes need rights which are > available to only the host. That's the whole point of caps. Which should not be taken as lightly as "you just need to create XYZ". It's something that essentially voids the entire virtualization/isolation that Linux-VServer provides... -- Daniel Hokka Zakrisson ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] OCS Inventory
On 3/17/07, Daniel Hokka Zakrisson <[EMAIL PROTECTED]> wrote: You absolutely never ever want to do that, if you care the least about the guest being secure... /dev/mem would give it complete access to the contents of your RAM. Seriously if you care about your guest being secure you make sure that the host doesn't have physical network access. If you want to be able to run certain programs in a guest you sometimes need rights which are available to only the host. That's the whole point of caps. Which should not be taken as lightly as "you just need to create XYZ". It's something that essentially voids the entire virtualization/isolation that Linux-VServer provides... You are right that I was a little flippant in my remark that one should just create /dev/mem, and should have mentioned the security implications. My remark did contain reservation you didn't pick-up on. "You might just need to create XYZ" carries a very different message than "you just need to create XYZ." In this case "might" means that it is possible that you would need to do XYZ, I realize that this reservation could be missed in a cursory reading. However that doesn't however negate the fact that to run OCS Agent as is in a guest you might just need to create /dev/mem. regards, D. blaze your trail -- redhat ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] OCS Inventory
in the same sense... disable all firewalls, open up your telnet port and allow passwordless rootlogin on all your machines or pull the plug those are the only possibilities, right? Daniel W. Crompton wrote: Seriously if you care about your guest being secure you make sure that the host doesn't have physical network access. If you want to be able to run certain programs in a guest you sometimes need rights which are available to only the host. That's the whole point of caps. I want to make it clear that I have no idea what the OCS program does, but if you want to run it in a guest then you need to be able to access /dev/mem. Making the guest insecure is the price you have to pay. Having network access for a machine means risking remote attacks it's the price you pay. I hardly run anything on my host systems besides syslog and sshd, practically everything runs in a guest. Some guests have caps that give it almost full access to the host system on other guests you don't even have write access to the disk or a compiler. (It logs to the host's syslog anyway.) The level of access you need in a guest determines who access is given to, not whether you do something or not. The only thing you "absolutely never ever" want to do is give somebody you don't trust physical access to the host, anything else is a question of need. -- harry aka Rik Bobbaers K.U.Leuven - LUDIT -=- Tel: +32 485 52 71 50 [EMAIL PROTECTED] -=- http://people.linux-vserver.org/~harry Nobody notices when things go right. Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] OCS Inventory
On Sat, Mar 17, 2007 at 02:37:39PM +, Daniel W. Crompton wrote: > On 3/17/07, Daniel Hokka Zakrisson <[EMAIL PROTECTED]> wrote: > >>>You absolutely never ever want to do that, if you care the least about > >>>the > >>>guest being secure... /dev/mem would give it complete access to the > >>>contents of your RAM. > >>Seriously if you care about your guest being secure you make sure that > >>the host doesn't have physical network access. If you want to be able > >>to run certain programs in a guest you sometimes need rights which are > >>available to only the host. That's the whole point of caps. > >Which should not be taken as lightly as "you just need to create XYZ". > >It's something that essentially voids the entire virtualization/isolation > >that Linux-VServer provides... > > You are right that I was a little flippant in my remark that one > should just create /dev/mem, and should have mentioned the security > implications. My remark did contain reservation you didn't pick-up on. > "You might just need to create XYZ" carries a very different message > than "you just need to create XYZ." In this case "might" means that it > is possible that you would need to do XYZ, I realize that this > reservation could be missed in a cursory reading. > > However that doesn't however negate the fact that to run OCS Agent as > is in a guest you might just need to create /dev/mem. you might want to check with the source (of OCS Agent) what the application actually does with /dev/mem best, Herbert > regards, > > D. > > > blaze your trail > > -- > redhat > ___ > 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] Vserver CPU limit question
On Fri, Mar 16, 2007 at 06:54:26PM -0700, Albert Mak (almak) wrote: > Hi, > > I have Linux (2.6.14.3 Kernel) with Vserver 2.0.1 and testing the CPU > limit capabilities. I have 2 vserver contexts both running CPU intensive > app capable of using up 100% CPU, I am setting up on vserver to limit 1 > context to 10% CPU and the 2nd to 80% CPU, both using flags sched_prio. > I am seeing CPU usage split 50/50 between the 2 contexts. I repeated the > same test using sched_hard with the same result (kernel VSERVER_HARDCPU > config set to y). I am expecting to see at least the CPU usage close to > the Vserver limits. > > Have I got the wrong settings or some other issues. Your help is really > appreciated. > > -Albert > > top - 18:37:04 up 26 min, 1 user, load average: 2.04, 1.40, 0.62 > Tasks: 127 total, 3 running, 124 sleeping, 0 stopped, 0 zombie > Cpu(s): 98.7% us, 1.3% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, > 0.0% si > Mem:513084k total, 115660k used, 397424k free,10200k buffers > Swap:0k total,0k used,0k free,39332k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 6616 root 20 0 1332 228 184 R 49.8 0.0 2:23.12 > exceed_cpu_limi > 6513 root 20 0 1336 232 184 R 48.1 0.0 2:43.79 > exceed_cpu_limi > > -bash-2.05b# vps > PID CONTEXT TTY TIME CMD > 3672 0 MAIN pts/000:00:00 bash > 6513 2 APP1 pts/000:03:01 exceed_cpu_limi > 6616 3 APP2 pts/000:02:40 exceed_cpu_limi > 7655 1 ALL_PROC pts/000:00:00 vps > 7656 1 ALL_PROC pts/000:00:00 ps > > -bash-2.05b# pwd > /etc/vservers/APP1 > -bash-2.05b# cat flags > sched_prio you want to add sched_hard here if you want hard scheduling, the prio scheduler will only adjust priorities according to the token buckets ... I'd also suggest to use a more recent kernel (and probably Linux-VServer patch) than this one as the scheduler was enhanced quite a lot in 2.2.x > -bash-2.05b# cat schedule > 80 > 100 > 200 > 50 > 140 > dummy > > -bash-2.05b# pwd > /etc/vservers/APP2 > -bash-2.05b# cat flags > sched_prio > -bash-2.05b# cat schedule > 10 > 100 > 200 > 50 > 140 > dummy > > -bash-2.05b# cat /proc/virtual/2/sched > Token: 140 > FillRate: 1 > Interval:100 > TokensMin:50 > TokensMax: 140 > PrioBias: 0 > VaVaVoom: -5 > cpu 0: 229674 71 0 > > -bash-2.05b# cat /proc/virtual/3/sched > Token: 140 > FillRate: 10 > Interval:100 > TokensMin:50 > TokensMax: 140 > PrioBias: 0 > VaVaVoom: -5 > cpu 0: 217275 54 0 looks like none of the token buckets is active here, what does the /proc/virtual/2/status show? TIA, Herbert > ___ > 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] Re: Oops with rejecting routes in vservers instance
On Thu, Mar 15, 2007 at 07:38:44PM +0100, Herbert Poetzl wrote: > On Thu, Mar 15, 2007 at 12:18:12PM +0100, Asier Baranguán wrote: > > Asier Baranguán escribió: > > > > >>~~~ > > >>quite ancient ... could you try something like 2.6.18-4 or > > >>even better 2.6.19.7-vs2.2.0-rc17 and tell me if you see > > >>the same issues? > > >> > > >>will try to recreate it here ... > > > > > >Oops. > > > > > >Kernel 2.16.38-vs2.0.3-rc1 and same problem... okay, was actually easy to recreate, thanks to your information and testing ... turned out to be an issue present in recent versions too ... > > >Is there any fix for this in the 'stable' 2.6.16 kernel? yep, we updated the 2.6.16 kernel to 2.6.16.43 and the patch to 2.0.3-rc2, you can find it here: http://vserver.13thfloor.at/Experimental/patch-2.6.16.43-vs2.0.3-rc2.diff thanks for spotting, Herbert > > Emm... I want to say "any fix for the 2.0.3rc1 release > > of the 'stable' > > 2.6.16 kernel" > > will check that tonight or tomorrow, when I get > around digging out that old kernel :) > > best, > Herbert > > > Thanks > > > begin:vcard > > fn;quoted-printable:Asier Barangu=C3=A1n > > n;quoted-printable:Barangu=C3=A1n;Asier > > org;quoted-printable:ELPA Gesti=C3=B3n > > adr;quoted-printable;dom:;;c/ Henao 4 - 3=C2=BAA;Bilbao;Bizkaia;48009 > > email;internet:[EMAIL PROTECTED] > > title:A/P > > tel;work:944.23.01.66 > > tel;fax:944.23.01.78 > > x-mozilla-html:FALSE > > url:http://www.elpagestion.com > > version:2.1 > > end:vcard > > > > > ___ > > 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] Vserver CPU limit question
Hi Herbert Here is the output of /proc/virtual/2/status as requested Both context 2 and 3 have the same setting. -bash-2.05b# cat /proc/virtual/2/status UseCnt: 7 Tasks: 2 Flags: 000202020210 BCaps: 354c24ff CCaps: 0101 Ticks: 0 Thanks. -Albert -Original Message- From: Herbert Poetzl [mailto:[EMAIL PROTECTED] Sent: Saturday, March 17, 2007 11:36 AM To: Albert Mak (almak) Cc: vserver@list.linux-vserver.org Subject: Re: [Vserver] Vserver CPU limit question On Fri, Mar 16, 2007 at 06:54:26PM -0700, Albert Mak (almak) wrote: > Hi, > > I have Linux (2.6.14.3 Kernel) with Vserver 2.0.1 and testing the CPU > limit capabilities. I have 2 vserver contexts both running CPU > intensive app capable of using up 100% CPU, I am setting up on vserver > to limit 1 context to 10% CPU and the 2nd to 80% CPU, both using flags sched_prio. > I am seeing CPU usage split 50/50 between the 2 contexts. I repeated > the same test using sched_hard with the same result (kernel > VSERVER_HARDCPU config set to y). I am expecting to see at least the > CPU usage close to the Vserver limits. > > Have I got the wrong settings or some other issues. Your help is > really appreciated. > > -Albert > > top - 18:37:04 up 26 min, 1 user, load average: 2.04, 1.40, 0.62 > Tasks: 127 total, 3 running, 124 sleeping, 0 stopped, 0 zombie > Cpu(s): 98.7% us, 1.3% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, > 0.0% si > Mem:513084k total, 115660k used, 397424k free,10200k buffers > Swap:0k total,0k used,0k free,39332k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 6616 root 20 0 1332 228 184 R 49.8 0.0 2:23.12 > exceed_cpu_limi > 6513 root 20 0 1336 232 184 R 48.1 0.0 2:43.79 > exceed_cpu_limi > > -bash-2.05b# vps > PID CONTEXT TTY TIME CMD > 3672 0 MAIN pts/000:00:00 bash > 6513 2 APP1 pts/000:03:01 exceed_cpu_limi > 6616 3 APP2 pts/000:02:40 exceed_cpu_limi > 7655 1 ALL_PROC pts/000:00:00 vps > 7656 1 ALL_PROC pts/000:00:00 ps > > -bash-2.05b# pwd > /etc/vservers/APP1 > -bash-2.05b# cat flags > sched_prio you want to add sched_hard here if you want hard scheduling, the prio scheduler will only adjust priorities according to the token buckets ... I'd also suggest to use a more recent kernel (and probably Linux-VServer patch) than this one as the scheduler was enhanced quite a lot in 2.2.x > -bash-2.05b# cat schedule > 80 > 100 > 200 > 50 > 140 > dummy > > -bash-2.05b# pwd > /etc/vservers/APP2 > -bash-2.05b# cat flags > sched_prio > -bash-2.05b# cat schedule > 10 > 100 > 200 > 50 > 140 > dummy > > -bash-2.05b# cat /proc/virtual/2/sched > Token: 140 > FillRate: 1 > Interval:100 > TokensMin:50 > TokensMax: 140 > PrioBias: 0 > VaVaVoom: -5 > cpu 0: 229674 71 0 > > -bash-2.05b# cat /proc/virtual/3/sched > Token: 140 > FillRate: 10 > Interval:100 > TokensMin:50 > TokensMax: 140 > PrioBias: 0 > VaVaVoom: -5 > cpu 0: 217275 54 0 looks like none of the token buckets is active here, what does the /proc/virtual/2/status show? TIA, Herbert > ___ > 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
