1171844373 Q * ema Quit: leaving 1171848515 Q * infowolfe_ Read error: No route to host 1171848583 Q * pstader 1171849993 Q * daniel_hozac Remote host closed the connection 1171850014 Q * notasnark Ping timeout: 480 seconds 1171851647 J * infowolfe ~infowolfe@c-67-164-195-129.hsd1.ut.comcast.net 1171855250 J * muuhDBX ~foo@a213-22-7-80.cpe.netcabo.pt 1171856370 T * * http://linux-vserver.org/ | latest stable 2.0.2.1, 2.0.3-rc1, 2.2.0-rc13.1/pre4, devel 2.3.0.10, stable+grsec 2.0.2.1, 2.2.0-rc13.1 | util-vserver-0.30.212 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the Wiki, and we'll forget about the minute ;) 1171856370 T * Bertl - 1171856913 J * ||Cobra|| ~cob@pc-csa01.science.uva.nl 1171858142 J * daniel_hozac ~daniel@c-091472d5.010-230-73746f22.cust.bredbandsbolaget.se 1171860963 P * muuhDBX 1171862826 J * DoberMann_ ~james@AToulouse-156-1-162-195.w90-38.abo.wanadoo.fr 1171862936 Q * DoberMann[ZZZzzz] Ping timeout: 480 seconds 1171863359 J * almak ~almak@willers.employees.org 1171867454 N * DoberMann_ DoberMann 1171868366 Q * gab Quit: Leaving 1171868383 J * gab ~gab@158.36.45.236 1171870422 N * DoberMann DoberMann[PullA] 1171870572 J * olivierk ~olivier@olivierk.org 1171870650 J * ntrs_ ~ntrs@68-188-55-120.dhcp.stls.mo.charter.com 1171870682 Q * olivierk_ Ping timeout: 480 seconds 1171870879 Q * gab cation.oftc.net galapagos.oftc.net 1171870879 Q * DoberMann[PullA] cation.oftc.net galapagos.oftc.net 1171870879 Q * ||Cobra|| cation.oftc.net galapagos.oftc.net 1171870879 Q * ag- cation.oftc.net galapagos.oftc.net 1171870879 Q * bXi cation.oftc.net galapagos.oftc.net 1171870879 Q * dev-zero cation.oftc.net galapagos.oftc.net 1171870879 Q * shedi cation.oftc.net galapagos.oftc.net 1171870879 Q * rob-84x^ cation.oftc.net galapagos.oftc.net 1171870879 Q * ZLinux cation.oftc.net galapagos.oftc.net 1171870879 Q * ntrs cation.oftc.net galapagos.oftc.net 1171870879 Q * phedny cation.oftc.net galapagos.oftc.net 1171870879 Q * michal`_ cation.oftc.net galapagos.oftc.net 1171870940 J * dev-zero ~TizianoMu@gw.ptr-80-238-235-63.customer.ch.netstream.com 1171870940 J * gab ~gab@158.36.45.236 1171870940 J * DoberMann[PullA] ~james@AToulouse-156-1-162-195.w90-38.abo.wanadoo.fr 1171870940 J * ||Cobra|| ~cob@pc-csa01.science.uva.nl 1171870940 J * ag- ~ag@caladan.roxor.cx 1171870940 J * bXi bluepunk@irssi.co.uk 1171870940 J * shedi ~siggi@ftth-237-144.hive.is 1171870940 J * rob-84x^ ~rob@submarine.ath.cx 1171870940 J * ZLinux ~ZLinux@88.213.57.11 1171870940 J * ntrs ~ntrs@68-188-55-120.dhcp.stls.mo.charter.com 1171870940 J * phedny ~mark@phedny.vps.van-cuijk.nl 1171870940 J * michal`_ ~michal@www.rsbac.org 1171870958 Q * phedny Remote host closed the connection 1171871008 J * phedny ~mark@phedny.vps.van-cuijk.nl 1171871067 Q * ntrs Ping timeout: 480 seconds 1171871262 J * FireEgl Proteus@68.220.222.136 1171871587 J * meandtheshell ~markus@85-124-207-204.dynamic.xdsl-line.inode.at 1171874447 J * bonbons ~bonbons@83.222.38.57 1171875400 J * Aiken ~james@ppp126-23.lns2.bne4.internode.on.net 1171876300 N * DoberMann[PullA] DoberMann 1171876441 J * dna ~naucki@9-208-dsl.kielnet.net 1171877097 Q * Aiken Read error: Connection reset by peer 1171877130 Q * kaner Remote host closed the connection 1171877131 J * kaner kaner@strace.org 1171877404 J * dlezcano ~dlezcano@blueice1n1.uk.ibm.com 1171877563 Q * shedi Quit: Leaving 1171879072 J * Aiken ~james@ppp126-23.lns2.bne4.internode.on.net 1171881486 J * bon bon@stichting-brein.eu 1171881509 Q * morfoh cation.oftc.net panulirus.oftc.net 1171881509 Q * bon` cation.oftc.net panulirus.oftc.net 1171881509 Q * glut cation.oftc.net panulirus.oftc.net 1171881509 Q * doener cation.oftc.net panulirus.oftc.net 1171881509 Q * badari cation.oftc.net panulirus.oftc.net 1171881518 J * morfoh ~morfoh@kilo105.server4you.de 1171881527 J * doener ~doener@host.magicwars.de 1171881539 J * glut glut@no.suid.pl 1171881774 J * shedi ~siggi@dsl-149-109-85.hive.is 1171882111 A * waldi likes slab leaks ... 1171882114 M * waldi not 1171882249 J * badari ~badari@bi01p1.co.us.ibm.com 1171882721 J * mauro ~mauro@217.11.85.41 1171884166 M * matti ;] 1171887001 J * yarihm ~yarihm@84-75-123-221.dclient.hispeed.ch 1171888167 Q * yarihm Quit: Leaving 1171888460 J * tzafrir ~tzafrir@62.90.10.53 1171888573 M * tzafrir Hi, I'm trying to set up vserver on Debian Etch (4.0). I used vserver-debiantools to create two vservers. But the standard init script does not seem to start them 1171888633 M * tzafrir The init script seems to be looking for configurations with the name /etc/vservers/*.conf but I don't see those files created anywhere, nor any document describing what they should have 1171888636 M * cehteh you have to tag them to be started in some class (default?) .. i dont know if the debian tools do that 1171888669 M * cehteh better dont use the debian tools they are rotten old 1171888680 M * tzafrir where do I tag them? Which file? 1171888729 A * cehteh using standard vserver tools not the debian ones 1171888740 M * cehteh they are documented in the wiki 1171888829 M * tzafrir there is a package called vserver-debiantools which basically seem to be a wrapper for vserver-tools 1171889421 M * matti cehteh: :) 1171889822 Q * mauro Quit: bye bye! 1171889870 M * tzafrir the wiki sends me to use those debian tools 1171889903 M * tzafrir sorry for the long response time: firefox is driving me crazy here 1171890086 J * n00b ~n00b1234@chello213047155237.5.sc-graz.chello.at 1171890741 N * Bertl_zZ Bertl 1171890765 M * Bertl good morning ... 1171890904 M * Bertl tzafrir: better avoid it and fix-up the wiki ...# 1171891004 M * Bertl okay, off for breakfast ... back shortly 1171891015 N * Bertl Bertl_oO 1171891072 M * n00b Hello 1171891264 J * DavidS ~david@vpn.uni-ak.ac.at 1171891360 M * tzafrir cehteh, I dug up the "standard" procedure from the docs. And surprisingly enough I got to the same issue: the server I have created is not "default" . Where do I set it so? 1171891408 M * tzafrir another tip for debian: bash completion seems to be disabled by default for root 1171891418 M * tzafrir . /etc/bash_completion helps 1171891559 Q * n00b Ping timeout: 480 seconds 1171891685 M * DavidS tzafrir: echo default > /etc/vservers/$name/apps/init/mark , at least on Debian 1171891819 M * tzafrir Works well (also for the vserver I defined with newvserver). aparantly no reason to update the wiki... 1171892378 J * n00b2733 ~n00b1234@chello213047155237.5.sc-graz.chello.at 1171892391 M * n00b2733 Hello 1171892583 M * n00b2733 Hello everyone! Could it be that the line "+ #include " is missing in patch for kernel 2.6.20? (file fs/jffs2/ioctl.c) 1171892818 Q * Aiken Quit: Leaving 1171892868 J * harti ~Hartmut@85-124-99-73.dynamic.xdsl-line.inode.at 1171893249 M * tzafrir n00b2733, I don't really know what you're talking about, but I figure that the leading "+ " in that line should not be there 1171893376 Q * n00b2733 Ping timeout: 480 seconds 1171893731 N * Bertl_oO Bertl 1171893823 M * Bertl tzafrir: except for the fact that newvserver is debian specific, while vserver - build -m debootstrap does similar and is not 1171893956 M * tzafrir the util-vserver package needs work. I can't find any documentation in it regarding the usage 1171893963 M * tzafrir newvserver is documented 1171894088 M * Bertl try vserver --help or vserver - build --help 1171894122 M * Bertl tzafrir: and of course, additional documentation is always welcome 1171894178 M * Bertl tzafrir: don't get me wrong, you can use whatever you like, just consider the potential issues with debian specific newvserver ... IMHO those are: 1171894206 M * Bertl - eventually newvserver gets outdated (probably already is) and thus lacks features 1171894229 M * Bertl - at some point the util-vserver interface changes, and as newvserver is only a wrapper, that breaks too 1171894248 M * Bertl - changes in the core tools now need to be handled in two places 1171894255 M * tzafrir well, I got those two from the same source... 1171894296 M * Bertl - the functionality, which can easily be added to util-vserver will be debian specific, if you move (for whatever reason) to a different distro, you have to learn the commands anew 1171894375 M * tzafrir the help text mentions vapt-get and vyum . I don't seem to have them anywhere 1171894389 M * tzafrir any idea where they are? 1171894605 M * Bertl those are wrappers for apt-get and yum 1171894623 M * Bertl i.e. you need to install the apt-get/yum, then the vapt-get/vyum will work 1171894631 M * Bertl (at least with mainline tools :) 1171894746 J * olivierk_ ~olivier@olivierk.org 1171894814 J * muuhDBX ~foo@a213-22-7-80.cpe.netcabo.pt 1171894851 Q * olivierk Ping timeout: 480 seconds 1171894902 J * n00b2733 ~n00b1234@chello213047155237.5.sc-graz.chello.at 1171894973 J * lilalinux ~plasma@dslb-084-058-216-170.pools.arcor-ip.net 1171895045 Q * DavidS Quit: Leaving. 1171896121 J * olivierk ~olivier@olivierk.org 1171896211 Q * olivierk_ Ping timeout: 480 seconds 1171897203 Q * gab Quit: Leaving 1171897336 Q * n00b2733 Ping timeout: 480 seconds 1171898634 J * olivierk_ ~olivier@olivierk.org 1171898741 Q * olivierk Ping timeout: 480 seconds 1171899003 M * tzafrir Where can I get vyum? I've installed yum (apt-getable on Debian). I have apt-get/deb, not sure how to install apt-rpm. But still I can't find vyum or something similar. 1171899146 M * Bertl if you get/build util-vserver, it is included since (sec): 1171899235 M * Bertl 0.30.201 1171899262 M * Bertl I have it here: /usr/sbin/vyum 1171899533 Q * shedi Quit: Leaving 1171899652 M * tzafrir hmmm... "mount point /etc/rpm does not exist" 1171899736 M * Bertl just create it, it is a debian oddity 1171899740 M * Bertl mkdir /etc/rpm 1171900340 J * boer ~boer@huizehennep.demon.nl 1171900434 M * boer I'm willing to test disk limits on XFS 1171900456 M * boer as per http://list.linux-vserver.org/archive/vserver/msg15084.html 1171900790 M * Bertl excellent, I'm looking into it as we speak :) 1171900845 M * boer really? 1171900855 Q * waldi Quit: reboot 1171900884 M * Bertl boer: really ... 1171900893 J * muuhDBXi ~foo@a213-22-7-216.cpe.netcabo.pt 1171900903 M * Bertl boer: but it is a coincidence ... 1171900916 P * muuhDBXi 1171900917 Q * harti Quit: Client exiting 1171900927 J * muuhDBXi ~foo@a213-22-7-216.cpe.netcabo.pt 1171900930 M * boer I guess I'll have to use 2.2+ or even 2.3 then, right? 1171900934 Q * muuhDBX Ping timeout: 480 seconds 1171900950 M * Bertl yes, first there will be some patches agains 2.2.x 1171900967 M * Bertl with a lot of debugging stuff 1171901107 M * boer ok, where do I sign up ;-) 1171901136 M * Bertl make sure to hang around here (and/or send me an email) 1171901822 M * mjt are there any plans to merge the stuff upstream? 1171901969 M * Bertl there is already an ongoing 'merge of some parts' 1171902017 M * Bertl i.e. mainline already implements some namespaces in 2.6.19+ which are basically identical to the previous Linux-VServer implementation 1171902311 Q * m`m`h Ping timeout: 480 seconds 1171902860 M * mjt you mean uname and time local to a 'container' ? 1171902883 M * mjt the same thing as used by openvz and others (are there others, btw?) 1171902913 M * Bertl I mean UTS and IPC (time is not a space yet) 1171902942 M * Bertl and yes, there are more to come, PID is work in progress, USER should be there soon 1171902955 M * mjt by the way, even if i don't select VSERVER_VTIME, basic "virtual time" support is still forcible selected 1171903058 M * mjt VSERVER_IDLETIME "This option allows the scheduler to artificially advance time (per cpu) when otherwise the idle task would be scheduled, thus keeping the cpu busy and sharing the available resources among certain contexts." 1171903068 M * mjt what does it mean, in two words? :) 1171903104 M * mjt from the description it sounds like the CPU will never idle ;) 1171903116 M * mjt even if there's really nothing to do 1171903172 M * Bertl reg. forcible selected: what kernels? 1171903199 M * mjt 2.6.19[.3] 1171903206 M * mjt moment 1171903207 M * Bertl reg idle time: that might be unclear from the help, it doesn't mean that the cpu is kept busy, it just means that fair scheduling will be enabled 1171903242 M * Bertl i.e. when there _is_ work to be done, but the token buckets are empty, and the idle task would be scheduled, this option artificially advances time 1171903253 M * Bertl (i.e. skips over the idle period) 1171903283 M * mjt i wonder why it's not enabled by default 1171903318 M * mjt ahh. 1171903325 M * mjt it's not time which is selected 1171903341 M * mjt but UTS and IPC namespaces 1171903369 M * mjt i trought(sp) UTS = time ;) 1171903403 M * Bertl UTS is the host name (uname stuff) 1171903408 M * mjt yup 1171903431 M * Bertl the per guest time is something of dubious value 1171903448 M * Bertl typically you do not want per guest system time 1171903471 M * mjt sure thing - that's why i was (wrongly) wondering 1171903585 Q * lilalinux Remote host closed the connection 1171903638 Q * boer Quit: Leaving 1171904093 A * mjt compiles his first vserver-enabled kernel... With all grsec features turned on, too (also for the first time)... ;) 1171904120 M * mjt that should be.. fun to run it for the first time :) 1171904184 M * Bertl will probably fail unless you have a proper guest aware setup (for grsec) 1171904471 M * mjt guest-aware setup. Heh. I'm.. umm.. praying the system -- the host itself -- will boot in the first place :) 1171904475 M * tzafrir can I bind-mount a partition from the host to the guest through the fstab file in the vserver config dir? 1171904607 M * Bertl yes 1171904636 M * Bertl just keep in mind, with the config fstab, the first argument is in host space, while the second is in guest space 1171904660 M * Bertl so if you want to bind mount /vservers/shared to /vservers/guest/shared, you would do: 1171904698 M * Bertl /vservers/shared /shared auto bind 0 0 1171904722 M * mjt or back (auto <=> bind) 1171904727 N * DoberMann DoberMann[PullA] 1171904744 M * Bertl mjt: hmm? 1171904755 M * mjt /vservers/shared /shared bind auto 0 0 1171904776 M * mjt device, mntpt, fstype, flags, ... 1171904782 M * mjt you mixed fstype and flags 1171904790 M * Bertl yes, but the fstype is not bind 1171904795 M * Bertl bind is an option :) 1171904813 M * mjt i thought auto is an option ;) 1171904835 M * mjt at least it's how i always did my bind-mounts -- from-dir to-dir bind auto ... 1171904840 M * Bertl hmm, right, let's agree on 1171904851 M * Bertl /vservers/shared /shared none bind 0 0 1171904866 M * Bertl although the fs field doesn't matter for bind mounts 1171904884 M * mjt augh. 1171904885 M * mjt fs/unionfs/inode.c: In function 'unionfs_link': 1171904885 M * mjt fs/unionfs/inode.c:261: error: too few arguments to function 'vfs_unlink' 1171904907 M * Bertl add ,NULL to any unionfs vfs line 1171904912 M * mjt oh well. another thing to patch 1171904914 M * mjt aha 1171904953 M * mjt thanks! You saved me quite.. some time! 1171904960 M * Bertl you're welcome! 1171905052 Q * Johnnie Server closed connection 1171905068 J * Johnnie ~jdlewis@jdlewis.org 1171905822 J * leon ~leon@82.198.125.154 1171906089 M * mjt blah. Lots of grsec-related unresolved symbols at link time, all over. 1171906116 Q * dlezcano Read error: Connection reset by peer 1171906117 Q * leon Quit: Abandonando 1171906125 M * harry ah 1171906126 M * harry tell me! 1171906139 M * mjt aha. No file in grsecurity/ has been compiled 1171906148 M * harry weirdness++ 1171906154 M * harry what distro are you compiling on? 1171906162 M * mjt does it really matter? :) 1171906164 M * harry debian stable linker fucks up 1171906172 M * mjt it's not a linker issue 1171906179 M * mjt it's some make(file) weirdness 1171906190 M * harry what kernel version? 1171906194 M * harry patch file? 1171906204 M * mjt 2.6.19[.3] 1171906213 M * mjt patch-2.6.19.3-vs2.2.0-rc13.1-grsec2.1.10-20070216.diff 1171906260 M * mjt it's ok 1171906267 M * mjt i mean, the patch's ok 1171906280 M * harry ah, okay : 1171906281 M * harry :) 1171906292 M * mjt for some reason my top-level makefile doesn't contain the hunk that adds grsecurity/ to obj-o 1171906299 M * harry odd... 1171906330 M * mjt to core-y, rather 1171906335 M * mjt s/rather/even/ blah 1171906351 M * harry there are only 2 changes in makefile for gsec 1171906353 M * harry grsec 1171906397 M * mjt first is here (-Wxx) second isn't 1171906410 M * mjt weirdness+++ 1171906411 N * DoberMann[PullA] DoberMann 1171906412 M * mjt ;) 1171906417 M * harry you did use a vanilla 2.6.19.3, right? 1171906435 M * mjt almost - with tons of fixes all over 1171906445 M * mjt ...linked successefully 1171906471 M * harry hmm... probably the patch didn't apply successful on your kernel then 1171906473 M * mjt i don't have a time to dig it right now (maybe it's my scripts) - the patch's ok, it's some local issue 1171906493 M * harry nice to know you got the thing going now 1171906515 M * mjt not yet.. ;) The most interesting part will be to reboot to it now ;) 1171906520 M * harry hehe 1171906540 M * harry well... if any grsec + vserver related problems arise... you know where i am... 1171906564 M * harry right now... at home, but off to shower/restaurant/... 1171906567 M * mjt yeah.. in #kernelnewbies ;) 1171906571 M * harry also, yes : 1171906572 M * harry :) 1171906579 M * harry and in @grsecurity 1171906585 M * harry and in #grsecurity dammit! 1171906619 M * harry and on pulltheplug/kotnet/netric/... ;) 1171906621 M * mjt aha - it was my scripts. Got it. 1171906659 M * mjt it took the wrong top-level makefile to patch LOCALVERSION 1171906736 M * mjt dpkg-deb: building package `kernel-2.6.19-i686vs' in `../kernel-2.6.19-i686vs_2.6.19.3_i386.deb'. 1171907405 M * mjt yay. it panics (invalid ..something in signal handler) when bringing up the network. But it works w/o the network. 1171907435 Q * click Server closed connection 1171907447 J * click click@ti511110a080-0186.bb.online.no 1171907464 M * mjt i'll debug it tomorrow. 1171908705 J * infowolfe_ ~infowolfe@c-67-164-195-129.hsd1.ut.comcast.net 1171908870 Q * tzafrir Quit: Leaving 1171909076 Q * infowolfe Ping timeout: 480 seconds 1171909218 J * |jmcaricand| ~jmcarican@d83-179-176-162.cust.tele2.fr 1171909389 Q * muuhDBXi Ping timeout: 480 seconds 1171909398 Q * Medivh Server closed connection 1171909889 Q * click Ping timeout: 480 seconds 1171909912 J * Medivh ck@paradise.by.the.dashboardlight.de 1171909926 Q * fosco Server closed connection 1171910226 J * fosco fosco@konoha.devnullteam.org 1171911034 J * shedi ~siggi@ftth-237-144.hive.is 1171911145 Q * |jmcaricand| Remote host closed the connection 1171911193 Q * TrueBrain Server closed connection 1171911198 J * TrueBrai_ truelight@openttd.org 1171911215 N * TrueBrai_ TrueBrain 1171911297 J * jmcaricand ~jmcarican@d83-179-176-162.cust.tele2.fr 1171912105 N * DoberMann DoberMann[PullA] 1171912343 J * gerrit ~gerrit@c-67-160-146-170.hsd1.or.comcast.net 1171912488 Q * Radiance Server closed connection 1171912502 J * Radiance 9a4d05407a@halt.1984world.eu 1171912866 Q * Wonka Server closed connection 1171913168 J * Wonka produziert@chaos.in-kiel.de 1171915771 J * yarihm ~yarihm@84-75-123-221.dclient.hispeed.ch 1171916052 M * phedny can the ipv6 patch be applied to a vserver+grsec kernel or will this fail? 1171916106 M * Bertl you have to try 1171916117 M * phedny okay 1171916191 Q * jmcaricand Quit: KVIrc 3.2.4 Anomalies http://www.kvirc.net/ 1171917094 J * DreamerC_ ~dreamerc@125-225-99-212.dynamic.hinet.net 1171917361 J * ema ~ema@lart.galliera.it 1171917501 Q * DreamerC Ping timeout: 480 seconds 1171917702 Q * FaUl Server closed connection 1171917704 J * FaUl immo@shell.chaostreff-dortmund.de 1171917747 M * FaUl have you mooed today btw? 1171917769 M * daniel_hozac what? 1171917791 M * Bertl FaUl: nope, moo :) 1171917797 J * fs fs@213.178.77.98 1171917881 M * FaUl Bertl: excellent! ;-) 1171918276 Q * Roey Server closed connection 1171918297 J * Roey ~katz@h-69-3-4-130.mclnva23.covad.net 1171918753 Q * UukGoblin Server closed connection 1171918765 J * UukGoblin ~jaaa@sr-fw1.router.uk.clara.net 1171919360 Q * neuralis Server closed connection 1171919362 J * neuralis ~krstic@solarsail.hcs.harvard.edu 1171919672 M * cehteh mhm load 2.00 on a 100% idele server .. i'd seen that years ago on a vserver is that still a bug? 1171919691 M * daniel_hozac D processes? 1171919700 M * daniel_hozac (i.e. from oopses or similar) 1171919740 M * cehteh no oopses since boot 1171919747 M * Bertl cehteh: maybe a kernel thread? 1171919760 M * cehteh root 22946 42 0.0 0.0 0 0 ? Z Feb09 0:00 [S90reboot] 1171919760 M * cehteh root 22947 42 0.0 0.0 0 0 ? Z Feb09 0:00 [reboot] 1171919769 M * cehteh mhm 1171919777 M * Bertl here we go ... 1171919787 M * daniel_hozac zombies shouldn't cause any load. 1171919787 M * cehteh root 22460 0 MAIN 0.0 0.0 112 24 ? D Feb09 0:00 /sbin/vnamespace --new -- /sbin/vserver ----nonamespace test start 1171919800 M * cehteh maybe those 1171919808 M * daniel_hozac yep. 1171919816 M * daniel_hozac what kernel is that? 1171919820 M * Bertl daniel_hozac: do we know what causes this? 1171919829 M * daniel_hozac never seen it before, to be honest. 1171919834 M * daniel_hozac (at least, not that i can remember) 1171919835 M * cehteh .20 1171919868 M * cehteh well remember 10 days ago when i had the problem with starting the vserver? 1171919885 M * cehteh still not rebootet and that are artifacts from the testing 1171919905 M * cehteh i think i have the choice to live with it or reboot :) 1171919925 M * daniel_hozac could we get a kernel trace for that process? 1171919936 M * daniel_hozac e.g. via magic sysrq? 1171919949 M * cehteh nope it not on a console 1171919965 M * cehteh (ssh) 1171919968 M * daniel_hozac you can trigger it via /proc/sysrq-trigger 1171919976 M * cehteh session ended days ago 1171920009 M * cehteh how do i select the process? 1171920019 M * daniel_hozac you don't. you'll have to pick it out of the logs. 1171920032 M * cehteh yuk 1171920074 M * cehteh mind when i do that tomorrow .. i dont expect the processes to vanish anytime soon ;) 1171920604 J * marcfiu ~mef@aegis.CS.Princeton.EDU 1171920658 Q * bonbons Quit: Leaving 1171920874 J * dreamind ~dreamind@C2107.campino.wh.tu-darmstadt.de 1171920879 Q * dreamind 1171921390 Q * micah Server closed connection 1171921394 J * micah ~micah@micah.riseup.net 1171921451 J * Aiken ~james@ppp126-23.lns2.bne4.internode.on.net 1171921509 M * Bertl wb micah! morning Aiken! 1171921642 M * Aiken good morning 1171922828 Q * Vudu Server closed connection 1171922831 J * Vudumen 7085956b92@217.20.138.14 1171922993 M * Bertl wb Vudumen! 1171923059 Q * gerrit Ping timeout: 480 seconds 1171924209 J * pflanze ~chris@80-218-220-172.dclient.hispeed.ch 1171924215 M * pflanze Hello 1171924230 J * gerrit ~gerrit@c-67-160-146-170.hsd1.or.comcast.net 1171924343 M * pflanze daniel_hozac: I've created a /etc/vservers//apps/vunify/exclude file, but "vserver hashify" still tries to exec into the package management. 1171924382 M * pflanze (or is this something for you, ensc?) 1171924429 M * pflanze So it's not working as advertised on http://linux-vserver.org/util-vserver:Vhashify 1171924740 M * daniel_hozac as expected, i guess. 1171924787 M * pflanze Well you did expect otherwise back then. 1171924804 M * daniel_hozac i didn't look at the code :) 1171924816 P * marcfiu 1171924952 M * daniel_hozac i don't see any way to stop it from running vpkg for vhashify/vunify. 1171925027 M * pflanze I don't like this very much for two reasons: 1171925047 M * pflanze [(a) security risk? (still not sure)] 1171925057 M * daniel_hozac how so? 1171925068 M * pflanze (b) I've got some vservers which haven't been running for quite a long time, 1171925087 M * pflanze not I'd just like to unifiy them to make space. No reason to start them up. 1171925096 M * daniel_hozac you can still hashify them manually. 1171925105 M * pflanze ah 1171925116 M * daniel_hozac or you know, use rpm-based guests ;) 1171925121 M * pflanze hm 1171925167 M * pflanze What's different with rpm-based guests? 1171925180 M * daniel_hozac you can use external package management. 1171925195 M * daniel_hozac which does not require the guest to run to query for configuration files. 1171925280 M * pflanze hm, me thinks, who cares about rpm being 100% safe in a normal setup? 1171925300 M * daniel_hozac what? 1171925335 M * pflanze in a normal setup files being read by rpm are owned by root. so no danger from buffer overflows etc. 1171925357 M * pflanze But here the files are owned by vserver guests. But read from an rpm on the host, if I understand correctly. 1171925374 M * daniel_hozac "owned" meaning associated with? 1171925378 M * pflanze yes 1171925397 M * daniel_hozac the guest does not have access to the rpm database. 1171925401 M * daniel_hozac it's external. 1171925405 M * pflanze ah 1171925599 M * daniel_hozac could you elaborate on "23:44 < pflanze> [(a) security risk? (still not sure)]"? 1171925778 M * pflanze daniel_hozac: Feb 08 17:11:25 iirc "vserver ... start" has been considered safe, "vserver .. enter" not. 1171925793 M * pflanze Maybe it's not true anymore. 1171925809 M * pflanze I just never heard any status change about this. 1171925823 M * pflanze except from you, 1171925826 M * pflanze Feb 08 17:11:41 AFAIK it's safe. 1171925857 M * daniel_hozac so what, in your mind, makes exec insecure that start avoids? 1171925875 M * pflanze (BTW actually only about a day later I ran into the problem with the struct refcount problem and actually it turned out that vserver exec *was* unsafe...) 1171925892 M * pflanze (of course, because of a bug.) 1171925895 M * Bertl off for dinner now ... back later ... 1171925899 M * pflanze (but still..) 1171925901 N * Bertl Bertl_oO 1171925929 M * daniel_hozac the refcount problem could make processes already in the guest suddenly be outside. 1171925954 M * daniel_hozac really, when refcounting goes bad, anything can happen. 1171925972 M * pflanze yes. actually vserver start probably has been unsafe as well. 1171925995 M * pflanze well, *I* don't know what's the difference between the two. Let me check the irc logs. 1171926872 M * pflanze Hm I didn't find what I had in remembrance yet, but this interesting piece: Feb 01 14:11:51 2007 starting the guest is required before using it is fully secure. that's why you need vserver ----insecure ... exec ... to run programs in stopped guests. (...) 1171926914 M * pflanze My leftover "vserver exec is unsafe" may well be from the time when vserver exec didn't check whether the vserver was running. 1171927492 M * pflanze So I probably thought, and saved in my brain, that the kernel context change part was unsafe with exec while in fact Bertl/co have meant only that using vserver exec on non-running vserver is unsafe. 1171927622 Q * ensc Ping timeout: 480 seconds 1171927637 Q * yarihm Quit: Leaving 1171928326 Q * Aiken Quit: Leaving 1171929076 Q * mnemoc Ping timeout: 480 seconds 1171929113 N * DoberMann[PullA] DoberMann 1171929192 J * mnemoc ~amery@kilo105.server4you.de 1171929192 Q * meandtheshell Quit: Leaving. 1171929257 N * DoberMann DoberMann[ZZZzzz]