1143245296 J * undefined ~undefined@adsl-68-93-109-94.dsl.rcsntx.swbell.net
1143245411 Q * Viper0482 Quit: bin raus, 
1143247237 Q * doener Quit: leaving
1143247641 P * undefined 
1143247881 N * Bertl_oO Bertl
1143247887 M * Bertl back now ...
1143248302 M * dev0 I tried before, it hangs even with SYS_ADMIN cap
1143248322 M * dev0 so it shouldn't be a permission thing
1143248388 M * Bertl will try to recreate the issue here now
1143248448 M * dev0 just tell me, if I can help you
1143248656 M * Bertl not at the moment, but probably with testing stuff in parallel shortly
1143248836 M * Bertl does something like:
1143248849 M * Bertl chcontext --xid 2 losetup /dev/loop0 /dev/zero
1143248853 M * Bertl hang too?
1143248879 M * Bertl and do you now use the vanilla loop device? 
1143248915 M * dev0 yes, the aes device still has the permission problems. I use now the vanilla loop device, patched with your changes though
1143248983 M * Bertl okay, I have a kernel now ... let me test that
1143249001 M * dev0 chcontext --xid 50 losetup /dev/loop0 /dev/zero
1143249001 M * dev0 ioctl: LOOP_SET_FD: Invalid argument. 50 is my vserver
1143249037 M * Bertl ah, /dev/zero seems badly chosen
1143249042 M * dev0 indeed
1143249058 M * Bertl ah, here we go, with debugging enabled:
1143249059 M * dev0 just use a file, probably with a filesystem inside
1143249063 M * Bertl [   57.923964] vxW: xid=2 tried to spawn a kernel thread.
1143249084 M * Bertl you would have got that with debugging enabled ...
1143249096 M * Bertl actually I was suspecting something like that ...
1143249119 M * dev0 ok, but nobody but developers have debugging enabled kernel ;)
1143249143 M * Bertl yeah, that wasn't something I'd expected from you
1143249191 M * Bertl so, the actual solution will come from mainline, when they start spawning kernel threads from init/idle
1143249205 M * Bertl let's see if we can figure a workaround for now
1143250287 M * Bertl looks like you did uncover two bugs here, one in mainline and one in the vserver code :)
1143250302 M * dev0 yes, I'm great *g*
1143250612 M * Bertl okay, the following patches will fix the hang, but not more atm
1143250621 M * Bertl http://vserver.13thfloor.at/Experimental/delta-pidmap-fix01.diff
1143250627 M * Bertl http://vserver.13thfloor.at/Experimental/ml-loop-fix01.diff
1143250659 M * Bertl I'll submit the mainstream patch now and then I'll look into the remaining issue
1143250836 M * dev0 ok, done. I'm going to reboot.
1143251077 M * dev0 oh, a new experience. loop gives *now* the same error than loop-aes
1143251103 M * dev0 however, the patch works, it doesn't block anymore
1143251190 M * Bertl yep, cool, isn't it :)
1143251394 M * Bertl so, patch sent, now to the 'required changes' to make it work for you :)
1143252019 M * Bertl http://vserver.13thfloor.at/Experimental/delta-loop-feat01.diff
1143252046 M * Bertl that should make the loop work, you have to do similar for the aesloop
1143252095 M * Bertl hey Aiken! how is it going?
1143252330 M * dev0 great! works perfectly.
1143252338 M * dev0 I'm now porting the patch to loop aes
1143252469 M * Aiken still waiting for kde to finish compiling on that machine
1143252494 M * Bertl ah, I'm sure that is 100% fun ... well, at least 98% :)
1143252840 M * dev0 HA! it works!
1143252844 M * dev0 great work Bertl 
1143252849 M * Bertl tx
1143252869 M * Bertl what capabilities do you actually need now?
1143252884 M * Bertl i.e. could you try to remove excessive caps if there are any?
1143252887 M * dev0 CAP_IPC_LOCK
1143252887 M * dev0 CAP_SYS_RAWIO
1143252896 M * dev0 ^21
1143252896 M * dev0 secure_mount
1143252896 M * dev0 secure_remount
1143252896 M * dev0 binary_mount
1143252906 M * Bertl try to remove the RAWIO, imho it's not required
1143252953 M * dev0 indeed. works even without
1143252975 M * Bertl the IPC_LOCK is probably required ... but better test that one too
1143252990 M * Bertl ah, that's required for the key, I remember
1143252996 M * dev0 yes
1143253025 M * Bertl binary mount is not required, only for nfs and such
1143253061 M * dev0 indeed² removed and works
1143253127 M * Bertl what are you using that for, if I might ask?
1143253137 M * dev0 my mailbox :)
1143253155 M * Bertl ah, and you moved that inside a guest now
1143253162 M * dev0 exactly
1143253222 M * Bertl sounds reasonable, so you basically 'decrypt' the entire stuff when you logon or so?
1143253241 M * Bertl i.e. hash the key, and unmount before logoff?
1143253345 M * dev0 well it's pretty useless using an crypted filesystem/container but having the key in fstab, so yes
1143253373 M * daniel_hozac why would you be using loop-aes when you have things like dm-crypt in mainline? :)
1143253394 M * Bertl because the author of aesloop stated several times ... :)
1143253432 M * dev0 I could cryptoloop to daniel_hozac *g*
1143253437 M * dev0 +o
1143253486 M * dev0 where should I place the wiki page Bertl?
1143253546 M * Bertl make a new one, add it to the Documentation page, maybe something 'more general' like 'Loop Device Inside Guest' or so
1143253564 M * Bertl or maybe 'Guest Loop Device'?
1143253611 M * Bertl explain the basic requirements first (for mainstream) then add a section AES loop, which explains the specifics
1143253644 M * dev0 ok
1143253658 M * Bertl you can send me the patch for AES loop and I'll upload it somewhere (if you do not have some kind of online presence)
1143253875 M * dev0 ok, do you add your changes on the generic loop.c to your devel tree?
1143253912 M * Bertl the ml-loop.fix will hopefully be included in mainline (or something similar)
1143253927 M * Bertl the loop-feat01 will get into the next devel release
1143253941 M * dev0 fine, then I don't need to add this patch.
1143253946 M * Bertl the pdimap patch is a bugfix, so it will definitely be included
1143253972 M * dev0 just to know how people can repeat my procedure
1143253974 M * Bertl regarding the cloop-feat01, I have to wait on your feedback :)
1143254007 M * Bertl but that should probably be fine, just want to have a few more folks look at tit
1143254010 M * Bertl *it
1143254296 M * daniel_hozac Bertl: re: proper stop, reboot, and restart, i think the current legacy system (i.e. async vshelper) works fine. what problems do you see with it?
1143254447 M * Bertl the _main_ problem is that the sys_reboot() will return and certain inits will do funny things
1143254585 M * micah dev0: once youve logged into your vserver and decrypted the loop device, it would also be viewable by the root host, right?
1143254600 M * Bertl yep
1143254605 M * daniel_hozac isn't there some way to keep sys_reboot from returning, but not keeping the init process in kernel space so it becomes unkillable?
1143254642 M * daniel_hozac or should sys_reboot just terminate the caller?
1143254687 M * dev0 micah: I just tried, not outside the vserver. However you can simply enter ...
1143254729 M * daniel_hozac Bertl: hmm, now that i think about it, making reboot_kill the default for guests with init makes sense.
1143254767 M * micah dev0: you are mounting a loop device that can only be read within a context and not from the host?
1143254794 M * daniel_hozac that's just the namespace stuff.
1143254803 M * daniel_hozac because the mount happens in the guest, it will only be visible in that namespace.
1143254843 M * dev0 but it's not a big issue for root to change the context and see what's going on
1143254843 M * Bertl yes, it could get secure when you disable entering the namespace
1143254880 M * micah you can disable entering the namespace?
1143254882 M * dev0 hmm why should it?
1143254902 M * daniel_hozac if you can't enter the namespace, you can't see the mount ;)
1143254902 M * dev0 I think it's a good idea, when root can do _any_thing *g*
1143254922 M * dev0 that's basically the concept of a superuser
1143254934 M * Bertl well, we have/had the idea/concept of 'locked' guests
1143254954 M * Bertl i.e. guests you could start/stop, but not enter or access from the host
1143254985 M * micah wow, that would be really interesting
1143254992 M * daniel_hozac vserver ... build --help...private: No other process can join this security context. Even root.
1143254995 M * micah dev0: I am very interested in your write up :)
1143255013 M * dev0 Bertl: if you are root, there *is* a way to get in
1143255016 M * daniel_hozac that, of course, doesn't mean it's actually supported :)
1143255022 M * Bertl well, we could even do a per guest encryption for the filesystem ala TCFS :)
1143255067 M * dev0 hrrr or set up my crypto loop as root fs :o)
1143255078 M * micah it would be very nice to be able to give guests the ability to have their data private from the root user
1143255107 M * dev0 yes micah, but if you don't trust your admin, you're wrong. 
1143255110 M * Bertl yeah, I always wondered that folks did not work into that direction yet
1143255136 M * micah dev0: yes, but if you are the admin and you want your users to have more privacy, even from you
1143255192 M * dev0 privacy is a good thing, but not by security through obscurity concepts. as I said Bertl before, setting up a cryptoloop FS and having the key in fstab _is_ useless
1143255252 M * dev0 if Bertl and friends find a way to set up the guests real secure, it's a godd thing, but I don't believe in it. 
1143255264 M * dev0 good
1143255282 M * dev0 as root you can load and unload modules, you can change contexts, whatever
1143255294 J * f_ ~f_@83-215-237-1.seek.stat.salzburg-online.at
1143255360 M * micah yes of course, thats why i was wondering how you were able to do this
1143255387 M * dev0 I am my own root 
1143255396 M * dev0 meaning guest and host system is mine
1143255463 M * dev0 if you're on a 8,95$ vserver from you ISP you can't do it.
1143256677 M * Bertl daniel_hozac: so, regarding the reboot_kill, do you have any educated guess how doing an async vshelper call, and immediately after that killing off the processes will affect the tools?
1143256799 M * daniel_hozac Bertl: hmm, do you really want to call vshelper at all for reboot_kill?
1143256824 M * Bertl will the tools work without that?
1143256834 M * Bertl i.e. will there be a restart?
1143256847 M * daniel_hozac oh, right, no.
1143256875 M * Bertl so it's probably not about me _wanting_ to do that :)
1143256962 M * Bertl dev0: btw, the loop fix is already in -mm :)
1143256991 M * dev0 oh nice. 
1143257022 M * daniel_hozac for guests with init, all the tools do to stop them is vkill --xid $S_CONTEXT -s INT 1
1143257051 M * Bertl stop, okay, what about reboot?
1143257066 M * daniel_hozac reboot calls restart, which calls stop and start.
1143257069 M * Bertl (note: reboot is inside the guest, restart outside)
1143257187 M * daniel_hozac so i guess it should work.
1143257247 M * Bertl okay, so let's assume we call the vshelper async, and kill off processes immediately
1143257289 M * Bertl then we could end up killing the 'restarting' server, or does userspace wait for the guest to disappear in this case?
1143257308 M * daniel_hozac stop would wait for the guest to die, as usual.
1143257346 M * daniel_hozac and start will not work if there is any process left in the context.
1143257384 M * daniel_hozac so as long as the kill happens in the first lifespan of the context, we should be safe.
1143257405 M * Bertl okay, I plan to introduce a flag/state which basically prohibits fork() inside a guest
1143257445 M * Bertl and to 'mark' contexts which get killed off (either by syscall command or reboot_kill)
1143257457 M * Bertl and to make sure that the kill is final
1143257496 M * Bertl the context will not return for the wait before all processes are gone
1143257539 M * Bertl alternatively we could send the kill first, then call the helper, but I guess that would mess up userspace tools
1143257565 M * daniel_hozac yeah.
1143257920 M * dev0 Bertl: do you include the loop.c changes (the context things) in 2.1.1-rc15 too? 
1143257990 M * Bertl the loop-feat01?
1143258025 M * dev0 delta-cloop-feat01.diff
1143258055 M * Bertl ah, that one .. well, daniel_hozac, micah, do you consider that useful?
1143258076 M * dev0 this patch is not needed for loop-aes but for people who want to use just loopback devices 
1143258117 M * Bertl http://vserver.13thfloor.at/Experimental/delta-cloop-feat01.diff
1143258247 M * daniel_hozac do people with just loopback devices really need it?
1143258263 M * daniel_hozac it seems to be just for encryption keys?
1143258277 M * dev0 nope
1143258289 M * dev0 loop-aes replaces loop.c with its own
1143258325 M * Bertl dev0: hmm, what daniel_hozac meant was: do folks who want to use loop, but not crypto or aes loop
1143258338 M * Bertl really require that change to use it?
1143258350 M * dev0 they could use sys_admin caps as well
1143258351 M * dev0 *g*
1143258365 Q * phedny Ping timeout: 480 seconds
1143258384 M * daniel_hozac both of those checks seem to depend on lo->lo_encrypt_key_size. does that mean something other than what the name suggests?
1143258489 Q * f_ Quit: This computer has gone to sleep
1143258524 M * Bertl it's a good question, let me check that
1143258580 M * Bertl daniel_hozac: ah, btw, do you have a list of the utsname places at hand?
1143258747 M * daniel_hozac fs/exec.c, sound/core/info_oss.c, and then lots of arch/*.
1143258782 M * Bertl okay, tx
1143258806 M * Bertl fs/exec was the coredump part, right?
1143258817 M * daniel_hozac yeah.
1143259511 Q * mkhl Quit: 
1143259644 M * Bertl hmm, could it be that chcontext is broken somehow?
1143259684 M * Bertl chcontext --xid 3 --cap IPC_LOCK --secure -- grep Cap /proc/self/status
1143259741 M * Bertl CapEff:	00000000344c04ff
1143259761 M * Bertl IPC_LOCK = 0x4000
1143259906 M * daniel_hozac --bcap?
1143259943 M * Bertl unrecognized option `--bcap'
1143259960 M * Bertl maybe my chcontext is outdated?
1143259983 M * daniel_hozac oh, i guess it's because you have --cap before --secure.
1143259998 M * Bertl nope, did try it the other way round too
1143260013 M * Bertl (that was actually my first thought :)
1143260096 M * daniel_hozac hmm, it seems it doesn't matter what order you give them to chcontext, it will hand them in --bcap ... --secure order to vattribute later.
1143260186 M * daniel_hozac where --secure overrides any previously set bcaps. seems like a bug in chcontext.
1143260262 M * Bertl okay, please file a bug-report for me, if possible
1143260299 M * daniel_hozac will do.
1143260305 M * Bertl TIA!
1143260425 M * Bertl okay, this 'hacky' workaround:
1143260429 M * Bertl chcontext --xid 3 --cap -1 --cap !SYS_ADMIN -- losetup /dev/loop0 /dev/hdc
1143260439 M * Bertl works without the cloop patch applied
1143260444 M * daniel_hozac http://daniel.hozac.com/vserver/util-vserver-0.30.210-chcontext-secure.patch
1143260463 M * Bertl no idea why the loop device still requires the memlock stuff
1143260577 M * dev0 hmm without cloop patch my patch does not work though since VXC_CRYPTO_LOOP is not defined. 
1143260591 M * Bertl yes, that is expected
1143260628 M * Bertl I have no problem with the cloop patch, and we will probably include it in 2.1.1
1143260654 M * dev0 hmm the first part is not really necessary, but at least the context flag I wish :o)
1143260661 M * Bertl we just wanted to clarify for what it is actually required
1143260725 M * Bertl btw, would you consider per guest namespace encryption desireable?
1143260799 M * daniel_hozac https://savannah.nongnu.org/patch/index.php?func=detailitem&item_id=4993
1143260882 M * Bertl hmm, I observed that it also overrides the removed caps
1143260896 M * Bertl does that change anything in the fix?
1143260964 M * Bertl chcontext --xid 3 --secure --cap !CAP_CHOWN -- grep Cap /proc/self/status
1143260969 M * Bertl CapEff:00000000344c04ff
1143261114 M * Bertl Hollow: what I wanted to say is, don't spend any time on the test app/script for now unless it helps your tools, I guess I figured a good way to have some userspace test tools
1143261257 M * daniel_hozac yes, the fix will apply --secure first, and then whatever --cap's were specified.
1143261363 M * Bertl excellent! thanks!
1143261382 M * Bertl guess I'm off to bed now ... the daystar is already rising ...
1143261430 M * Bertl have a good whatever everyone ... cya tomorrow!
1143261436 N * Bertl Bertl_zZ
1143261437 M * dev0 Bertl_zZ: I'm still writing on the wiki. I'll save later my Howto to HowtoGuestLoopDevice, just take a look later(TM). 
1143261897 Q * lonewolff jupiter.oftc.net testlink1.oftc.net
1143261897 Q * mountie jupiter.oftc.net testlink1.oftc.net
1143261897 Q * Greek0 jupiter.oftc.net testlink1.oftc.net
1143261985 J * lonewolff lonewolff@adleman.lonewolff.info
1143262020 J * Greek0 ~greek0@85.255.145.201
1143262162 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com
1143262624 M * dev0 http://linux-vserver.org/HowtoGuestLoopDevice - but I go to bed now. Will have a further look on it later. 
1143262837 M * daniel_hozac dev0: you don't want /dev/console in your guest.
1143263316 M * dev0 I just tried it. works even without, for crypted root filesystems it's needed though
1143263387 M * daniel_hozac on the host, perhaps.
1143263430 M * daniel_hozac in a guest, prompting /dev/console for passwords is not what you want to do.
1143263453 M * daniel_hozac what if the person starting the guest (and thereby mounting the root filesystem) is logged on over SSH?
1143263552 M * cehteh you likely can mknod a /dev/console which is really a /dev/tty
1143263622 M * dev0 hmm, nope, mounting a crypted root partition needs /dev/console, just read http://loop-aes.sourceforge.net/loop-AES.README - however this is not covered by my howto
1143263655 M * cehteh dont use loop, use the device mapper
1143263693 M * cehteh http://www.pipapo.org/pipawiki/mountdmcrypt btw .. i made that for user-mounting of encrypted DVD's dunno if it helps you, you may check it
1143263733 M * dev0 I'm already done now. crypted containers work fine
1143263813 M * cehteh btw .. for what do you need encrypted devices on a server? :)
1143263828 M * dev0 devices? I don't
1143263836 M * dev0 I just use a crypted container
1143263836 M * cehteh containers or whatever
1143263842 M * dev0 for my mailbox
1143263854 M * cehteh doesnt make too much sense to me
1143263901 M * cehteh since it is open while the server is running, a possible attacker can likely look into it
1143263926 M * dev0 that's true. 
1143263954 M * cehteh encrypted containers are only usefull against someone stealing the harddisc .. so for laptops
1143263992 M * dev0 hrhr and to stroe some illegale things I guess *eg*
1143263995 M * cehteh well last time someone told me he implemented a async crypted fuse filesystem, kindof write only .. you need another key to read the data
1143264029 M * dev0 loop-aes can be used over gnupg too
1143264044 M * dev0 and supports even multiple keys 
1143264069 M * cehteh yes but the data is encrypted symetrically on disk 
1143264075 M * dev0 true
1143264078 M * cehteh (hence the AES)
1143264102 M * cehteh if the device is 'open' then it is readable at least by root
1143264112 M * dev0 I am my own root. 
1143264112 M * cehteh no matter if you use gpg or not
1143264129 M * cehteh i am talking about a possible attacker .. gaining root
1143264157 M * dev0 but to be paranoid I could it unlock the container just for acessing mails with my TLS login. 
1143264168 M * dev0 incoming mails could be stored meanwhile in a queue
1143264172 M * dev0 -it
1143264200 M * dev0 so if an attacker gains root access he could only access a little part of the mails
1143264239 M * cehteh well .. imo either you do that at least oper something better (let the mailer gpg-encrypt all mails to you before storing them) or you dont do any encryption
1143264273 M * cehteh if the scheme is easily to circumvent, then its not worth the work
1143264292 M * dev0 how would you circumvent it?
1143264324 M * cehteh as i saied if you only store on loop-aes which is unlocked while the server is running 
1143264346 M * dev0 no I mean my scenario with the tls key
1143264352 M * cehteh then 'just' hacking the box somehow suffices mostly
1143264394 M * cehteh loop-aes only protects the data when someone has to shutdowm the machine as in stealing it
1143264437 M * cehteh if stealing it is more unlikely (because it is in a secured computer room) than someone hacking it then loop-aes makes no sense to me
1143264508 M * cehteh letting the mailer automatically encrypt each recieved mail before puttin them in the maildirs is likely easier and much more secure
1143264555 M * cehteh i would expect that there are plugins/scripts for common mail daemons already available
1143264683 M * dev0 probably, yes. 
1143265070 M * dev0 gna I really go to bed now. night
1143265072 Q * dev0 Quit: Peace, Love & Linux
1143269742 J * Dr4g ~Dr4g@82-40-203-70.stb.ubr06.uddi.blueyonder.co.uk
1143271337 J * f_ ~f_@83-215-237-1.seek.stat.salzburg-online.at
1143271579 P * f_ 
1143275260 Q * FireEgl Quit: Bye...
1143276761 J * coocoon GrTB0T@p54A058CD.dip.t-dialin.net
1143276765 M * coocoon morning
1143277368 Q * coocoon Ping timeout: 480 seconds
1143279267 J * Viper0482 ~Viper0482@p54977D74.dip.t-dialin.net
1143280492 J * BartVB ~BartVB@84.35.48.206
1143280599 M * BartVB lots and lots of spam on the vserver wiki ;(
1143280669 M * BartVB I can't find any info about this 'no space left on device' message that I'm getting.
1143280687 M * BartVB There are hundreds of GBs available on the machine but still it's complaining that the disk is full?
1143280693 M * cehteh df -h on the root server might clear the things up
1143280710 M * cehteh and ... we shall deploy a spam filter on the wiki
1143280711 M * BartVB gulltoppr:/# df -h
1143280711 M * BartVB Filesystem            Size  Used Avail Use% Mounted on
1143280711 M * BartVB /dev/md0              231G  3.7G  228G   2% /
1143280711 M * BartVB tmpfs                1005M     0 1005M   0% /dev/shm
1143280733 M * BartVB looks like there is plenty of space :)
1143280766 M * cehteh eh ehere is the spam?
1143280779 M * BartVB try searching for something
1143280787 M * BartVB for instance 'disk full'
1143280805 M * BartVB also check out the shoutbox and 'last changes'
1143280823 M * BartVB On this site: http://vserver.strahlungsfrei.de/tiki-index.php
1143280851 J * harry_ ~harry@d54C2508C.access.telenet.be
1143280851 Q * harry Read error: Connection reset by peer
1143280872 M * cehteh http://linux-vserver.org/ is the main wiki ...
1143280884 M * BartVB ah, ok
1143280885 Q * harry_ Quit: 
1143280922 M * BartVB I tried the other wiki because on the main site search takes ages to complete :)
1143280943 M * BartVB if it completes at all?
1143280954 M * cehteh well i am not responsible for either wiki ... and my wikis are spam-free ;)
1143281029 M * BartVB this is weird:
1143281032 M * BartVB area51:/tmp# echo bla > bla ; ls -al bla
1143281032 M * BartVB -rw-r--r--  1 root root 0 2006-03-25 11:03 bla
1143281037 M * BartVB (that's on the vserver)
1143281069 M * BartVB shouldn't I get a 'no space left on device' message?
1143281113 M * BartVB But this 'no space left on device' problem is not a known problem (or configuration mistake on my part) with vserver?
1143281184 M * cehteh dunno
1143281209 M * cehteh eh tmp ... is that a tmpfs?
1143281224 M * BartVB no, it's just the normal /tmp dir
1143281230 M * cehteh strange
1143281243 M * cehteh quota enabled? .. which filessystem?
1143281275 M * BartVB quota isn't enabled as far as I know, I haven't enabled it :)
1143281281 M * BartVB reiserfs on raid1
1143281338 M * cehteh mhm dunno maybe a reiser glitch ... i am using reiser too, but you cant be really sure ;)
1143281346 M * cehteh not reiser4?
1143281370 M * BartVB 3.6
1143281392 M * cehteh strange .. can you try it with ext3?
1143281400 M * BartVB not really
1143281405 M * BartVB machine is already in the rack
1143281430 M * cehteh well i cant help
1143281434 M * cehteh no idea
1143281449 M * BartVB bummer :)
1143281452 M * BartVB but thanks :)
1143282026 M * BartVB same problem on another vserver
1143282064 M * BartVB but I could create a file of 16MB on that vserver before I got the error message
1143282105 M * BartVB first vserver where I got this message contains 784MB, second vserver contains 494M
1143282122 M * BartVB omg
1143282124 M * BartVB eeehm
1143282127 M * BartVB *grmbl*
1143282151 M * BartVB  /tmp is a tmpfs
1143282152 M * BartVB oops
1143282154 M * BartVB sorry! :)
1143287108 Q * Aiken Ping timeout: 480 seconds
1143288068 Q * Loki|muh Ping timeout: 480 seconds
1143288611 Q * lilo Read error: Connection reset by peer
1143288637 J * lilo ~lilo@lilo.usercloak.oftc.net
1143288788 J * doener ~doener@i5387E7A4.versanet.de
1143289614 J * FireEgl Atlantica@Atlantica.Tcldrop.US
1143290241 J * NetAsh ~foo_bar@88.222.136.221
1143290248 M * NetAsh hello
1143290309 M * NetAsh is there any one a live?
1143290339 M * NetAsh ok
1143290366 M * NetAsh all a sleep, but neverless a good news (in case you do not know yet)
1143290433 M * NetAsh debian has official precompiled kernel packages with vserver functionality !
1143290527 M * NetAsh so far in unstable only, but this the start :)
1143290537 M * NetAsh ./
1143290570 M * Wonka hehe
1143290581 M * Wonka i mentioned their arrival in experimental several days ago :)
1143290632 M * NetAsh experimental is experimental, but unstable is already something :)
1143290688 M * NetAsh I beleve it is a good topic for the news section in linux-vserver.org :)
1143290896 M * cehteh since suse now ships with openvz ....
1143290971 M * Wonka i see some advantages of linux-vserver over openvz
1143290992 A * cehteh too
1143291024 M * Wonka also, virtuozzo is not completely open, iirc... i also don't like that
1143291068 M * NetAsh I would say this:
1143291116 M * NetAsh I started using vlinux befour openvz was anounced, so as long vserver do not fail my needs, why bother triing openvz?
1143291151 M * Wonka one might see openvz as an "enemy" of linux-vserver
1143291164 M * Wonka and then say "...but keep your enemies closer"
1143291189 M * Wonka also, one might say, they also do virtualization, let's see if there's something we could use
1143291217 M * Wonka so, there are at least two reasons to look at openvz :)
1143291238 M * NetAsh unfortunatly I am only a user
1143291243 M * Wonka me too
1143291351 M * NetAsh for developers - yap you are totaly right, they need to compare, find whats better/smarter in other packages and add/reimplement/use others experience in vserver
1143291392 M * NetAsh btv I am the one who beleves vlinux hase more credibility to be merged into mainstreem kernel :)
1143291429 M * Wonka the openvz people submitted their stuff to lkml some days ago
1143291435 M * Wonka heise.de reported
1143291456 M * NetAsh so fck... what
1143291469 M * NetAsh there are toms of paches awaiting to be merged
1143291479 M * Wonka i fear linus will integrate openvz, and then say to linux-vserver, we already have virtualization
1143291486 M * NetAsh lets take an egzample reiserfs4
1143291502 M * Wonka one of five patches was already approved, or so it sounded
1143291518 M * Wonka but then, heise sometimes reports bullshit
1143291530 M * NetAsh also true :)
1143291535 M * Wonka ah, reiser... reiser is a special chapter
1143291544 M * NetAsh not necesery
1143291558 M * NetAsh openvz falls into the same category
1143291563 M * NetAsh I gues so
1143291571 M * NetAsh to much proprietary stuff
1143291575 M * cehteh if reiser4 would be stable ... 
1143291592 M * NetAsh AND cleanly implemented :)
1143291594 M * Wonka and commented...
1143291598 M * cehteh actually it always crashed whenever i tested it again :)
1143291602 M * doener AFAIK Sam also submitted Linux-VServer stuff to LKML... didn't have the time to follow all the stuff though
1143291611 M * Wonka _i_ won't touch reiserfs anytime soon
1143291623 M * cehteh performance is superior ... but that is no excuse for crashing
1143291629 M * Wonka i'd rather try ext3 with that online-resizing-patch
1143291640 M * NetAsh btv I am all fours for xfs, and only then compatibility is needed I go for ext3
1143291643 M * cehteh i use reiser3 since years and never lost data 
1143291650 M * NetAsh riser is no good outside /tmp
1143291653 M * Wonka i need something _stable_ which can be resized up _and_ down
1143291661 M * Wonka xfs can just be made bigger
1143291663 M * Wonka not smaller
1143291708 M * NetAsh I not exactly understood yours "xfs can just be made bigger"
1143291739 M * NetAsh but xfs as long as my nolige is not outdated is laging only in delete operations
1143291763 M * Wonka several filesystems can be resized
1143291793 M * Wonka for example, if you need to change the size of the block device below the fs, with LVM...
1143291794 M * NetAsh aaaa
1143291801 M * NetAsh I got yours ide
1143291840 M * NetAsh ok
1143291877 M * NetAsh who is doing file system resizing with out backuping all data?
1143291917 M * Wonka it is stable with xfs, afaik, and i've not heared of problems with ext3
1143291917 M * NetAsh and which file system can do it live (aka with out unmounting and providing at least read access to services)?
1143291934 M * Wonka xfs can only do it live
1143291945 M * NetAsh cool
1143291948 M * Wonka ext3 can do it live with a patch which is not stable yet
1143291963 M * NetAsh but I prefier backuping twice
1143291970 M * NetAsh and reformat file system ;)
1143291973 M * Wonka that costs time...
1143291978 M * NetAsh sort of natural defragment :)
1143291982 M * Wonka time you don't necessarily have
1143291997 M * NetAsh but it tens of times more relaible
1143291999 M * Wonka and also needs storage space, which you also don't have :)
1143292049 M * NetAsh ok I am giving up, but in reality - I do not mess with file systems with out good backup
1143292095 M * NetAsh btv if data is not so important i can aford a chance to lose, I even do not bother to do multiple partitions
1143292117 M * NetAsh one big pool of stuff and multiple binds :)
1143292131 M * Wonka hrhr
1143292149 M * Wonka we got 5GB /, 5GB /var and 220GB /var/lib/vservers/
1143292176 M * Wonka and possibly later an upgrade to the latter
1143292304 M * NetAsh I yours situation, I would do
1143292388 M * NetAsh 10G / big swap, tmpfs (~75% size of swap) on /tmp and all else /var/lib/vserves
1143292390 M * NetAsh :)
1143292405 M * NetAsh I fourgot
1143292432 M * NetAsh ~100MB for /boot (ext3), and all else except tmp - xfs :)
1143292442 M * NetAsh ./
1143292475 M * NetAsh btv do you know any defragmentation tools for linux, except the one dedicated for xfs
1143292520 M * Wonka we also got 100MB /boot
1143292550 M * Wonka and on both of the hard drives which are joined to a RAID1, the last 5 GiB are split off and used for swap
1143292579 M * Wonka defragmentation tools are not necessary for ext3 and xfs, those FS are designed in a way that will reduce fragmentation
1143292590 M * NetAsh ok
1143292606 M * NetAsh xfs_fsr - is a defragmentation tool
1143292630 M * NetAsh and in case you use big files - trusm me you usualy want a defragment tool
1143292670 M * NetAsh for example you have an ftp server
1143292699 M * NetAsh to separate sesions upload big files (lets say debian iso images)
1143292744 M * NetAsh kernel do not knwo how big the files will be, and the logic files
1143292781 M * NetAsh ./
1143292857 M * Wonka mh-mmh
1143292896 M * Wonka (debian iso images are a stupid idea anyway... 40MB netinstall image is the biggest debian iso anyone should ever need...)
1143292916 M * NetAsh :)))
1143292965 M * NetAsh ok
1143292979 M * NetAsh let it be movies, data files thatewer you wish
1143292993 M * NetAsh there are large files in this world
1143293031 M * Wonka yes
1143293067 M * NetAsh I admint I never runed any defragmentation utility on linux, just out of curiosity
1143293138 M * NetAsh technikaly I done small reserche how to make ntfs WERY fragmented, and just out of curiosity, I would like to test my tehcneeks on linux
1143293157 M * NetAsh the fing I need an utility to report a defragmentation level ;)
1143293271 M * NetAsh ./
1143293281 M * NetAsh ok, it was fun diskusing
1143293288 M * NetAsh I need to depart
1143293290 M * NetAsh by
1143293293 Q * NetAsh Quit: 
1143294429 N * Bertl_zZ Bertl
1143294433 M * Bertl morning folks!
1143294592 M * doener morning Bertl 
1143294787 M * Bertl hey doener! everything fine?
1143294897 M * doener sure ;) how are you?
1143294927 M * Bertl I'm reasonably fine for the fact that I just got up, tx :)
1143294935 M * doener heh
1143295295 M * Bertl doener: can I have an hour or so of your time (sometime today)?
1143295318 M * Bertl I'd like to discuss missing stuff for the release
1143295323 M * doener ok
1143295438 M * Bertl just let me know when you've got time ...
1143298398 Q * Dr4g Ping timeout: 480 seconds
1143298527 J * mkhl ~mkhl@200-153-181-199.dsl.telesp.net.br
1143298652 J * meandtheshell ~markus@85-125-227-230.dynamic.xdsl-line.inode.at
1143298694 J * f_ ~f_@83-215-237-1.seek.stat.salzburg-online.at
1143299260 Q * f_ Quit: This computer has gone to sleep
1143299278 M * Bertl wb meandtheshell! mkhl!
1143299563 J * harry ~harry@d54C2508C.access.telenet.be
1143299569 M * Bertl welcome harry!
1143299628 M * harry hey Bertl 
1143299639 A * harry installing new kernel
1143299644 M * harry pretty slow on compiling
1143299654 M * harry so i thought, just join irc again, until compile finishes
1143299664 M * Bertl good idea
1143299665 M * harry (i hope it finishes by 18h or so :s
1143299698 M * harry should i run vserver on this computer too maybe? ;)
1143299702 M * harry it's a p200 :)
1143299717 M * harry 64 mb ram :)
1143299750 M * harry brb... gotta run now
1143299938 M * meandtheshell hi bertl ;-)
1143300352 M * Bertl harry: should work fine on that too :)
1143300769 J * matta ~matta@c-68-81-35-243.hsd1.pa.comcast.net
1143300836 M * Bertl wb matta!
1143300872 Q * daniel_hozac Quit: reboot
1143300954 J * dev0 ~arno@85-124-3-80.dynamic.xdsl-line.inode.at
1143300956 M * dev0 hi
1143300960 M * Bertl hey dev0!
1143301028 M * dev0 I wrote the howto, you might have a look on it, since I guessed some things with future releases.
1143301029 J * daniel_hozac ~daniel@c-2d1472d5.010-230-73746f22.cust.bredbandsbolaget.se
1143301191 M * Bertl dev0: hmm, where did you put it?
1143301231 M * dev0 http://linux-vserver.org/HowtoGuestLoopDevice not yet linked on the docs
1143301256 M * Bertl ah, good ...
1143301369 M * Bertl looks very nice and clean to me ...
1143301392 M * Bertl one comment, regarding the loop devices though
1143301425 M * Bertl you might want to mention that you probably should assign 'certain' loop devices to each guest
1143301451 M * dev0 indeed. using a loop in one guest makes in unable to use in other
1143301453 M * Bertl e.g. /dev/loop1 for guest1 , loop2 and loop3 for guest2 ...
1143301485 M * Bertl otherwise guests will be able to mount the decrypted loop devices a second time :)
1143301515 M * dev0 it gives an error though, but you are right
1143301534 M * Bertl well, maybe mounting it readonly does work?
1143301554 M * dev0 nope, remember that the container is a file in a local guest context
1143301572 M * Bertl (i.e. something like, mount -t ext2 -o ro /dev/loop0 /mnt :)
1143301578 M * daniel_hozac Bertl: re: rpm-fake.so, my new kernel didn't fix it... and the debugging shows that the switch isn't called.
1143301595 M * Bertl which is indeed interesting ...
1143301624 J * spd1snd ~spd1snd@68-232-131-226.chvlva.adelphia.net
1143301627 M * Bertl you do use hollows lib for that? or the util-vserver one?
1143301632 M * Bertl welcome spd1snd!
1143301683 M * daniel_hozac it's all util-vserver.
1143301712 M * Bertl okay, we fixed some issues with PIC code in hollows library (in the syscall wrapper)
1143301740 M * Bertl right now, I cannot remember what exactly, but you might have a look at one of the shiny changes
1143301741 M * spd1snd I've got a vserver running and i want to use mrtg to graph any network traffic on that particular vserver... anyone have any experience with this? i can get mrtg working on physical machines easily, but it seems that because of the way networking is setup within each vserver, mrtg is not able to "see" anything from within a vserver... any thoughts?
1143301767 M * Bertl yes, you have several options here
1143301787 M * harry Bertl: i know it should work... but it's kinda... useless i think :)
1143301796 M * Bertl spd1snd: 1) assign a separate physical (or virtual/vlan) interface to the guest
1143301820 M * Bertl spd1snd: 2) setup a simple iptables accounting rule for the guest and graph that
1143301866 M * spd1snd Bertl: would the iptables accounting rule run from inside that particular vserver?
1143301878 M * Bertl spd1snd: 3) use the socket accounting in /proc/virtual/<xid>/cacct
1143301931 M * Bertl spd1snd: no, but it is probably easier (and more secure) to feed mrtg data from outside anyway
1143302074 M * Bertl daniel_hozac: look for special __PIC__ handling and %ebx
1143302159 Q * harry Quit: leaving
1143302227 M * daniel_hozac Bertl: when was this? didn't we add this for util-vserver around 0.30.208 or so?
1143302414 M * Bertl IIRC, we changed something when hollow encoutnered issues
1143302418 J * harry ~harry@d54C2508C.access.telenet.be
1143302443 M * Bertl those were not present in util-vserver, because hollow linked a library from another library, one having PIC code, the other not
1143302549 M * harry wiiii... online again
1143302559 M * harry Linux lucifer.homelinux.com 2.4.32-grsec #2 Sat Mar 25 13:38:50 CET 2006 i586 i586 i386 GNU/Linux
1143302593 J * doener_ ~doener@i5387D54C.versanet.de
1143302691 M * Bertl wb doener_ :)
1143302806 Q * spd1snd Quit: spd1snd
1143302935 M * daniel_hozac hmm, it seems to be a problem with the VC_CALL macros in the syscall wrappers.
1143302953 M * Bertl let's hear
1143302959 M * daniel_hozac if i just put vc_set_vhi_name_v13(...) in vc_set_vhi_name, it works fine.
1143302998 M * Bertl and what is normally there?
1143302998 M * daniel_hozac so it seems to be a tool issue, mostly. but i wonder why the test kernel i built worked fine...
1143303007 Q * doener Ping timeout: 480 seconds
1143303034 M * daniel_hozac   CALL_VC(CALL_VC_V13   (vc_set_vhi_name, xid, type, val, len),
1143303034 M * daniel_hozac           CALL_VC_OLDUTS(vc_set_vhi_name, xid, type, val, len));
1143303077 M * Bertl can you show me the relevant asm section?
1143303086 M * Bertl (or point me to that in the dump)
1143303147 M * daniel_hozac vc_set_vhi_name.
1143303159 M * daniel_hozac line 7093 in libvserver.so.objdump.
1143303180 M * Bertl url plz
1143303198 M * daniel_hozac http://daniel.hozac.com/vserver/libvserver.so.objdump http://daniel.hozac.com/vserver/rpm-fake.so.objdump
1143303202 M * Bertl tx
1143303309 M * daniel_hozac so it seems to be util-vserver that is generating the ENOSYS.
1143303339 M * Bertl which actually explains where it comes from
1143303459 M * daniel_hozac the question then becomes, why doesn't it call the function?
1143303481 M * Bertl b84879
1143303497 M * Bertl depending on what the utilvserver_checkCompatVersion returned
1143303513 M * daniel_hozac right.
1143303529 M * Bertl I assume this one already fails
1143303540 M * Bertl in which case none of the below are called
1143303574 M * daniel_hozac well, the function returns ENOSYS in errno.
1143303588 M * Bertl and ENOSYS is?
1143303591 M * daniel_hozac so ver must somehow be negative...
1143303592 M * daniel_hozac 38
1143303696 M * Bertl you do not happen to call those routines from inside a context, do you?
1143303732 M * daniel_hozac vc_ctx_create happens a bit before that.
1143303751 M * Bertl and you are still in setup state, right?
1143303762 M * daniel_hozac yeah, otherwise setting the vhi name would always fail, no?
1143303780 M * Bertl hmm, not necessarily
1143303825 M * daniel_hozac ver = -1208400240
1143303914 M * Bertl http://vserver.13thfloor.at/Experimental/delta-enosys-clean01.diff
1143303921 M * Bertl might this be related somehow?
1143303938 M * Bertl (not ready for inclusion yet, needs some more testing)
1143303969 M * daniel_hozac well, the switch debug showed that it wasn't called at all.
1143303970 M * Bertl I'm thinking about the vc_vx_info() call inside a setup
1143304011 M * Bertl do you have the switch debug log?
1143304033 M * daniel_hozac it seems that something is overwriting the the utilvserver_checkCompatVersion value.
1143304065 M * daniel_hozac http://phpfi.com/109307
1143304111 M * Bertl that is a stable kerne, yes?
1143304134 M * daniel_hozac yep.
1143304150 M * Bertl dynamic contexts?
1143304163 M * daniel_hozac that's just because i'm not supplying one when testing.
1143304187 M * Bertl okay, the version seems to get returned quite fine
1143304187 M * daniel_hozac and they can't be disabled on stable, can they?
1143304197 M * Bertl x86_64 or x86?
1143304203 M * daniel_hozac x86.
1143304283 M * Bertl hmm, what's that _init function?
1143304314 M * Bertl does the library need some kind of init call which is not executed?
1143304345 J * dos000 ~dos000@i216-58-16-34.cybersurf.com
1143304348 M * dos000 howdy
1143304354 M * Bertl welcome dos000!
1143304372 M * dos000 hey Bertl .. long time no see .. err chat
1143304379 M * Bertl yep, indeed
1143304394 M * daniel_hozac shouldn't _init be called automatically by ld?
1143304402 M * dos000 and this little thing is growing and growing
1143304415 M * Bertl daniel_hozac: yes, emphasis on should
1143304417 Q * phreak`` Ping timeout: 480 seconds
1143304489 J * phreak`` ~phreak``@styx.xnull.de
1143304497 M * Bertl wb phreak``!
1143304527 M * phreak`` thanks :)
1143304620 M * dos000 i am trying to run bind in a vserser but there is no *.conf so i can put the S_CAPS thing
1143304629 M * phreak`` Bertl: got a second (well for some patch against the current git-tree) ?
1143304638 M * dos000 in etc/vserver .. anyone has idea ?
1143304644 M * daniel_hozac dos000: echo CAP_SYS_RESOURCE >> /etc/vservers/<name>/bcapabilities
1143304645 M * phreak`` (concerning vs)
1143304689 M * Bertl dos000: have a look at the flower page for config details, but recompiling bind without linux-caps is a better choice
1143304698 M * Bertl phreak``: sure
1143304703 M * phreak`` Bertl: http://dev.gentoo.org/~phreak/patch-2.6.16-git-vs2.0.2-rc14-incr.diff
1143304712 M * phreak`` especially the jfs part ..
1143304730 M * phreak`` (s/jfs/jfs_imap.c that is)
1143304738 M * phreak`` *fs/jfs/jfs_imap.c even
1143304777 M * dos000 Bertl, humm .. the hint from daniel_hozac  is not good then ?
1143304818 M * daniel_hozac dos000: it's the quick'n'dirty hack way. best way is to patch bind or configure without linux-caps.
1143304853 M * Bertl phreak``: hum, where does jfs_ip->saved_uid go?
1143304927 M * phreak`` Bertl: in the original ? or in the patch ?
1143304940 M * Bertl after your patch
1143304953 M * Bertl i.e. IMHO that one is not assigned anymore, no?
1143305007 M * phreak`` well IMHO  jfs->saved_uid saves le32_to_cpu(dip->di_uid); right ? so does uid ..
1143305039 M * Bertl ahem, well, yes, but you are changing the semantics here quite heavily
1143305044 M * phreak`` well the jfs->saved_uid / uid switch would not be necessary ..
1143305071 M * Bertl also the INOXID_UID(XID_TAG(ip) in the _from_dinode() is probably wrong
1143305101 M * Bertl you are reading a disk inode here, so you want to use the 'tag' info from the disk representation
1143305407 M * Bertl i.e. this looks like a vserver bug to me
1143305433 Q * dos000 Quit: Leaving
1143305453 M * Bertl ag, no, ignore that one, I'm confused by the devel code
1143305504 M * phreak`` so you say, I should use something other to read the info from the disk ?
1143305507 M * Bertl but you have to set the saved_uid
1143305525 M * phreak`` (thats what I already changed)
1143305533 M * Bertl look, as far as I understood the jfs changes (read: I haven't looked into them yet)
1143305551 M * Bertl they allow for some uid=xy mount option
1143305567 M * Bertl but! and that is the important part, they _save_ the
1143305583 M * Bertl ondisk uid somewhere (jfs_ip->saved_uid)
1143305607 M * Bertl so that a) the disk uids are not changed, and b) they can
1143305617 M * Bertl switch bach to uid=-1 (disabled) at any time
1143305635 M * Bertl don't ask me who would need such a feature, but obviously somebody does
1143305673 M * Bertl so you are basically _extracting_ uid/gid/xid from the on-disk values
1143305694 M * Bertl then you store the uid/gid to the jfs_ip->saved_uid/gid unconditionally
1143305709 M * Bertl and proceed with the 'normal' execution
1143305735 M * Bertl keep in mind that you _need_ the uid/gid for the xid extraction
1143305768 M * Bertl if you take a look at the fs/jfs/jfs_imap.c on devel, you will see
1143305778 M * Bertl         uid = le32_to_cpu(dip->di_uid);
1143305778 M * Bertl         gid = le32_to_cpu(dip->di_gid);
1143305778 M * Bertl         ip->i_uid = INOTAG_UID(DX_TAG(ip), uid, gid);
1143305778 M * Bertl         ip->i_gid = INOTAG_GID(DX_TAG(ip), uid, gid);
1143305778 M * Bertl         ip->i_tag = INOTAG_TAG(DX_TAG(ip), uid, gid, 0);
1143305801 M * Bertl basically you want to make the ip->i_uid jfs_ip->saved_uid
1143305817 M * Bertl and same for the saved_gid
1143305825 M * Bertl then do whatever jfs does with that
1143305944 M * daniel_hozac Bertl: does utilvserver_checkCompatVersion look ok to you? i can't see anything wrong with it, but something's got to be overwriting the version.
1143305990 M * daniel_hozac ... and of course, adding debugging printf's to it makes it work :/
1143305998 M * Bertl as usual
1143306109 M * Bertl which gcc is that?
1143306123 M * daniel_hozac gcc (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3)
1143306166 M * Bertl the library is shiny patched, yes?
1143306219 M * daniel_hozac well, not any more so than util-vserver-0.30.210 usually is.
1143306228 M * Bertl hmm ...
1143306291 Q * matta Ping timeout: 480 seconds
1143306343 M * Bertl okay, should not be relevan, I have one patch in my rpm, but it only concerns mips
1143306352 M * Bertl try the following though:
1143306381 M * Bertl look for the i386 implementation (asm/syscall)
1143306394 M * Bertl and change the
1143306403 M * Bertl #define __sysc_clobber  __sysc_regs, "eax", "memory"
1143306406 M * Bertl to
1143306421 M * Bertl #define __sysc_clobber  __sysc_regs, "eax", "ebp", "memory"
1143306621 M * daniel_hozac lib/syscall.c: In function 'vc_set_ipv4root':
1143306621 M * daniel_hozac lib/syscall.c:61: error: bp cannot be used in asm here
1143306649 M * Bertl hmm, okay, gcc4 is trying to outsmart us here
1143306656 M * Bertl but we are smarter ...
1143306662 M * Bertl let's change the following instead:
1143306681 M * Bertl -        __casm(n,6,1,   "pushl  %%ebp"          ,                       )\
1143306701 M * Bertl +        __casm(n,0,1,   "pushl  %%ebp"          ,                       )\
1143306720 M * Bertl and the same for the pop in __sysc_fin
1143306743 M * Bertl (and change the ebp stuff back
1143306864 M * daniel_hozac no change.
1143306880 M * Bertl okay, good, the asm code shows the push/pop, yes?
1143307041 M * daniel_hozac right before and after the int $0x80, yeah.
1143307045 M * Bertl just to make sure, let me ask once again:
1143307056 M * Bertl you are not mixing PIC with non-PIC code, right?
1143307081 M * daniel_hozac not that i am aware of.
1143307126 M * daniel_hozac how can i tell?
1143307169 M * Bertl well, in the code, you could check for __PIC__
1143307239 M * Bertl thing is, as pic code (as libverver here is) uses %ebx for the location
1143307247 M * daniel_hozac only matches are in the alternative syscall implementation.
1143307275 M * Bertl yeah, I suggested to add some #ifdef __PIC__ #warning stuff
1143307294 M * Bertl your libvserver is definitely PIC code
1143307324 M * Bertl now what about the rest?
1143307388 M * daniel_hozac rpm-fake.so would seem to be PIC too.
1143307415 M * Bertl and the library containing __errno_location for example?
1143307489 M * daniel_hozac glibc? definitely PIC.
1143307503 M * Bertl hmm, you are linking against glibc?
1143307532 M * daniel_hozac util-vserver always links the shared libraries against glibc, AFAIK.
1143307547 M * daniel_hozac they are of rather limited use when linked against diet.
1143307568 M * Bertl okay
1143307600 M * Bertl well, the only thing I can suggest is to disable the ptrace checks and use gdb
1143307609 M * Bertl then single step it ...
1143307804 M * doener_ Bertl: I'm available now...
1143307873 M * Bertl good ... let's check the kernel todo list together including the following (not listed there):
1143307895 M * Bertl - utsname stuff for coredump
1143307910 M * Bertl - version bump for stable and devel
1143307952 M * doener_ hm, i need more screen real estate...
1143308051 M * doener_ ok, got it... (all needed windows on one screen, not more sre ;)
1143308058 M * Bertl okay, first section, the mask_caps (they seem dormant right now, i.e. nobody cared yet)
1143308082 M * Bertl the uid hashes are not really an issue right now
1143308111 M * Bertl I've done some profiling and improved certain hot pathes
1143308145 M * Bertl the CPU virtualization is still missing, nothing for stable, but might be nice to do something right after the devel release in this direction
1143308166 M * doener_ cpu virtualization means?
1143308176 M * Bertl user/sys/idle values
1143308185 M * doener_ ah right
1143308203 M * Bertl the ipc accounting should be there, limits only where folks asked about
1143308238 M * Bertl daniel_hozac: we did include the limit availability mask changes, right?
1143308313 M * Bertl the per context integrals seem not very interesting right now ... but we might look into that at a later time
1143308344 M * doener_ what are those anyway?
1143308347 M * Bertl the proc/locks should be done, but we have still no testing there, right?
1143308365 M * Bertl doener_: accounting based on time
1143308380 M * doener_ k
1143308414 M * Bertl the hash lock part might be worth looking into mutexes
1143308437 M * Bertl but the overhead there is minimal atm, so that's something for devel
1143308467 M * doener_ there are currently spinlocks, right?
1143308473 J * liquid3649_ ~Viper0482@p54975189.dip.t-dialin.net
1143308481 M * Bertl the slab cache ditto, might reduce memory fragmentation over long time ...
1143308486 M * Bertl doener_: yes, IIRC
1143308513 M * doener_ ok, just testing my remaining knowledge of the patch ;)
1143308562 M * Bertl SOCK_USER_SOCKET is not used atm, it's dead code
1143308584 M * Bertl maybe we should remove it for now
1143308634 M * Bertl for the inode sizes, I have no idea 'how' we should do that properly, but it doesn't cause issues in general
1143308706 M * Bertl the parisc stuff is still open, maybe I add a patch to fix that
1143308767 M * Bertl I'm currently trying to sort out the syscall checks, but this will take a few days
1143308784 A * Bertl is working on a test tool right now
1143308873 M * Bertl the proc_dointvec_bset is something which would be nice to have, but it's not really relevant
1143308908 Q * Viper0482 Ping timeout: 480 seconds
1143308942 M * Bertl the atomic_inc_return() idea is something for the next devel
1143308960 M * Bertl socket limits, do we have anything there?
1143309000 M * doener_ at least nothing I know of, but well... doesn't mean anything ;)
1143309079 M * Bertl we do nice accounting there, we might as well check for the limit
1143309088 M * Bertl anybody interested in doing a patch for devel?
1143309167 M * Bertl the set vs init checks have been done .. as far as I remember everything turned out correct
1143309214 M * Bertl regarding the overflow*id, not sure how we should a) check that properly and b) how we would want the logic to behave
1143309226 M * Bertl in any case, it seems not really relevant/urgent
1143309293 Q * liquid3649_ Quit: bin raus, 
1143309305 J * Viper0482 ~Viper0482@p54975189.dip.t-dialin.net
1143309316 M * Bertl I'm doing the user annotation checks right now ...
1143309374 M * Bertl seems we missed two of them
1143309383 M * Bertl vc_enter_namespace and vc_cleanup_namespace
1143309390 M * Bertl will be fixed in the next rc
1143309564 M * Bertl the sequencer stuff is still on my todo list, maybe I get to it now
1143309606 M * Bertl the NBIPV4 will go away with the ipv6 interfaces, something I have to cleanup too
1143309748 M * Bertl the COWBL stuff will be broken out shortly
1143309786 M * Bertl adding the context uts should be trivial too
1143309811 M * Bertl so ... any things we are still missing / we want to have in 2.0.2 or 2.1.1 ?
1143309843 M * Bertl daniel_hozac: if you have a few minutes, you might join the 'discussion' regarding reboot/reset/helper/defaults
1143309866 M * doener_ what about the utsname-coredump and version bump items?
1143309899 M * Bertl ah, good point too ... I want to fix the coredump part, not the oss and arch* parts right now
1143309919 M * Bertl (of course, complete patches are always welcome ;)
1143309938 M * Bertl ad version, I'd like to announce something like
1143310013 M * Bertl 0x00020101 for devel and 0x00020002 for stable
1143310025 M * Bertl (assuming the tools can cope with that)
1143310081 M * Bertl the devel will contain the _new_ APIs for scheduler and probably monitoring (if I get to that) and should have 'defined' behaviour regarding reboot
1143310253 M * Bertl util vserver seems to handle VCI: 0002:0101 fine
1143310333 M * Bertl okay, any comments regarding any of those issues?
1143310476 M * doener_ i don't see any problems with the proposed actions.
1143310510 M * Bertl good, so the remaining topic is: reboot behaviour 
1143310718 M * Bertl as it seems that we lost daniel_hozac ... and Hollow/bonbons are not here, I guess we delay that a little ...
1143311074 M * daniel_hozac well, as i said yesterday, making reboot_kill the default for guests with init sounds fine.
1143311113 M * Bertl okay, could you test a patch for that?
1143311130 M * Bertl +easily  i.e. verify that it doesn't break stuff
1143311237 M * daniel_hozac well, i don't have any init-based guests. micah?
1143311291 M * daniel_hozac plus it takes forever for me to build kernels ;)
1143311318 M * Bertl well, a no would suffice :)
1143311563 M * daniel_hozac are defaults something we want to have in the kernel? shouldn't the utils handle that?
1143311705 M * Bertl in what regard, and yes, they should
1143311828 M * daniel_hozac so the patch you are speaking of would be a utils patch?
1143311850 M * Bertl no, not necessarily, we have the following situation right now
1143311858 M * Bertl if (vx_info_flags(vxi, VXF_REBOOT_KILL, 0)) {
1143311868 M * Bertl else ret = vs_reboot_helper(vxi, cmd, arg);
1143311875 M * daniel_hozac oh, i see.
1143311888 M * Bertl and there we have
1143311896 M * Bertl #ifndef CONFIG_VSERVER_LEGACY ret = do_vshelper(vshelper_path, argv, envp, 1);
1143311896 M * Bertl #else ret = do_vshelper(vshelper_path, argv, envp, 0);
1143311896 M * Bertl #endif
1143311911 M * daniel_hozac right.
1143311923 M * Bertl so we have to decide what 'options' we want from userspace PoV
1143311936 M * Bertl then we can patch the tools to do the proper things
1143311970 M * Bertl my suggestion would be to add a flag which selects the reboot helper
1143311989 M * Bertl and make the first one two separate if()s
1143312024 M * Bertl but, if that isn't required from userspace, then we can simply make the vshelper call unconditional right _before_ the kill
1143312340 M * daniel_hozac well, you'll always need a reboot helper, won't you?
1143312369 M * Bertl I thought so too, but last time Hollow didn't want it
1143312401 M * Bertl or maybe I got that wrong back then?
1143312417 M * daniel_hozac i guess we'll just have to wait for Hollow to explain :)
1143312436 M * Bertl note, we do send helper calls on context destruction
1143312475 M * Bertl vs_state_change()
1143312542 M * Bertl the difference is, those are sent _after_ the context disappeared
1143312603 M * daniel_hozac how do you tell halt from reboot?
1143312614 M * Bertl atm, not at all
1143312648 M * Bertl we discussed saving the sys_reboot() cmd somewhere
1143312660 M * Bertl and presenting that on context exit in ENV or so
1143312690 M * derjohn (slightly) OT question: is there a specialzied tool to set sysfs values? (I dont mean echo ... more something like debians /etc/sysctl.conf ... but for /sys values (I want to set cfq IO sched at startup))
1143312705 M * Bertl sysctl?
1143312734 M * derjohn Bertl, this only set /proc/sys values which differ from /sys 
1143312778 M * Bertl AFAIK, there is only one sys interface
1143312824 M * Bertl the proc/sys is just a subset of /sys (but maybe that changed)
1143312925 M * derjohn Bertl, ls -l /sys/block/hda/queue/scheduler -> exists, find /proc/sys/ -name "*sche*" -> empty
1143313018 M * derjohn but thx, I will make some custom initscript :/ [I hate that, because my colleagues hate me when creating custom stuff they dont know ;)]
1143313033 M * Bertl interesting ...
1143313086 M * derjohn sorry, didn't want to bore and/or disturb you :)
1143313104 M * Bertl yes, it seems that sys contains a lot more nowadays than can be reached with sysctl
1143313141 M * derjohn tokkee, th right place to fix is not the sysctl util, but the kernel side?
1143313168 M * Bertl not sure about that, haven't looked at the kernel part yet
1143313199 M * Bertl if you find something (e.g. a new tool or so) please let me know
1143313228 M * derjohn ok, no problem. maybe i file a wish on the procps homepage
1143313250 M * daniel_hozac what's wrong with echo?
1143313284 M * Bertl you need many of them, actually :)
1143313325 M * derjohn daniel_hozac, basically nothing, but there is no /etc/echo.conf ... I (at least on Debian) I dont have a _standard_ init script for setting the values (like /etc/sysctl.conf for /proc values)
1143313367 M * Bertl rc.local is probably the best choice
1143313395 M * doener_ derjohn: there's sysfsutils in Etch, no idea if it is in Sarge
1143313431 M * derjohn doener_, I am in sid .... but: did yoz try to set /sys values with sysfsutils? try it and be surprised!
1143313438 M * derjohn (sysctl -a ...)
1143313451 M * derjohn grep for sched
1143313476 M * daniel_hozac systool seems to be just for showing values.
1143313558 M * doener_ daniel_hozac: it comes with /etc/sysfs.conf for setting values at boot
1143313569 J * yarihm ~yarihm@84-74-23-214.dclient.hispeed.ch
1143313578 M * daniel_hozac doener_: hmm, what version is that?
1143313601 M * daniel_hozac 1.3.0 here, and i have no /etc/sysfs.conf, and systool --help just has options for showing things.
1143313601 M * derjohn ahhhh /etc/sysfs.conf - Configuration file for setting sysfs attributes. systool was the hint ...
1143313606 M * derjohn (hopefully)
1143313636 M * Bertl welcome yarihm!
1143313686 M * doener_ daniel_hozac: probably a debian add-on, it doesn't actually use systool
1143313699 M * daniel_hozac doener_: ah. that explains it.
1143313714 M * derjohn yup, the initscript of sysfstools can set the values in /sys 
1143313729 M * Bertl great! live and learn ...
1143313754 M * derjohn now my colleagues wont hate me for my arcane scripts :)
1143313790 M * derjohn (which would get lost wit the next server migration with a probability of about 90% ;))
1143313859 M * Bertl systool is there on mandriva too
1143313878 M * doener_ wow... allyesconfig takes 17m33 to compile... i had not expected my config to include so much less...
1143313956 M * derjohn doener_, 18 mins only? what machine?
1143313972 M * Bertl a fast one :)
1143313985 M * derjohn Bertl, interesting conclusion ! ;)
1143314018 A * derjohn needs an Athlon64 X2 ......
1143314020 M * doener_ 4400+, 2GB... compile with my config takes about 1m50 on gcc4 and 1m30 on gcc3.4... just wanted to see how much longer a allyesconfig takes...
1143314062 M * derjohn doener_, SCSI subsys or SATA-Foo?
1143314076 M * doener_ SATA, SW RAID 1
1143314092 M * Bertl yeah, the swraid1 helps here
1143314099 M * Bertl (at least on the first run)
1143314108 M * derjohn doener_, you run exactly my future config :)
1143314116 M * doener_ heh :)
1143314146 M * derjohn Bertl, really? I dont think there is much parallelisation on swraid mit COTS hardware
1143314159 M * derjohn sry _not much_
1143314172 M * Bertl well, the disk will be handled independantly
1143314181 M * Bertl so for reads, you have twice the speed
1143314190 M * derjohn Bertl, NACK.
1143314208 M * derjohn Bertl, I could prove empirically.
1143314213 M * Bertl bonnie++?
1143314225 M * derjohn (hdparm -t /dev/md0 is about the same as on /dev/sda1
1143314234 M * Bertl gah, that doesn't tell anything
1143314251 M * Bertl besides this will not have two reads in parallel
1143314263 M * derjohn Bertl,  is at least says that the *2 theory is not true in SATA std HW.
1143314280 M * Bertl no, it just says that hdparm is the wrong tool :)
1143314311 M * Bertl try doing a kernel build -j4 on both, then we talk
1143314332 M * derjohn Bertl, hm, why? The queue should be full of read commands ... the kernel should reorder by modulo #ofdisk ...
1143314339 M * derjohn Bertl, ok ..
1143314346 M * derjohn will try :)
1143314414 M * derjohn ah ... you mean the kernel shares the load simply per .. hmm .. file request?
1143314449 M * micah Bertl: is your hppa machine available?
1143314470 M * Bertl yup, I can arrange a logon, but it isn't updated atm ...
1143314520 M * Bertl i.e. latest kernel is vmlinux-2.6.15-vs2.1.0.4-pa4
1143314551 M * micah ok, that should be fine though since this is mostly a userspace issue, right?
1143314565 M * micah well, if it isn't we'll find out :)
1143314630 M * Bertl yep, no problem to compile a more recent one, just takes time ...
1143317488 Q * yarihm Ping timeout: 480 seconds
1143318193 M * Bertl hmm, anybody around who tested UML kernels recently?
1143318561 M * rmoriz hi
1143318573 M * Bertl hey rmoriz!
1143318589 M * rmoriz is there a uptodate documentation about setting up quota inside a vserver (lvm driven)?
1143318604 M * Bertl yes, I think so ...
1143318622 M * rmoriz http://www.5dollarwhitebox.org/wiki/index.php/Howtos_Linux-Vserver_With_LVM_And_Quotas for example misses the point where to mount the device with "usrquota,grpquota "
1143318656 M * Bertl well, depends on the filesystem, on ext2 this isn't required for example
1143318685 M * rmoriz hm i'm using xfs at the moment.
1143318697 M * daniel_hozac http://linux-vserver.org/Standard+non-shared+quota
1143318698 M * Bertl you might want to add a note there
1143318737 M * rmoriz thank you
1143318798 M * rmoriz one tip (don't hit me) - add corresponding kernel, vserver and util-vserver version to each wiki page :)
1143318894 Q * mnemoc Ping timeout: 480 seconds
1143318895 M * Bertl might make sense, but you have to tell this to the folks adding the pages .)
1143318954 Q * mkhl Quit: 
1143319015 J * mnemoc ~amery@user4-2.tutopia-dialup.ifxnw.cl
1143319024 M * Bertl wb mnemoc!
1143319075 M * rmoriz :)
1143319208 Q * hallyn Remote host closed the connection
1143319220 J * hallyn ~xa@c-24-11-243-196.hsd1.in.comcast.net
1143319229 M * Bertl wb hallyn!
1143319244 M * rmoriz is that a script? ;)
1143319249 M * Bertl no :)
1143319677 M * derjohn how do I tell cfq to schedule per vserver ? any magic ? or is every server a process group my the kernels perspective ?
1143319680 M * mnemoc thanks Bertl :)
1143319703 M * Bertl derjohn: one io queue per guest, per default on 2.1.1
1143319825 M * derjohn Bertl, so: if I set cfq I -> I dont have to do anything else in the guests config or so?
1143319833 M * Bertl nope
1143319847 M * derjohn what happens with AS scheduler?
1143319858 M * Bertl nothing special, works as always
1143319864 M * derjohn (and: does vserver patch the cfq part ???)
1143319870 M * Bertl yep
1143319984 M * derjohn 2.6.15-amd64-vs2.1.0.5.1 :(
1143320024 M * Bertl might already have that ... it's not _that_ new
1143320117 M * derjohn hm, so I may try to move forward towards 2.6.16 + devel? or exp?
1143320139 M * derjohn oh, exp 
1143320172 M * Bertl would not hurt to test rc14
1143320209 M * derjohn rc14 sounds promising. when do you expect rc1x so be declared devel ?
1143320231 M * Bertl pretty soon
1143320240 M * Bertl I didn't plan such a long rc series
1143320292 M * derjohn well .. yes and no. if the rcs only fix trivial stuff on each increment, the series could get long ..
1143320317 M * derjohn did anyone use 2.6.16 rc14 on amd64 ?
1143320355 M * Bertl yep, it booted fine there ... didn't get to much more though
1143320563 M * derjohn what was about the openvz stuff that got into kernekl recently? do we have to adapt linux-vserver to that piece of code?
1143320576 M * derjohn kernel .. I mean: mainline ...
1143320593 M * derjohn http://www.heise.de/newsticker/meldung/71236 (german)
1143320680 M * Bertl well, the heise news seem simply payed advertizement
1143320716 M * Bertl the lkml reference is outdate, much happened since
1143320781 M * Bertl the only information is that they release a suse kernel and want to sell VZ(tm) ;)
1143320785 M * derjohn eh, what? did mainline adapt vz code or not?
1143320795 M * Bertl not at all
1143320844 M * derjohn if this is the case I would like to contact heise and ask for the source. if they cant prove the truth, they should at least update the news
1143320853 M * Bertl as I said, probably payed advertizement from swsoft
1143320871 M * Bertl feel free to do so ...
1143320911 M * derjohn i dont see a problem in that kind of deal (I would act the same way if I owned a computer mag) but the part with the mainline chage is simply a lie ????
1143320920 M * derjohn if so, that would be not OK.
1143320931 M * derjohn (the suse part is absolutely OK)
1143320950 M * Bertl what do they claim? nothing except for a 'pisitive reaction'
1143320954 M * Bertl *positive
1143320968 A * derjohn cheks the url again 
1143320990 M * Bertl and this is a link to lwn, which focuses on one of many mails in a thread
1143321041 M * derjohn ok I should have read more carefully: Mindestens den ersten der insgesamt fünf Patches sieht er als geeignet für die Aufnahme in den Standardkernel an. 
1143321058 M * derjohn so it is not in mainline yet. which part are they talkign about?
1143321080 M * derjohn does linus know about the vs code as alternative?
1143321101 M * Bertl http://thread.gmane.org/gmane.linux.kernel/375206
1143321116 J * yang ~yang@cpe-213-157-253-172.dynamic.amis.net
1143321146 M * yang My vserver got hacked, now i get this error on my reboot - is it still safe to run it or is it better to reinstall? http://pastebin.com/622226
1143321182 M * yang the output is for guest
1143321254 M * Bertl well, a hacked guest is never good to run, but the host should not be affected, (if only the guest was hacked)
1143321297 M * derjohn the output does ot look worse then a normal guest .. yang which line scares you?
1143321318 M * derjohn yang, how does the output of a differnet guest on that host look?
1143321337 M * yang the line ... /usr/lib/util-vserver/vserver.stop: line 85: 16222 Killed 
1143321351 M * dev0 uhm that's not that unusual
1143321363 M * yang becouse when i restart the normal guest i dont get this line
1143321364 M * derjohn dev0, the idea here ... 
1143321391 M * Bertl probably some shutdown scripts are running
1143321392 M * derjohn yang, a differnt server-process that procuces that line? or do all have the _same_ conf?
1143321401 M * yang so its enough that i removed the user from the guest, he wont be able to log in again?
1143321415 M * derjohn yang, no
1143321416 M * daniel_hozac yang: you can't be sure of that.
1143321422 M * yang they have the same confs
1143321431 M * daniel_hozac for all you know, sshd could be replaced.
1143321434 M * derjohn yang, build a new guest and put the configs in
1143321445 M * derjohn daniel_hozac, at least (!)
1143321462 M * derjohn daniel_hozac, at least it not a kernel-module rootkit ;)
1143321467 M * yang well this bloody user waas ddosing one server with 80mbit/s from my server, and luckily i got an email from the abused server so that i know what happened
1143321471 M * derjohn s/it/it is/
1143321497 M * derjohn yang, that shows you have proper hardware and a proper ISP !
1143321512 M * yang i have removed his shell at 12:00 and he was capable of ddosing at 20:00
1143321519 M * derjohn yang, wasnt it the www-data user what shot the DoS ?
1143321538 M * derjohn shell? UID 0 ? or normal user?
1143321539 M * yang no it was a user which i added, then changed his shell to /bin/false
1143321549 M * yang normal user
1143321566 M * derjohn weak password?
1143321568 M * yang he was ddosing for 2 hours
1143321591 M * derjohn yang, hope you are charged at 95% method by your ISP ;)
1143321610 M * yang what do you mean by method?
1143321630 M * derjohn yang, eh, forget it, not so imporent by now. fix your guest ;)
1143321645 M * derjohn yang, which distro ?
1143321659 M * yang debian sarghe
1143321701 M * derjohn well, the easiest way is to setup a new guest. if you try coroning ... that can take a lot of time and you cant be suer at all
1143321704 M * derjohn *sure
1143321706 M * yang well, i dont remember of changing root password on a guest, maybe he figured it out
1143321735 M * yang but the abuse was started from user shell
1143321738 M * derjohn yang, check lastlog -> are the logins from strange IPs ?
1143321765 M * yang he hasnt logged after 12h, but the ddos was triggered at 20h
1143321788 M * derjohn to my experience most hackers to care much about hiding fingerprints
1143321795 M * derjohn (nowadays)
1143321808 M * derjohn yang, so the syslog was stopped at 12 ?
1143321822 M * derjohn and the last few logins before that time?
1143321824 M * yang ok i ll setup new guest, what about host server, can it get hacked if the guest is compromised?
1143321841 M * derjohn yang, usually not.
1143321862 M * Bertl very unlikely unless you have ssh-keys for guest2root :)
1143321896 M * derjohn linux-vserver has security features. it would ring alarm bells here if this attacker found an overflow 
1143321953 M * derjohn yang, the attacker cant escape the "chroot" if the barrierflag ist set and/or xid tagging is on
1143321981 M * Bertl xid tagging is not relevant here
1143322000 M * yang ok
1143322031 M * yang ./bin/false shell disables user from getting inside over ftp, telnet, ssh
1143322066 M * derjohn yang, ftp? nor necessarily
1143322068 M * derjohn not
1143322085 M * derjohn check /etc/shells and you ftp setup. 
1143322141 M * yang in /etc/shells /bin/false isnt listed
1143322263 M * yang ok well, i am leaving
1143322664 M * Bertl cya
1143322815 Q * lilalinux_ Remote host closed the connection
1143323155 J * f_ ~f_@83-215-237-1.seek.stat.salzburg-online.at
1143323202 M * Bertl welcome f_!
1143323987 P * meandtheshell 
1143324007 J * independence ~independe@80.252.191.9
1143324030 M * Bertl welcome independence!
1143324040 M * independence Hi :)
1143324062 M * independence You remember me? I had a problem with Xforwarding from a vserver guest a couple of days ago
1143324073 M * Bertl yup
1143324113 M * independence Ok, so now I get this error message: Xlib: connection to "dione:10.0" refused by server
1143324116 M * independence Xlib: Invalid MIT-MAGIC-COOKIE-1 key
1143324118 M * independence xterm Xt error: Can't open display: dione:10.0
1143324130 M * independence Sometimes I get this though: xterm: Error 32, errno 2: No such file or directory
1143324133 M * independence Reason: get_pty: not enough ptys
1143324135 M * independence Cannot chmod /dev/pts/0 to 666 currently 620: Operation not permitted 
1143324142 M * independence Don't know why, it seems quite random to me..
1143324188 M * Bertl well, first, it seems that the pts does not belong to you
1143324266 M * Bertl let's upload the output of testme.sh and 'vserver-info - SYSINFO' first
1143324276 M * independence If i ls -l it, i get that I'm the owner
1143324279 M * Bertl (pastebin.com or so)
1143324299 M * Bertl how did you enter the guest?
1143324311 M * independence via ssh
1143324320 M * Bertl as the user you are now, right?
1143324334 M * independence http://pastebin.com/622328
1143324337 M * independence yes
1143324396 M * Bertl okay, quite an old kernel ...
1143324423 M * daniel_hozac not even the latest stable :)
1143324434 M * independence It's the one from portage.. (gentoo)
1143324477 M * Bertl do you have a problem switching to a more recent one?
1143324495 M * daniel_hozac it's not the most recent one in portage.
1143324497 M * independence I havn't tried
1143324513 M * independence But 2.6.15 is in portage now, I'll try that instead
1143324619 M * independence I ran make oldconfig and got a question about what IO Scheduler to use as default, any ideas?
1143324639 M * daniel_hozac Bertl: how would i output a register's contents from C?
1143324703 M * Bertl you need inline asm for that
1143324744 M * daniel_hozac ok... i figured as much, but i really don't know asm :)
1143324744 M * Bertl i.e. move that register to some C variable in asm
1143324750 M * Bertl okay, sec
1143324952 M * Bertl http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html
1143325004 M * daniel_hozac ah, thanks!
1143325471 J * VLD ~Nihuya@80.72.16.107
1143325502 Q * VLD Quit: 
1143325764 Q * f_ Quit: This computer has gone to sleep
1143326777 M * daniel_hozac Bertl: just to make sure i understand, return values are stored in %eax, right?
1143326795 M * daniel_hozac that is also true for syscalls, correct?
1143326795 M * Bertl on call return, on x86 yes
1143326814 M * Bertl yep
1143326876 M * Bertl see http://vserver.13thfloor.at/Stuff/SYSCALL/syscall.h
1143326893 M * Bertl (the comment for i386)
1143326925 M * daniel_hozac so in utilvserver_checkCompatVersion, the return value from the syscall should be stored in %esi as we reach b7fb61.
1143326974 M * daniel_hozac however, %esi is not used to save the return value to the position where the variable is.
1143326977 J * f_ ~f_@83-215-237-1.seek.stat.salzburg-online.at
1143327007 M * daniel_hozac %eax is used for that, which has been clobbered by the call to __errno_location.
1143327112 M * daniel_hozac am i misinterpreting the asm code, or does that look like the problem?
1143327175 M * daniel_hozac b7fb6c is two instructions too late.
1143327208 M * Bertl let's start at b7fb5c
1143327217 M * Bertl we compare with -MAX_ERR
1143327238 M * Bertl when above that, we branch to b7fb95 (error case)
1143327250 M * daniel_hozac which the kernel debugging shows doesn't happen.
1143327273 M * Bertl okay, let's look at the 'ok' branch then
1143327291 M * Bertl we get the errno var (call) returned in eax
1143327330 M * Bertl it is then saved to a pic position 0x160
1143327351 M * Bertl (the location)
1143327354 M * daniel_hozac but 0x160 is the result variable.
1143327365 M * Bertl is it?
1143327372 M * daniel_hozac judging by b7fb3a.
1143327390 M * daniel_hozac (that's an if (res == 0))
1143327428 M * Bertl would be easier to have source annotated asm code there
1143327457 M * Bertl maybe you could 'test' compile the responsible file with -S ?
1143327471 M * Bertl (make sure to use the same options, flags, etc ...)
1143327473 M * daniel_hozac would -save-temps works?
1143327482 M * Bertl could do the trick
1143327562 M * daniel_hozac it looks like an optimizer bug to me.
1143327563 M * Bertl but that very much reminds me of the issues we saw with Hollow
1143327588 M * Bertl nah, not necessarily, the errno part is still inside the asm wrapper
1143327626 M * daniel_hozac is it? even for the success case?
1143327722 M * Bertl yes, well, the errno part should not happen there
1143327765 M * daniel_hozac i think that's the utilvserver_checkCompatVersion code.
1143327778 M * daniel_hozac right after the syscall, it does v_errno = errno;
1143327804 Q * independence Quit: reboot
1143327872 M * daniel_hozac http://daniel.hozac.com/vserver/lib_libvserver_la-checkversion.o
1143327925 M * Bertl hmm, close but no banana :)
1143327943 M * daniel_hozac ?
1143328003 M * Bertl the code here seems correct
1143328046 M * daniel_hozac i think it seems to have the same problem.
1143328073 M * Bertl ah, yes indeed
1143328115 M * Bertl but why is the call reordered there, I don't get it
1143328174 M * daniel_hozac me neither.
1143328244 M * Bertl can we get preprocessed C code?
1143328251 M * Bertl i.e. -E output?
1143328353 M * daniel_hozac http://daniel.hozac.com/vserver/lib_libvserver_la-checkversion.E
1143328780 M * Bertl well, it seems as if gcc is making assumptions which are not true
1143328821 M * daniel_hozac yeah.
1143328864 M * Bertl uninlining the syscalls will probably fix that
1143328947 M * micah bertl: i've finally got 0.30.210 built against dietlibc 0.29 which incorporate those parisc syscall tweaks
1143328974 M * micah Bertl: so... should I run some of the test scripts?
1143328990 M * Bertl won't hurt, no?
1143329025 M * Bertl [011]# failed.
1143329043 M * Bertl but this one is funny too:
1143329048 M * Bertl Ea 0.30.210  (S*) <>
1143329069 M * micah I dont see that in the one I ran, i see: Linux 2.6.15-vs2.1.0.4 parisc64/0.30.210/0.30.210 [Ea] (0)
1143329081 M * micah VCI:  0002:0001 263 031101f6
1143329091 M * Bertl use the testme.sh-0.15
1143329096 M * micah ah, a new testme
1143329101 M * Bertl vserver-info - SYSINFO
1143329103 M * Bertl lseek(): Invalid argument
1143329158 M * micah this is with --enable-apis=NOLEGACY
1143329177 M * Bertl lseek is unrelated, it's a dietlibc bug, I think
1143329178 Q * Viper0482 Remote host closed the connection
1143329371 M * micah uf, my xorg just hung
1143329389 M * micah Bertl: could it be related to the toolchain in stable?
1143329435 J * mkhl ~mkhl@200-148-40-3.dsl.telesp.net.br
1143329648 M * Bertl micah: possible, but not very likely
1143330082 M * Bertl daniel_hozac: http://vserver.13thfloor.at/Stuff/SYSCALL/sysct.c
1143330093 M * Bertl does this show similar effects with your gcc?
1143330248 M * Bertl http://vserver.13thfloor.at/Stuff/SYSCALL/sysct.s here is the output of gcc 3.3.5
1143330420 M * daniel_hozac Bertl: no, that moves %eax to res before calling __errno_location.
1143330451 M * Bertl okay, that is a _copy_ from the preprocessor code you uploaded
1143330477 M * Bertl the only difference is the errno_location function
1143330502 M * Bertl well, and your compile options, whatever they may be
1143330508 Q * f_ Ping timeout: 480 seconds
1143330508 P * cmantito *CRACK*
1143330533 M * daniel_hozac i used the same compile options as before.
1143330577 M * Bertl okay, try to 'adjust' the testcase until it does something wrong
1143330593 M * Bertl I know that isn't that easy ...
1143330675 J * f_ ~f_@83-215-237-1.seek.stat.salzburg-online.at
1143330679 M * daniel_hozac removing __errno_location and #include'ing errno.h does it.
1143330988 M * daniel_hozac it seems to be the __attribute__((__const__)) that does it.
1143331043 M * daniel_hozac once i add that to the __errno_location definition, it's wrong even without errno.h
1143331055 M * daniel_hozac remove it, the correct code is generated again.
1143331095 M * Bertl cool, now the only thing you have to do is to try that with gcc-HEAD
1143331113 M * Bertl and ask the gcc folks if that is a bug or feature :)