1316649783 Q * dowdle Remote host closed the connection 1316650018 Q * clopez Ping timeout: 480 seconds 1316650144 Q * manana Remote host closed the connection 1316650537 J * clopez ~clopez@238.10.117.91.dynamic.mundo-r.com 1316651776 N * Bertl_oO Bertl 1316652538 Q * clopez Ping timeout: 480 seconds 1316657946 Q * Aiken Remote host closed the connection 1316666753 M * Bertl off to bed now ... have a good one everyone! 1316666757 N * Bertl Bertl_zZ 1316668154 J * fisted ~fisted@xdsl-87-78-215-184.netcologne.de 1316668193 Q * fisted_ Ping timeout: 480 seconds 1316668784 J * ircuser-1 ~ircuser-1@025.205-93-216-nokia-dsl.dynamic.surewest.net 1316668797 Q * ircuser-1 Remote host closed the connection 1316668827 J * ircuser-1 ~ircuser-1@025.205-93-216-nokia-dsl.dynamic.surewest.net 1316669484 J * ghislain ~AQUEOS@adsl2.aqueos.com 1316671370 J * ncopa ~ncopa@3.203.202.84.customer.cdi.no 1316671377 N * AndrewLe1 AndrewLee 1316672601 J * mikez mike@no.phear.eu 1316676656 J * fanto666 fantomas@fantomas.fantomas.sk 1316677161 M * fanto666 hello, after upgrading to vserver 2.3.0.36.32 I can't start vservers, says "vcontext: pivot_root(): Device or resource busy" 1316677582 M * fanto666 sttributed for the dir are ----buic- and ----Buic- for the parent 1316677589 M * fanto666 attributes, it is 1316678922 M * ghislain do you upgraded your tools before ? 1316678972 M * ghislain tools are tied to the kernel release, if you upgrade the kernel and not the tools you will have issues 1316679015 M * ghislain 1/ stop guests 2/ upgrade kernel/upgrade tool 3/ reboot and pray ;p 1316679228 M * fanto666 after.. 1316679257 M * fanto666 upgraded kernel and then tools 1316679262 M * fanto666 I'll check 1316679301 M * fanto666 0.30.216_pre2910 1316679317 M * ard you can upgrade tools before kernel 1316679326 M * ard tools are usually backwards compatible 1316679335 M * ard just as long as your kernel is not too ancient 1316679343 M * fanto666 hmmm I'm afraid it's a bit late 1316679353 M * ard no, it's early! :-) 1316679366 J * BenG ~bengreen@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com 1316679423 M * fanto666 well, we've been running 2.6.22-vs2.2.0.7 with 0.30.215-r3 1316679458 M * ard Hmmmm, that's quite a leap forward then 1316679488 M * fanto666 how we have 2.6.35-vs2.3.0.36.32 with 0.30.216_pre2910 1316679488 M * ard I think the latest tools should be able to cope with vs2.2.0.7 1316679537 M * fanto666 s/how/now 1316679563 M * ard Hmmm, the only thing I know is that we are running: 2:0.30.216-svn2939-6 1316679575 M * fanto666 which kernel? 1316679578 Q * BenG 1316679589 M * ard we build the kernels ourselves (debian kernels have a tendency to break f.i.), and we build our own packages 1316679597 M * ard 2.6.37.6-vs2.3.0.37-rc5-d64-i7 1316679599 M * ard :-) 1316679602 M * ard gtg... 1316679609 M * fanto666 I can try util-vserver-0.30.216_pre2955 1316679610 M * ard back in 30 I guess 1316679621 M * ard that's better I think... 1316679771 J * ex ex@valis.net.pl 1316679836 M * fanto666 vector-free.c:(.text+0x26): warning: warning: your code still has assertions enabled! 1316679838 M * fanto666 :-) 1316679874 M * ghislain how do you get 3.0 kernels ? 1316679880 M * daniel_hozac you want 2987 1316679892 M * daniel_hozac ghislain: git clone? 1316679910 M * fanto666 tried with 2935 , same result. I use gentoo and prefer versions 1316679916 M * fanto666 that are in portage... 1316679926 M * ghislain never used this git thing :( 1316679956 M * ghislain kernel.org still down, this must be a very very bad situation down there :( 1316679971 M * Wonka I wonder _who_ is working on that. 1316679976 M * Wonka takes a bit long now 1316680166 M * ghislain imagine if kernel code was modified :( 1316680182 M * daniel_hozac git makes that impossible. 1316680489 M * ghislain heard that but what about irrationnal fear ! :p 1316680537 M * Wonka ghislain: cannot happen because of how git works 1316680549 M * Wonka oh, daniel_hozac ^5 1316680554 M * Wonka <- bit slow today 1316680670 M * fanto666 makes impossible what? kernel modification? why do they use it then? ;-) 1316680689 M * Wonka fanto666: unnoticed malicious kernel modifications 1316680709 M * fanto666 well, even upgrading utils to 0.30.216_pre2987 didn't help, 1316680756 M * fanto666 still ggettint "vcontext: pivot_root(): Device or resource busy" 1316680767 M * daniel_hozac maybe your kernel is broken. 1316680800 M * fanto666 a way to check that? 1316680822 M * daniel_hozac try a new one? :) 1316680904 M * fanto666 a bit older maybe 1316681058 M * daniel_hozac no... 1316681070 M * daniel_hozac you want 2.6.38 or 3.0. 1316681137 M * fanto666 i prefer those in gentoo portage, but i could try hack own ebuild 1316681586 J * _nono_ ~gomes@licencieux.ircam.fr 1316682374 J * clopez ~clopez@155.99.117.91.static.mundo-r.com 1316683367 M * ghislain ok got 3.0, patched, building. Got to try it 1316684798 M * fanto666 any plans about making vs2.3 stable? 1316685529 J * derjohn_mob ~aj@213.238.45.2 1316685935 M * daniel_hozac yes, see the mailing list 1316686566 J * BenG ~bengreen@212.183.140.51 1316687248 Q * _nono_ Quit: Leaving 1316687907 Q * BenG Ping timeout: 480 seconds 1316690042 Q * derjohn_mob Ping timeout: 480 seconds 1316690585 J * derjohn_mob aj@80.187.235.134 1316690842 N * Bertl_zZ Bertl 1316690855 M * Bertl morning folks! 1316692865 J * manana ~mayday090@178.162.120.195 1316693456 M * fanto666 btw, what's the .oldroot directory for? 1316693527 M * daniel_hozac for putting the old root somewhere. 1316693606 M * fanto666 what old root? 1316693614 M * daniel_hozac the root of the host 1316693633 M * fanto666 root directory? root user? process? 1316693646 M * daniel_hozac directory, obviously. 1316693688 M * fanto666 sorry, I still don't get it 1316693737 M * daniel_hozac you did read man 2 pivot_root, right? 1316693796 M * fanto666 long time ago 1316693801 M * fanto666 reading now... 1316694914 M * fanto666 what does the 'c' flag in showattr mean? copy-on-write? 1316695109 M * daniel_hozac yes. 1316695202 M * fanto666 is it set by default ? the old showattr on old system doesn't show it, and on updated system I see it everywhere 1316695443 M * daniel_hozac lowercase means unset but available, uppercase means set. 1316695596 M * Bertl from what util-vserver version was the old showattr? 1316695885 J * _nono_ ~gomes@licencieux.ircam.fr 1316696138 M * fanto666 aha, ok. so it's only available, ok 1316696178 M * fanto666 the old was/is 0.30.215, fyi. new is 0.30.216-pre2987 but i tried older pre* too 1316697136 Q * _nono_ Quit: Leaving 1316697643 J * _nono_ ~gomes@licencieux.ircam.fr 1316698794 M * Rockj hm 1316698799 M * Rockj anyone else experienced this? http://lists.debian.org/debian-kernel/2011/07/msg00749.html 1316698815 M * Rockj noticed my authorized_keys file get squashed by nfs or something when logging in 1316698867 M * daniel_hozac hmm? 1316700075 M * fanto666 do I _need_ to specify either namespace or nonamespace ? 1316700174 M * fanto666 because I don't have any defined globally even in vserver 1316700176 M * Bertl Rockj: so, your guest resides on NFS (or at least the user home) and you login via ssh or so? 1316700195 M * Rockj Bertl: this is at my host, probably just a normal nfs issue oof some sort 1316700214 M * Bertl okay, and what happens to authorized_keys? 1316700227 M * Rockj the uid/gid get squashed by nfs when logging in 1316700236 M * Rockj but getent passwd etc gives me the users so 1316700241 M * Rockj anyhow, restarted nfs on server and stuff 1316700246 M * Rockj going to see if this solves the issue 1316700253 M * Bertl nfsv3 or v4? 1316700268 M * Bertl because v4 depends on a separate id daemon 1316700295 M * Bertl (which does the uid/gid mapping, or not :) 1316700639 M * Rockj nfs4 1316700669 M * Rockj dont get it tho, because the nfs mount works 1316700677 M * Rockj it has my ownership on files and stuff 1316700703 M * Bertl yeah, but what about root? 1316700715 M * Bertl by default, client root is squashed to nobody 1316700729 M * Bertl (see option no_root_squash) 1316700956 M * Rockj mhm, I use that option on the export dirs, but it works fine on another server 1316700973 M * Rockj which uses the same nfs server and has the same export options from the server 1316701360 M * Bertl okay, does it 'just' happen on this specific file or is root squashed in general? 1316701389 M * Bertl i.e. what happens if you touch a new file as root on the nfs share, what uid/gid does it get? 1316701404 M * Bertl also, what kernel/patch version are we talking about? 1316702509 M * Rockj let me check Bertl 1316702538 M * Rockj norangsh@absint:~$ touch foo && ls -la | grep foo 1316702540 M * Rockj -rw-r--r-- 1 norangsh dotkom 0 Sep 22 16:42 foo 1316702574 M * Rockj (but that's not in the root of the mount, but it gets right permissions .. /home is only readable by root so other users on the box shouldn't navigate in the /home folders 1316702911 M * Rockj it has the right uid/gid until I ssh, and it squashed it .. so sounds like ssh is touching/doing something with the file 1316702913 M * Rockj which is odd 1316702926 M * fanto666 hmmm 1316702945 M * fanto666 vcontect --create seemed to work as expected 1316702945 M * Rockj after the login it seems to even revert the file to proper permissions, is just under the login it seems :O 1316702964 M * fanto666 it's the "vserver" that complains about pivot_root 1316703130 M * Bertl Rockj: sounds strange, still I'd be interested in the kernel/patch version :) 1316703157 M * Bertl fanto666: selinux enabled? 1316703164 M * fanto666 no 1316703177 M * fanto666 hmmm I'll check for sure 1316703184 M * Bertl any other 'security' which might prevent pivot_root? 1316703200 M * fanto666 I don't know about any 1316703206 M * Bertl k :) 1316703210 M * fanto666 is pivot_root needed for vserver? 1316703215 M * fanto666 for running vserver? 1316703240 M * Bertl yes, recent util-vserver/kernels use pivot_root for isolation 1316703282 M * fanto666 hmmm 1316703297 M * fanto666 older utils did work but changed global hostname to hostname of last vserver 1316703311 M * Bertl that isn't called working :) 1316703311 M * fanto666 well, not sure if it workeddid 1316703325 M * Bertl it just means, that your guests were not properly isolated 1316703354 M * fanto666 well, that's why we upgraded vserver-utils after kernel upgrade 1316703544 M * Bertl okay, you probably already mentioned it, but could you repeat for me what kernel/patch and util-vserver version(s) we are talking about? 1316703571 M * fanto666 2.6.35-vs2.3.0.36.32-gentoo and 0.30.216-pre2987 1316703585 M * fanto666 unfortunately there's no newer kernel in gentoo repository now 1316703882 J * BenG ~bengreen@host86-173-179-211.range86-173.btcentralplus.com 1316703990 J * dowdle ~dowdle@scott.coe.montana.edu 1316704013 Q * hparker Ping timeout: 480 seconds 1316704676 M * fanto666 hmmm we have CONFIG_SECURITY=y 1316704702 M * fanto666 and CONFIG_SECURITYFS, that's all 1316704767 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647 1316704864 M * Bertl sounds fine, so I suspect the gentoo kernel is broken in some way 1316704879 M * Bertl I'd suggest to try with a mainline kernel just to verify that 1316704892 M * Bertl e.g. 2.6.38.8 + latest patch 1316704899 M * fanto666 and CONFIG_SECURITYFS, that's all 1316704901 M * fanto666 ops 1316705354 M * fanto666 hmmm can I trace what exactly is vserver trying to do when calling pivot_root? 1316705358 M * fanto666 strace? 1316705381 M * Bertl to some extend, but it's simpler to run the startup with --debug 1316705396 M * fanto666 ah, --debug .. 1316705406 M * Bertl which should give you the final command sequence, which you can easily copy/paste and inject some strace at the proper position 1316705552 M * fanto666 wow 1316705782 M * fanto666 upeek: ptrace(PTRACE_PEEKUSER,25321,120,0): Operation not permitted 1316705782 M * fanto666 detach: ptrace(PTRACE_DETACH, ...): Operation not permitted 1316705804 M * Bertl yep, that's when you try to strace across a context switch 1316705818 M * Bertl i.e. move the strace behind the context switch 1316705829 M * fanto666 so I should push strace before last /usr/sbin/vcontext 1316705836 M * fanto666 aha, or so 1316705911 M * fanto666 that should be the "/usr/sbin/vcontext --create" part, correct? 1316705933 M * Bertl the migrate will change into the guest context 1316705948 M * Bertl so putting the strace behind that should work fine 1316705976 M * Bertl (but that might be too late for the pivot part) 1316706036 Q * FireEgl Quit: Leaving... 1316706091 M * fanto666 I'll try 1316706673 Q * ncopa Quit: Leaving 1316706842 Q * derjohn_mob Ping timeout: 480 seconds 1316707001 M * fanto666 vcontext: vc_ctx_create(): Device or resource busy 1316707050 M * Bertl means the guest is already running (at least partially) 1316707054 M * Rockj Bertl: 3.0.4-vs2.3.1-pre10.1-UAC , could be something stupid ive done on the server tho. not sure if its releated to vserver either. 1316707505 M * fanto666 aha, left process from previous try 1316707580 M * Bertl Rockj: yeah, no problem, just curious :) 1316707619 M * fanto666 vserver(0xa010002, 0x2, 0x7fff3e6fcbc0, 0x8, 0) = -1 EPERM (Operation not permitted) 1316707622 M * fanto666 unshare(CLONE_NEWNS) = 0 1316707625 M * fanto666 mkdir("./.oldroot", 0700) = -1 EEXIST (File exists) 1316707627 M * fanto666 pivot_root(".", "./.oldroot") = -1 EBUSY (Device or resource busy) 1316707651 M * Bertl well, EBUSY is definitely interesting 1316707663 M * fanto666 EBUSY new_root or put_old are on the current root file system, or a 1316707663 M * fanto666 file system is already mounted on put_old. 1316707665 M * fanto666 hmmm 1316707686 M * fanto666 is it possible that this changed since older linux kernels? 1316707701 M * Bertl everything is possible 1316707931 M * Bertl still trying with a different (recent) kernel would probably shed some light on the issue (i.e. tell us where to look) 1316707935 M * fanto666 that would explain it 1316708369 J * bonbons ~bonbons@2001:960:7ab:0:c9bf:a920:8dc8:ae6e 1316708834 M * fanto666 using pivot_root since 0.30.216? means requiring separate FS for vservers 1316708852 M * fanto666 (separate from OS root, not needed for each other) 1316708931 M * Bertl well, /vservers should in any case be a separate partition, but that shouldn't stop util-vserver (and 0.30.216 isn't out yet) 1316708975 M * fanto666 well, that makes pivot_root not working 1316709052 M * fanto666 and since vserver uses pivot_root, it will make it not- working too 1316709347 M * fanto666 are the attributes used by vserver copyable using rsync or cp -a ? 1316709363 M * fanto666 rsync -X means extended attributes, is that it? 1316709492 Q * BenG Quit: I Leave 1316709517 Q * manana Ping timeout: 480 seconds 1316709525 M * Bertl well, util-vserver also uses namespaces and bind mounts, so pivot root is fine even for guests on shared host root 1316709545 M * Bertl I just verified that this still works fine on 2.6.38.8 with recent util-vserver 1316709617 M * Bertl and yes, you can rsync a guest with rsync -axHPSD --numeric-ids (-X is not required, unless you have EA) 1316709677 M * fanto666 bertl do you have system where vservers are on the same filesystem as host root? 1316709695 M * Bertl as I said, I just verified that on a test system 1316709701 M * fanto666 hmm 1316709712 M * Bertl i.e. moved a guest from /vservers (partition) to the host root 1316709805 M * fanto666 are the vserver attributes standard somehow? 1316709824 M * fanto666 i mean those set by setattr... 1316709856 M * Bertl the only attribute used are related to unification (immutable linkage invert and cow link breaking) and the barrier 1316709892 M * Bertl they are basic filesystem xattrs (not to be confused with EA) and they are copied/dumped by low level tools like dump/restore 1316710000 M * fanto666 aha 1316710007 M * fanto666 well, separate FS didn't help 1316710056 M * fanto666 ehrmmmm 1316710098 M * fanto666 touching "nonamespace" fixed that 1316710109 M * Bertl because it disables pivot_root 1316710120 M * Bertl i.e. you do not get a namespace isolation for that guest 1316710147 M * fanto666 what exactly does that affect? 1316710167 M * Bertl the guest shares the filesystem namespace with the host 1316710176 M * Bertl i.e. chroot escapes are possible 1316710185 M * Bertl mounts from the host are visible, etc 1316710281 M * fanto666 I see them in old system too 1316710304 M * fanto666 didn't have neither "namespace" nor "nonamespace" anywhere. 1316710318 M * Bertl what kernel/patch and util-vserver version? 1316710327 M * fanto666 2.6.22-vs2.2.0.7-gentoo 1316710332 M * fanto666 0.30.215 1316710352 M * Bertl 0.30.215 is a few years old, it was long before namespaces were invented 1316710366 M * Bertl note that the 0.30.215 version is also unsuited for 2.6.22 1316710447 M * fanto666 didn't have much more choices 1316710464 M * Bertl well, you had, tools and kernels are available 1316710474 M * fanto666 ...or maybe we upgraded uselessly when recompiling whole system except the kernel 1316710489 M * fanto666 or there was no newer stable kernel that time 1316710511 M * fanto666 because I didn't hack gentoo much 1316710533 M * fanto666 so, in fact, when I use nonamespace, it's the same as with the old kernel and utils, correct? 1316710584 M * Bertl as with the old kernel and ancient utils, yes 1316710689 M * fanto666 well, will work at least today 1316710723 M * Bertl such a guest is probably fine for testing or if you control host and guest environment and do not really care about complete isolation, but it is definitely dangerous for a potential hostile guest scenario 1316710746 M * Bertl i.e. if somebody else (whom you do not trust) is root in the guest 1316710753 M * fanto666 nobody should be 1316710826 M * fanto666 gotta go home 1316710840 M * fanto666 while I won't increase security, I hope I won't decrease it 1316710868 M * fanto666 i can get the pivot thingie for solving later, thanks for infos 1316710886 M * Bertl you're welcome! 1316710923 M * fanto666 still better than pure chroot, we have isolated networks at least 1316710948 M * fanto666 good night, thanks 1316711040 M * Bertl with the barrier in place, the chroot should be somewhat secure as well 1316711887 Q * ghislain Quit: Leaving. 1316712005 M * Bertl off for now .. bbl 1316712010 N * Bertl Bertl_oO 1316712416 J * derjohn_mob aj@tmo-042-147.customers.d1-online.com 1316712703 Q * fisted Ping timeout: 480 seconds 1316712941 J * fisted ~fisted@xdsl-87-78-209-235.netcologne.de 1316718205 N * Bertl_oO Bertl 1316718208 M * Bertl back now ... 1316718312 Q * derjohn_mob Ping timeout: 480 seconds 1316718443 J * derjohn_mob aj@tmo-042-147.customers.d1-online.com 1316721252 Q * derjohn_mob Ping timeout: 480 seconds 1316723046 J * derjohn_mob aj@tmo-019-142.customers.d1-online.com 1316723054 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f 1316723887 Q * derjohn_mob Ping timeout: 480 seconds 1316724090 Q * clopez Ping timeout: 480 seconds 1316724320 J * FireEgl ~FireEgl@173-16-9-169.client.mchsi.com 1316724643 J * LuckyLuke ~luca@host65-83-static.228-95-b.business.telecomitalia.it 1316729026 Q * bonbons Quit: Leaving 1316731128 M * Bertl off to bed now ... have a good one everyone! 1316731150 N * Bertl Bertl_zZ 1316732409 Q * dowdle Remote host closed the connection