[00:27] <virtuoso> re
[00:49] <Bertl> hi!
[01:26] Nick change: noel- -> noel
[01:27] <Bertl> hi noel!
[01:27] <noel> hello together.
[01:28] <tanjix> hi noel
[01:31] <noel> everybody suvived christmas?:) in germany we had a very christmassy tv program. "terminator 2" on the first day and "die hard" on the second.;)
[01:32] <Bertl> hmm, what about 'nightmare on elmstreet?' ;)
[01:33] <tanjix> noel thats what some ppl like :)
[01:56] tanjix (ViRu_@pD9049C6B.dip.t-dialin.net) left irc: 
[02:36] nathan (~nathan@29.sub-166-156-241.myvzw.com) joined #vserver.
[02:42] <Bertl> hi nathan!
[02:44] <nathan> hey bert
[02:44] <nathan> Bertl, i think there may still be a race condition in 1.3.1
[02:45] <Bertl> hmm, possible, where?
[02:45] <nathan> the put that releases locks on iplist_lock
[02:45] <nathan> but where in the get is that lock obtained?
[02:46] <nathan> it just decs refcount after obtaining vxlist_lock but vxlist_lock is only obtained in the create
[02:46] <Bertl> yup, it isn't (yet)
[02:46] <nathan> oh, so this still isnt smp safe?
[02:47] <Bertl> well, the list lock is/will be used on allocation ...
[02:47] <Bertl> and again, the task lock will be used to prohibit races with the task->ip_info ...
[02:47] <Bertl> wait a second ...
[02:49] <Bertl> http://vserver.13thfloor.at/Experimental/split-2.4.23-vs1.3.2/
[02:50] <Bertl> I'm currently finalizing this version ;)
[02:50] <nathan> looking
[02:53] <nathan> ok so in the 1.3.2 it seems that proc_pid_status needs to obtain the tasklist_lock 
[02:53] <nathan> based on the current implementation
[02:53] <nathan> unless i am overlooking something
[02:54] Action: Bertl is searching the code ... sec
[02:54] <Bertl> proc pid status does:         vxi = task_get_vx_info(task);
[02:55] <Bertl> which takes the task_lock() ;)
[02:55] <nathan> right, but the task_lock only happens in the scope of task_get_vx_info, once it returns the task becomes unlocked
[02:55] <nathan> so the code following the vxi=task_get.. is a critical section
[02:56] <Bertl> yup, but the refcount is hold until put_vx_info() ;)
[02:56] <Bertl> s/hold/held/
[02:57] <Bertl> keep looking/searching/asking, it's good to have a second opinion ...
[02:58] <nathan> ok i see what you are saying, i see what you are saying
[02:58] <nathan> yea i gotcha makes sense
[02:59] <Bertl> I'm more worried about the ip_info and 'required' locking I missed .. one place I marked with /* locking ... required? */
[03:00] <Bertl> or something similar .. should be easy to find in the net split ...
[03:01] <nathan> wgeting all the splits on this slow connection
[03:02] <Bertl> sorry should have bzip2ed them ...
[03:03] <Bertl> and I added the vx_verify_info()/ip_verify_info() checks, just to catch wrong assumptions ;)
[03:04] <nathan> ill need to give this a run when i get back to boston tomorrow/monday
[03:06] <Madkiss> Is it safe to use 1.3.1?
[03:06] <Madkiss> Or are unexpected kernel panics to expect?
[03:06] <Madkiss> 1.22 appears to work here ;)
[03:06] <Bertl> hmm. if I'm right, I guess it's more stable than vs1.22 ...
[03:06] <Madkiss> <0>seth[1002]:~# vserver sendmail enter
[03:06] <Madkiss> SIOCSIFBRDADDR: Cannot assign requested address
[03:06] <Madkiss> SIOCSIFFLAGS: Cannot assign requested address
[03:06] <Bertl> vs1.3.2 I mean ...
[03:06] <Madkiss> Is that right, by the way?
[03:07] <Bertl> well, it depends on your config ... but probably you try to assign an already existing address ...
[03:07] <Bertl> and do it the _wrong_ way ...
[03:07] <Madkiss> Where could the problem be?
[03:07] <Madkiss> This box has one IP only
[03:08] <Bertl> and you want to use it in and outside the vserver?
[03:08] <Madkiss> right.
[03:08] <Bertl> show me your vserver config ...
[03:09] <Madkiss> which one?
[03:09] <Bertl> the one which reports those errors ...
[03:09] <Bertl> only the uncommented lines ...
[03:09] <Madkiss> both vserver configs report this error
[03:11] <Bertl> if you want more details, http://vserver.13thfloor.at/Stuff/VServer-IP-Setup-0.1.txt
[03:12] <Bertl> short explanation, your start script tries to create an alias, where the ip already exists ...
[03:13] <Bertl> without IPROOTDEV, the existing one is used ...
[03:14] <nathan> Bertl, so you are thinking the locking with ip_info may not be adequate?
[03:14] <Bertl> I'm not sure ... I have to look at all cases where current isn't the reference ...
[03:15] <Bertl> and especially the place I commented, looked racy to me ...
[03:15] <nathan> im seeing it in 07_2.4.23_net.diff
[03:15] <nathan>     118 + /* check for locking here */$
[03:16] <Bertl> well, we are talking about a one in a milion race there ... but ...
[03:17] <nathan> 0 out of 0 is a better odd :)
[03:17] <Bertl> yup, agreed ...
[03:17] <nathan> so what is the race condition you see there?
[03:17] <Bertl> if I had _seen_ a race there, I would have fixed it .. I just _suspect_ a race there ...
[03:18] <Bertl> or a possibility for a race ...
[03:19] <nathan> actually back to my original lock thing i thought i saw
[03:19] <nathan> what is to stop a get while mid-put?
[03:19] <Bertl> huh? please elaborate ...
[03:20] <Bertl> by the way, the comment should be changed to: +/* reordering required? */
[03:20] <nathan> what is to stop a get_ip_info() while put_ip_info() in its critical section obtaining tasklist_lock
[03:20] <nathan> or vx_info for that matter
[03:21] <nathan> probably a better example is the vx_info with the proc calls
[03:21] <Bertl> simple, put() acquires the list lock when zero is reached ...
[03:21] <Madkiss> Bertl: You are from Austria?
[03:21] <Bertl> okay?
[03:21] <Bertl> Madkiss: yes!
[03:22] <Madkiss> Bertl: Hallo Nachbar -wink-
[03:22] Action: Bertl winke winke ...
[03:23] <Bertl> nathan: okay?
[03:23] <nathan> Bertl, lets say count goes to 0 and it gets tasklist_lock and while that is happening another processor enters at proc_pid_status and goes for a task_get_vx_info() while tasklist_lock is still obtained in the put
[03:23] <Bertl> there is no tasklist_lock ...
[03:23] <nathan> sorry, tasklist_lock=vxlist_lock
[03:24] <Bertl> okay, so how could this reach zero ...
[03:24] <Bertl> simple: it could be the 'last' release where the task_struct is freed ...
[03:25] <Bertl> in release_task() right?
[03:25] <nathan> hmm ok so in that case the process will be locked by another piece of code in the kernel
[03:25] <nathan> right
[03:26] <nathan> so its not a problem
[03:26] <Bertl> so if it happens by the last releasing of an out of task reference, it's no problem either ...
[03:26] <Bertl> the actual race was never between get/put ...
[03:26] <Bertl> it was between task->vx_info = NULL and vxi=task->vx_info ;)
[03:26] <Bertl> and this is now protected by the task_lock()
[03:28] <nathan> yep ok
[03:29] <Bertl> and if you are interested in actually testing it, you can enable preemption, to give races a better chance ;)
[03:32] <Bertl> Madkiss: where in Austria are you from?
[03:39] Nick change: doener_aw -> Doener
[03:39] <Doener> hi
[03:39] <Bertl> hi Doener 
[03:41] <Madkiss> Bertl: I'm not from Austria, I'm from Germany. We are, so to say, Country-Neighbours
[03:42] <Bertl> ahh, okay ... I assumed that you are from austria too ...
[03:43] <Madkiss> i'm not.
[03:44] <Bertl> well, we won't use it against you, at least not yet ;)
[03:44] monako (~monako@ts1-a50.Perm.dial.rol.ru) joined #vserver.
[03:44] <Madkiss> Naja, wenigstens habt ihr 'nen richtigen Bundeskanzler. Wir haben nur Gerhard Schröder.
[03:44] <Madkiss> :\
[03:45] <Bertl> hi monako!
[03:46] <Bertl> nathan? still here? or are you busy reading the patches ...
[03:54] <Doener> do i remember correctly that there was an issue with an earlier version of vserver that could cause processes to get stuck in D state?
[03:54] <Doener> if so, what could trigger this?
[03:55] <Bertl> hmm, every interaction with the I/O system, can trigger such races (which are often the cause for such 'hanging' processes)
[03:56] <Bertl> one issue, fixed in vs1.22 could be triggered by accessing the proc fs while a vserver task dies ...
[03:56] <Doener> hmm, no... doesn't apply here... for some reason a lvm partition got mounted ro and now some rm processes are stuck
[03:57] <Bertl> lvm has some races too ...
[03:57] <Bertl> (known races) if you are not updated to the latest version ...
[03:57] <Bertl> have you tried to mount the partition rw?
[03:58] <Bertl> remount, I mean?
[03:58] <Doener> yeah, no success
[03:58] <Bertl> do you have magic sysreq enabled?
[03:58] <Bertl> which kernel version are we talking about?
[03:59] <Doener> 2.4.22-c17f guess it will get it's update when we reboot to get rid of the rm processes
[04:00] nathan (~nathan@29.sub-166-156-241.myvzw.com) left irc: Ping timeout: 512 seconds
[04:00] <Bertl> hmm, well there are some issues fixed since then ... local root exploit, races in vserver, ...
[04:01] <Bertl> I would also suggest to have a look at http://vserver.13thfloor.at/Stuff/patches-2.4.23vs1.22/
[04:04] <Doener> for the partition being mount read-only, are there situations/reasons apart from mount starting fsck that could cause that? never saw that before
[04:05] <Bertl> well, usually any filesystem falls back to ro, if there is sever fs corruption or disk failure ...
[04:07] <Doener> e2fsck reports no errors
[04:07] <Bertl> check the logs ...
[04:46] <Doener> nothing unusual there... thanks anyways...
[04:47] <Doener> i'll have some sleep now... g'night all
[04:47] Nick change: Doener -> doener_zZz
[04:47] <Bertl> good night ...
[04:52] monako (~monako@ts1-a50.Perm.dial.rol.ru) left irc: Ping timeout: 480 seconds
[05:23] monako (~monako@ts1-a2.Perm.dial.rol.ru) joined #vserver.
[05:58] tanjix (ViRu_@c-180-204-230.n.dial.de.ignite.net) joined #vserver.
[05:59] <Bertl> back again?
[05:59] <tanjix> sure :)
[05:59] <Bertl> and fixed you issues?
[05:59] <Bertl> s/you/your/
[05:59] <tanjix> no
[05:59] <Bertl> didn't try, or didn't succeed?
[05:59] <tanjix> was not successful
[06:00] <tanjix> trying since hours
[06:01] <Bertl> what's the problem, still ipac-ng?
[06:04] <tanjix> yep
[06:04] <Bertl> maybe ask on the mailing list, maybe somebody made it work yet ...
[06:04] <tanjix> when that runs fine i'm happy but that tool costs my life :)
[06:05] <tanjix> another question: how can i see what vroot devices are set
[06:05] <Bertl> hmm, not possible at the moment ... you have to do some bookkeeping ...
[06:06] <tanjix> you can put that on the todo list if you like :)
[06:06] <tanjix> do they have to bet set again on each server reboot ?
[06:07] <Bertl> nope the vserver reboot has no effect on that, the host reboot will clear them
[06:07] <tanjix> i meant that :)
[06:08] <tanjix> so i could put that into a startup script
[06:08] <Bertl> sure ...
[06:08] <tanjix> again for better understanding:
[06:08] <tanjix> mknod /dev/vroot0 b 4 0
[06:08] <tanjix> mknod /dev/vroot1 b 4 1
[06:08] <tanjix> ...
[06:08] <tanjix> ?
[06:09] <Bertl> yup?, that will create the device nodes ...
[06:09] <tanjix> then setting them up with the vrsetup tool
[06:09] <Bertl> this is only required once, and only if you do not use devfs
[06:09] <Bertl> (the node creation)
[06:09] <tanjix> so i dont neeed to put the mknod command into the startup
[06:09] <tanjix> ?
[06:10] <Bertl> nope, this is like your /dev/zero, it won't go away, unless you delete it ...
[06:10] <tanjix> done once and it's over
[06:10] <tanjix> ok
[06:10] <tanjix> the same with the vrsetup ?
[06:10] <Bertl> nope, vrsetup is like the losetup for loopback devices ...
[06:11] <tanjix> so this has to be done on eahc reboot of the host
[06:11] <Bertl> actually it's pretty much like the loop device setup
[06:11] <Bertl> and now that I think about it, how do you tell what loop device isn't configured yet?
[06:12] <tanjix> eh sorry ?
[06:15] <Bertl> well, I don't know a way to find out if a loop device is used or not, do you?
[06:15] <Bertl> (except for trying to configure it, and failing to do so)
[06:15] <tanjix> i would look into "ifconfig" ?
[06:15] <tanjix> if it is present or not ?
[06:16] <Bertl> not the network loopback , the loop device /dev/loop0 ...
[06:16] <tanjix> oh, sry
[06:16] <tanjix> don't know
[06:17] <Bertl> me neither, just because you mentioned that I should put that on my todo list for the vroot device .)
[06:17] <tanjix> mh ok understood what you mean :)
[07:37] monako (~monako@ts1-a2.Perm.dial.rol.ru) left irc: Ping timeout: 512 seconds
[08:00] <Bertl> okay, enough work for me for today ...
[08:00] <Bertl> wish you a good whatever, cu 2morrow ...
[08:01] Nick change: Bertl -> Bertl_zZ
[08:05] tanjix (ViRu_@c-180-204-230.n.dial.de.ignite.net) left irc: 
[09:53] Doener` (~doener@pD9E12F48.dip.t-dialin.net) joined #vserver.
[10:00] doener_zZz (~doener@pD9588874.dip.t-dialin.net) left irc: Ping timeout: 512 seconds
[10:33] noel- (~noel@pD9E09745.dip.t-dialin.net) joined #vserver.
[10:40] noel (~noel@pD9E09741.dip.t-dialin.net) left irc: Ping timeout: 493 seconds
[13:15] serving (~serving@213.186.189.100) left irc: Ping timeout: 480 seconds
[15:07] serving (~serving@213.186.189.88) joined #vserver.
[15:37] <Tamama> Hunk #3 succeeded at 101 with fuzz 2.
[15:37] <Tamama> hm
[15:44] Nick change: noel- -> noel
[17:05] <Tamama> chctx skips 'dev' entries
[17:05] <Tamama> guess touch will do
[18:52] Nick change: Bertl_zZ -> Bertl
[18:52] <Bertl> hi everyone!
[19:08] <noel> hello Bertl. you are sleeping very long.;)
[19:08] <Bertl> hmm, well, I'm working very hard ;)
[19:09] <noel> ok, this is true and an excuse.;)
[19:09] <Bertl> thank you!  I'm glad to hear! ;)
[19:15] <virtuoso> :)
[19:15] <virtuoso> Hi.
[19:16] <Bertl> hi virtuoso!
[19:16] maharaja (maharaja@ipax.tk) left irc: Ping timeout: 485 seconds
[19:16] <noel> Bertl: you asked one or 2 days ago if anybody wants to test memory limits. Now I have a dedicated testsystem and would test it. just if you still need one.
[19:18] <Bertl> I always need people who do some testing, what do you have in mind?
[19:18] <Bertl> what is this 'dedicated' test system?
[19:22] <Bertl> noel: hmm you had those fixed context id issues?
[19:23] <noel> I setup quota and the only missing for me is limiting memory of a vserver. this testsystem is just a dedicated i386 just for this tests and sometimes I will test the stuff I do on sparc64.
[19:23] <noel> Bertl: yes. its me.
[19:23] <Bertl> hmm, and it doesn't take the S_CONTEXT value?
[19:23] <noel> for me not. it works for you?
[19:24] <Bertl> I assume so, let me test ...
[19:25] <noel> S_CONTEXT isn't in the manpage in 0.29 so I thought it got removed. but its possible the problem is on my side.
[19:26] <Bertl> # uname -a
[19:26] <Bertl> Linux (none) 2.4.23-vs1.22 #1 SMP Sat Dec 13 19:02:02 CET 2003 i686 unknown
[19:26] <Bertl> # vserver XXXX start
[19:26] <Bertl> Starting the virtual server XXXX
[19:26] <Bertl> Server XXXX is not running
[19:26] <Bertl> ipv4root is now 192.168.0.2
[19:26] <Bertl> Host name is now XXXX.test.org
[19:26] <Bertl> Domain name is now 
[19:26] <Bertl> New security context is 1001
[19:26] <Bertl> Kernel do not support chrootsafe(), using chroot()
[19:26] <Bertl> Starting system logger: [  OK  ]
[19:27] <Bertl> with 'chcontext version 0.24' 
[19:27] <Bertl> S_CONTEXT=1001
[19:28] <Bertl> I'll test with the newer tools ... sec
[19:28] <noel> hmm. ok. I have "chcontext version 0.26" here.
[19:29] <Bertl> is this util-vserver or vserver?
[19:29] <noel> vserver.
[19:30] maharaja (maharaja@ipax.tk) joined #vserver.
[19:30] <Bertl> could you test http://vserver.13thfloor.at/Stuff/testme.sh and make the result available/ see if everything works ...
[19:31] <noel> sure. one moment.
[19:32] <noel> is it ok to paste it here?
[19:32] <Bertl> hmm, dcc or web or email ...
[19:32] <Bertl> or send it in private ...
[19:32] <noel> ok.
[19:34] <Bertl> ahh, you are using util-vserver (at least my script says so ;)
[19:35] <Bertl> anyway, that should have no effect on that ...
[19:35] <noel> hmm. right, sorry I forgot.I installed it after I found the problem into /usr/local. mom. will remove it and try again.
[19:35] JonB (~Jon@0x503e03ba.kjnxx7.adsl.tele.dk) joined #vserver.
[19:35] <Bertl> hi Jon!
[19:35] <JonB> hey Bertl 
[19:35] <Bertl> hi maharaja! alsmost missed you!
[19:37] <JonB> does anyone know of an OS X11 irc/icq/yahoo client program in one?
[19:41] <JonB> later
[19:41] JonB (~Jon@0x503e03ba.kjnxx7.adsl.tele.dk) left irc: Quit: ChatZilla 0.9.35 [Mozilla rv:1.5.1/20031120]
[20:36] netrose (~john877@CC3-24.171.21.47.charter-stl.com) joined #vserver.
[20:37] JonB (~Jon@0x503e03ba.kjnxx7.adsl.tele.dk) joined #vserver.
[21:30] JonB (~Jon@0x503e03ba.kjnxx7.adsl.tele.dk) left irc: Quit: ChatZilla 0.9.35 [Mozilla rv:1.5.1/20031120]
[21:31] <Tamama> hm
[21:31] <Bertl> hmhm!
[21:32] <Tamama> root@ns1:/etc# named
[21:32] <Tamama> named: capset failed: Operation not permitted
[21:33] <Bertl> sounds like your named want's to play with the capabilities ;)
[21:33] <Tamama> i gave it S_CAPS="CAP_QUOTACTL CAP_NET_RAW"
[21:34] <Tamama> ah
[21:34] <Tamama> strace helps :)
[21:34] <Bertl> is this bind?
[21:34] <Tamama> capset(0x19980330, 0, {CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE, CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE, CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE}) = -1 EPERM (Operation not permitted)
[21:34] <Tamama> yep
[21:34] <Bertl> you should 'recompile' without linux capablilities ...
[21:35] <Tamama> hrm
[21:35] <Bertl> for security reasons, but you can 'just' give CAP_SYS_RESOURCE ...
[21:35] <Tamama> --disable-linux-caps disable linux capabilities
[21:35] <Bertl> (this will disable resource control for this vserver)
[21:35] <Tamama> hm what exactly does this do? linux-caps that is
[21:36] <Bertl> well, the bind people 'think' it is a good idea, to raise/modify the limits themselves ... and then drop that capability ...
[21:36] <Tamama> hrm
[21:37] <Bertl> of course, this doesn't work in a vserver, where the capabilities are already dropped ...
[21:37] <Tamama> well a recompile is no biggy :)
[21:37] <Tamama> i guess it does not need RAW then either
[21:38] <Bertl> nope, should not require that ...
[21:38] <Tamama> and i just found out i dont need quotas either, doh
[21:39] <Bertl> for a nameserver, not very likely ;)
[21:39] <Tamama> oh well, good excercise :)
[21:39] <Tamama> nah, web/ftp
[21:39] <Bertl> hmm, why then use bind?
[21:39] <Tamama> its a diff vserver :)
[21:39] <Bertl> ah okay ...
[21:39] <Bertl> what tools do you use?
[21:39] <Bertl> vserver tools, I mean ...
[21:39] <Tamama> hardly any
[21:40] <Bertl> hmm, how do you start vservers?
[21:40] <Tamama> vserver web start :)
[21:40] <Bertl> well, there is a tools involved in that, right?
[21:41] <Bertl> where does vserver come from?
[21:41] <Tamama> i guess, but i did not say i did not use any :)
[21:41] <Tamama> just that vserver is the only thing really being used heh
[21:41] <Bertl> basically, I'm only interested in _what_ version this is ;)
[21:42] <Tamama> the thing doesnt tell
[21:43] <Tamama> ;)
[21:43] <Bertl> hmm, I know ... try chcontext --ctx 100 false
[21:44] <Tamama> 0.26
[21:44] <Bertl> okay, probably this is enricos util-vserver 0.26 ....
[21:44] <Tamama> the one that is linked to on the 1.22 stable page
[21:45] <Bertl> yeah, okay, because I just discovered, that jacques tools (0.29) are more broken, than I thought ...
[21:45] <Tamama> oh?
[21:46] <Tamama> b0rked eyond recognition? heh
[21:46] <Bertl> hmm, almost, problem is, he changed to much, without extensive testing ...
[21:46] <Tamama> right...
[21:47] <Tamama> that usually results in 'crap'
[21:47] <Tamama> heh
[21:47] <Tamama> righto named now works :)
[21:56] <Tamama> so, what parts are already known not to work in 0.29 then?
[21:56] <Bertl> it ignores S_CONTEXT for example ...
[21:56] <Tamama> guess he didnt use them
[21:57] <Bertl> possible ...
[21:57] Linux_Lord (~dr@pD9507EDD.dip0.t-ipconnect.de) joined #vserver.
[21:58] <Bertl> Linux_Lord: hi!
[22:02] <Bertl> hmm, I hate those auto joins ...
[22:05] LL0rd (~dr@pD9507ECB.dip0.t-ipconnect.de) left irc: Ping timeout: 480 seconds
[22:13] <Tamama> heh
[22:34] <noel> Bertl: is  vserver-0.29-fix01 the answer of my problem?:)
[22:34] <Bertl> yup, I hope so ;)
[22:35] <noel> great. testing...
[22:47] Tamama (~Tamama@a62-216-20-152.adsl.cistron.nl) left irc: Read error: Connection reset by peer
[23:40] <virtuoso> Fuff.
[23:40] Action: virtuoso is going to compile a kernel for production server.
[23:40] <Bertl> good idea ...
[23:40] <virtuoso> What to take: 1.22 or 1.3.1?
[23:41] <Bertl> hmm, I would take 1.3.2, but that isn't an option for you, yet ;)
[23:41] <Bertl> but vs1.22 is stable, and production quality ...
[23:42] <virtuoso> Ok, will take it.
[23:42] Action: virtuoso also wonders if there is new rmap patch.
[23:42] <Bertl> nope, rik is pining ... ;)
[23:43] <noel> anybody had this error: "Can't chroot to directory . (Permission denied)" the dir is ok and a manual chroot works. the second vserver works. (/me has always errors:))
[23:44] <Bertl> hey, we'll fix em ;)
[23:44] <virtuoso> Are you uid 0? :)
[23:44] <noel> virtuoso: sure.
[23:44] <Bertl> noel: first some questions ...
[23:44] <Bertl> context tagging enabled?
[23:45] <Bertl> (if you do not know what this means, the answer is probably no)
[23:45] <noel> ok: no.:)
[23:46] <noel> the command is (set -x in /usr/sbin/vserver): /usr/sbin/chbind --ip 192.168.74.101 --bcast 192.168.74.255 /usr/sbin/chcontext --cap CAP_NET_RAW --flag lock --flag nproc --ctx 101 --hostname v101 --secure /usr/lib/vserver/save_s_context /var/run/vservers/v101.ctx /usr/lib/vserver/capchroot . /etc/init.d/rc 2
[23:46] <Bertl> next, check the permissions of _all_ directories in the path to that directory/vserver ...
[23:47] <noel> ok. will check permission diffs between v101 and v102 (this one is working).
[00:00] --- Mon Dec 29 2003