1141344648 M * Bertl hey micah!
1141345083 Q * shedi Quit: Leaving
1141345284 J * Doener ~doener-of@i5387D439.versanet.de
1141346651 J * rs ~rs@vol75-7-82-229-177-124.fbx.proxad.net
1141346666 M * rs hi there
1141347000 M * Bertl hey
1141347105 M * Doener hm, interesting... just switched to debian and replacing the stock debian kernel by a selfmade one cut kernel compilation time by 50%
1141347129 M * Bertl lol
1141347143 M * Doener from 4min to 1:50...
1141347153 M * mugwump from what version to what?
1141347167 M * Doener 2.6.12-whatever to 2.6.15.5
1141347184 M * Doener both k8, both smp...
1141347191 M * mugwump same config?
1141347201 M * Doener NO!
1141347212 M * mugwump I mean, the builds ...
1141347242 M * Doener hm? kernel config I assume?
1141347251 M * mugwump well, anyway, I guess there were a few big improvements between those two kernel version
1141347254 M * mugwump s
1141347257 M * Doener ah, I guess I got it now...
1141347286 M * mugwump but, building a debian kernel will always take longer because of the ~allmodconfig
1141347291 M * Doener i just rebuilt the kernel another time after reboot, because I wondered that it took so long on debian
1141347313 M * Doener so the builds were done with the same config, but the kernel running had of course a different config
1141347346 M * Bertl wouldn't be very fair to build one with allnoconfig and the other with allyesconfig :)
1141347438 M * mugwump that's a huge difference.  I guess the question is, is it a different story between stock 2.6.12 and 2.6.15.5 ?
1141347460 M * mugwump or, whether that matters, given debian is always so friggin' out of date
1141347465 A * mugwump jumps on the bandwagon
1141347531 M * Doener AFAICT the 'major' changes in the config were from kernel preemp on to off and HZ from 1000 to 100
1141347679 M * mugwump ... and the iosched
1141347704 M * mugwump iosched apparently can make a huge difference
1141347705 M * Doener unchanged
1141347715 M * mugwump well, it wasn't in 2.6.12, was it ?  :)
1141347788 M * Doener uhm, no idea how the 2 went in there... it was 2.6.15-whatever
1141347798 M * mugwump oh
1141347816 M * mugwump well, that's even more incredible
1141347826 M * mugwump I mean, surprising
1141347913 M * mugwump high HZ shouldn't hurt that bad, esp. on a screamingly fast system like that
1141347986 M * Doener maybe I'll spend some time recompiling and rebooting later
1141350221 M * Doener mugwump: hm, I checked the logs, there were messages about "Losing too many ticks" with the debian kernel, could that be related?
1141350253 M * Bertl with the HZ, yes
1141350270 M * mugwump I guess that means it's queueing
1141350297 M * mugwump did you use make -j ?
1141350302 M * Doener -j4
1141350499 M * mugwump worth logging as a bug, I'd say.  >250 as a default is just silly.
1141350509 M * mugwump if that's the problem
1141350588 M * mugwump though I would have thought the interrupts should still get serviced regardless; unless something was holding a non-preemptable lock a lot, like an IO driver
1141350871 Q * f_ Quit: This computer has gone to sleep
1141353184 M * mugwump eek, $chargable_work took so long today!  It's almost beer o'clock
1141353443 M * Bertl lol
1141353492 M * mugwump so, should I submit my vserver-inclusion patch under the name "task namespaces" ?
1141353573 M * mugwump this would make things like vx_info, task_ns
1141353641 M * Bertl hmm ...
1141353659 M * Bertl more a context or container or permission namespace, no?
1141353680 M * mugwump "context" is overused
1141353688 M * mugwump "container" is a brand, not a term IMHO
1141353689 M * Bertl in what context? :)
1141353693 M * mugwump :)
1141353709 M * Bertl well, what about 'bottle'?
1141353737 M * mugwump Well, namespaces are already there as `filesystem namespaces'
1141353745 M * mugwump (obviously ;))
1141353748 M * Bertl matches nicely with beer which can be related to the free/beer/speech stuff
1141354024 J * Hmmmm ~Hmmmm@221.135.51.19
1141354046 M * Bertl Hmm ...
1141354127 M * mugwump "vx" is nice, when you look at functions like "vx_task_xid"
1141354747 M * Bertl that's why I used them :)
1141354788 M * mugwump I'm just trying to think of the poor VM subsystem maintainer, for whom vx_ is going to imply something different
1141354812 M * mugwump actually the functions starting with vx_info_ look good still as task_ns_
1141354990 M * Bertl yeah, but IMHO task_ is a bad choice
1141355006 M * Bertl because it reminds me of tasks, but it is not task related at all, no?
1141355019 M * mugwump I don't understand that, it's grouping tasks
1141355050 M * Bertl well, maybe we mean different things ...
1141355065 M * Bertl for me the pid_ns or pid_space or whatever groups tasks
1141355080 M * Bertl and the vx_info is definitely not pid related
1141355114 M * mugwump no, it's task_struct related
1141355125 M * mugwump pid_space / pid_ns would be something again
1141355131 M * Bertl _all_ spaces are task struct related
1141355146 M * Bertl so that is something you can prepend to each of them
1141355154 M * Bertl task_pid_space, task_pid_ns
1141355212 M * Bertl anyway, I'm off to bed now .. so I leave you with your hard decisions :)
1141355232 M * Bertl have a good whatever everyone .. cya tomorrow!
1141355234 M * mugwump night!
1141355240 N * Bertl Bertl_zZ
1141355928 Q * pflanze Quit: [x]chat
1141356041 Q * matta Ping timeout: 481 seconds
1141356595 Q * Hmmmm Ping timeout: 480 seconds
1141359223 Q * Doener Quit: leaving
1141360394 Q * wally Ping timeout: 480 seconds
1141363342 J * Hmmmm ~Hmmmm@221.135.51.19
1141363594 M * Hmmmm hi guys, im having some trouble with vservers. i get the following error:
1141363596 M * Hmmmm Setting network parameters:  error: unknown error 1 setting key 'net.ipv4.ip_forward'
1141363998 M * Hmmmm hi, anyone home?
1141364226 J * f_ ~fwl@83-215-237-1.seek.stat.salzburg-online.at
1141365005 M * Hmmmm Hi Bertl_zZ u there?
1141367040 Q * f_ Ping timeout: 480 seconds
1141368704 Q * Aiken Ping timeout: 480 seconds
1141369014 P * Hmmmm Ex-Chat
1141373208 J * ||Cobra|| ~cob@pc-csa01.science.uva.nl
1141373561 J * dothebart ~willi@xdsl-213-196-255-29.netcologne.de
1141373984 Q * tudenbart Ping timeout: 480 seconds
1141374065 Q * rs Quit: rs
1141374635 Q * fh Quit: changing servers
1141374811 J * fh fiona@cheeto.net
1141374871 Q * fh Remote host closed the connection
1141375566 J * fwl ~fwl@83-215-237-1.seek.stat.salzburg-online.at
1141377222 J * Hmmmm ~Hmmmm@221.135.51.19
1141378590 Q * fwl Quit: This computer has gone to sleep
1141378692 J * fwl ~fwl@83-215-237-2.seek.stat.salzburg-online.at
1141378892 M * Hmmmm hullo guys
1141379110 M * daniel_hozac hi
1141379164 M * Hmmmm daniel_hozac, im facing some problems with vservers
1141379173 M * Hmmmm i get this error while starting my vserver
1141379200 M * Hmmmm actually i lost the error msg
1141379209 M * Hmmmm but its something about ipv4.forward
1141379214 M * daniel_hozac Setting network parameters:  error: unknown error 1 setting key 'net.ipv4.ip_forward' ?
1141379222 M * Hmmmm righto
1141379235 M * daniel_hozac why is your guest trying to do that in the first place?
1141379235 M * Hmmmm any idea about what i did wrong?
1141379240 M * Hmmmm i dunno
1141379247 M * Hmmmm do i need to change somethng in the kernel config?
1141379247 M * daniel_hozac it's not something a guest can do.
1141379257 M * daniel_hozac no, you need to change something in the guest config.
1141379267 M * Hmmmm ok, like what?
1141379269 J * Smutje_ ~Smutje@xdsl-87-78-4-5.netcologne.de
1141379284 M * daniel_hozac disable that initscript, for instance.
1141379291 M * Hmmmm where's that?
1141379332 M * daniel_hozac i wouldn't know, considering you haven't even told us what distro is in that guest.
1141379364 M * Hmmmm my host is centos4, and my guest is a skeleton based on the host itself
1141379374 Q * Smutje Ping timeout: 480 seconds
1141379374 N * Smutje_ Smutje
1141379380 M * daniel_hozac chkconfig network off then.
1141379392 M * daniel_hozac you really ought to use vserver ... build -m yum -- -d centos42.
1141379401 M * daniel_hozac it will clean up the guest properly.
1141379402 M * Hmmmm ok i'll try that (am just reinstalling the machine to start from scratch)
1141379422 M * Hmmmm daniel_hozac, but wou'dn -m yum use internet access?
1141379430 M * daniel_hozac depends on the configuration.
1141379439 M * Hmmmm what configuration?
1141379440 M * daniel_hozac you could obviously point it at a local repository.
1141379445 M * Hmmmm ah okay
1141379446 M * daniel_hozac the yum configuration
1141379454 M * Hmmmm but i would like to build my guest based on the host
1141379472 M * Hmmmm so i asked herbert and he suggested i use skeleton and then copy stuff into it
1141379767 M * Hmmmm should i enable " IP: policy routing" while ocmpiling the 2.6 kernel?
1141380058 M * daniel_hozac if you do that, you'll have to see to it that the guest is cleaned yourself.
1141380084 M * daniel_hozac read the help, i haven't configured a kernel for months.
1141380094 M * Hmmmm daniel_hozac, ok will do that. thanks
1141380112 M * daniel_hozac sorry, gotta run.
1141380115 M * Hmmmm would you know if there is a rpm version of the centos kernel for vservers?
1141380120 M * Hmmmm ok thanks anyway
1141380122 M * Hmmmm ttfn
1141380133 M * daniel_hozac no, the RHEL kernel is too old.
1141380147 M * Hmmmm ah ic
1141380147 M * daniel_hozac i'm using the Fedora kernels on one of my CentOS boxes.
1141380158 M * Hmmmm and it works fine?
1141380162 M * daniel_hozac seems to.
1141380166 M * Hmmmm cool
1141380205 M * daniel_hozac http://rpm.hozac.com/dhozac/fedora/4/vserver/i386/ if you want to try yourself.
1141380470 J * wam ~wigwam@p549DEB08.dip.t-dialin.net
1141380493 M * wam Hi! Is there already a patch a gainst 2.6.15.5?
1141380517 M * Hollow no, but did you try the patch for 2.6.15.4 maybe it applies cleanly
1141380536 M * wam Where do I find it? I already looked at http://www.13thfloor.at/vserver/s_rel26/v2.01/
1141380545 M * Hollow http://vserver.13thfloor.at/Experimental/
1141380564 M * wam should I use this on a production-server?
1141380580 M * Hollow the 2.0.* patches should be fine imo
1141380580 J * Viper0482 ~Viper0482@p5497681B.dip.t-dialin.net
1141380584 M * Hmmmm daniel_hozac, thanks
1141380588 M * wam ok - I'll try. Thanks!
1141380588 M * Hollow but don't use the 2.1.* ones yet
1141380592 M * wam ok
1141380750 M * wam So is patch-2.6.15.4<font size="3">-vs2.0.2-rc10.diff best?</font>
1141380760 M * wam whops - html?!
1141380776 M * wam So is patch-2.6.15.4-vs2.0.2-rc10.diff best?
1141380834 M * Hollow yup
1141380871 M * wam for 2.6.12 I needed also the "delta-vroot"-patch. Is this already included?
1141380887 M * Hollow i think so ;)
1141380918 M * teukka is there any development between 2.0.1 and 2.0.2 other than porting to new kernel version?
1141381265 M * teukka ah, at least bme patches seem to be included?
1141381416 M * Hollow teukka: deltas can be found at http://vserver.13thfloor.at/Devel/PAT-2.0.2/ but they are not up to date with rc10
1141381450 M * teukka ok, thx
1141381453 M * Hollow you can also find some deltas in the Experimental/ dir
1141383398 N * Bertl_zZ Bertl
1141383402 M * Bertl morning folks!
1141383786 M * Hmmmm hi Bertl 
1141383793 M * Hmmmm got a question for you
1141383815 M * Hmmmm i caught u a few days back here on irc to help me build a skeleton-based vserver
1141383833 M * Hmmmm quick question, do i copy the /proc from the host machine or not?
1141383982 M * cehteh you mount /proc in the guest ... better the vserver tools do that for you
1141383990 M * Bertl precisely
1141384043 M * cehteh is the same supported for sysfs?
1141384109 M * Hmmmm so i don't dump the /proc from the host to the template?
1141384159 M * cehteh no
1141384284 J * shedi ~siggi@inferno.lhi.is
1141384350 M * Hmmmm ok lemme try 
1141384746 M * Hollow morning Bertl!
1141384788 M * Bertl hey Hollow!
1141384996 J * Dr4g Dr4g@82-40-43-245.cable.ubr06.uddi.blueyonder.co.uk
1141385273 Q * Dr4g Quit: 
1141385318 Q * Hollow Remote host closed the connection
1141385372 J * rs ~rs@APuteaux-151-1-40-16.w82-124.abo.wanadoo.fr
1141385405 J * Dr4g ~Dr4g@82-40-43-245.cable.ubr06.uddi.blueyonder.co.uk
1141385425 M * Hmmmm Bertl, i have a few errors while starting my vserver
1141385436 Q * Dr4g Quit: 
1141385456 M * Hmmmm Bertl, can you pls take a look here: http://pastebin.com/581720
1141385471 M * Bertl sure, sec
1141385537 M * Bertl hmm, yeah, you have a few issues there ...
1141385546 M * Hmmmm wait i solved a few
1141385573 M * Bertl first, you should not copy the proc that is right, but you have to copy the /proc dir where proc is mounted (or just create it with mkdir)
1141385588 M * Hmmmm http://pastebin.com/581722
1141385599 M * Bertl second, you should remove any network or hardware related scripts
1141385606 M * Hmmmm ah okay
1141385631 M * Bertl this includes (but is not limited to) the networking, irqbalance, kernel logger
1141385660 M * Hmmmm how do i find out whic hscripts are to be removed?
1141385807 M * Hmmmm Bertl, can u give me an example of a file i should remove please?
1141385858 M * cehteh Hmmmm: which distri do you use?
1141385867 M * Hmmmm centos 4
1141385888 M * Bertl Hmmmm: easiest way is the following:
1141385888 M * Hmmmm vservers/min-centos4/etc/rc[06].d/K90network ?
1141385889 M * cehteh i dont know that
1141385901 M * Hmmmm Bertl, im listening
1141385912 M * Bertl ls /etc/rc.d or /etc/init.d
1141385929 M * Bertl then think about what the various scripts might be designed for
1141385939 M * Bertl e.g. pcmcia will be?
1141385955 M * Hmmmm okay
1141385967 M * Bertl right, cardbus/pcmcia setup, so hardware
1141385977 M * Bertl then check out
1141385983 M * Bertl chkconfig --list
1141385986 M * Hmmmm K02NetworkManager ?
1141385988 M * Bertl (again inside)
1141385993 M * Hmmmm ok
1141386057 M * Hmmmm say i remove  S10network. will my network not stop working inside the vserver?
1141386086 M * Bertl nope
1141386091 M * cehteh mhm .. my usual way to make a template server is debootstrap, then dselect and remove any package which is not required and but any important/required package which does natworking or hardware on hold .. 
1141386097 M * Bertl Hmmmm: networking is done/configured on the host
1141386119 M * Bertl Hmmmm: btw, you can remove services with chkconfig too
1141386121 M * Hmmmm Bertl, but i need the vserver to have a specific IP address and be able to work as a separate server
1141386133 M * cehteh i thinnk that applicable to other distris too if there is some package manager
1141386204 M * cehteh too bad that most didtributions dont offer a kernel/hardware independent base install
1141386208 M * Hmmmm Bertl, if i remove the network capabilities from indie the vserver, how will it interact with other machines?
1141386238 M * Bertl perfectly fine, because networking happens on the host, which is already configured
1141386249 M * Bertl i.e. it will add IPs and routes and stuff for your guest
1141386282 A * cehteh delegated some hardware handling (scanner printer) to a vserver ... but that bit more tricky to set up
1141386291 M * Hmmmm ah okay ic
1141386359 M * Hmmmm ok i removed the network from startup and i already lost a lot of error messages
1141386374 Q * rs Quit: rs
1141386483 M * Hmmmm what do i do about the fstab that i copied into the guest from the host?
1141386668 M * Bertl the fstab inside the guest can be removed
1141386780 M * Hmmmm Bertl, but won't it complain while starting?
1141386816 M * Hmmmm anyway im giving it a shot
1141386842 M * Hmmmm getting this error while stop: "umount: /tmp: must be superuser to umount"
1141386868 M * Bertl same issue, your guest 'tries' to unmount stuff
1141386881 M * Hmmmm so what do i do?
1141386884 M * Bertl you might want to cleanup the shutdown script
1141386890 M * Hmmmm ah okay
1141386896 M * Bertl i.e. remove hardware related stuff again, and mounts
1141386898 M * Hmmmm which wud that be?
1141386924 M * Bertl don't know centos here, but look for something in rc.0 
1141386934 M * Bertl or rc.6
1141386937 M * Hmmmm okay
1141387090 M * Hmmmm anyways, Bertl thanks a lot. my day's over out here
1141387100 M * Hmmmm will continue efforts tom
1141387107 M * Hmmmm thanks to u too, cehteh 
1141387141 Q * Hmmmm Quit: Ex-Chat
1141387814 M * Bertl sorry folks, I have to try this: startkeylogger stopkeylogger
1141387840 M * Bertl startkeylogger
1141387865 M * Bertl okay, seems no windows/symantec folks here :)
1141387888 M * Bertl http://it.slashdot.org/article.pl?sid=06/03/03/004215
1141388978 A * RoadRunnR slaps Bertl with a keylogger ;-)
1141389016 M * Bertl meep meep!
1141389032 M * RoadRunnR wusssssssccccchhhhh ... ;-)
1141389048 M * Bertl :)
1141389130 M * harry Can't load '/usr/lib/perl5/auto/Locale/gettext/gettext.so' for module Locale::gettext: /usr/lib/perl5/auto/Locale/gettext/gettext.so: cannot enable executable stack as shared object requires: Permission denied at /usr/lib/perl/5.8/DynaLoader.pm line 225.
1141389146 M * harry why the fuck would we want an executable stack? i don't want that!
1141389202 M * waldi you run unsupported kernel modifications
1141389226 M * harry so
1141389237 M * harry is that a reason to want executable stack?
1141389243 J * PilatomiK ~tek@ADijon-151-1-108-168.w83-203.abo.wanadoo.fr
1141389275 M * harry you sound like a commercial support service
1141389306 M * waldi at least on my machine, this file does not request executable stack
1141389323 M * PilatomiK hi
1141389370 M * harry waldi: yes it does
1141389376 M * harry you just allow executable stack
1141389381 M * waldi use harry use objdump -x $file and look at the STACK definition in the program headers
1141389442 M * Bertl hum, waldi you're sure you perl DynaLoader does not allocate the stack on the fly?
1141389495 M * waldi Bertl: this is a error message from ld.so
1141389525 M * waldi it does strict checking since 2.3.5
1141389540 M * Bertl was perl included in ld.so lately?
1141389548 M * Bertl Permission denied at /usr/lib/perl/5.8/DynaLoader.pm line 225.
1141389552 M * waldi ld.so or -ldl
1141389559 M * harry it did work in the non-grsec'ed kernel
1141389582 A * harry doesn't see what this is needed
1141389584 M * waldi Bertl: perl calls dlopen, dlopen fails and perl reports the location of the failure
1141389645 M * Bertl well, I don't know what it does in DynaLoader.pm line 225 :)
1141389688 M * harry Setting up libc6 (2.3.5-13) ...
1141389689 M * harry mv: error while loading shared libraries: libacl.so.1: cannot enable executable stack as shared object requires: Permission denied
1141389692 M * harry pretty annoying :s
1141389721 M * harry anyone that has a sollution? or do i HAVE to remove all non-exec pages support
1141389776 M * Bertl harry: recompile the userspace stuff or fixup the elf headers
1141389833 M * harry util-vserver?
1141389999 M * Bertl well, more *libc :)
1141390109 M * harry :S
1141390129 M * harry strange thing is... in my previous kernel (grsec + vserver), there was no problem
1141390142 M * Bertl probably the relevant parts were disabled
1141390238 M * harry Starting MTA: /usr/sbin/exim4: error while loading shared libraries: libgcrypt.so.11: cannot enable executable stack as shared object requires: Permission denied
1141390242 M * harry haha
1141390256 M * harry every fucking piece of software seems to need an executable stack
1141390262 M * harry wtf!!!
1141390777 M * wam Are there known problems with util-vserver 0.30.209 and v2.01? I would upgrade to util-vserver 0.30.210, but in sid 209 is the latest version - so that'll have to do it for a few days. But if there were problems, I'd compile the utils from scratch.
1141390929 M * wam Waaaaa - since when does vserver have SMP support inside the vservers? I used to have only 1 cpu inside.
1141391026 M * Bertl lol
1141391040 M * Bertl well, 0.30.209 should work, even from sid :)
1141391068 M * wam ok - thanks. This is so cool to have smp in my vservers ;)
1141391136 M * Bertl I assume you did a kernel update lately
1141391148 M * wam yeah - from 2.6.12 to 2.6.15-5
1141391162 M * Bertl SMP was probably disabled in your older kernel
1141391173 M * wam no, on the host I had 2 cpus.
1141391194 M * wam s/host/root server/
1141391293 J * rs ~rs@APuteaux-151-1-40-16.w82-124.abo.wanadoo.fr
1141391346 M * Bertl wam interesting ...
1141391351 M * Bertl welcome rs!
1141391352 M * wam but that's not so important. More important is that I disabled preemption. I hope, I'll get a step closer to wiping out those short hangs in the network-interfaces...
1141391386 M * Bertl what kind of hangs do you experience?
1141391403 M * wam Ok - that'll take a while ;)
1141391646 J * glen_ ~glen@elves.delfi.ee
1141391661 M * glen_ lsof doesn't work under vserver because it can't open /proc/mounts
1141391674 M * glen_ should i vprocunhide /proc/mounts or is there alternative way?
1141391691 M * glen_ btw, why is /proc/mounts not unhiden by default, what bad could it cause?
1141391715 M * Bertl proc mounts should be unhidden by default
1141391734 M * Bertl well, it is a symlink to your process
1141391892 M * wam Bertl: ready for the story?
1141391931 M * Bertl glen_: and it is visible on my guests here ...
1141391944 M * Bertl glen_: maybe give testme.sh a try and upload the output somewhere?
1141391949 M * Bertl wam: sure ...
1141391950 M * wam I have a cronjob with "wget myserver", which checks if httpd is alive. This job checked httpd on the rootserver AND on some vservers. There wasn't a problem for months.
1141391961 M * wam But when I moved the httpd from the rootserver to another vserver, I had hangs on the network - sometimes it was only one connection that didn't come through and sometimes it took a few minutes without traffic. In this time I also couldn't connect via ssh to the rootserver. There were/are about 6-10 hangs a day.
1141391978 M * wam So I began to debug the problem and started a ping > logfile from the rootserver to altavista.com (=random host). Every second 1 ping. As long as the ping ran (2 days), I had NO hangs. So it seams that WHEN there is constantly traffic, the network is ok.
1141391995 M * wam Next I dumped "ifconfig" and "route -n" once per minute to a logfile. The hangs happened! But all interfaces were up and running during the problems. There was even traffic logged on eth0! So it seams that only single packets are destroyed.
1141392013 M * wam Right now, I just upgraded to 2.6.15-vs201 to see, if it was just some bug. If this will not help, I'll see, if I can log vast amounts of iptables-warnings. Maybe it's some anti-ddos-setting or so that I've overseen.
1141392057 M * wam But the strange thing is, that it started when I shut down the last service (except sshd) on the root-server.
1141392147 M * Bertl sounds more like bad connectivity to me, but we will see
1141392172 M * wam could be
1141392194 M * wam Debugging such things just takes so much time... You always have to wait, if the hang comes or not.
1141392237 M * Bertl yes, but from your description, it sounds like tcp retries
1141392277 M * Bertl if you encounter the issue again, and lowering the mtu to 576 or so improves it, I would suggest having a talk with your network provider :)
1141392305 M * wam You mean THEY throw away packets due to fragmentation or so?
1141392456 M * wam but your words inspire me: I'll log the whole network-traffic on the server (with some filter).
1141392752 M * eyck am I right that vserver was thoghourly tested on AMD64?
1141392782 M * glen_ baggins: hmm, maybe i have broken setup
1141392783 J * JimmyGulp ~james@ns0.esagroup.co.uk
1141392812 M * glen_ Bertl: hmm, maybe i have broken setup
1141392818 M * glen_ baggins: you fix it! :)
1141392822 Q * shedi Read error: Connection reset by peer
1141393013 J * wally ~homebase@62.116.83.242
1141393019 M * glen_ grep -c mount /usr/lib/util-vserver/defaults/vprocunhide-files
1141393019 M * glen_ 0
1141393155 Q * _mountie Remote host closed the connection
1141393438 M * JimmyGulp Howdy :) I'm fiddling with vserver to try and consolodate some of our quieter machines into one (more powerful) box (save power and space, etc). the old machines are RH 7.2. I simply copied all the bin, etc, usr and whatnot to the vserver machine, and got it running, but for some reason, I can't get inn to run properly. I've checked the permissions with the original server, and they're all fine, but I just get this in the news.err log: "innfeed[xxx]
1141393438 M * JimmyGulp : seteuid(0) failed: Operation not permitted" (xxx is the PID). Is there any reason why it shouldn't be able to seteuid to 0? (I assume its to get hold of port 119)
1141393760 M * JimmyGulp (I'm running linux 2.6.15 with the vserver 2.0.2-rc9 patch
1141393818 J * shedi ~siggi@inferno.lhi.is
1141393827 M * Bertl welcome JimmyGulp!
1141393837 M * JimmyGulp Bertl, hi :)
1141393855 M * Bertl JimmyGulp: strange issue, please check the bcaps
1141393859 M * JimmyGulp I'm just seeing if its trying to bind to the wrong IP, it takes a while to start :)
1141393873 M * Bertl i.e. inside the guest do:
1141393889 M * Bertl grep Cap /proc/self/status
1141393918 M * Bertl do this as user and as root
1141393967 J * restill ~restill@24.11.171.10
1141393989 M * JimmyGulp for the news user (the one inn runs as), CapInh, CapPrm, CapEff are all set to lots of 0's
1141394096 M * JimmyGulp and for roo, CapInh = 0, CapPrm = 00000000344c04ff (same for CapEff)
1141394096 M * JimmyGulp s/roo/root
1141394096 M * Bertl and for the root user?
1141394096 M * Bertl welcome restill!
1141394111 M * Bertl JimmyGulp: maybe the innfeed is a suid root app, which lost it's suid flag?
1141394126 M * restill Hey there.  I am excited.  I am running the 64bit SMP kernel
1141394143 M * Bertl JimmyGulp: see seteuid manpage for details ...
1141394155 M * Bertl restill: congrats, how many CPUs?
1141394191 M * restill 1 dual core athlon.  Its an Athlon 2X 3800
1141394208 M * restill Seems to be running fine
1141394248 M * Bertl with 64bit guests or 32bit ones?
1141394283 M * restill I haven't got that far yet.   I am doing the painfully long 1st yum update after the install.
1141394295 M * Bertl ah, k
1141394336 M * restill The first thing I installed was kernel-smp-2.6.13-1.1532_FC4.vs2.0.1.0.pre2.1.x86_64.rpm and rebooted.  It worked
1141394493 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net
1141394507 Q * rs Quit: rs
1141394714 M * JimmyGulp d'oh, think i had one of the suid files owned by the wrong person :) lets see if this works now :)
1141394773 M * Bertl restill: great!
1141394796 M * Bertl restill: test with testme.sh and testfs.sh (if you want to share your joy) and post it to the ML :)
1141394812 M * restill I will.
1141394824 M * JimmyGulp aha, different error now, just a config mess up :)
1141394924 M * Bertl JimmyGulp: good, so if you ahve a working system, just compare the settings/flags
1141394946 M * Bertl JimmyGulp: might be that you used tar or rsync without the --numeric-uid flags
1141394967 M * Bertl (which will have adjusted your ownership somewhat :)
1141395019 M * JimmyGulp :)
1141396200 J * pagano ~pagano@lappagano.cnaf.infn.it
1141396220 M * pagano hi guys, question of the day :)
1141396308 M * pagano on Host System i have 2 guest with public ip, but when i configure them with sshd and i connect to them 
1141396328 M * pagano i access to host machine
1141396341 M * daniel_hozac restill: that's an ancient kernel, you know.
1141396347 M * pagano i have change ListenAddress 
1141396365 M * JimmyGulp pagano, you need to configure the ListenAddress on the hosts sshd_config too (incase you haven't) (and restart sshd)
1141396367 M * daniel_hozac restill: 2.6.15-1.1833_FC4.vs2.0.2.0.rc10.1 was pushed this morning.
1141396372 M * pagano in /etc/ssh/sshd_config 
1141396377 M * pagano yes yes i have done it
1141396392 M * JimmyGulp have you restarted sshd following that change?
1141396409 M * pagano yes, but maybe i have done an error...
1141396414 M * Bertl pagano: which ListenAddress did you change, the one of the host or  guest?
1141396420 M * pagano i have change /etc/ssh/sshd_config in GUEST
1141396428 M * pagano right?
1141396429 M * Bertl that's wrong
1141396434 M * pagano opppps :P
1141396437 M * Bertl you only have to limit the host :)
1141396448 M * Bertl the guests are automagically limited to their subset
1141396485 M * pagano ok, i'm trying
1141396809 M * pagano uhmmm
1141396831 M * pagano i must no have sshd on guest right? all on host
1141396868 J * Roey ~katz@h-69-3-4-130.mclnva23.covad.net
1141396886 M * Bertl welcome Roey!
1141396891 M * Roey hello Bertl!!
1141396899 M * Roey what's new by you?
1141396908 M * Bertl pagano: no, you can have as many sshd's as you like
1141396909 M * Roey wass ist neue bei Dir?
1141396924 M * pagano and on host can i have more ListenAddress lines? (one for only vserver that i have configured and that i want to connect)
1141396931 M * Bertl Roey: we recently switched to english on the cahnnel :)
1141396939 M * JimmyGulp pagno: you need an sshd on each server that you're going to want to ssh to. The host ssh needs to be limited to the hosts IP. the guests don't need that configuring, they can only see their own IP anyway.
1141396942 M * daniel_hozac recently? :)
1141396971 M * Roey Bertl:  aber ich kann nur Deutsch
1141396975 M * Bertl daniel_hozac: well, it seemed to me he didn't know :)
1141397015 M * JimmyGulp pagano, you should have a ListenAddress line for each IP that the host sshd will listen on (generally, its own ip, and 127.0.0.1). DO NOT set it to listen on the IPs used by the guest servers.
1141397142 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com
1141397156 M * Bertl welcome mountie!
1141397228 M * mountie Bertl: Man, you are quick... Every single time I drop my connection, I'm welcomed back as soon as I reconnect ;-)
1141397248 M * Bertl it's part of the service :)
1141397635 M * restill is there a 64 bit util-vserver rpm?
1141397655 M * daniel_hozac not that i'm aware of.
1141397671 M * restill ok I just got the src.rpm.
1141397721 M * restill I don't usually compile from rpm.  what are the best arguments for rpmbuild?
1141397747 J * mnemoc ~amery@user4-2.tutopia-dialup.ifxnw.cl
1141397809 M * daniel_hozac mkdir -p ~/rpms/{RPMS/i686,RPMS/i386,RPMS/noarch,SRPMS,BUILD,SOURCES,SPECS}; rpmbuild --define '_topdir ~/rpms' --rebuild ...src.rpm
1141397836 M * restill wow.  ok.  TY
1141397844 M * daniel_hozac you'll have to expand ~/rpms in the --define manually.
1141397922 M * daniel_hozac i guess you'll want RPMS/x86_64 too, btw.
1141398330 M * restill I am running the smp 64 now, but  I will compile the newer version today sometime.
1141398426 J * brc bruce@20151181056.user.veloxzone.com.br
1141398516 M * Bertl welcome brc!
1141398541 M * Bertl hey mnemoc! almost missed you :)
1141398633 M * restill ok so it is compiling now.  Does it also install it?
1141398664 M * daniel_hozac no.
1141398681 M * daniel_hozac it'll put the built RPMs in ~/rpms/RPMS/<arch>.
1141398714 M * restill Yes, I just found them
1141398715 M * wam Why could my quota inside a vserver not work anymore after upgrading to v2.01 / util-vserver 0.30.209?
1141398721 M * restill cool
1141398732 M * wam Error is (/etc/init.d/quota start): quotaon: using //aquota.group on /dev/hdv1 [/]: Invalid argument
1141398743 M * daniel_hozac wam: did you run vrsetup?
1141398750 M * wam no?
1141398757 M * wam Ah - i think yes
1141398773 M * wam mompl
1141398818 M * wam is :/etc/vservers/SERVERNAME/scripts/prepre-start.d still started?
1141398837 M * daniel_hozac yep
1141398911 M * wam so it is still executed.
1141398918 M * wam vrsetup /dev/vroot0 /dev/mapper/main-vstorage
1141398942 M * daniel_hozac you did include VROOT support in the kernel config, right?
1141398961 M * wam let me check it
1141399032 M * wam Virtual Root device support: YES
1141399119 M * wam do I need "Quota v2 support"? I only have this as module.
1141399175 M * Bertl well, loading it might help :)
1141399206 M * wam oh - found it. It was already loaded.
1141399223 M * Bertl okay, what does /etc/mtab inside the guest show?
1141399236 M * Bertl what ls -la /dev/hdv1
1141399355 M * wam Bertl: http://www.rafb.net/paste/results/ehwtzQ51.html
1141399419 M * Bertl okay, last check, what does cat /proc/virtual/<xid>/status show?
1141399430 M * Bertl (replace <xid> by your context id)
1141399464 M * wam Bertl: http://www.rafb.net/paste/results/nlD2e728.html
1141399526 M * wam btw: This is the exact error: http://www.rafb.net/paste/results/23MoFp99.html
1141399749 J * Hollow ~bene@home.xnull.de
1141399780 M * restill I am compiling 1833 now.  Is it normal to get a bunch of warnings?
1141399893 M * wam Bertl: running quotacheck -m /dev/hdv1 does not give an error and it rewrites /aquota.*. But it doesn't help.
1141399932 M * Bertl what do you do next?
1141399948 M * Bertl did you do quota on?
1141399962 M * wam I tried - but same errors occur.
1141399977 M * Bertl what filesystem and what quota tools do you use?
1141399993 M * Bertl also try: quotaon -Fvfsv0 /
1141400008 M * wam quotatool version 1.4.7, ext3
1141400034 M * Bertl no, the quota 'tools' version, not the debian quotatool :)
1141400042 M * Bertl check with quota -V
1141400046 Q * Hollow Quit: Leaving
1141400053 J * Hollow ~bene@home.xnull.de
1141400059 M * wam sorry ;) Quota utilities version 3.12.
1141400078 M * wam The strange thing is: it already worked...
1141400086 M * wam before upgrading today.
1141400109 M * Bertl and what did you upgrade?
1141400110 M * wam At least I think, it worked until today. It definitely worket a week ago.
1141400134 M * wam I upgraded from Kernel 2.6.12 / v2.00 to Kernel 2.6.15-4 / v2.01
1141400156 M * Bertl try quotaon on the host
1141400229 M * wam quotaon -a tells me that the devices are busy. But /etc/init.d/quota restart works.
1141400246 M * wam Although I don't quota the vserver-partition from the host.
1141400291 M * wam the mount-options on the host for the vserver-quota-partition are: (rw,tagxid)
1141400467 J * coocoon ~coocoon@p54A07481.dip.t-dialin.net
1141400485 M * Bertl welcome coocoon!
1141400489 M * Bertl wam: strange!
1141400511 M * harry http://pastebin.com/581983
1141400525 M * harry wtf does one have to do to set the name of the server... and KEEP IT
1141400557 M * coocoon hello bertl
1141400564 M * coocoon hello to all
1141400565 M * harry perl: warning: Falling back to the standard locale ("C").
1141400571 M * harry this continues to pop up!!
1141400582 M * Bertl missing locale
1141400596 M * Bertl check locale
1141400610 M * Bertl and either install the missing ones or set:
1141400617 M * Bertl export LC_ALL=C LANG=C
1141400680 M * harry how do i install missing ones?
1141400690 M * harry it's a debian guest
1141400696 M * Bertl 'urpmi locale-de' or so :)
1141400707 M * Bertl sorry, I'm no debian guy :)
1141400759 Q * fwl Ping timeout: 480 seconds
1141400760 M * daniel_hozac restill: yes.
1141400760 M * harry me neither :)
1141400764 M * harry but... i fixed it :)
1141400765 M * harry tnx
1141400773 M * daniel_hozac restill: you should get tons of warnings.
1141400789 M * coocoon harry: dpkg-reconfigure localeconf
1141400835 M * daniel_hozac restill: i686 gets 1754 warnings :)
1141400852 M * wam Bertl: could you please have one last look? I don't understand why quotaon doesn't find the mountpoint "/". http://www.rafb.net/paste/results/T19LNc72.html
1141401013 M * daniel_hozac harry: /etc/vservers/<name>/uts/nodename
1141401074 M * Bertl wam the tools ar a little weird, check /etc/fstab inside the guest, does it contain a proper entry?
1141401089 Q * shedi Read error: Connection reset by peer
1141401091 M * wam Bertl: oh - that's unconfigured.
1141401094 M * wam damn
1141401108 M * wam I can't understand why this worked before. I'll try to set it up.
1141401112 M * Bertl don't worry, the quota tools always look in strange locations
1141401128 M * Bertl I wish Honza would fix that ...
1141401181 M * wam Bertl: sorry, but that also didn't fix it... :/
1141401235 M * wam I bet this is something totally stupid I'm overseeing here.
1141401248 M * Bertl this is inside the guest now, yes?
1141401258 M * wam yes
1141401267 M * Bertl tool version is 3.12?
1141401272 M * wam yes
1141401275 J * fwl ~fwl@83-215-237-1.seek.stat.salzburg-online.at
1141401284 M * wam no
1141401286 M * wam 3.13
1141401298 M * Bertl okay, what does:
1141401309 M * Bertl quotaon -Fvfsv0 -a
1141401311 M * Bertl give you?
1141401339 M * wam sorry - tools are 3.12.
1141401347 M * wam # quotaon -Fvfsv0 -a
1141401347 M * wam quotaon: using //aquota.group on /dev/hdv1 [/]: Invalid argument
1141401347 M * wam quotaon: Maybe create new quota files with quotacheck(8)?
1141401347 M * wam quotaon: using //aquota.user on /dev/hdv1 [/]: Invalid argument
1141401347 M * wam quotaon: Maybe create new quota files with quotacheck(8)?
1141401374 M * Bertl but the files /aquota.group/user do exist?
1141401392 M * wam yes, and they are regenerated / touched when I call quotacheck -m /dev/hdv1
1141401410 M * wam -rw-------    1 root root  8192 Mar  3 16:43 aquota.group
1141401410 M * wam -rw-------    1 root root  7168 Mar  3 16:43 aquota.user
1141401423 M * Bertl okay, and the mountpoint of your guest is the guest root?
1141401441 M * wam sorry?
1141401442 M * Bertl i.e. /vservers/guestx
1141401457 M * Bertl is where you mounted the original hdv1 device?
1141401463 M * wam On the host it is /vservers/www/
1141401464 M * Bertl (not the hdv1, the real device)
1141401487 M * Bertl okay, and you did mount /dev/soemthing /vservers/www/
1141401498 M * wam Bertl: yes.
1141401510 M * wam  /dev/mapper/main-vstorage on /vservers/www type ext3 (rw,tagxid)
1141401579 J * dev ~dev@swsoft-mipt-nat.sw.ru
1141401605 M * Bertl okay, let's do an 'strace -fF -o quota.trace  quotaon -Fvfsv0 -au' on the guest
1141401658 M * Bertl and upload the resulting trace file somewhere please
1141401692 M * wam Bertl: http://www.rafb.net/paste/results/tYduqr12.html
1141401700 M * Bertl tx
1141401781 M * Bertl okay, that is now 2.01 right?
1141401792 M * Bertl you did upgrade from what version?
1141401796 M * wam from 2.00
1141401799 M * daniel_hozac can't be, it's 2.6.15.
1141401827 M * daniel_hozac 2.0.1 is for 2.6.14.3.
1141401828 M * Bertl okay, do we already have an uploaded testme.sh output?
1141401856 M * wam (11:08:13) wam: Hi! Is there already a patch a gainst 2.6.15.5?
1141401856 M * wam (11:08:37) Hollow: no, but did you try the patch for 2.6.15.4 maybe it applies cleanly
1141401856 M * wam Maybe? ;)
1141401885 M * daniel_hozac so then you're running 2.0.2-rc10.
1141401896 M * Bertl wam: okay, plz get us a testme.sh output :)
1141401898 M * wam testme.sh: http://www.rafb.net/paste/results/lw55dY30.html
1141401903 M * Bertl excellent!
1141401909 M * wam whops
1141401913 M * wam 2.02?! wtf?
1141401922 J * shedi ~siggi@inferno.lhi.is
1141401932 M * Bertl wam: yes, that looks much better
1141401953 M * wam I need more sleep.
1141401955 M * wam ;(
1141401957 M * wam ;)
1141401991 M * Bertl daniel_hozac: btw, could you test something for me?
1141402007 M * daniel_hozac Bertl: sure, what?
1141402027 M * Bertl daniel_hozac: I think I observed (not 100% sure) that using vattribute to set the ccaps messes with the bcaps too
1141402043 M * Bertl which of course would be very unfortunate
1141402097 M * Bertl (ah, this was with 0.30.210 on x86, 2.0.2)
1141402128 M * daniel_hozac Enrico seems to have but ccaps and bcaps in the same structure, handled by the same function, so that wouldn't surprise me at all.
1141402193 M * wam Bertl: should I use a older kernel with vserver 2.0.1?
1141402208 M * Bertl nope, give me a few minutes to check the kernel path
1141402288 M * Bertl wam: could you (in the meantime) update your testme.sh to the newest version and redo the test?
1141402299 M * Bertl (ah, and upload/update it :)
1141402324 M * wam sure ;)
1141402364 M * Bertl wam: ah, another question, do you have the debugging enabled in your kernel?
1141402368 M * daniel_hozac using vattribute to set ccaps should set bcaps to 0.
1141402375 M * Bertl (i.e. CONFIG_VSERVER_DEBUG)
1141402385 M * daniel_hozac (if i'm reading the code right)
1141402387 M * Bertl daniel_hozac: yeah, that is exactly what happened :)
1141402405 Q * PilatomiK Quit: Leaving
1141402410 M * Bertl of course, this will basically disable any guest
1141402416 M * daniel_hozac yeah.
1141402423 M * daniel_hozac IIRC i observed that too a while ago.
1141402431 M * wam Bertl: no debugging
1141402442 M * Bertl wam: okay, np
1141402452 M * wam http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh ?
1141402458 M * Bertl yup, that one
1141402470 M * daniel_hozac would be nice if vattribute would use current values as default, but have some switch to reset them all.
1141402509 M * Bertl hmm, the interface should allow for masking that, no?
1141402524 M * daniel_hozac not for bcaps, i think.
1141402532 M * Bertl let me check
1141402532 M * wam Bertl: current testme.sh: http://www.rafb.net/paste/results/May8z116.html
1141402539 M * Bertl tx
1141402605 M * Bertl wam: I'd say your vroot isn't configured/loaded properly
1141402616 M * Bertl wam: let's redo that part, I tell you the commands, okay?
1141402621 M * wam ok
1141402623 M * daniel_hozac vcmd_ctx_caps_v0 doesn't have a bmask member.
1141402657 M * daniel_hozac and vc_set_ccaps does vxi->vx_bcaps &= vc_data.bcaps;
1141402691 M * Bertl daniel_hozac: guess we have to fix that somehow
1141402703 M * daniel_hozac ~0 bcaps in vattribute would do it, no?
1141402711 M * Bertl yeah, jsut had the same ide
1141402713 M * Bertl +a
1141402720 M * wam Bertl: right now I'm doing "vrsetup /dev/vroot0 /dev/mapper/main-vstorage" before start (prepre-start.d) and "vrsetup -d /dev/vroot0" in postpost-stop.d
1141402743 M * Bertl wam: ls -la /dev/vroot0
1141402752 M * wam brw-rw----  1 root disk 4, 0 Mar  3 13:38 /dev/vroot0
1141402761 M * Bertl vrsetup /dev/vroot0 /dev/mapper/main-vstorage
1141402784 M * wam good
1141402795 M * Bertl ah, that's interesting, should have failed
1141402800 M * Bertl try it again
1141402806 M * wam ioctl(): Device or resource busy
1141402811 M * Bertl okay, that's much better
1141402813 M * wam ah - i shut down the guest before ;)
1141402828 M * Bertl hrm, did I say anything about that :)
1141402833 M * wam sorry.
1141402848 M * Bertl np, start the guest, back to the beginning
1141402863 M * wam ok
1141402875 M * Bertl enter the guest as root, and do:
1141402914 M * Bertl quotaon -Fvfsv0 -au
1141402923 M * pagano excuse me :)
1141402925 M * wam # quotaon -Fvfsv0 -au
1141402925 M * wam quotaon: using //aquota.user on /dev/hdv1 [/]: Invalid argument
1141402925 M * wam quotaon: Maybe create new quota files with quotacheck(8)?
1141402948 M * Bertl pagano: you will be excused :)
1141402952 M * pagano when i view in the manual "/usr/sbin/vserver-copy -i 192.168.5.62 -d example.com template web62"
1141402969 M * pagano what is template ? what web 62 ?
1141402979 M * pagano web62 guest
1141402991 M * Bertl I'd assume one is the guest-template and the other the new guest
1141402993 M * pagano name of vserver
1141403016 M * pagano but guest template what is it ?
1141403039 M * daniel_hozac Bertl: http://cvs.hozac.com/viewcvs/*checkout*/util-vserver/fedora-4/util-vserver-0.30.210-bmask.patch?root=rpms&rev=1.1
1141403040 M * Bertl basically a 'special' guest you have prepared, which you copy/clone to make new guests
1141403080 M * Bertl wam: okay, now on the host do:
1141403090 M * Bertl vrsetup /dev/vroot0 /dev/mapper/main-vstorage
1141403102 M * wam ioctl(): Device or resource busy
1141403144 J * rs ~rs@APuteaux-151-1-40-16.w82-124.abo.wanadoo.fr
1141403156 M * pagano E: vserver-copy: Directory "/etc/vservers/.defaults/vdirbase/template" does not exist
1141403191 M * Bertl pagano: yep, there should have been your 'special' guest (the template)
1141403202 M * wam pagano: "template" is the vserver FROM which you wish to copy.
1141403274 M * Bertl wam: is a kernel compile very complicated?
1141403280 M * wam Bertl: not at all
1141403285 M * wam but reboot is ;)
1141403292 M * Bertl ah, well :)
1141403299 M * wam do you want debugging?
1141403318 M * Bertl yes and no, basically I have an idea what might go wrong
1141403328 M * wam ok - I'll recompile.
1141403336 M * Bertl I'd like you to enable vserver debugging and compile the vroot into the kernel
1141403347 M * Bertl (you are currently using it as module, right?)
1141403363 M * wam 1. VServer Debugging Code ?
1141403371 M * wam inclusive history tracing?
1141403379 M * Bertl no, we don't need the history part
1141403397 M * restill how long does it take to make the debuginfo rpm?  it has been sitting for quite a while
1141403404 M * wam Virtual Root device support is enabled in the kernel right now.
1141403408 M * daniel_hozac restill: it's usually ~400 MiB in size.
1141403416 M * restill oh!
1141403431 M * Bertl wam: it isn't a module?
1141403437 M * wam no it's not.
1141403452 M * Bertl okay, then let me check a few other things first
1141403462 M * Bertl (i.e. before you reboot)
1141403477 M * wam I'll compile now ;)
1141403516 M * Bertl ah, but the quota is compiled as module, right?
1141403533 M * wam let me check
1141403536 M * Bertl yeah, you said something like that, is it jsut the quota format, or all of it?
1141403551 M * wam [*] Quota support
1141403559 M * wam <M>   Old quota format support 
1141403563 M * wam  <M>   Quota format v2 support 
1141403566 M * wam like that.
1141403577 M * Bertl hmm, okay, that should be fine too
1141403642 M * restill ok done compiling 1833
1141403679 M * wam Bertl: I'll get a cup of coffee - back in a minute - when the kernel is compiled...
1141403686 M * Bertl k
1141403706 M * daniel_hozac restill: any chance i could get access to them? :)
1141403719 M * pagano don't worry bert i'm remain with u :)
1141403728 M * pagano with my beautiful question
1141403747 M * restill yup.  I have a question tho
1141403758 M * restill the filenames are wierd
1141403760 M * pagano eheh
1141403765 M * daniel_hozac what do you mean?
1141403776 M * pagano my ticket is 22
1141403779 M * pagano :)
1141403792 M * restill they have %{fedora} in them instead of "4"
1141403807 M * daniel_hozac oh.
1141403824 M * daniel_hozac i probably should change that back...
1141403834 M * Bertl pagano: np, but I guess we already answered that, no?
1141403848 M * pagano yes yes, all works
1141403850 M * wam re
1141403880 M * daniel_hozac restill: you'll need buildsys-macros installed or --define 'fedora 4'.
1141403957 J * stefani ~stefani@superquan.apl.washington.edu
1141403961 M * daniel_hozac restill: sorry about that.
1141403980 M * restill maybe next time.  I just changed the filenames
1141403986 M * restill ok how do you want them?
1141403993 M * daniel_hozac the version will still contain it.
1141403997 M * daniel_hozac release, i mean.
1141404015 M * daniel_hozac doesn't matter to me. HTTP is always nice :)
1141404044 M * restill Meaning you want me to put them on a website.  um, give me a couple minutes
1141404052 M * restill how about ftp?
1141404066 M * daniel_hozac sure, anything wget'able is fine by me.
1141404146 M * daniel_hozac you had util-vserver RPMs too?
1141404235 M * restill yup
1141404650 M * wam Bertl: rebooting.
1141404790 J * doener ~doener@i5387DA57.versanet.de
1141404860 Q * doener Quit: 
1141404871 M * wam Bertl: vservers are being started
1141404900 M * wam online
1141404911 M * Bertl okay, let's enable the relevant debug info with:
1141404943 J * doener ~doener@i5387DA57.versanet.de
1141404969 Q * shedi Quit: Leaving
1141405096 M * Bertl hmm, sec
1141405233 M * Bertl sysctl vserver.debug_misc=1
1141405248 M * Bertl then stop and start the guest, and check dmesg output
1141405250 M * wam on the host?
1141405257 M * Bertl yup
1141405302 M * wam Bertl: you meen lines starting with vxD?
1141405318 M * wam http://www.rafb.net/paste/results/xmzTAu20.html
1141405325 M * Bertl yup
1141405407 M * coocoon daniel_hozac: u r a gentoo professional aren't u
1141405407 M * Bertl looks really good .. and inside, still EINVAL?
1141405413 M * Bertl coocoon: we are all professionals here, no? *G* :)
1141405441 M * wam Bertl: inside the guest anything is like before...
1141405454 M * coocoon Bertl: maybe there is a professional professional
1141405464 M * coocoon professional²
1141405482 M * Bertl wam: okay, when you try the quota -Fvfsv0 -au inside the guest, is there some vxD logging?
1141405516 M * wam # quota -Fvfsv0
1141405516 M * wam Disk quotas for user root (uid 0): none
1141405524 M * wam vxD: vroot[0]_get_real_bdev: dev=c2b61480[0,254:4]
1141405555 M * Bertl okay, let's double check the real device major and minor on the host
1141405590 M * wam http://www.rafb.net/paste/results/6imkmo99.html
1141405638 M * Bertl hmm, nice, but we want the devmapper one :)
1141405649 M * wam Bertl: does it matter that I have a kernel-parameter with max_vroot=24?
1141405656 M * Bertl nope, that is fine
1141405663 M * wam brw-------   1 root root 254,  3 Mar  3 17:53 main-vservers
1141405674 M * wam eh
1141405678 M * wam brw-------   1 root root 254,  4 Mar  3 17:53 main-vstorage
1141405680 M * wam this is it.
1141405762 M * Bertl okay,
1141405779 M * Bertl I suspect a tool/kernel issue, let's verify that now
1141405789 M * Bertl do the following onthe host:
1141405812 M * Bertl cp -va /dev/mapper/main-vstorage /vservers/www/dev/hdv1
1141405815 M * Bertl it was www?
1141405820 M * harry http://pastebin.com/582161
1141405820 M * wam right
1141405823 M * harry what can we do?
1141405854 M * wam Bertl: do we have it?
1141405856 M * Bertl harry: unmount it in the guests which 'copied' the mount
1141405870 M * Bertl wam: what?
1141405882 M * wam Bertl: this is new. hdv1 was 0,4 before.
1141405889 M * harry ?
1141405893 M * harry i don't get it
1141405928 M * Bertl harry: I'd say you mounted it at some point, then started a guest, now you try to umount it
1141405944 M * Bertl harry: the guest is still holding that mount
1141405944 M * harry stopped guest, unmounted, and now remove, yes
1141405960 M * Bertl not that one, the 'other' one :(
1141405980 M * harry there is no other one afaik
1141405985 M * Bertl wam: simply copy the real devmapper device into the guest
1141405992 M * Bertl harry: what kernel/patch version?
1141405994 M * wam Bertl: ok done
1141406002 M * harry my patch ;)
1141406004 M * Bertl wam: now retry the quotaon
1141406004 M * harry 2.6.14.7
1141406028 M * Bertl harry: might have the ext3/devlock issue
1141406045 M * harry it's reiseer:)
1141406050 M * Bertl harry: but maybe there are just remaining mounts
1141406055 M * wam Bertl: still the same error. Must I restart the guest? redo the vrsetup or so?
1141406061 A * harry will check it out...
1141406063 M * Bertl harry: so check with cat /proc/mounts
1141406071 M * Bertl wam: nope
1141406082 M * Bertl wam: we now know that the issue is not vserver related
1141406089 M * wam ah ;)
1141406097 M * Bertl wam: does the quotaon work on the host?
1141406117 M * wam Bertl: it seems so
1141406142 M * Bertl okay, please compare both versions, and if necessary install the host version of the quota tools inside the guest
1141406142 M * wam mompl
1141406143 Q * ||Cobra|| Remote host closed the connection
1141406169 M * wam yes it works on the host.
1141406227 M * Bertl okay, do a quotaoff on the host, copy over the tools into the guest
1141406332 M * wam Bertl: I'm so sorry - I have to go now. I'm back at 22:00 I think.
1141406347 M * Bertl okay, np, cya!
1141406350 M * wam I'll see where I got that quota-package from and install it on the quest. I'll tell you!
1141406364 J * bonbons ~bonbons@83.222.39.180
1141406455 M * pagano i have compressed with tar a guest
1141406461 M * pagano scp to another machine
1141406479 M * pagano un tar, copyed, and start machine
1141406481 M * pagano all ok
1141406491 M * pagano how can i change at fly
1141406493 M * mnemoc you can pipe it :)   tar -c | ssh tar -x  :p
1141406497 M * doener hi folks
1141406503 M * pagano its ip ?
1141406513 M * pagano eheh thx mnemoc
1141406523 M * doener it's strange, I can't reproduce the long compile times anymore :(
1141406531 M * Bertl pagano: on the fly is complicated, but you can easily change the config when the guest is stopped
1141406548 M * pagano so stop machine
1141406571 M * pagano create a config file (i use new syntax so no config file are created)
1141406575 M * Bertl stop the guest, change the entries in interfaces/0 or so
1141406581 M * pagano and restarted?
1141406588 M * pagano ah k
1141406593 J * gerrit ~gerrit@129.33.1.37
1141406602 M * Bertl and then restart, yes, you can generate a skeleton and use that config
1141406959 M * pagano thank a lot to everybody, have a good weekend
1141406962 M * pagano bye
1141406966 M * Bertl you too!
1141406970 Q * pagano Quit: 
1141407194 M * daniel_hozac coocoon: no, that'd be Hollow and phreak`` ;)
1141407214 M * coocoon daniel_hozac: ah ok thanx
1141408442 M * coocoon getting this error after starting default vserver it is vserver specific and regards RH vservers (FC3+4/ CentOS 4.2) ->http://pastebin.com/582220, after that one of these 
1141408459 M * coocoon specific vservers doesn't start
1141408564 Q * rs Quit: rs
1141408916 M * Bertl coocoon: who is doing the iptables stuff?
1141408994 Q * Hollow Quit: Leaving
1141408995 M * coocoon Bertl: good question I will have a look
1141409057 J * Hollow ~hollow@home.xnull.de
1141409170 M * coocoon Bertl:
1141409176 Q * Duckx Quit: Leaving
1141409201 M * coocoon Bertl: only the scripts in vservers folder, I thought
1141409217 M * coocoon Bertl: have checked them there is everything alright
1141409231 M * restill daniel_hozac:  how much longer?
1141409492 M * coocoon Bertl: I thonk I must activate iptables at startup, right
1141409527 M * coocoon Bertl: +i
1141409545 M * Bertl inside the guests?
1141409572 M * coocoon Bertl: no
1141409576 M * Bertl ah, okay
1141409587 M * coocoon Bertl: make a reboot
1141409592 M * Bertl no iptables inside the guests, on the host it depends on your setup
1141409619 M * daniel_hozac restill: it's still on the debuginfo.
1141409643 M * daniel_hozac restill: it's just downloading at 44 KiBps.
1141409683 M * coocoon Bertl: ah ok so I must install it there, right, but the other vservers (Debian) aren't involved of that issue
1141409713 M * restill oh!  I can type much faster thean what shows up on the screen
1141409728 M * Bertl coocoon: hmm, no guest does require any iptables stuff 
1141409748 M * Bertl coocoon: why the guest startup failed I do not know yet, you might want to add logging for that one
1141409776 M * coocoon Bertl: yes right, so I only use iptables on my server to access vserver guests
1141409807 M * Bertl yep, that's fine
1141409831 M * bonbons Bertl: How does one specify which process in a guest gets PID=1 inside? I think I'm missing something as either the intended init process does not get PID=1 or I get Operation not permitted. Seems I'm missing a flag before executing vexec
1141409833 M * coocoon Bertl: little question how to use add logging
1141409837 M * daniel_hozac restill: i think it should be done in 40 minutes or so.
1141409888 M * bonbons I have hide_mount,hide_netif,state_setup and persisteat on the context, state_setup and persistant on the network context before calling vexec
1141409985 M * bonbons For init process vexec tries to set info_init and unset state_init on the context, but fails on setting flags for (network) context -- does it after migrating. Doing it before -> not getting PID=1
1141409991 M * coocoon Bertl: sorry for my question forget it
1141410003 M * Bertl coocoon: ah, guess you found it
1141410003 M * coocoon Bertl: I don't want to
1141410035 M * Bertl coocoon: no problem, ahve you checked the flower page?
1141410041 M * coocoon Bertl: must go now maybe this question will be asked tomorrow or not ;-)
1141410053 M * Bertl coocoon: okay, cya
1141410058 M * coocoon Bertl: nope but thanx for this infomation will have a look there
1141410061 M * coocoon bye
1141410071 M * Bertl coocoon: have fun!
1141410071 M * bonbons It must be a missing flag, as exactly same vexec worked previously -- though there were broken things at least with bcaps
1141410086 M * Bertl bonbons: the process is two steps actually
1141410089 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1141410102 M * Bertl and in the near future you will have at least two more options to do so
1141410125 M * Bertl the 'original' startup sequence is like this:
1141410150 M * Bertl - process creates context and becomes 'special' setup process
1141410165 M * Bertl - then some things are set up
1141410178 M * Bertl - when done, the setup flag is cleared (you already know that)
1141410197 M * Bertl - similar to the setup, the init flag triggers the setting of init
1141410234 M * Bertl http://linux-vserver.org/Caps+and+Flags
1141410241 M * Bertl (it's the STATE_INIT flag)
1141410266 M * bonbons On what process does it trigger the setting of init?
1141410279 M * Bertl it is the process which calls it
1141410298 M * Bertl (usually the one which then vexec's init
1141410330 M * Bertl in the near future (tomorrow?) we will have some more ways to do so
1141410365 M * Bertl ah, forgot to mention, the legacy context creation does similar when using info_init/fakeinit
1141410366 M * bonbons from inside the context or from outside (from outside does not produce the right visible PID)
1141410388 M * Bertl from outside it will not work I guess
1141410423 M * bonbons and from inside I get operation not permitted
1141410440 M * Bertl are you doing it after the setup finish?
1141410498 M * Bertl best would be to clear setup _and_ init in one go, then vexec the 'real' init
1141410507 M * bonbons No, state_setup is not cleared yet at that point (nor is it to be cleard by the vexec call)
1141410669 M * bonbons Bertl: Removing the STATE_SETUP flags before does not help either
1141410683 M * Bertl no, you must not remove it before
1141410696 M * Bertl you should remove both at the same time (ideally)
1141410726 M * Bertl (of course, requires that you have set them both, if you use the newer create calls)
1141410747 M * Bertl show me the relevant code section if possible
1141410805 M * bonbons I'm preparing all data for showing, code + flag/caps-dumps
1141411240 J * private Terrorista@201.227.34.93
1141411258 Q * private Quit: 
1141411896 J * fh fiona@cheeto.net
1141411923 M * Bertl welcome fh!
1141411939 A * fh sits on Bertl 
1141411978 M * doener o.O
1141411983 M * daniel_hozac lol
1141411994 M * daniel_hozac restill: all done now, thanks a million!
1141412008 A * Bertl is used to that, he has cats :)
1141412071 J * rs ~rs@office.dailymotion.com
1141412092 M * fh :)
1141412203 M * Bertl wb rs!
1141412209 M * rs re
1141412321 M * bonbons Bertl: Start-log with verbose flag output: http://homepage.internet.lu/BrunoP/vserver/start-log, http://homepage.internet.lu/BrunoP/vserver/start-log2
1141412428 M * Bertl bonbons: do you have a debug log (kernel) too?
1141412437 M * Bertl switch debug would be nice
1141412467 M * bonbons The matching sourcecode is libvserver (svn trunk) for the vserver calls, vexec: http://homepage.internet.lu/BrunoP/vserver/vexec.c
1141412506 M * bonbons I have no kernel debug, but that's easy to "fix"
1141412536 M * bonbons what debug bits should I enable for the kernel logs?
1141412639 M * Bertl sysctl vserver.debug_switch=1
1141412815 M * bonbons Bertl: Kernel log is here: http://homepage.internet.lu/BrunoP/vserver/kernel.log
1141412896 M * Bertl add a  flags.flags |= VXF_STATE_INIT;
1141412909 M * Bertl to the 'i' case
1141412988 M * Bertl and clear both before you do the execvp as I suggested
1141413144 M * bonbons already fails on clearing the STATE_SETUP flag on the network context... "Failed to set network context flags", vexec.c line 176
1141413199 M * Bertl which kernel version?
1141413208 M * Bertl (I mean, which patch/branch)
1141413318 M * restill sweet.
1141413326 M * bonbons 2.6.16rc5-vs2.1.1rc10 -- works fine with prior version of vserver-utils and libvserver (with BCAPS = ...fffffeff, not sure of the exect position of the 'e')
1141413369 M * bonbons note thazt just taking vexec of that prior vserver-utils version fails the same way, so it has something to do with {b,c}caps/flags
1141413429 M * Hollow Bertl, bonbons: i noticed that issue too
1141413436 M * Hollow somehow i didn't get init working lately
1141413456 M * Bertl lately means? i.e. about what versions do we talk here?
1141413463 M * Hollow 7-10?
1141413464 M * Hollow rc
1141413474 M * Hollow not sure
1141413507 M * Bertl so rc6 works/worked?
1141413517 M * restill Do I need a vserver running to run the testme.sh?
1141413523 M * Hollow we'll have to test it i guess
1141413540 M * Bertl bonbons: and you said it fails on the network context?
1141413544 M * bonbons just downgrading to vserver-utils-1.0.3+libvserver-1.0.2 works, but bcaps are set to -1
1141413566 M * Hollow maybe it's a pure userspace problem too
1141413582 M * bonbons Bertl: fails on network context, but when I did comment that one out, it failed 3 lines later: setting for context itself
1141413617 M * Hollow but these triggers are weird anyway, why can't we just make the switch to vx_set_initpid?
1141413645 M * Bertl bonbons: we can, for devel
1141413670 M * Hollow yup, i'm talking about devel :)
1141413677 M * Hollow in case you meant me
1141413679 M * Bertl bonbons: but ut seems to work with util-vserver no?
1141413729 M * Bertl bonbons: IMHO you are killing your bcaps somehow
1141413734 M * bonbons It works when bcaps are set to fff...fff (except one bit that gets dropped)
1141413767 M * daniel_hozac vc_set_ccaps?
1141413770 M * Bertl and you are setting it to?
1141413814 M * Bertl daniel_hozac: interesting coincidence ...
1141413824 M * daniel_hozac indeed...
1141413931 M * bonbons I am setting bcaps to same values as it's on a util-vserver guest... BCAPS=00000000144c04ff, CCAPS=0000000000000101, FLAGS=0000004103000000 (after the failure)
1141413958 M * Bertl you are missing the admin cap
1141414018 M * Bertl or am I wrong here? sec
1141414095 M * Bertl 200000 CAP_SYS_ADMIN
1141414294 M * bonbons I get difference of CAP_AUDIT_WRITE to running util-vserver guest BCAPS=00000000344c04ff
1141414384 M * bonbons Adding CAP_SYS_ADMIN does not help
1141414531 M * restill daniel_hozac:  Do the rpms look right?
1141414619 M * Bertl bonbons: if you do vc_set_ncaps() or vc_set_nflags()
1141414633 M * Bertl there are only 3 possible return values
1141414647 M * Bertl a) EPERM (means you are missing CAP_SYS_ADMIN)
1141414660 M * Bertl b) EFAULT (means your struct is wrong)
1141414676 M * Hollow bonbons: when do you get the EPERM?
1141414677 M * Bertl c) ESRCH (means your context was not found)
1141414719 M * bonbons vexec.c, setting [network]context flags after migration for init process
1141414756 M * Hollow well, maybe util-vserver removes the sys_admin cap after migrating to the context and triggering the init 
1141414758 M * Hollow flag
1141414773 M * bonbons "Operation not permitted" should be EPERM, though it also happens if CAP_SYS_ADMIN is there
1141414892 M * daniel_hozac restill: apart from the %{fedora} in release, i think so.
1141414903 M * daniel_hozac restill: you tell me though, i can't even test-install them :)
1141414954 M * bonbons Hollow: vu_printf() always first prints a '\0'... at least in vserver-utils SVN-rev=82, did you fix this in a later revision?
1141414995 M * Hollow maybe.. at least it works pretty good in trunk ;)
1141414997 M * restill I am not going to reboot till I get home, just in case it panics.
1141415057 M * bonbons The \0 is not visible on console, it's only when piping e.g. to less
1141415058 M * restill should I redo it to correct the name thing, or just wait till next time?
1141415086 M * Hollow bonbons: ah, this is interesting.. i noticed an issue while doing pipes for vcd that may be caused by this.. hm hm
1141415120 M * daniel_hozac restill: i guess it's really just cosmetic.
1141415394 Q * rs Quit: rs
1141415462 M * bonbons away eating something, will be back in half an hour
1141415722 Q * gerrit Ping timeout: 480 seconds
1141415799 Q * fwl Quit: Leaving
1141415865 J * fwl ~fwl@83-215-237-1.seek.stat.salzburg-online.at
1141416597 M * Roey http://www.linuxjournal.com/article/8909   nice article on Xen 3's architecture.
1141416883 J * tam ~tam@nettam.com
1141416996 M * tam So here's my minute being a fool...  2.6.15.4-vs2.0.2-rc10, centos 4.2... when i start up a vserver my default interface for outbound traffic changes... so the host machine is sending out data on one of the virtual servers ip's... 
1141417004 M * tam anyone know what I might have done to cause this?
1141417117 M * Bertl welcome tam!
1141417144 M * Bertl maybe an unfortunate config for the guest?
1141417160 M * tam Seems like it must be...
1141417201 M * tam After tying that out, i noticed that my netmasks are not the same between the host and the vservers... i'm going to try to syncronize that and see if it gets better
1141417260 M * tam Yeah... seems that fixed it.
1141417267 M * tam Guess typing it out was enough to make me think of the answer.
1141417282 M * Bertl excellent!
1141417393 M * tam Thanks!
1141417581 M * bonbons Bertl: some idea about what other capability might be needed?
1141417657 J * shedi ~siggi@inferno.lhi.is
1141417835 M * Bertl bonbons: hmm, you might hit one of the switch checks
1141417981 M * Bertl bonbons: but you did not leave setup at this point, yes?
1141418064 M * bonbons STATE_SETUP is set to be cleared in the failing call in vexec.c
1141418082 M * Bertl was it set before?
1141418143 P * Roey Leaving
1141418183 M * bonbons It is with the creation call for both contexts
1141418294 M * Bertl let me verify that, the kernel log should tell us
1141418645 M * wam Bertl: re
1141418696 M * Bertl bonbons: could you do a single network config (failing) and upload the kernel log part for that?
1141418700 M * Bertl wb wam!
1141418708 M * wam Bertl: I upgraded to quota 3.13 on the guest. But still the same error.
1141418762 M * bonbons Bertl: what do you mean by 'a single'?
1141418797 M * Bertl bonbons: only the setup part till the failing net flag command
1141418981 M * Bertl bonbons: you know what I mean?
1141419000 M * Bertl wam: okay, let's try with chroot to the guest
1141419029 M * bonbons I think, doing a step-by step case with tags on each step in kernel log
1141419068 M * Bertl bonbons: either that or at least some marker, i.e. call the version syscall inbetween
1141419134 M * bonbons I think with all details is easiest, will add cat /proc/virt*/<xid>/state + commandline on each step (3 steps should be sufficient)
1141419327 M * wam Bertl: ok, I'm chrooted to the guest-dir on the host.
1141419449 M * bonbons Bertl: here is the log: http://homepage.internet.lu/brunop/vserver/debug.verbose
1141419478 P * fwl Leaving
1141419522 M * Bertl brb, afk (getting something to eat)
1141420180 J * tudenbart ~willi@xdsl-213-196-245-220.netcologne.de
1141420190 M * Bertl back now ...
1141420305 M * Bertl wam: and, does the quotaon work there?
1141420375 M * wam # quotaon -a
1141420375 M * wam quotaon: Cannot find quota file on / [/dev/hdv1] to turn quotas on/off.
1141420375 M * wam quotaon: Cannot find quota file on / [/dev/hdv1] to turn quotas on/off.
1141420412 M * wam # cd / && ls -l aquota*
1141420412 M * wam -rw-------  1 root root 8192 Mar  3 18:13 aquota.group
1141420412 M * wam -rw-------  1 root root 7168 Mar  3 21:54 aquota.user
1141420438 M * wam he gets /dev/hdv1 from /etc/mtab...
1141420454 M * Bertl which should be fine, no?
1141420465 M * wam i think yes. It's normal at least ;)
1141420536 M * wam ah - thats interesting. I'm in the guest and try:
1141420536 M * wam # mv aquota.group a.g
1141420536 M * wam www:/# mv aquota.user a.u
1141420536 M * wam www:/# quotaon /
1141420536 M * wam quotaon: Cannot find quota file on / [/dev/hdv1] to turn quotas on/off.
1141420537 M * wam quotaon: Cannot find quota file on / [/dev/hdv1] to turn quotas on/off.
1141420560 M * wam without quotafiles the error doesn't happen. So let's just create them from scratch.
1141420597 M * wam damn.
1141420597 M * wam # /etc/init.d/quota start
1141420597 M * wam quotaon: using //aquota.group on /dev/hdv1 [/]: Invalid argument
1141420597 M * wam quotaon: Maybe create new quota files with quotacheck(8)?
1141420597 M * wam quotaon: using //aquota.user on /dev/hdv1 [/]: Invalid argument
1141420599 M * wam quotaon: Maybe create new quota files with quotacheck(8)?
1141420619 Q * dothebart Ping timeout: 480 seconds
1141420626 M * Bertl is this now in the chroot?
1141420636 M * wam no, in the guest.
1141420730 M * bonbons Bertl: did you read something out of my log?
1141420762 M * Bertl not yet, as I missed it, sorry :/
1141420857 M * wam Bertl: what does ufs mean? User File System?
1141420922 M * Bertl wam: no it means unix filesystem and it is just there to trick the tools into not using direct raw disk acccess
1141420940 M * bonbons The content is: cmdline executed, cat /proc/virt{net,ual}/12/state (after cmd), dmesg -c (after cmd) <= 3 times the tripplet
1141420952 M * wam do I need the entry "/dev/hdv1 / ufs rw,usrquota,grpquota 0 0" only in $CFG_DIR/apps/init/mtab or also $CFG_DIR/fstab?
1141420992 M * Bertl bonbons: okay, but that looks good, no?
1141421173 M * bonbons The third command fails setting context flags after migrating: Operation not permitted (init case)
1141421175 M * Bertl bonbons: okay, please make a static binary which causes your issues
1141421195 M * Bertl I will check it here in my test setup 
1141421196 M * bonbons binary IS static, dietlibc
1141421207 M * Bertl good :)
1141421211 M * Bertl url?
1141421267 M * bonbons Will give you the 3 binaries vncontext, vcontext, vexec
1141421366 M * bonbons They are here: http://homepage.internet.lu/brunop/vserver/vtools.tar
1141421814 Q * sladen Ping timeout: 480 seconds
1141421964 J * sladen paul@starsky.19inch.net
1141421984 M * Bertl bonbons, okay and what fails?
1141422013 M * bonbons Bertl, the vexec call fails
1141422178 M * Bertl ah, okay
1141422451 M * Bertl so the command should be:
1141422474 M * Bertl vcontext -C -x 12 -f PERSISTANT,STATE_SETUP -- vexec -cfi -x 12 -- /sbin/initng
1141422477 M * Bertl or what?
1141422487 M * Bertl or just the vexec?
1141422660 M * Bertl bonbons: how am I supposed to call them=
1141422666 M * Bertl s/=/?
1141422684 M * bonbons as show in my log file http://homepage.internet.lu/brunop/vserver/debug.verbose
1141422712 M * Bertl but then the second one (vexec) will be a different process, no?
1141422730 Q * shedi Read error: Connection reset by peer
1141422785 M * bonbons For vexec you can also do "vexec -ci -x12 -- /bin/echo Hi from inside guest" (-f is for fork, what follows -- is what is executed in chroot to '.', so call it from a (virtual)fs root)
1141422801 M * Bertl bonbons: you can only have _one_ setup task
1141422810 M * bonbons s/(virtual)/(guest's)/
1141422843 M * Bertl I'm obviously missing something as you seem to finalize the setup in the vcontext call
1141422955 M * bonbons there is not finalization there, unless I'm doing something wrong. Its source is here: http://homepage.internet.lu/brunop/vserver/vcontext.c
1141423084 M * Bertl let me upload something:
1141423103 M * bonbons vserver-utils has always been doing things with multiple processes: context creation; configuring network context; setting caps/flags; setting up namespace; entering guest & starting its init
1141423194 Q * restill Quit: Leaving
1141423236 M * Bertl http://pastebin.com/582570
1141423400 M * bonbons Oh, and I forgot to use the network context in the whole process, but does not really matter here (should have added -n 12 to vexec's arguments)
1141423411 M * Bertl no, doesn't matter
1141423439 M * Bertl now check the switch.c (kernel side)
1141423450 M * Bertl         /* those are allowed while in setup too */
1141423455 M * Bertl         if (!vx_check(0, VX_ADMIN|VX_WATCH) &&
1141423458 M * Bertl                 !vx_flags(VXF_STATE_SETUP,0))
1141423461 M * Bertl                 return -EPERM;
1141423622 Q * Viper0482 Remote host closed the connection
1141423671 M * bonbons what do both positions arguments for vx_check(a, b) and vx_flags(a, b) mean (or how do they define the return value)?
1141423711 J * shedi ~siggi@inferno.lhi.is
1141423718 M * Bertl the first vx_check() basically means either admin or spectator context
1141423731 M * Bertl admin in this case means xid=0
1141423745 M * Bertl the second check is a check for the setup flag
1141423769 M * Bertl so, assumed that this check gives you the EPERM (will test that in a minute)
1141423842 M * matti Hm, Intel e1000 6.0.x family drivers seems to have some issues with 10BaseT-FD links.
1141423845 M * matti That sucks...
1141423847 M * matti ;/
1141423848 M * bonbons so EPERM is returned if either VXF_STATE_SETUP is NOT set or call comes from neither spectator/admin contexts?
1141423849 M * matti Bertl: :)
1141423903 M * Bertl bonbons: no, if you are _not_ admin, and the current context is _not_ in setup then it fails
1141423933 M * Bertl let me do a few checks there first, then we check again
1141424002 M * bonbons ups, my 'or' should have been an 'and' and 'either' dropped
1141424416 M * Bertl bonbons: your vexec migrates into the context
1141424474 M * bonbons that's exact, it's its job, migrate to the context to execv inside
1141424491 M * Bertl yes, but it is trying to change the context from inside?
1141424527 M * bonbons Only if it should execv the guest's init process
1141424606 M * Bertl that can't work
1141424614 M * bonbons I just kept the way of doing as of previous vserver-utils which were working (except for giving the context all present and future bcaps)
1141424625 Q * wam Ping timeout: 480 seconds
1141424640 M * Bertl bonbons: yes, it would at least require CAP_CONTEXT
1141424663 M * Bertl if your vexec process has CAP_CONTEXT, the checks will be overridden
1141424680 M * Bertl but IMHO this sequence is broken by design
1141424718 M * bonbons but previously you even said setting the init flag should be done from inside, or did I mis-understand something?
1141424756 M * Bertl the original idea is like this: (it's old and it is based on the way util-vserver works, so not necessarily the future way)
1141424777 M * Bertl - process A creates context in setup state
1141424822 M * bonbons As soon as the future ways is available I will use it, but until then...
1141424903 M * Bertl okay, then lets ignore the current setup, and think about the future ...
1141424922 M * Bertl how do you want to create a guest init?
1141425083 M * bonbons I would want to fork, then the forked instance says "I will be the init" and migrates e.g. vx_set_init_pid(pid = 0); nx_migrate(nid); vx_migrate(xid);
1141425166 M * bonbons But I would also want the option to take any existing process of an init-less context and elevate it to init status for that context: vx_set_init_pid(pid = 1234)
1141425184 M * Bertl at a later time?
1141425201 M * Bertl be careful that might cause complicated issues
1141425222 M * Bertl processes tend to store the pid of other processes
1141425236 M * Bertl such an 'elevated' process will suddenly disappear
1141425236 M * cehteh mhm
1141425256 M * bonbons at any time in context's lifetime would be ideal
1141425301 M * cehteh i once suggested to have a fixed bias for all processes in kernel space, each user/kernel trnasisiton just adjusts pibs by that bias
1141425303 M * Bertl bonbons: how are you going to deal with those broken pid references?
1141425308 M * cehteh pids
1141425386 M * bonbons we already have that disapearing issue when a process migrates to another context, so same behavior would be appropriate
1141425390 M * cehteh well, that doesnt address the init-ends problem
1141425498 M * cehteh but shouldnt all guest processes be childs of their init ?
1141425499 M * Bertl bonbons: okay, I don't see a special issue to allowing a vx_set_init() and vx_set_reaper() for the current process, would that suffice?
1141425571 M * bonbons That's sufficient to get it working, and I'm fine with it
1141425583 M * Bertl bonbons: either allowed from admin/cap_context or setup state
1141425686 M * bonbons yep, from admin/cap_context it does implicit migration, from inside it just does it's job
1141425835 J * Smutje_ ~Smutje@xdsl-84-44-186-91.netcologne.de
1141425874 M * Bertl bonbons: nope, you have to do the migration afterwards
1141425905 M * Bertl (from the setup it already happened)
1141425932 M * bonbons I thought of vx_set_init(xid), (!(admin/CAP_CONTEXT XOR xid > 1)) && return EPERM
1141425939 Q * Smutje Ping timeout: 480 seconds
1141425939 N * Smutje_ Smutje
1141425961 M * Bertl leave the checks to me :)
1141425985 M * cehteh Bertl: pardon me, but how does adopting of orphaned processes work in normal linux/unix?
1141426004 M * cehteh just hardcoded to pid 1?
1141426005 M * Bertl cehteh: they do not get adopted, they get reaped when they die
1141426018 M * Bertl and yes, the child_reaper is hardcoded
1141426021 M * bonbons so if migration must be done explicitely afterwards, the vx_set_init() can never really fail... (failure would be asynchronous)
1141426038 M * Bertl huh?
1141426053 M * Bertl bonbons: no, the set init just makes the current pid the initpid
1141426070 M * Bertl (or in case of the reaper, it assigns the guest reaper)
1141426102 M * cehteh huh so the impression that runnning orphaned processes are childs of init is a special case, actually they just hang somewhere in nowhere?
1141426103 M * bonbons ok, but assume that app just decides on another xid between set_init_pid() and migrate() <= how does that get catched?
1141426117 M * Bertl not at all
1141426135 M * Bertl but maybe a combined migrate/set would be better?
1141426153 M * Bertl maybe just a migrate with flags?
1141426158 M * bonbons it's to avoid my example that I sugested the implicit migration
1141426202 M * bonbons adding "init" flag to migration does the same job
1141426221 M * cehteh Bertl: here comes my bias idea :)
1141426385 M * Bertl bonbons: okay, then we do that, simply another migrate command
1141426394 M * Bertl cehteh: let's hear :)
1141426397 Q * matta Read error: Connection reset by peer
1141426449 M * cehteh Bertl: add a int init_bias to a context which is the pid of the intended init process for that context
1141426521 M * cehteh this bias is substracted from the kenels pid on each kernel->user passing means that init looks always as if it has pid 1 for the context
1141426538 M * cehteh vice versa when you pass a pid into the kernel
1141426565 M * cehteh (and adustments for other interfaces think about proc ..)
1141426576 M * Wonka oh. cehteh is alive.
1141426589 M * Bertl cehteh: and in what cases would that help and how?
1141426602 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net
1141426602 M * bonbons Bertl: will it be vx_migrate_init(xid), or a vx_migrate_v2(xid, flags); I would opt for the second one, more future-oriented (allows addition of more process-flags in future)
1141426630 M * cehteh each process from every process can locate the init which belongs to it .. and init is always pid 1
1141426650 M * cehteh well dunno i dont know how the kernel handles that stuff ...
1141426652 M * Bertl bonbons: yes, the latter one
1141426691 M * cehteh if the init of a context dies, all its child should be killed too right?
1141426696 M * Bertl cehteh: would immediately disable what bonbons want to do (e.g. start a later init)
1141426712 M * cehteh ok .. 
1141426716 M * cehteh bonbons: bad idea :)
1141426769 M * cehteh why do you need that?
1141426825 M * bonbons cehteh: why so bad? Very useful when testing new/specialized inits! Even useful to switch guest from fake init to real init
1141426863 M * cehteh the 'bad idea' was just a joke :) 
1141426895 M * cehteh but i had this bias idea to bring fake-init little closer to a real init like behaviour
1141426941 M * cehteh and init could exec another init, thats likely the more sane method to exchange a init imo 
1141426969 M * cehteh switching from guest to real init is not really something i want
1141426985 M * cehteh better nested contexts if such things are needed
1141427043 M * Bertl #define VCMD_ctx_migrate_v0     VC_CMD(PROCMIG, 1, 0)
1141427043 M * Bertl #define VCMD_ctx_migrate        VC_CMD(PROCMIG, 1, 1)
1141427043 M * Bertl struct  vcmd_ctx_migrate { uint64_t flagword;
1141427043 M * Bertl };
1141427195 M * bonbons cehteh: each context already has (can have) an init with pid=1
1141427304 M * cehteh bonbons: i am little behind the current development ... but the old fakeinit i know was really a fake not a init process started and configured by the user or?
1141427327 Q * fh Ping timeout: 480 seconds
1141427348 A * cehteh needs to dig up vserver more for #linuxtag
1141427366 M * bonbons cehteh: currently you can have both, either fake init or a process which is visible in its context as pid=1
1141427391 M * cehteh ok
1141428369 Q * phreak`` Ping timeout: 480 seconds
1141428520 J * phreak`` ~phreak``@styx.xnull.de
1141428708 J * ESL|caseme ~fs@87.193.18.108
1141428759 M * Bertl welcome ESL|caseme!
1141429009 M * Bertl bonbons: http://vserver.13thfloor.at/Experimental/delta-migrate-feat01.diff
1141429102 M * bonbons Bertl: Ok, userspace upgrading in process here, vexec done, vcontext's migration in progress
1141429191 J * gerrit ~gerrit@c-24-22-19-208.hsd1.or.comcast.net
1141429997 M * bonbons Bertl: what does reaper exactly mean? That all processes of same context whose parent dies get reparented to it (once they die themselves)?
1141430064 M * Bertl task which have no parent get reaped by init (on a typical linux system)
1141430097 M * Bertl in the guest this means that the 'reaper' process will receive the child signals of such processes and has to reap them
1141430107 M * Bertl (otherwise they will remain as zombies)
1141430152 M * bonbons so the init process of a context should also have VXM_SET_REAPER flag in addition to VXM_SET_INIT?
1141430159 P * stefani I'm Parting (the water)
1141430237 M * Bertl bonbons: typically yes
1141430345 M * bonbons Ok, userspace adjusted, doing kernel patch, reboot & test...