1191543449 Q * toidinamai Quit: Leaving
1191546547 Q * nospoonuser Ping timeout: 480 seconds
1191549357 J * balbir ~balbir@122.167.82.87
1191559451 Q * hparker resistance.oftc.net oxygen.oftc.net
1191559451 Q * ^Toad resistance.oftc.net oxygen.oftc.net
1191559451 Q * besonen_mobile resistance.oftc.net oxygen.oftc.net
1191559451 Q * hardwire resistance.oftc.net oxygen.oftc.net
1191559668 J * hparker ~hparker@linux.homershut.net
1191559668 J * ^Toad ~tl@tyler.cs.brown.edu
1191559668 J * besonen_mobile ~besonen_m@71-220-225-178.eugn.qwest.net
1191559668 J * hardwire ~bip@rdbck-5433.palmer.mtaonline.net
1191562303 J * friendly12345 ~friendly@ppp59-167-67-185.lns1.mel4.internode.on.net
1191562676 J * Hollow_ ~hollow@proteus.croup.de
1191562676 Q * Hollow Read error: Connection reset by peer
1191562754 N * Hollow_ Hollow
1191563530 J * insitu ~user@abailly.pck.nerim.net
1191563578 M * insitu hello, I just started playing with vserver and it rocks !
1191563591 M * insitu I have a question about cloning/unifying/hashifying
1191563638 M * insitu I would like to create a "master" or template vserver that could be replicated at will, without the overhead of loading the FS with duplicate distribution.
1191563655 M * insitu What is "The Right Way" (tm) to do this ?
1191563739 M * insitu I am using vserver 0.30.214 on debian etch, with kernel 2.6.21-2-vserver-686 from the distro.
1191564212 N * _Hunger Hunger
1191564361 J * nospoonuser ~nospoonus@n18-241.dsl.vianetworks.de
1191564367 J * ntrs__ ~ntrs@79.125.236.189
1191564790 J * virtuoso_ ~s0t0na@pppoe-166.2.110.89-adsl.spbnit.ru
1191564844 Q * harry Ping timeout: 480 seconds
1191565171 J * Punkie ~Punkie@melkor.coolhousing.net
1191565201 Q * virtuoso Ping timeout: 480 seconds
1191565253 J * morten ~morten@85-10-210-201.clients.your-server.de
1191565273 J * JonB ~NoSuchUse@kg1-20.kollegiegaarden.dk
1191566131 J * dna ~dna@p54BCE068.dip.t-dialin.net
1191566240 Q * hparker Read error: Operation timed out
1191566276 M * morten mornin' :-=
1191566371 M * morten mornin'...
1191566389 M * morten oops, screen messed up ...
1191566559 J * balbir_ ~balbir@122.167.81.189
1191566977 Q * balbir Ping timeout: 480 seconds
1191567093 Q * JonB Quit: This computer has gone to sleep
1191567386 J * harry ~harry@d54C2508C.access.telenet.be
1191568055 M * insitu good morning
1191568113 M * daniel_hozac insitu: just build a guest named master, and do vserver ... build -m clone ... -- --source master?
1191568132 M * daniel_hozac (after setting iunlink on the files)
1191568244 M * insitu just wondering where is the vserver command documented on the site ? man page is a bit laconic...
1191568278 M * daniel_hozac vserver --help; vserver - build --help
1191568328 M * insitu obvious :) thx 
1191568350 J * JonB ~NoSuchUse@kg1-20.kollegiegaarden.dk
1191568364 M * insitu forgive my dumbness but what is iunlink 
1191568432 M * daniel_hozac it is the immutable linkage invert attribute, combined with immutable, it is what makes something unified.
1191568724 M * insitu Is it not possible to share same /usr/ directory for example ? This is taken care of by unify/hashify I presume. Mounting a shared directory wouldn't do the trick ?
1191568803 M * daniel_hozac mounting works too.
1191568833 M * daniel_hozac it has a different set of advantages/disadvantages though.
1191568913 M * insitu ability to move the vserver ?
1191569016 M * daniel_hozac well, there's that, and in order for it to be secure, the guests can't have write access.
1191569031 M * daniel_hozac so to install any application, you'd have to do it on the master.
1191569048 M * daniel_hozac which would make it available in all guests.
1191569065 M * insitu sure. You lose isolation of the vservers, that's it ?
1191569080 M * insitu just plain chroot would then be enough ?
1191569108 M * daniel_hozac hmm?
1191569120 M * daniel_hozac as long as it's read-only, it's still secure.
1191569225 Q * JonB Quit: This computer has gone to sleep
1191569683 Q * ^Toad Read error: Operation timed out
1191569760 M * insitu how do I set the iunlink attribute ? 
1191569770 M * daniel_hozac setattr --iunlink
1191569771 J * ^Toad ~tl@tyler.cs.brown.edu
1191569863 Q * ntrs__ Ping timeout: 480 seconds
1191570119 M * insitu find /vserver/master -type f -exec setattr {} --iunlink \; would be ok ?
1191570132 M * daniel_hozac yep.
1191570161 M * insitu ok, just reading the --help, so setattr -R --iunlink is probably better
1191570174 M * daniel_hozac no.
1191570184 M * daniel_hozac you only want to set it on the regular files.
1191570185 M * epicbjorn takes dirs too
1191570228 M * insitu aah. Ok thx
1191570411 M * insitu if I understand correctly, hashify would do something similar but on running instances ?
1191571318 M * morten daniel_hozac : you guys got somethin' new regarding my problem?
1191571842 Q * balbir_ Ping timeout: 480 seconds
1191572086 M * daniel_hozac morten: we know what's causing it, no fix yet though.
1191572104 M * daniel_hozac insitu: pretty much.
1191572363 M * morten daniel_hozac : thx
1191572428 P * friendly12345 
1191572633 M * insitu thx a lot. If you are interested, I could post something about it for the "Success stories" section.
1191572639 J * JonB ~NoSuchUse@130.227.63.19
1191572865 M * insitu if I am successful of course :)
1191573047 M * morten daniel_hozac : you guys got somethin' like a timeline or an idea how long it will take to fix it? 
1191573206 J * Piet ~piet@tor.noreply.org
1191575659 Q * Loki|muh Remote host closed the connection
1191575961 J * Loki|muh loki@satanix.de
1191576257 N * Bertl_zZ Bertl
1191576262 M * Bertl morning folks!
1191576436 M * fb_ hi Bertl :)
1191576709 N * virtuoso_ virtuoso
1191576915 M * JonB hey Bertl 
1191577014 J * DavidS ~david@85.125.165.34
1191577149 Q * insitu Ping timeout: 480 seconds
1191577637 M * daniel_hozac morten: i'd expect it to be fixed today...
1191577689 M * Bertl morten: we just haven't decided how to do it, and we need some detailed testing of course
1191577727 M * Bertl morten: if you feel like helping, you could start testing right away
1191579037 M * morten Bertl : you got some testcases for me? Which infos you need (traces, outputs...)?
1191579135 M * Bertl there are two tests, both involve rebuilding the kernel with a simple patch
1191579153 M * Bertl and then testing the following cases:
1191579184 M * Bertl - binding to 127.0.0.1, binding to 0.0.0.0 (with 1 and 2 guest ips)
1191579215 M * Bertl - address check with lsof/netinfo/ip
1191579290 M * morten ok, you already got this "simple patch"?
1191579311 M * Bertl yes, you can do that with a simple editor
1191579440 M * Bertl include/linux/vs_inet.h at line 61, change:
1191579457 M * Bertl         if ((tmask & NXA_LOOPBACK) &&
1191579459 M * Bertl to
1191579479 M * Bertl oops sorry, sec
1191579534 M * Bertl        if ((addr == IPI_LOOPBACK) &&
1191579536 M * Bertl to
1191579545 M * Bertl        if (0 && (addr == IPI_LOOPBACK) &&
1191579565 M * Bertl then recompile and test
1191579570 M * morten will do
1191579593 M * Bertl what we expect to happen is the following:
1191579607 M * Bertl - binding should work properly, and not mess up the host
1191579624 M * morten gimme a few minutes :-)
1191579634 M * Bertl - addresses shown will be missing the 127.0.0.1 although it should be available for binding
1191579653 M * Bertl yeah, take your time, no need to hurry
1191579691 N * eSa| fede
1191579702 M * Bertl wb fede!
1191579726 M * fede Hi Bertl 
1191579734 M * fede wassup Bertl 
1191579788 M * Bertl everything fine here, and for you?
1191580082 M * morten Bertl : I'll compile the kernel with "Automatic Single IP Special Casing" ... ok?
1191580093 M * Bertl yes, that's fine
1191580096 M * morten aeehm, without
1191580097 M * morten i mean
1191580108 M * morten right now i always have to deactivate it per guest...
1191580110 M * Bertl no, leave that on
1191580124 M * Bertl otherwise we cannot test those cases
1191580138 M * morten then a * binding results in a binding only on the eth ...
1191580181 M * Bertl you can turn it off if you like, but it should be trivial to test with two ips
1191580192 M * Bertl (which will ato-disable it)
1191580204 M * Bertl *auto
1191580260 M * morten i'll leave it on for the moment
1191580297 M * Bertl daniel_hozac: how does that look for you? http://vserver.13thfloor.at/Experimental/delta-lback-fix04.diff
1191580344 M * morten ahh
1191580346 M * morten shutdown
1191580349 M * morten cya soon
1191580350 M * morten :-)
1191580356 Q * morten Quit: BitchX-1.1-final -- just do it.
1191580357 J * bragon_ ~bragon@2001:7a8:aa58::1
1191580398 Q * bragon Read error: Connection reset by peer
1191580410 J * morten ~morten@mail.geek-it.de
1191580434 M * daniel_hozac Bertl: looks good.
1191580436 M * morten back :-)
1191580454 M * morten Bertl : which was the lback diff thing... my history is gone :-)
1191580465 M * JonB is it a security problem to add a lo interface to a vserver guest?
1191580587 M * daniel_hozac JonB: use 2.3.
1191580607 M * JonB daniel_hozac: is that ready for production use?
1191580614 M * daniel_hozac it's devel :)
1191580620 M * JonB great
1191580645 M * JonB maybe i should ask the developers why they feel they need a lo interface with 127.0.0.1
1191580657 Q * nou Ping timeout: 480 seconds
1191580692 M * fb_ daniel_hozac: -bash: kill: (1) - No such process
1191580697 M * fb_ is this normal?
1191580709 M * daniel_hozac does your guest have an init?
1191580717 M * fb_ sure
1191580718 M * fb_ root         1     0  0 Sep25 ?        00:00:00 init [2]  
1191580736 M * daniel_hozac is that a fake init or a real one?
1191580789 M * fb_ if the guys that manage the host didn't change anything without my knowledge, it's normal init
1191580794 Q * PhatJ Read error: Connection reset by peer
1191580853 M * daniel_hozac well, verify that...
1191580877 J * PhatJ ~PhatJ@24-231-253-65.dhcp.aldl.mi.charter.com
1191581005 M * fb_ yup
1191581021 M * fb_ normal etch's init
1191581034 M * daniel_hozac so sysv initstyle?
1191581041 M * fb_ yes
1191581047 M * daniel_hozac then it's a fakeinit.
1191581061 M * fb_ h
1191581063 M * fb_ hm
1191581066 J * nou Chaton@causse.larzac.fr.eu.org
1191581075 M * fb_ now i'm lost :)
1191581095 M * fb_ so what process interprets inittab? 
1191581118 M * daniel_hozac init.
1191581128 M * daniel_hozac which is why you need the plain initstyle to use it ,)
1191581150 M * fb_ then why changes to this file are reflected inside the guest?
1191581173 M * fb_ specifically, it was trying to start login on ttys
1191581194 M * fb_ until i commented this out
1191581217 M * daniel_hozac then you're not using the sysv initstyle ;)
1191581250 M * Bertl morten: http://irc.13thfloor.at/LOG/2007-10/LOG_2007-10-05.txt
1191581347 M * Bertl JonB: developers of what?
1191581404 M * fb_ daniel_hozac: http://paste.linux-vserver.org/6871 then how you explain this?
1191581452 M * daniel_hozac fb_: explain what?
1191581468 M * fb_ is this fakeinit or not?
1191581486 M * daniel_hozac i have no way to tell as you don't have any relevant info in that paste...
1191581500 M * fb_ if it is, why it interprets inittab, if not -- why can't be kill -HUPed?
1191581535 M * fb_ unfortunately, i don't have access to the host
1191581547 M * fb_ nor to the guys who manahe this
1191581568 M * Bertl telling whether it is fake init or not shouldn't be too ahrd
1191581595 M * Bertl (from the guest) just try use anything from the init process
1191581604 M * daniel_hozac e.g. ls /proc/1/fd
1191581605 M * Bertl e.g. the current working dir or similar
1191581663 M * fb_ there's no /proc/1/
1191581727 M * Bertl then there is no init :)
1191581738 M * morten Oct  5 10:53:30 vserver2 named[6355]: socket.c:1151: unexpected error:
1191581738 M * morten Oct  5 10:53:30 vserver2 named[6355]: internal_send: 193.0.14.129#53: Invalid ar
1191581738 M * morten gument
1191581788 M * fb_ and i have it's real pid
1191581803 M * morten Bertl: tcp bindings seem to work, udp not... 
1191581818 M * Bertl interesting
1191581833 M * morten Bertl: is that possible? does it make sense? :-)
1191581841 M * Bertl not really, daniel_hozac?
1191581869 M * daniel_hozac should be using the exact same code nowadays...
1191581908 M * daniel_hozac in what way don't UDP bindings work?
1191581947 M * Bertl morten: maybe let's ignore the funny bind9 for now, and try with something else?
1191581987 M * daniel_hozac e.g. nc
1191582039 M * morten ALL_IP Bindings for UDP result in a binding only on eth... like the single_ip option suppose to force it...
1191582058 M * daniel_hozac even with multiple IP addresses?
1191582065 M * daniel_hozac or NXF_SINGLE_IP removed?
1191582066 M * morten explict binding of a udp port only on localhost results in no binding/function at all
1191582091 M * Bertl ah, so the udp binding uses 127.0.0.1 then .. hmm
1191582099 M * daniel_hozac that shouldn't happen...
1191582099 M * morten single_ip deactivated---
1191582106 M * morten for all guests right now
1191582106 M * Bertl seems we are missing an lback remap there
1191582119 M * morten by (un)setting the nflag for disabling it
1191582159 M * morten default (by kernel compiling options) is to enable single ip for a host...
1191582165 M * morten aehm, guest...
1191582166 M * daniel_hozac yeah...
1191582265 M * morten Bertl : you said it's normal that i can see a lo interface on a guest right now ?
1191582282 M * Bertl you _can_ see it atm?
1191582286 M * morten can't
1191582287 M * morten sorry
1191582289 M * morten :-)
1191582292 M * Bertl okay, yeah, that is fine
1191582295 M * morten k
1191582335 M * daniel_hozac Bertl: hmm, the mapping is done in af_inet.c... that should affect both TCP and UDP, no?
1191582363 M * Bertl but we do not map the destination, no?
1191582410 M * daniel_hozac ah, good point...
1191582434 M * Bertl btw, I like the DaveM comment on UDP :)
1191582450 M * daniel_hozac hehe, yeah.
1191582499 M * morten the one in inet_hashtables? :-)
1191582551 M * daniel_hozac Bertl: well, we do use ip_v4_find_src in UDP too.
1191582564 M * daniel_hozac in spite of the name, that should handle it, no?
1191582582 M * Bertl right, hmm, I guess we need to get some debug traces for that
1191582583 M * daniel_hozac morten: you do have CONFIG_VSERVER_AUTO_LBACK enabled still, right?
1191582590 M * morten right
1191582603 M * Bertl morten: is VSERVER_DEBUG enabled too?
1191582648 M * morten nope
1191582663 M * Bertl could you enable that and rebuild, please ?
1191582683 M * Bertl (requires KERNEL_DEBUG)
1191582704 M * morten http://paste.linux-vserver.org/6872
1191582726 M * Bertl ah, nice ...
1191582741 M * morten i get a lot of errors (even before the patch) on the host kernel...
1191582755 M * Bertl similar to those?
1191582767 M * morten yes
1191582812 M * morten is this enough, or should i rebuild it with VSERVER_DEBUG? 
1191582861 M * Bertl and you don't get those with a vanilla kernel?
1191582957 M * Bertl this is a mainline message, and it seems to have triggered around 2.6.17/18 with sky2 driver
1191583346 M * Chr0nicles would it be wise to place vservers(ftp) on drbd? or just the data
1191583389 M * Bertl bth should be fine
1191583493 J * mattzerah ~matt@121.50.219.188
1191583547 M * morten sky2 driver? ^^
1191583558 M * Chr0nicles k will be running some tests today then :) thx
1191583571 J * jmcaricand_O ~user@d77-216-233-159.cust.tele2.fr
1191583591 M * daniel_hozac Bertl: kernel with delta-lback-fix04.diff works fine here.
1191583743 J * Julius ~julius@p57B263C0.dip.t-dialin.net
1191584038 M * Bertl daniel_hozac: ah, excellent, all expected features? udp/tcp/etc
1191584054 M * daniel_hozac AFAICT.
1191584062 M * Bertl good, tx!
1191584065 M * daniel_hozac everything i've thought to test works fine at least.
1191584115 M * Bertl nevertheless, I think we should investigate morten's issue, maybe we are missing some detail
1191584126 M * Bertl (with the hack patch/change)
1191584162 M * PhatJ is there specific documenation how to use the vserver ... build -m rsync option -- google isn't helping me  :( 
1191584286 M * morten Bertl: i've just tried your manual hack (forcing the var to be false)... i haven't tried http://vserver.13thfloor.at/Experimental/delta-lback-fix04.diff
1191584356 M * daniel_hozac PhatJ: vserver ... build --help?
1191584382 M * PhatJ i've read it, but it doesn't explain much at all 
1191584412 M * PhatJ i think i may have found something on google 
1191584479 M * PhatJ actually - there is a doc that says to just rsync the /usr/lib/vservers/*  and /etc/vserver/*
1191584516 M * PhatJ on the host -   is that typical ?
1191584633 M * PhatJ i'm looking to do this the right way 
1191584657 M * PhatJ esp since i'm dealing with cloning a production usage situation 
1191585011 M * Bertl morten: that's fine, but maybe try the fix04 for now
1191585020 M * Bertl morten: (probably fixes your issues)
1191585159 M * morten Bertl : ok, as it looks to me right now.. the guests lost complete ipv4 connectivity using the one line patch...
1191585163 M * morten spencer:/# ping 212.76.144.43
1191585163 M * morten connect: Invalid argument
1191585190 M * morten ^^
1191585190 M * morten spencer:/# telnet 212.86.xx.xx
1191585190 M * morten Trying 212.86.xx.xx...
1191585190 M * morten telnet: Unable to connect to remote host: Invalid argument
1191585196 M * morten î'l try the delta patch
1191585822 M * morten hmpf, tried the delta patch against linux-2.6.22.9 vanilla+linux-2.6.22.9-vs2.3.0.26.diff
1191585828 M * morten got these hunks, etc...
1191585829 M * morten http://paste.linux-vserver.org/6873
1191586155 M * Bertl hmm ... shouldn't happen
1191586216 M * Bertl applies cleanly here, maybe you somehow messed up your sources?
1191586282 M * morten tar xf linux-2.6.22.9.tar; ln -s linux-2.6.22.9 linux; cd linux; patch -p1 <../patch-2.6.22.9-vs2.3.0.26.diff; patch -p1 <../delta-lback-fix04.diff
1191586300 M * morten maybe i got another (old?) patch-2.6.22.9-vs2.3.0.26.diff?
1191586317 M * Bertl no, those are not updated in place, for a good reason
1191586372 M * Bertl let me check that there isn't a mess up in my trees ...
1191586435 J * julius_ ~julius@p57B25398.dip.t-dialin.net
1191586467 M * Bertl morten: you did remove 'linux' before?
1191586493 M * Bertl I mean, if 'linux' already existed, your ln -s will not do what you expected it to do :)
1191586642 M * morten vhost1:/usr/src# history | grep "rm linux"
1191586642 M * morten   583  rm linux
1191586774 M * Bertl hmm, indeed there is some problem in my trees, sec
1191586868 Q * Julius Ping timeout: 480 seconds
1191586872 Q * JonB Ping timeout: 480 seconds
1191587460 J * hparker ~hparker@linux.homershut.net
1191587776 M * Bertl morten: try with -l now (as aptch option) seems to be whitespace brokeness
1191587945 M * hparker morning all
1191587952 M * Bertl morning hparker!
1191588720 Q * dna Read error: Connection reset by peer
1191588744 J * dna ~dna@p54BCE068.dip.t-dialin.net
1191588783 Q * Aiken Quit: Leaving
1191589485 M * morten Bertl: i still can't initialize any outgoing connections from the guest anymore :-(
1191589545 M * morten vserver4:/# ping 209.85.129.104
1191589545 M * morten connect: Invalid argument
1191589575 M * morten telnet 209.85.129.104 80
1191589575 M * morten Trying 209.85.129.104...
1191589575 M * morten telnet: Unable to connect to remote host: Invalid argument
1191589575 M * Bertl are you sure that your IP(s) are configured correctly?
1191589586 M * Bertl and the routing is fine?
1191589650 M * morten "Invalid argument" doesn't sound like incorrect routing.. does it? just a second...
1191589698 J * JonB ~NoSuchUse@kg1-20.kollegiegaarden.dk
1191589742 M * Bertl morten: let's get an strace -fF of the issue, and then we see what we can get with a Linux-VServer debug run
1191589744 J * ema ~ema@rtfm.galliera.it
1191589752 M * Bertl wb JonB! ema!
1191590316 M * ema hi Bertl 
1191590359 M * morten gotta go.. i'll be back :-)
1191590449 M * Chr0nicles vserver/drbd works \o/
1191590458 M * Chr0nicles now trying unionfs
1191590461 M * morten before i go...
1191590464 M * morten Bertl: http://paste.linux-vserver.org/6874
1191590488 M * morten thanks so far!
1191590495 Q * morten Quit: byeieieiei...
1191590687 Q * DavidS Quit: Leaving.
1191590818 M * Bertl well, as usual, ping isn't a good example :/
1191590827 M * daniel_hozac i'm seeing it with nc too...
1191590839 Q * JonB Quit: This computer has gone to sleep
1191590847 M * Bertl so what's going wrong here?
1191590848 M * daniel_hozac i have no idea what the problem is though, i don't think we modified this behaviour at all.
1191590874 M * daniel_hozac http://paste.linux-vserver.org/6875 is with 127 > debug_net
1191590878 M * Bertl should be easy to check by reverting to older code
1191590905 M * daniel_hozac 192.168.20.2 is the address assigned to the guest, 192.168.102.6 is the source address of the default route.
1191591022 M * daniel_hozac thing is, i don't see any failures.
1191591231 M * Bertl and you get EINVAL too?
1191591248 M * Bertl do you have an strace -fF at hand for this case?
1191591267 M * daniel_hozac seems to only happen with NXF_SINGLE_IP disabled.
1191591300 M * Bertl even with two IPs assigned?
1191591330 M * matti Hi Bertl 
1191591377 M * daniel_hozac Bertl: yeah.
1191591405 Q * julius_ Remote host closed the connection
1191591474 M * daniel_hozac Bertl: ip_v4_find_src, line 199 right before found:, shouldn't that be the guest's first address rather than the lback address?
1191591575 M * Bertl that actually depends on the case
1191591585 M * Bertl with SINGLE_IP, yes, definitely#
1191591619 M * Bertl without that, we had the loopback ip there as last option
1191591635 M * Bertl so then it depends on LBACK yes/no
1191591672 M * Bertl but the remapping is done _after_ that
1191591690 M * Bertl so that is definitely wrong here, as we actually want 127.0.0.1 there if at all
1191591716 M * Bertl so IMHO the better check would be something like:
1191591779 M * Bertl found = (nx_info_flags(nxi, NXF_SINGLE_IP, 0) ? nxi->v4.ip[0].s_addr : IPI_LOOPBACK;
1191591859 M * Bertl but I think we should rerun the __ip_route_output_key(rp, fl); in this case :)
1191591928 M * Bertl but let me go through the code once again, because we do not even execute this code in the single IP case
1191592119 M * Bertl daniel_hozac: in your test case, the first assigned IP has been tried, yes?
1191592164 Q * blizz Ping timeout: 480 seconds
1191592388 J * blizz ~stephan@evilhackerdu.de
1191592402 M * Bertl daniel_hozac: just verified, the old code used the first assigned ip, unless dst is loopback, in which case the loopback address was used
1191592721 M * Bertl so, yes, we should use primary there
1191594114 Q * Punkie Quit: Odcházím
1191594198 J * meandtheshell ~markus@85-127-110-169.dynamic.xdsl-line.inode.at
1191596150 M * Bertl okay, off for a nap .. back later ...
1191596155 N * Bertl Bertl_zZ
1191596594 J * JonB ~NoSuchUse@kg1-20.kollegiegaarden.dk
1191597232 Q * JonB Quit: This computer has gone to sleep
1191599217 N * ensc Guest967
1191599227 J * ensc ~irc-ensc@p54B4D668.dip.t-dialin.net
1191599332 Q * Guest967 Ping timeout: 480 seconds
1191601439 Q * jmcaricand_O Quit: ERC Version 5.0.2 $Revision: 1.726.2.11 $ (IRC client for Emacs)
1191601852 Q * mountie Ping timeout: 480 seconds
1191602252 J * JonB ~NoSuchUse@kg0-194.kollegiegaarden.dk
1191602428 Q * meandtheshell Quit: Leaving.
1191602739 N * Bertl_zZ Bertl
1191602743 M * Bertl back now ...
1191602826 M * JonB hey Bertl 
1191603557 J * mountie ~mountie@trb229.travel-net.com
1191603564 M * Bertl wb mountie!
1191603574 Q * ema Quit: leaving
1191604184 Q * mountie Remote host closed the connection
1191604583 J * esa ~esa@ip-87-238-2-45.adsl.cheapnet.it
1191604597 Q * fede Ping timeout: 480 seconds
1191604759 Q * bzed Ping timeout: 480 seconds
1191604958 J * bzed ~bzed@devel.recluse.de
1191605195 J * jescheng ~jescheng@proxy-sjc-1.cisco.com
1191605213 M * Bertl welcome jescheng!
1191605237 M * jescheng hi Bertl. 
1191605265 M * jescheng when i do a vserver sync stop, i see it takes > 5 minute to timeout and stop
1191605281 M * jescheng but my timeout has been set to 30s
1191605303 M * Bertl what util-vserver version/kernel/patches do you use?
1191605335 M * jescheng vserver 2.01/kernel 2.6.14.3
1191605407 M * jescheng i see in the --debug that it's stuck on acquiring a lock file
1191605425 M * Bertl give me a second to double check something
1191605437 M * Bertl (and get me the util-vserver version in the meantime :)
1191605458 M * jescheng and i should also say that the "vserver start " is stuck in a loop (probably holding the lock)
1191605513 M * Bertl in general I would say, updating to recent versions will fix this
1191605536 M * jescheng util-vserver-0.30.210
1191605557 M * Bertl all quite ancient, any reasons for using such old versions?
1191605559 Q * PhatJ Read error: Connection reset by peer
1191605585 J * PhatJ ~PhatJ@24-231-253-65.dhcp.aldl.mi.charter.com
1191605638 M * jescheng we are planning to move to new version in the next release, but cannot do now
1191605728 M * Bertl i.c. so what _can_ you change right now? :)
1191605767 M * jescheng well just wondering if it's something expected...or is it something i did wrong
1191605787 M * jescheng should "vserver stop" also kill the "vserver start" process if start is in a loop?
1191605789 M * Bertl nah, I think it is a bug, daniel_hozac will have the details I guess
1191605810 M * Bertl but I'm pretty sure we fixed it a year ago or so 
1191605836 M * Bertl you can try if 'vkill' is able to stop the guest when 'hanging'
1191605855 M * Bertl but basically you can also solve the issue by making your guest abort properly when signalled
1191605870 M * Bertl (in which case the timeout doesn't even matter)
1191605890 M * jescheng so we can do something like kill (vserver pid) 
1191605900 M * Bertl yes, vkill does that
1191605916 M * Bertl I just checked, the kernel side interface for that is in your kernel
1191605928 M * Bertl (not sure the tools support that though)
1191605931 J * Piet_ ~piet@tor.noreply.org
1191605940 M * jescheng ok great... do we need to worry about stuff left behind...process ...or files)
1191605959 M * Bertl no, the vkill will terminate all processes
1191605985 M * Bertl together with that, files and similar will get eliminated
1191605997 M * Bertl sockets will time out with some delay
1191606019 M * jescheng great! I think that will do. we do have it in our version (what luck :))
1191606082 M * Bertl may I ask what you use Linux-VServer for? sounds like a larger project with fixed schedules and releases :)
1191606279 Q * Piet Ping timeout: 480 seconds
1191606810 M * jescheng yup vkill works well
1191606844 M * jescheng about the project..not sure if i can say :)
1191606855 M * Bertl well, np if not :)
1191606879 M * jescheng yup,  thanx a lot for your help! vserver is great!
1191606894 M * Bertl have fun! feel free to hang around!
1191606991 J * jm_caricand ~user@d77-216-233-159.cust.tele2.fr
1191607001 M * Bertl welcome jm_caricand!
1191607009 M * jm_caricand Hi Bertl
1191607204 Q * jescheng Remote host closed the connection
1191607223 J * jescheng ~jescheng@proxy-sjc-1.cisco.com
1191607599 Q * matti Ping timeout: 480 seconds
1191607694 Q * dna Quit: Verlassend
1191607873 Q * jescheng Quit: Leaving
1191608602 J * matti matti@acrux.romke.net
1191608913 M * Bertl wb matti!
1191609249 J * faheem ~faheem@cpe-065-190-207-119.nc.res.rr.com
1191609255 M * Bertl welcome faheem!
1191609984 M * faheem Bertl: Hi.
1191609992 M * faheem Just visiting.
1191609998 M * Bertl np
1191610010 M * Bertl feel free to hang around .. or ask stuff :)
1191610019 M * faheem I'm trying to set up vserver on Debian, but I'm having networking problems.
1191610029 M * Bertl how so?
1191610039 M * faheem I'm using newvserver from vserver-debianutils.
1191610057 M * daniel_hozac stop :)
1191610061 M * Bertl well, better drop that one and go for 'vserver' from util-vserver :)
1191610066 M * faheem However, even while running, at the end it can't get networking.
1191610086 M * faheem Bertl: Something wrong with newvserver?
1191610104 M * Bertl yeah, it's kind of a third leg out of wood :)
1191610134 M * Bertl you don't need it, and if you use it, it'll break :)
1191610158 M * faheem Bertl: Oh. Anyway, I tried once and it worked, then the second time it didn't. I did upgrade in the middle, I think, but still...
1191610179 M * faheem So the generally recommended thing to use is vserver from util-vserver, then?
1191610191 M * Bertl but let's ingnore the newvserver part, what _is_ the actual problem?
1191610203 M * Bertl faheem: yes, for several reasons:
1191610225 M * faheem Well, when I go into the vserver, I can't get networking. Is it supposed to work out of the box?
1191610226 M * Bertl first, there is nothing what newvserver can do, which cannot be done with util-vserver
1191610249 M * Bertl second, newvserver only works on/for debian, so you lose some of the functionality
1191610266 M * Bertl third, the argument names used in newvserver are misleading
1191610277 M * Bertl s/argument/option/
1191610318 M * faheem Bertl: Ok. I upgraded to 0.30.214-3 on Debian (etch backports). Is there any potential problem with that?
1191610319 M * Bertl faheem: depends on your config, if you have assigned a public ip, it should work out of the box (given that the resolver is configured properly inside)
1191610338 M * Bertl faheem: no, no known problems with 0.30.214
1191610380 M * faheem Bertl: No, I'm using an internal address like 192.168.1.202. My machine is sitting behind a router and has 192.168.1.200.
1191610382 M * daniel_hozac at least not with the etch backports version.
1191610410 M * faheem Seems to work out of the box with at least one vserver.
1191610410 J * morten ~morten@mail.geek-it.de
1191610411 M * Bertl faheem: and the router allows 192.168.1.202 to reach the internet?
1191610416 M * morten hi everyone.
1191610421 M * Bertl wb morten!
1191610438 M * faheem  Bertl: Yes, the router is not blocking outgoing stuff at all.
1191610449 M * morten Bertl: ignore the non-connectivity-at-all thing i reported at the end.. somethin' was wrong with my host ^^
1191610456 M * faheem Nice friendly people you are here. :-)
1191610468 M * morten Bertl : i will now test the delta patch again :-)
1191610475 M * Bertl faheem: okay, please try the following on the host: 'ping -I 192.168.1.202 www.google.com'
1191610488 M * Bertl morten: give me a second, I'll upload a test version for you
1191610493 M * Bertl faheem: thanks!
1191610512 M * morten a new one? :-) okeydoke...
1191610514 M * faheem  Bertl: No problem with that.
1191610522 M * daniel_hozac morten: the Invalid argument is legit.
1191610528 M * faheem pinging, with 192.168.1.202, I mean.
1191610543 M * Bertl faheem: good, and from inside the guest? what do you get there?
1191610556 M * Bertl faheem: also try with the ip from the previous test (for google)
1191610567 M * faheem  Bertl: Same command?
1191610574 M * Bertl yes
1191610599 M * Bertl morten: http://vserver.13thfloor.at/Experimental/patch-2.6.22.9-vs2.3.0.26.4.diff
1191610628 J * ntrs__ ~ntrs@79.125.244.223
1191610634 M * faheem Bertl: test2:/# ping -I 192.168.1.202 google.com
1191610634 M * faheem ping: unknown host google.com
1191610645 M * faheem No connectivity at all.
1191610649 M * Bertl now try with the ip you got before
1191610660 M * FaUl arr, no recent change-logs ;-)
1191610667 M * FaUl it would be so much easyer to check ;-)
1191610674 M * daniel_hozac hmm?
1191610679 M * faheem Bertl: Sorry, don't follow. What IP?
1191610685 M * daniel_hozac faheem: google.com's IP.
1191610688 M * Bertl faheem: e.g. 209.85.129.99
1191610706 M * daniel_hozac FaUl: you mean for 2.2?
1191610710 M * faheem Bertl: Oh, you mean bypass the nameserver?
1191610715 M * Bertl yep
1191610738 M * FaUl daniel_hozac: 2.3 would be even nicer ;-)
1191610742 M * daniel_hozac 2.3 is updated.
1191610743 M * faheem ping -I 192.168.1.202 64.233.169.99
1191610743 M * faheem PING 64.233.169.99 (64.233.169.99) from 192.168.1.202 : 56(84) bytes of data.
1191610743 M * faheem 64 bytes from 64.233.169.99: icmp_seq=1 ttl=243 time=22.9 ms
1191610755 M * faheem Oh, that works. Nameserver problem, apparently?
1191610757 M * Bertl so, the problem is your resolv.conf
1191610766 M * Bertl and that is likely to be caused by newvserver :)
1191610780 M * FaUl daniel_hozac: ah, oops
1191610783 M * daniel_hozac granted, util-vserver doesn't do anything resolvery unless you tell it to.
1191610784 M * faheem Bertl: Ah, I see. It is set to 
1191610788 M * faheem search home.earth.
1191610791 M * FaUl daniel_hozac: i missinterpreted the color of the link , sorry
1191610795 M * faheem Which is not very useful.
1191610802 M * Bertl faheem: you can fix it inside the guest in /etc/resolv.conf
1191610853 M * faheem  Bertl: Thanks very much. That was a very efficient piece of debugging.
1191610870 M * faheem Bertl: Should have been able to figure it out myself, but somehow I'm always missing the obvious,
1191610873 M * FaUl check the assigned IP addresses networks to find the most appropriate route <- what does that mean? no more sourcerouting?
1191610877 M * Bertl faheem: you're welcome! feel free to hang around as I said ...
1191610912 M * faheem Should I set the /etc/resolv.conf to look the same as the host?
1191610931 M * Bertl in your case, I think so, unless your host has a dns proxy or such
1191610949 M * daniel_hozac FaUl: it means: if you assign x.y.z.2 and z.y.x.2 to a guest and connect to z.y.x.5, use z.y.x.2 as the source IP, rather than the first.
1191610968 M * faheem Bertl: No, nothing special. Just an ordinary machine sitting behind a router on cable internet.
1191610988 M * Bertl then identical resolv.conf makes sense
1191611022 M * faheem Bertl: Would vserver have created the resolv.conf in a more sensible fashion, then?
1191611028 M * FaUl daniel_hozac: ah, ok
1191611045 M * Bertl faheem: daniel_hozac can give you the details here
1191611051 M * morten Bertl : http://paste.linux-vserver.org/6878 .. can i ignore this..? :-)
1191611076 M * faheem Usually, I use debian specific tools because they do debian specific things, and generally work fine. But there are always exceptions, I suppose.
1191611083 M * daniel_hozac faheem: it does what you tell it to do. you can put the resolv.conf you want for new guests in /etc/vservers/.defaults/files/resolv.conf
1191611086 M * Bertl morten: hmm, let me double check that
1191611142 M * faheem One nice thing about using Debian is that there enough technically minded people using it that egregious stupidity of the technical variety usually gets squashed pretty speedily.
1191611148 M * morten at least, it's just a warning :-)
1191611159 M * daniel_hozac Bertl: it works fine for me now.
1191611166 M * Bertl daniel_hozac: excellent!
1191611188 M * daniel_hozac morten: you didn't get that warning before?
1191611192 M * daniel_hozac morten: what gcc is that?
1191611211 M * faheem /etc/vservers/.defaults/files/ is currently empty. Is that normal?
1191611246 M * daniel_hozac yes.
1191611262 M * morten daniel_hozac : not sure.. i'll will ignore it by now... :-) gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
1191611283 M * Bertl morten: I don't see what gcc is seeing there
1191611288 M * daniel_hozac that's essentially equivalent to what i'm using...
1191611292 M * Bertl morten: looks like a false positive
1191611300 M * morten Bertl : k
1191611309 M * daniel_hozac yeah, IIRC 4.0 had a lot of those.
1191611555 M * faheem So, can anyone point me to a usage guide for installing vservers on Debian using vserver?
1191611589 M * JonB faheem: it'sm under documentation on the homepage
1191611611 M * Bertl faheem: also a good source for information is 'vserver - build --help'
1191611644 M * faheem http://linux-vserver.org/Installation_on_Debian ?
1191611669 M * JonB faheem: yes
1191611719 M * faheem Someone should tell the maintainer of vserver-debiantools that it is deprecated. :-)
1191611726 M * faheem It's still under development.
1191611746 M * Bertl well, the maintainer is ola, yes?
1191611747 M * JonB faheem: yeah, you do that
1191611764 M * daniel_hozac me and ola had a rather lengthy discussion about it.
1191611784 M * Bertl short summary, ola is deprecated too? :)
1191611789 M * daniel_hozac haha.
1191611826 M * faheem Ok, I'll try using vserver as described on the installation page. Are you guys developers, BTW?
1191611853 M * daniel_hozac that's what the Developers page would have you believe, anyway.
1191611866 M * Bertl faheem: we do some development now and then :)
1191611894 M * JonB when you are not answering my (clueless?) questions
1191611929 M * Bertl hehe, see topic :)
1191611954 M * faheem So I see. :-) I was just wondering, what the situation is, with regard to getting vserver into the kernel. Apolgies in advance if this is a sensitive topic.
1191611982 M * daniel_hozac parts are getting integrated, though we're not actively working on that.
1191612006 M * faheem daniel_hozac: Any idea when patches will no longer be necessary?
1191612013 M * Bertl daniel_hozac: well, at least not with patches
1191612022 M * daniel_hozac well, for Linux-VServer, they will always be necessary.
1191612028 M * faheem daniel_hozac: Why?
1191612041 M * JonB Bertl: yeah i know, i like the topic
1191612044 M * daniel_hozac because no one solution is ever going to make it into the kernel whole sale.
1191612045 M * Bertl because mainline is heading towards heavier virtualization
1191612060 M * daniel_hozac it's bits and pieces, most of it entirely new code...
1191612065 M * Bertl and Linux-VServer is still focusing on lightweight isolation
1191612072 M * faheem Bertl: You mean like Xen?
1191612084 M * JonB daniel_hozac: didnt they include one solution lately ?
1191612094 M * Bertl yes, the aim is to have the features of Xen but at the OS level
1191612102 M * daniel_hozac JonB: i'm talking OS-level virtualization.
1191612130 M * daniel_hozac mainline is nowhere near complete in that area right now, though there are various patches.
1191612159 M * JonB daniel_hozac: okay, but does that include where you can run copies of the same kernel? maybe called kvm?
1191612170 M * Bertl yep, that got merged
1191612177 M * daniel_hozac KVM runs separate kernels, that's not OS-level.
1191612200 M * faheem Fortunately Debian has pretty good support for Xen and Vserver, so it is not too bad. I'd hate having to patch stuff myself. Still, it would be better if it was in the kernel.
1191612281 M * JonB daniel_hozac: are there competing OS level virtulization ?
1191612320 M * Bertl JonB: yes, there is a solution from IBM, two differenc Linux-VServer spinoffs and OpenVZ
1191612320 M * faheem Well, you guys have been really great. Nothing beats having your questions answered by the project leader. In terms of friendliness you are up there with #mercurial. :-)
1191612355 M * Bertl faheem: good to hear!
1191612366 M * daniel_hozac Bertl: two? i know of FreeVPS, what's the other one?
1191612398 M * Bertl hmm, we had a page listing those :)
1191612406 M * JonB can they do anything you can not? or are they doing anything better?
1191612448 M * morten Bertl & daniel_hozac ... 2.6.22.9-vs2.3.0.26.4 looks good to me on the first look... :-) me and some "guests :-)" will test it further... 
1191612458 M * Bertl JonB: most of them focus on snapshoting and complete virtualization
1191612467 M * morten thanks for the fast fix... :-)
1191612476 M * morten i'll give u some feedback asap...
1191612477 M * Bertl morten: okay, great! let us know how it goes!
1191612499 M * JonB Bertl: what do you mean by complete virtulization?
1191612521 N * Piet_ Piet
1191612525 M * Bertl JonB: e.g. network stack virtualization or pid virtualization
1191612544 M * Bertl JonB: has more overhead, but simplifies checkpointing and similar
1191612557 M * faheem Light-weight virtualization is very useful. I think of it as a substitute for chroots, which are very klunky.
1191612565 M * JonB okay, so your focus is the least overhead possible?
1191612582 M * Bertl daniel_hozac: sorry, can't remember, so for now, let's assume there is only one spinoff :)
1191612591 M * faheem Most of the time, you don't need heavy virtualization unless you are trying to run different OS's on top of the host.
1191612605 M * Bertl JonB: least overhead, most sharing and least intrusive
1191612610 M * mnemoc i first knew vserver as "bsd-jails for linux" :p
1191612632 M * Bertl mnemoc: and now you know it as bsd-jails on steroids :)
1191612641 M * mnemoc heheh :D
1191612642 M * daniel_hozac i like to think of it as "anything more than 1% overhead is a bug".
1191612666 M * Bertl actually I think that anything noticeable is a bug ...
1191612698 M * JonB Bertl: do you mean benchmarkable or human noticeable?
1191612714 M * Bertl and although lately I didn't do much testing in this regard, the last tests we did showed no measureable overhead for typical loads
1191612738 M * Bertl JonB: you can, of course, do artifical tests which show overhead
1191612762 M * Bertl JonB: but we can conter those with artifical tests which show faster than real-thing speeds :)
1191612816 M * JonB Bertl: my point was that humans can more easily be deceived and that most people doesnt notice 10%
1191612832 M * daniel_hozac try telling that to a Gentoo user :)
1191612852 M * Bertl JonB: I meant typical benchmarks
1191612879 M * JonB Bertl: ok
1191612896 M * JonB daniel_hozac: heh
1191612990 Q * mugwump Ping timeout: 480 seconds
1191613023 J * bonbons ~bonbons@2001:960:7ab:0:20b:5dff:fec7:6b33
1191613030 J * Julius ~julius@p57B25398.dip.t-dialin.net
1191613034 M * Bertl JonB: if you find a benchmark which is worse in a guest than on the host (statistically representativ) please let us know, we'll investigate and hopefully fix that
1191613070 M * Bertl +e
1191613085 M * JonB Bertl: i rarely benchmark, because i dont get into situations where i overload the servers that much
1191613092 M * hparker daniel_hozac: I resemble that remark
1191613096 M * JonB i leave benchmarking to gentoo users
1191613111 M * JonB REDACTED!
1191613119 M * hparker And vserver works just fine on gentoo ;)
1191613131 M * hparker Though i've never benchmarked it ;)
1191613173 Q * JonB Quit: This computer has gone to sleep
1191613192 M * hparker Didn't mean to chase him off
1191613205 M * Bertl hmm, seems his apple book was more tired than he :)
1191613416 M * faheem Is the recommended way of sharing /home from the host with the guests using mount bind? I couldn't see any other suggestions.
1191613425 M * daniel_hozac yep.
1191613435 M * faheem daniel_hozac: thanks.
1191613470 M * Bertl faheem: you can put that mount into the guest config's fstab
1191613512 M * faheem Bertl: Um, wouldn't it need to be in the hosts fstab? That is where I put it when using chroot.
1191613532 M * faheem Bertl: The guest is not aware of the hosts config, surely?
1191613551 M * Bertl if you put it into the guest's config (not the guest's fstab) then it will be mounted on guest startup
1191613573 M * faheem Bertl: Oh, sorry. You mean /etc/vservers/.default?
1191613582 M * daniel_hozac no, /etc/vservers/<guest>/fstab
1191613587 M * Bertl right :)
1191613602 M * matti Bertl: :)
1191613613 M * Bertl hey matti! back again?
1191613652 J * mountie ~mountie@trb229.travel-net.com
1191613669 M * matti Oops.
1191613671 M * matti Yes.
1191613684 M * Bertl wb mountie!
1191613712 M * matti Bertl: Call me "channel log collector" ;p
1191613713 M * matti ;D
1191613724 M * faheem Is it reasonable to add an fstab to defaults?
1191613745 M * daniel_hozac well, except that it doesn't work, sure! :)
1191613758 M * faheem daniel_hozac: Huh?
1191613793 M * daniel_hozac the fstab is per-guest.
1191613798 M * daniel_hozac .defaults is not consulted.
1191613808 M * faheem daniel_hozac: Oh, Ok.
1191613894 M * faheem Can vserver handle anything but etch? Eg. lenny, unstable... Or does it just hand it over to deboostrap?
1191613914 M * Bertl all flavors, just choose :)
1191613938 M * daniel_hozac if you apt-get install yum, you'll get a larger pool too...
1191613962 M * Bertl vserver lenny32 build -m debootstrap --context 10105 --hostname lenny32.debian.org --interface eth1:10.1.5.32/24 -- -d lenny -m http://ftp.debian.org/debian -- --arch i386
1191613968 M * Bertl (just an example :)
1191613996 M * Bertl I really have to test all the distros once again and write a page about that
1191614013 M * Bertl (or ar there any volunteers for that?)
1191614057 Q * puck Ping timeout: 480 seconds
1191614076 J * puck` ~puck@leibniz.catalyst.net.nz
1191614125 M * faheem Bertl: Thanks, but What's with all the -- ?
1191614138 M * daniel_hozac separates the different parts of the command.
1191614171 M * daniel_hozac first are generic vserver ... build options. second part are options specific to the chosen method (debootstrap). the third part are options which will be passed directly to debootstrap.
1191614205 M * faheem daniel_hozac: Ok. Add to page?
1191614247 M * Bertl faheem: feel free to do so
1191614572 Q * maddoc Ping timeout: 480 seconds
1191614593 M * faheem Bertl: Added stuff about --. Probably should not add yum stuff without testing it.
1191614648 J * Aiken ~james@ppp121-45-249-108.lns2.bne4.internode.on.net
1191614690 M * Bertl wb Aiken! how's going?
1191614731 M * faheem tested using vserver as per the page. Wouldn't hurt to add a friendly message like
1191614754 M * faheem now type vserver test  start, as newvserver does. :-)
1191614802 M * Bertl feel free to do so too :)
1191614815 M * Aiken Bertl, life is good down under. Who is the gentoo + vserver person?
1191614827 M * daniel_hozac Hollow and phreak``.
1191614827 M * Bertl Aiken: probably Hollow 
1191614867 M * Hollow pong :)
1191614888 M * Aiken I am moving my machines to gentoo
1191614889 M * faheem Bertl: No, I meant in the output of vserver.
1191614897 M * Hollow Aiken: good idea :)
1191614906 M * faheem The wiki page already has it. 
1191614918 M * Bertl faheem: ah, well, I guess that drives you nuts after a few hundred runs :)
1191614931 M * Aiken I think there maybe had been different base layout. Is that still the case or is it fine with a std image?
1191614943 M * Bertl faheem: I think we prefer the unix approach over the M$ wizzards :)
1191614945 M * Aiken I had planed on starting with a stage3 with the vserver
1191614964 M * daniel_hozac Aiken: http://people.linux-vserver.org/~hollow/stages/
1191615009 M * Hollow Aiken: with >=baselayout-2 things work out of the box, but baselayout-2 is not stbale yet, so it's not in the "official" stages
1191615018 M * Hollow but the link has some stages with baselayout-2
1191615021 M * Aiken the bit I am not looking forward to is my red hat 6.2 server with a 2.4 kernel and changing it to gentoo + 2.6 kernel and migrating it's guests
1191615033 M * daniel_hozac haha
1191615038 M * daniel_hozac that's quite a migration.
1191615042 M * Hollow :)
1191615061 M * Aiken they might end up full rebuilds yet but wanted to have a look at migration first
1191615062 M * faheem Bertl: Ok, fair enough. Though, while I agree that tools should not be overly chatty, little friendly reminders never bother me.
1191615097 M * Aiken daniel_hozac, it was an interesting exercise getting vserver working on a rh6.2 box to start with, how much harder can it be?  :)
1191615120 A * hparker bets that was... Interesting...
1191615420 J * maddoc maddoc@social.ostruktur.com
1191615428 M * Bertl wb maddoc!
1191615448 M * faheem I don't see an option to vserver to put it in a specific directory. I'm using LVM volumes, and mounting them at /mnt/test*vserver,
1191615518 M * daniel_hozac it's better to mount them at /vservers/..., as you'll traditionally have the barrier set on /vservers.
1191615518 M * Bertl --rootdir ?
1191615540 M * faheem daniel_hozac: barrier set?
1191615558 M * mnemoc *G*
1191615578 M * Bertl faheem: the barrier is a mechanism to make the chroot secure
1191615626 M * faheem Bertl: Sorry, don't know what you mean. Chroot? What chroot?
1191615649 M * faheem --rootdir is not mentioned in the output of --help or in the man page.
1191615651 M * Bertl the guest lives in a chroot environment (in a guest private namespace, if selected)
1191615671 M * Bertl faheem: it is here, on the previously suggested 'vserver - build --help'
1191615684 M * Bertl twice even :)
1191615691 M * daniel_hozac really? :)
1191615710 M * daniel_hozac oh, you mean the usage and the help text?
1191615716 M * Bertl yeah :)
1191615780 M * faheem Bertl: Blimey, that is one elusive help command. :-)
1191615790 Q * Julius Remote host closed the connection
1191615793 M * faheem I'd better make a note.
1191615808 M * Bertl faheem: and more important, it is almost always up to date
1191615825 M * faheem daniel_hozac: Yes.
1191615832 M * danman hi
1191615839 M * Bertl hey danman!
1191615866 M * faheem daniel_hozac: Do you suggest mounting my lvm volumes on /vservers?
1191615889 M * Bertl well, you can also let the tools do that for you :)
1191615900 M * daniel_hozac (once you've built the guests)
1191615908 M * faheem Bertl: How so?
1191615910 M * Bertl (by just putting it into the fstab)
1191615965 M * faheem Bertl: Oh, you mean the vserver build will mount the vserver volume if not mounted?
1191615981 M * Bertl the build not, but the startup will
1191616005 M * faheem Bertl: Well, I'll just leave it mounted. No biggie.
1191616016 M * Bertl i.e. mount it for the guest install, and after that, put the lvm into the geust's fstab
1191616117 M * faheem Bertl: You guys are using chroots? I though this was all high-powered virtualization stuff?
1191616144 M * Bertl it is all high-powered isolation stuff
1191616155 M * Bertl with fancy (name)spaces :)
1191616275 M * Bertl and chroot is the mechanism used for filesystem isolation
1191616292 Q * puck` Ping timeout: 480 seconds
1191616386 M * daniel_hozac chroot works well, why would we reimplement it?
1191616415 M * faheem daniel_hozac: Ok. Anyway, so /vservers is a better place than /mnt, then?
1191616446 M * Bertl whatever you prefer actually, just make sure the barrier is intact
1191616452 M * daniel_hozac well, where you put them doesn't really matter.
1191616494 M * faheem Bertl: Excuse my cluelessness, but I've no idea what this barrier is, or how to check for it being intact. :-)
1191616503 M * daniel_hozac showattr <path>
1191616529 M * faheem daniel_hozac: What should that look like?
1191616529 M * Bertl http://linux-vserver.org/Secure_chroot_Barrier
1191616541 M * faheem Bertl: Thanks.
1191616577 M * Bertl you're welcome! 
1191616735 M * faheem I get showattr /mnt/testvserver/
1191616735 M * faheem ---Bui- /mnt/testvserver/
1191616735 M * faheem ---bui- /mnt/testvserver/lost+found
1191616735 M * faheem ---bui- /mnt/testvserver/test1
1191616746 M * faheem Is that Ok?
1191616754 M * daniel_hozac capital B means it's set.
1191616757 M * Bertl if /mnt/testvserver/test1 is your guest's root, then yes
1191616788 M * faheem Bertl: Yes it is.
1191617145 M * Bertl daniel_hozac: maybe it would be an idea to have a really simple/trivial script to do some sanity checks?
1191617156 M * jm_caricand q
1191617162 Q * jm_caricand Quit: ERC Version 5.0.2 $Revision: 1.726.2.11 $ (IRC client for Emacs)
1191617170 M * Bertl daniel_hozac: I'm thinking about something checking proper barrier and context settings and such
1191617187 M * Bertl (for all configured guests)
1191617189 M * daniel_hozac Bertl: there's already the sanity checking done by the scripts when starting the guest, checking the helper and such.
1191617224 J * jm_caricand ~user@d77-216-233-159.cust.tele2.fr
1191617241 M * Bertl ah, right, but the barrier is not checked there, yes?
1191617251 M * daniel_hozac not at the moment, i don't think.
1191617257 M * Bertl and we do not have sanity checks across guests
1191617275 M * Bertl e.g. identical context number or shared dirs
1191617307 M * Bertl I also think that this should be done in a separate run, e.g. by 'vserver check' or so?
1191617338 M * Bertl but that's just an idea, nothing urgent or important
1191617349 M * daniel_hozac i imagine there might be cases where shared dirs are okay.
1191617357 M * daniel_hozac something akin to what OLPC are doing?
1191617397 M * Bertl not necessarily, but I think it would be nice to get some overview ala 'rpm -Va'
1191617446 M * Bertl if shared dirs are listed then this is fine, you can always say: yes, that's intentional (same for cotnext ids :)
1191617448 M * faheem Added some more stuff to wiki, please check it looks ok.
1191617460 M * daniel_hozac right
1191617469 M * faheem ie. vserver - build --help
1191617512 M * daniel_hozac faheem: don't worry, i read every diff for the wiki ;)
1191617640 M * Bertl hmm, shouldn't Recent changes contain them btw?
1191617646 M * daniel_hozac it does.
1191617690 M * Bertl ah, it was just added to the debian specific build
1191617726 M * faheem Bertl: Yes, didn't where else I should be adding it.
1191617736 M * faheem didn't know, sorry.
1191617742 J * puck ~puck@leibniz.catalyst.net.nz
1191617764 M * Bertl welcome puck!
1191617778 M * Bertl faheem: probably fine, other distros do not suffer from a newvserver :)
1191618162 M * faheem reboot does not work. I get 
1191618162 M * faheem shutdown: /dev/initctl: No such file or directory
1191618163 M * faheem init: /dev/initctl: No such file or directory
1191618184 M * Bertl no, reboot does work, but your guest is configured to 
1191618191 M * Bertl not use a separate init process
1191618201 M * Bertl and thus, contacting init does not work :)
1191618211 M * Bertl reboot -f will work though
1191618252 M * Bertl http://linux-vserver.org/util-vserver:InitStyles
1191618412 Q * puck Ping timeout: 480 seconds
1191618445 M * faheem Looks like more stuff has to be done manually than with newvserver, ie. locales seems to be unset.,,
1191618471 M * Bertl what util-vserver version are you using?
1191618507 M * faheem Bertl: 0.30.214-3
1191618667 M * Bertl m_stone: http://vserver.13thfloor.at/Stuff/OLPC/delta-vsOLPC.0.4.7.diff will send all of them to dillinger shortly :)
1191618949 M * m_stone Bertl: excellent, thanks!
1191619012 M * Bertl it passes all my tests, please let me know how it does for you
1191619163 Q * bonbons Quit: Leaving
1191619187 M * m_stone Bertl: can you describe what the mm_init() change does?
1191619234 M * daniel_hozac should be a noop change, it just looks better.
1191619263 M * m_stone daniel_hozac: thanks.
1191619272 M * Bertl well, the commit message makes it more clear :)
1191619372 M * Bertl assuming that current->mm->mm_vx_info is identical to current->vx_info is is a noop
1191619611 M * Bertl *it is
1191619760 M * m_stone okay, thanks.
1191619838 M * Bertl daniel_hozac: any missing stuff for 2.3.0.27 ?
1191619851 M * Bertl ah, yes, the proc tagging ...
1191619856 M * daniel_hozac yeah.
1191619885 M * Bertl will look into that shortly, are you going to be around for another hour or so=
1191619888 M * Bertl s/=/?
1191619892 M * daniel_hozac yeah.
1191619898 M * Bertl okay, great!
1191620622 Q * fb_ Ping timeout: 480 seconds
1191620986 M * Bertl daniel_hozac: okay, I went through the code and I think we have another special case, devpts (which should probably be xid tagged too)
1191620990 J * fb ~fback@red.fback.net
1191621008 M * daniel_hozac ah yes, that's right.
1191621014 M * Bertl daniel_hozac: so what I think is the following: 
1191621040 M * Bertl we should create some kind of check if the filesystem is tagged or xid based
1191621053 M * Bertl (testing for special cases like proc or devpts
1191621073 M * Bertl we should use that check for assigning the proper tagging (when required)
1191621098 M * Bertl and we should use that test to decide whether to call dx_permission() or some vx_permission()
1191621114 J * igraltista ~jens@p4FD245AE.dip.t-dialin.net
1191621129 M * Bertl if course, vx_permission will be quite similar to dx_permission, except for the fact that it uses vs_check instead of dx_check
1191621150 M * Bertl does that make sense?
1191621182 M * daniel_hozac did we already rule out the idea of simply ignoring the tag on these filesystems?
1191621214 M * Bertl okay, let's assume we do so (simply ignore it)
1191621235 M * Bertl what does that mean for proc? we probably allow access to other pids there, no?
1191621274 M * Bertl what about devpts? we use the tag for isolation there, no?
1191621301 M * daniel_hozac i was under the impression we were using other means of isolating them.
1191621314 M * Bertl okay, let's verify that then :)
1191621399 M * Bertl fs/devpts/inode.c:31
1191621400 M * daniel_hozac devpts looks safe to me.
1191621412 M * Bertl if (vx_check((xid_t)inode->i_tag, VS_WATCH_P | VS_IDENT))
1191621415 M * Bertl it does?
1191621442 M * daniel_hozac well, since it handles the tag check on its own, we don't need dx_permission for it, no?
1191621453 M * Bertl ah, you mean, we actually do the check where we do it right now, and ignore it for the generic case
1191621460 M * daniel_hozac exactly.
1191621471 M * Bertl I thought you meant we remove the checks completely :)
1191621482 M * daniel_hozac oh, haha, no, that would be silly :)
1191621489 M * Bertl *phew* :)
1191621509 M * Bertl okay, now that we are on the same page ... yes, that seems to be a viable option
1191621526 M * Bertl (probably better than checking for the filesystem)
1191621575 M * Bertl actually all we need to do is add a procfs permission, and we should be good
1191621586 M * daniel_hozac we'd still need to override the dx_permission for DEVPTS though.
1191621608 M * daniel_hozac i.e. make sure it doesn't influence the result.
1191621757 Q * matti Ping timeout: 480 seconds
1191621760 M * Bertl hmm, we do?
1191621786 M * daniel_hozac or am i missing something?
1191621791 M * Bertl right, be are before the fs specific check
1191621808 M * daniel_hozac right
1191621811 J * rgl ~rgl@84.90.232.200
1191621814 M * rgl hello
1191621819 J * puck ~puck@leibniz.catalyst.net.nz
1191621824 M * Bertl hello rgl! wb puck!
1191621839 M * rgl hi Bertl :D
1191621864 J * matti matti@acrux.romke.net
1191621951 J * dna ~dna@231-208-dsl.kielnet.net
1191621959 M * rgl you guys known how can I known when sockets are created and destructed on the system?   should I use iptables for this?
1191621998 J * ntrs_ ~ntrs@79.125.226.30
1191622037 M * daniel_hozac like you want an event of some sort?
1191622050 M * daniel_hozac or just accounting?
1191622070 M * rgl accounting is enough.
1191622080 M * Bertl /proc/virtual/*/limit
1191622096 M * rgl like, a log entry saying, tcp at port x open
1191622107 Q * Piet Remote host closed the connection
1191622130 Q * bzed Quit: brb
1191622144 M * Bertl that can probably be done with the audit framework
1191622159 M * michal_ i think yes
1191622160 J * Piet ~piet@tor.noreply.org
1191622170 M * michal_ althought no ready solution exist
1191622205 M * rgl going to check audit. thx :)
1191622214 M * michal_ look for 'auditd'
1191622281 M * faheem tmpfs is kind of small by default. Does this live in memory?
1191622289 M * michal_ yes
1191622301 M * michal_ but its content can be swapped out
1191622304 M * michal_ oposite to ramfs
1191622320 M * michal_ -o size=<size>K/M/G/T ;)
1191622328 M * Bertl faheem: you can make it larger in fstab, but I'd suggest to move data intensive stuff to /var/tmp
1191622400 Q * ntrs__ Read error: Operation timed out
1191622404 M * faheem What is tmpfs used for?
1191622407 M * rgl michal_, I'm not finding the homepage of auditd.  you known where is it?
1191622415 M * michal_ no idea
1191622426 M * michal_ it's selinux devs product
1191622434 M * Bertl faheem: for storing small and short lived files in memory :)
1191622436 M * michal_ (but can be used without selinux)
1191622478 M * michal_ http://people.redhat.com/sgrubb/audit/
1191622486 M * michal_ maybe something is there
1191622512 M * rgl michal_, that seems like it.  thx :)
1191622537 M * Bertl google: auditd homepage
1191622549 M * michal_ google: linux audit
1191622550 M * michal_ :P
1191622578 M * michal_ (i'm going to write a book about all possible mistakes during instalaton of sun's java web server on solaris. i think i've made them all. rule no 1 - don't touch default configuration :)
1191622601 M * Bertl michal_: self inflicted, what else shall I say :)
1191622611 M * rgl damn.  I looked for auditd in the debian repo, but it didn't find http://packages.debian.org/unstable/admin/auditd :(
1191622636 M * michal_ :>
1191622661 M * fb enough for today
1191622669 M * fb good night 
1191622676 M * michal_ good night
1191622681 M * Bertl fb: night!
1191622711 M * Bertl daniel_hozac: yeah, I guess we'll leave the tagging stuff for tomorrow
1191622712 J * bzed ~bzed@devel.recluse.de
1191622722 Q * puck Ping timeout: 480 seconds
1191622737 M * daniel_hozac Bertl: okay, fine by me...
1191622765 M * Bertl I'm kind of tired so I take fb's suggestion and call it a day :)
1191622791 M * michal_ have a nice one Bertl :)
1191622796 M * daniel_hozac hehe, good night then!
1191622850 M * rgl night :D
1191622871 M * Bertl yeah, cya all tomorrow!
1191622876 N * Bertl Bertl_zZ
1191622892 J * puck ~puck@202.78.240.7
1191622928 Q * bzed 
1191622931 J * bzed ~bzed@devel.recluse.de
1191623079 M * michal_ uf
1191623082 M * michal_ it's working this time!
1191623462 Q * puck Ping timeout: 480 seconds
1191623649 J * puck ~puck@leibniz.catalyst.net.nz
1191623730 J * Supaplex ~e@166-70-62-194.ip.xmission.com
1191623743 A * Supaplex checks the wiki for any known issues/workarounds
1191623751 M * Supaplex ssh -X bites me :-/
1191623992 M * faheem Supaplex: Need to set X11UseLocalhost to no, and also set the guest ip in /etc/hosts.
1191624054 M * Supaplex ahh. in /etc/ssh/sshd_config ?
1191624067 M * faheem Supaplex: Yes. 
1191624156 M * Supaplex # cat /etc/hosts
1191624156 M * Supaplex 10.140.0.2      sid.armada.daxal.com    sid.armada      sid
1191624174 M * faheem Supaplex: right.
1191624184 M * faheem Does it work?
1191624201 M * Supaplex $ xclock
1191624201 M * Supaplex _X11TransSocketINETConnect() can't get address for localhost:6010: Name or service not known
1191624209 M * Supaplex no. why's it u... wait. 
1191624211 M * faheem Supaplex: restart ssh
1191624222 M * faheem and log out and back in
1191624235 M * Supaplex yeah. :) restart++
1191624244 M * faheem you should see the name of the machine to the left.
1191624258 M * Supaplex uh yeah.
1191624297 M * Supaplex hurm
1191624309 M * Supaplex it just sits there, and times out
1191624328 M * faheem Check auth list
1191624337 Q * dna Quit: Verlassend
1191624358 M * faheem Um, you have xbase-clients installed?
1191624371 M * Supaplex yes
1191624381 M * Supaplex xauth list is the same before and after I login
1191624403 M * faheem Supaplex: xauth on guest, I mean.
1191624410 M * Supaplex that's right
1191624419 M * Supaplex xauth on host+guest are identical
1191624439 M * Supaplex ohhhhh
1191624446 M * Supaplex I have /home remounted into the guest.
1191624459 M * Supaplex is that an issue?
1191624464 M * faheem Supaplex: Have you bound ssh on host to not listen to all interfaces?
1191624480 M * Supaplex yes
1191624482 M * faheem Supaplex: Dunno. I'm about to find out. I just did the same. :-)
1191624493 M * Supaplex tcp        0      0 armada.daxal.com:ssh    *:*                     LISTEN
1191624503 M * Supaplex hehe ok.
1191624517 M * Supaplex I figured why suffer when sid breaks.
1191624521 M * Supaplex :D
1191624533 M * faheem Apparently not. Works for me.
1191624572 M * Supaplex the guest thinks it has the same hostname to. I think it has to do with /etc/vservers/guest/ config
1191624588 M * Supaplex hostname -f :-/
1191624630 M * Supaplex $someday 'vserver foo build -m wizard' humm...
1191624655 M * faheem Supaplex: too much manual config, agree.
1191624662 M * faheem better than chroot though.
1191624665 M * Supaplex kinda like how vmware asks stuff
1191624687 M * Supaplex yup. less adverse host issues if the guest kills random pids. :p
1191624780 M * Supaplex armada:/etc/vservers/sid# echo sid > uts/nodename
1191624795 M * Supaplex yay! that fixed it to
1191624817 M * faheem Supaplex: Do you think it makes sense to bind password/groups to the guest? That's what I was doing for chroots.
1191624829 M * faheem Supaplex: X forwarding now working?
1191624846 M * Supaplex oh it works now.
1191624869 M * Supaplex I think the guest was confused over host: because it resolved to the host system
1191624891 M * Supaplex faheem: I thought about it, but I just copied /etc/passwd* /etc/shadow* /etc/group* over.
1191624907 M * Supaplex and oowriter goes bewm on sid. same issue. humm.
1191624912 A * Supaplex checks bugs.debian.org
1191624923 M * Supaplex this is going to suck if I can't print envelopes.
1191624986 M * Supaplex http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397305
1191624996 M * Supaplex ouch. it's over a year old?! wth?
1191625027 Q * puck Ping timeout: 480 seconds
1191625139 Q * rgl Quit: Enough
1191625320 M * daniel_hozac faheem: uh, what is there to manually configure?
1191625683 J * puck ~puck@leibniz.catalyst.net.nz
1191625732 Q * igraltista Read error: Connection reset by peer
1191626307 Q * dowdle Remote host closed the connection
1191626329 Q * puck Remote host closed the connection
1191626411 M * faheem daniel_hozac: Well, X forwarding for one. :-)
1191626424 J * puck ~puck@leibniz.catalyst.net.nz
1191626464 M * faheem I'm lazy.
1191627025 M * Supaplex vserver feisty build --force -m debootstrap -- -d feisty -m ftp://us.archive.ubuntu.com/ubuntu
1191627028 M * Supaplex is that right?
1191627036 M * Supaplex it .. apparently does nil.
1191627048 M * daniel_hozac oh?
1191627051 M * daniel_hozac works fine here.
1191627111 Q * FireEgl Read error: No route to host
1191627128 M * Supaplex nm. my /usr/lib/debootstrap was dainbrammaged.
1191627147 M * Supaplex I moved the old copy aside, and symlinked it to a known working copy.
1191627222 J * dreamind apwdsl@p548AA710.dip0.t-ipconnect.de
1191627236 M * Supaplex this rawkz. :) I <3 remounting /home buhuhahaaaahaaaa
1191627258 N * dreamind Guest990
1191627276 N * Guest990 dreamind
1191627292 M * dreamind Hi folks
1191627299 M * Supaplex ay'
1191627325 M * dreamind hi Supaplex :)
1191627381 M * Supaplex how goes? :)
1191627403 M * dreamind well, could be better :/
1191627436 M * Supaplex yeah. I keep thinking it's the saturday. I could have dropped off a package at the post office.
1191627445 M * Supaplex atleast the atm's always available. hehe
1191627704 M * dreamind hehe ;)
1191627937 Q * puck Ping timeout: 480 seconds
1191628020 J * puck ~puck@leibniz.catalyst.net.nz
1191628662 Q * puck Ping timeout: 480 seconds
1191628759 J * puck ~puck@leibniz.catalyst.net.nz