1258761836 M * Bertl because they do not try to bind in that way
1258762012 M * mkee is because that automatic special ip sepecial casting?
1258762021 M * Bertl yep
1258762076 M * mkee i will recompile kernel and check it, thanks Bertl ;)
1258762112 M * Bertl no need to recompile, that's what the ~single_ip in nflags is for
1258762120 M * Bertl i.e. it disables the special casing
1258762132 M * mkee it doesnt work
1258762172 M * Bertl did you check that the single_ip flag is gone, after you restarted your guest?
1258762198 M * mkee well how to check that ;)?
1258762264 M * Bertl nattribute --get --nid <guest-nid>
1258762542 M * mkee i recompiled kernel
1258762547 M * mkee and its still same
1258762549 M * mkee ;/
1258762611 M * Bertl run strace -fF on the proftpd start, and upload the trace (inside the guest)
1258762829 M * daniel_hozac what does netstat -pnlt show on the host?
1258762932 Q * AndrewLee Remote host closed the connection
1258762993 M * mkee Bertl: how i can grab strace -fF in to one file to show you?
1258763008 M * Bertl strace -fF -o file ...
1258763029 M * mkee daniel_hozac: netstat -apln doesnt show there is running anyhting on guest on port 21
1258763059 M * daniel_hozac that's why i said the host.
1258763131 M * mkee err i mean host
1258763132 M * mkee sorry
1258763148 M * mkee even cant check on guest cause of grsec
1258763148 M * daniel_hozac so proftpd is not running on the host?
1258763158 M * mkee nope
1258763210 M * mkee Bertl: http://213.251.165.88/log.txt
1258763281 M * mkee i even dont know what does that mean
1258763282 M * mkee ;S
1258763303 M * daniel_hozac it says proftpd is already running.
1258763310 M * Bertl it means that you did it wrong :)
1258763326 M * mkee lol
1258763342 M * mkee sorry
1258763352 M * mkee my first steps with strace ;p
1258763423 M * mkee any solution?
1258763446 M * Bertl yeah, stop it and try again :)
1258763467 M * mkee stop what ;}?
1258763503 M * Bertl proftpd, as the scripts say it is already running
1258763638 M * mkee hthttp://213.251.165.88/log1.txt
1258763707 M * mkee is it good now?
1258763878 M * Bertl yep, looks better
1258763904 M * Bertl you sure you are not sharing any guest IP with another guest, or have a proftpd running on the host?
1258763921 J * AndrewLee ~andrew@u7.hlc.edu.tw
1258763934 M * Bertl (or maybe in that very same guest :)
1258763940 M * mkee nope im sure i run only 1 guest
1258763959 M * mkee if thats handy i can run now proftpd on host and run strace on guest
1258763964 M * mkee ?
1258763990 M * Bertl nah, run lsof -ni :21 in the guest
1258764065 M * Bertl and if that doesn't return anything, run 'ncontext --migrate --nid 1 -- lsof -ni :21' on the host
1258764067 M * mkee nothing
1258764143 M * mkee ncontext: execvp("lsof"): No such file or directory
1258764162 M * Bertl you don't have lsof on the host?
1258764210 M * mkee got it now
1258764247 M * mkee that doesnt return anything
1258764282 M * Bertl what kernel/patch do you use?
1258764322 M * mkee latest one
1258764328 M * mkee .31.6
1258764333 M * mkee vs+gr
1258764351 Q * vServer_User Ping timeout: 480 seconds
1258764379 M * Bertl well, it might be grsec related, at least I don't see why it shouldn't work or fail in that way on a vanilla + Linux-VServer kernel
1258764410 M * Bertl so, probably the best would be to try without grsec
1258764417 M * mkee no problem
1258764482 M * mkee recompiling
1258764494 J * vServer_User ~vServer_U@host90-152-0-26.ipv4.regusnet.com
1258764555 M * mkee i could try with other ftpd deamon like vsftpf, what you thinking?
1258764853 M * Bertl nah, proftpd is working fine in Linux-VServer, if not it would be a bug
1258764855 J * blues_ ~blues@bir64.neoplus.adsl.tpnet.pl
1258764974 Q * blues Ping timeout: 480 seconds
1258765057 Q * dowdle Remote host closed the connection
1258765583 Q * AmokPaule Remote host closed the connection
1258766122 M * mkee Bertl: done
1258766200 Q * vServer_User Ping timeout: 480 seconds
1258766280 J * vServer_User ~vServer_U@host90-152-0-26.ipv4.regusnet.com
1258766317 M * mkee Bertl: same -_-
1258766350 M * Bertl and you only have a single guest running with that proftpd?
1258766368 M * Bertl and no ftpd on the host?
1258766373 M * mkee do you wanna look ;p?
1258766384 M * mkee yes Bertl 
1258766393 M * mkee i want run ftp on guest and host
1258766433 M * Bertl could you pack up your guest (with the proftpd) and put it somewhere for me to download?
1258766462 M * mkee yup
1258766467 M * mkee just hold a sec
1258766483 M * mkee if u want i can give u access
1258766489 M * mkee but i can tar it for u anyway
1258766547 M * mkee you need only source of guest or sysconfig fir as well?
1258766568 M * Bertl well, for now the guest data should suffice 
1258766577 Q * Chlorek Ping timeout: 480 seconds
1258766591 J * Chlorek cokolwiek@c.sed.pl
1258766738 M * mkee tar: var/run/proftpd/proftpd.sock: socket ignored
1258766777 M * mkee http://213.251.165.88/guest.tgz
1258766897 M * mkee got it?
1258766936 M * Bertl yep, what distro is the guest?
1258767021 M * mkee gentoo
1258767033 Q * yarihm Quit: This computer has gone to sleep
1258767252 Q * vServer_User Ping timeout: 480 seconds
1258767349 J * vServer_User ~vServer_U@host90-152-0-26.ipv4.regusnet.com
1258767488 M * mkee Bertl: any luck?
1258767573 M * Bertl works fine here, no problem to bind to the assigned address (had to change it in the config to match my setup)
1258767642 M * Bertl so I conclude that you either have an unusual config, or what is more likely, some overlap with host (or other guest) services
1258767667 M * mkee Bertl: can i pm you
1258767680 M * Bertl kernel here is 2.6.31.5-vs2.3.0.36.22, that should match yours quite well
1258767691 M * Bertl if necessary, yes :)
1258768057 Q * uva Ping timeout: 480 seconds
1258768142 J * uva bno@118-160-164-147.dynamic.hinet.net
1258768337 J * nwmcsween ~nwmcsween@dhcp-0-23-69-9d-4d-67.cpe.citywest.ca
1258768357 Q * Chlorek Ping timeout: 480 seconds
1258768371 N * nwmcsween Guest2957
1258768387 M * Guest2957 does anyone have a somewhat new patch for libvirt to implement vserver?
1258768406 M * Guest2957 I wouldn't mind working with it and trying to get it into libvirt
1258768602 M * Bertl I guess daniel_hozac should have the patch which was submitted some years? ago ... you can probably start from there
1258768627 M * Bertl I doubt that  anything newer was done, but maybe I'm just wrong :)
1258768722 M * Bertl but I guess libvirt integration shouldn't be too hard, after all it handles OpenVZ as I heard ...
1258769016 M * mkee oh crap! the host was running an ftpd which unfortunatley boun to 0.0.0.0, and that the issue is non of Linux-VServer or grsec related
1258769064 M * Bertl another mystery solved .. :)
1258769077 M * mkee Bertl: thanks for pacient and help ;}
1258769094 M * Bertl you're welcome!
1258769104 M * mkee If i wouldnt be a man I could shag with you ;D
1258769720 J * jrklein ~jrklein@ppp-70-130-46-49.dsl.wchtks.swbell.net
1258769825 Q * AndrewLee Ping timeout: 480 seconds
1258770192 J * AndrewLee ~andrew@u7.hlc.edu.tw
1258770604 J * Chlorek cokolwiek@c.sed.pl
1258772267 Q * Chlorek Ping timeout: 480 seconds
1258772426 J * derjohn_foo ~aj@e180192008.adsl.alicedsl.de
1258772859 Q * derjohn_mob Ping timeout: 480 seconds
1258773887 J * Chlorek cokolwiek@c.sed.pl
1258774282 J * aj__ ~aj@e180193045.adsl.alicedsl.de
1258774658 Q * derjohn_foo Ping timeout: 480 seconds
1258775697 J * nwmcsween_laptop nwmcsween_@dhcp-0-23-69-9d-4d-67.cpe.citywest.ca
1258775822 J * saulus_ ~saulus@c193028.adsl.hansenet.de
1258775953 M * Bertl wb nwmcsween_laptop! 
1258775971 M * Bertl off to bed now .. have a good one everyone!
1258775984 N * Bertl Bertl_zZ
1258776227 Q * SauLus Ping timeout: 480 seconds
1258776229 N * saulus_ SauLus
1258778719 Q * barismetin Remote host closed the connection
1258780097 Q * padde Quit: leaving
1258780104 J * padde ~padde@patrick-nagel.net
1258780161 Q * padde 
1258780207 J * padde ~padde@patrick-nagel.net
1258780228 Q * hparker Quit: Read error: 104 (Peer reset by connection)
1258790408 N * DoberMann[ZZZzzz] DoberMann
1258790835 J * SubZero ~SubZero@chello089076140236.chello.pl
1258790840 J * yarihm ~yarihm@80-219-171-38.dclient.hispeed.ch
1258792637 J * uva_ bno@118-160-164-147.dynamic.hinet.net
1258792752 Q * uva_ Max SendQ exceeded
1258792770 J * uva_ bno@118-160-164-147.dynamic.hinet.net
1258792788 Q * yarihm Quit: This computer has gone to sleep
1258792873 N * DoberMann DoberMann[PullA]
1258793037 Q * uva Ping timeout: 480 seconds
1258795485 J * yarihm ~yarihm@77.109.189.6
1258795699 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1258797706 Q * nwmcsween_laptop Ping timeout: 480 seconds
1258797962 J * barismetin ~barismeti@jua06-1-82-242-159-114.fbx.proxad.net
1258798828 Q * barismetin Remote host closed the connection
1258799281 J * barismetin ~barismeti@jua06-1-82-242-159-114.fbx.proxad.net
1258800662 Q * yarihm Quit: This computer has gone to sleep
1258800937 J * AmokPaule ~amokpaule@brsg-4dbb1e65.pool.mediaWays.net
1258801567 M * mkee mm
1258802890 J * florian_freenode ~Florian@dslb-088-076-048-058.pools.arcor-ip.net
1258802910 Q * florian_freenode 
1258803690 J * fleischergesell ~fleischer@dslb-088-076-048-058.pools.arcor-ip.net
1258803737 M * fleischergesell hello, does anybody know if the limits set in /etc/security/limits.conf apply within a vserver without having to add any capabilities?
1258804227 J * yarihm ~yarihm@80-219-171-38.dclient.hispeed.ch
1258804820 Q * Guest2957 Ping timeout: 480 seconds
1258805282 Q * yarihm Quit: This computer has gone to sleep
1258806013 J * BenG ~bengreen@94-169-110-10.cable.ubr22.aztw.blueyonder.co.uk
1258806550 Q * BenG Quit: I Leave
1258806571 M * daniel_hozac fleischergesell: you can't raise limits that way, but you can lower them.
1258806591 M * daniel_hozac fleischergesell: so make sure your initial settings are good enough.
1258809173 N * Bertl_zZ Bertl
1258809178 M * Bertl morning folks!
1258809469 M * arachnist moin
1258809481 M * Bertl daniel_hozac: any chance for an updated pre tarball (before folks start using the 2855?
1258809486 M * arachnist not exactly morning. it's 2:20 PM ;>
1258809537 M * Bertl it's exactly 12 minutes since I got up, so definitely 'Monring' in BUT :)
1258811050 M * daniel_hozac Bertl: yeah
1258811086 M * daniel_hozac i was just looking at doing some more fixes before doing a new snapshot.
1258811138 M * daniel_hozac adding f12, upstart, etc.
1258811291 M * Bertl k, just keep in mind, perfect is the enemy of good :)
1258811365 M * daniel_hozac yeah.
1258811373 M * daniel_hozac i'll spin one tonight.
1258811390 M * daniel_hozac just didn't want to create one while i was working on things :)
1258811495 Q * theocrite Quit: Lost terminal
1258811518 J * theocrite ~Hubert@kim.theocrite.org
1258811876 M * fleischergesell daniel_hocaz: so the limits.conf on the host applys to the guests in a way that it sets the upper limits which I can then lower for that particular guest using the limits.conf inside the guest?
1258812077 M * Bertl kind of .. host limits are inherited, unless overwritten
1258812214 M * fleischergesell but I can only overwrite limits by lowering them - the host sets always the upper limits? (given the guest have no extra capabilites)
1258812287 M * Bertl depends on where you set it .. in the guest config you can also raise them
1258812790 M * daniel_hozac Bertl: http://people.linux-vserver.org/~dhozac/p/k/delta-dlimit-feat02.diff
1258812798 M * daniel_hozac re: ML
1258812814 M * daniel_hozac this is something i'll need too in about 48 hours :)
1258812992 Q * eyck Ping timeout: 480 seconds
1258813432 Q * fleischergesell Ping timeout: 480 seconds
1258813455 M * Bertl daniel_hozac: ookayy ... :)
1258813640 J * geb ~geb@earth.gebura.eu.org
1258813655 J * hparker ~hparker@208.4.188.201
1258813766 M * Bertl daniel_hozac: the question for me is, should we really 'switch' the interface? I'd tend more to extend it .. i.e. have a 32bit and 64bit interface side by side .. but maybe switching to 64bit only is the way to go ...
1258813802 M * daniel_hozac what purpose would that serve though?
1258813815 M * daniel_hozac that seems to just complicate it further IMHO.
1258813830 J * eyck ~eyck@77.79.198.60
1258814208 M * Bertl well, we account at byte level (as the kernel does), but our base unit is 1k, switching to a 64bit interfaces gives us two choices: a) map the values 1:1 for space and inodes b) shift the space by 10bits as for the 32bit interface
1258814307 M * Bertl a) obviously produces a lot of 'untested' cases for existing interfaces, while b) simply extends the existing setup by several bits and create some cornercases for the upper 10 bits
1258814308 M * daniel_hozac that's true.
1258814409 M * Bertl we could avoid that by having a flag/command which still uses 32bit structures, but with a higher shift (maybe for space and inodes)
1258814437 M * Bertl e.g. 20 or 30 instead of 10
1258814478 M * Bertl it would obviously increase the granularity for larger settings, but I'm not sure that this would matter
1258814515 M * Bertl but just an idea ... after all, most of the handling is in userspace
1258814727 M * daniel_hozac well, personally, from a lazyness and least-amount-of-testing-required point of view, i like this interface.
1258814956 M * Bertl this interface means the existing one, extended to 64bit, capped at 53/54 bit?
1258814966 M * daniel_hozac yeah.
1258814979 M * Bertl okay, and you want to 'replace
1258814986 M * Bertl it via versioning, yes
1258814994 M * daniel_hozac yes.
1258815024 M * Bertl okay, fine for me ... but please add some checks at the 53/54 bit border in userspace
1258815046 M * daniel_hozac we can have those in the kernel, can't we?
1258815074 M * Bertl they will be implicit, i.e. after the shift, bits will be dropped
1258815107 M * Bertl and error reporting that actual bits were dropped in the kernel is a bad idea IMHO
1258815124 M * daniel_hozac yeah, but we can do an if (x & 0xFFC0000000000000) return -EINVAL;
1258815125 M * daniel_hozac why?
1258815160 M * Bertl because negative values are handled special
1258815191 M * daniel_hozac they're not negative anymore though.
1258815204 M * daniel_hozac which... can be considered a bad thing.
1258815232 M * Bertl I was talking about the magic values to keep settings
1258815238 M * daniel_hozac yeah
1258815250 M * daniel_hozac but they're uint32_t's.
1258815261 M * daniel_hozac so with a 64-bit interface, they're no longer negative.
1258815265 M * Bertl and we need to rearrange the struct to move the 64bit values up front
1258815272 M * daniel_hozac nah.
1258815282 M * Bertl otherwise we will hit packing issues
1258815289 M * daniel_hozac it's padded correctly in my patch, by moving the flags after the pointer.
1258815304 M * daniel_hozac or... hmm.
1258815327 M * Bertl wrong patch :)
1258815339 M * daniel_hozac hmm?
1258815345 M * Bertl +	uint32_t flags;
1258815345 M * Bertl +	uint64_t space_used;			/* used space in kbytes */
1258815358 M * Bertl that's a nono
1258815365 M * daniel_hozac why?
1258815378 M * Bertl because it will cause padding after flags
1258815394 M * Bertl (on certain architectures :)
1258815399 M * daniel_hozac right.
1258815455 M * Bertl btw, we leave the inodes on 32bit? sounds half hearted to me
1258815471 M * arachnist good to see at least some poeple still care about details like that
1258815483 M * arachnist (like the padding)
1258815490 M * daniel_hozac we have to...
1258815504 M * Bertl arachnist: it bite us once :)
1258815520 M * daniel_hozac and 4 million inodes will be enough for everyone :-)
1258815536 M * daniel_hozac billion, i mean.
1258815551 M * Bertl Bill, is it you? :)
1258815620 M * Bertl okay, I agree that we should stick to the 32bit for inodes, especially as the accounting is 32bit there too
1258815645 M * Bertl (at least on 32bit archs)
1258815714 M * Bertl okay, I'll work my way through it and upload a patch for review shortly
1258816047 Q * balbir_ Read error: Connection reset by peer
1258816534 M * Bertl hmm, we have another problem, the magic values need to be extended to 64bit too and checked depending on 32bit or 64bit interface ...
1258816663 M * Bertl and you need to use 32bit and 64bit magics for inodes and space (in userspace) i.e. different ones
1258816786 M * daniel_hozac yeah
1258816923 M * Bertl you sure you want to go through with that and not just use a flag to change the shift value? I mean, that's an awfull lot of testing
1258817287 M * daniel_hozac i'd rather we add the shift value as a field to the struct if that's the route you want to go.
1258817453 Q * barismetin Remote host closed the connection
1258817487 M * Bertl that'd be an option too, but we need to have two structs for that, which doesn't seem to be required
1258817594 M * Bertl as far as I can tell, the flags field is unused
1258817704 M * Bertl I presume it is set to 0 in current implementations (userspace)
1258817727 J * balbir_ ~balbir@122.172.35.113
1258817937 M * daniel_hozac well, it's passed as an argument, but yes.
1258818035 M * Bertl so we could simply add a mega and giga flag there
1258818093 M * Bertl all you need to do in userspace is check for the limit and shift by 10, setting the appropriate flag(s)
1258818144 M * Bertl same for reading the values, just the other way round
1258818164 M * daniel_hozac not exactly pretty, but i guess it works.
1258818261 M * Bertl the advantage is that we a) do not need two magic sets b) we do not need to retest the interface for 32/64bit issues and for different archs c) we are backward compatible 
1258818261 Q * Piet Remote host closed the connection
1258818320 M * Bertl we still add a new syscmd version, so that userspace knows how to handle it
1258818369 J * Piet ~Piet__@04ZAACGAI.tor-irc.dnsbl.oftc.net
1258818388 M * Bertl overflows in the old interface are handled like they are handled now (not at all) working with 'old' tools should nevertheless be consistant 
1258818836 M * Bertl we could make it a little more 'organic' by interpreting the lower two bits of the flags field as shift value (x10)
1258818965 M * Bertl (if you prefer that)
1258818991 M * daniel_hozac how about the lower 4 bits? :)
1258819017 M * Bertl fine for me too
1258819029 M * daniel_hozac (lower 3 is already too much, but a nibble seems like a nice boundary)
1258819098 M * Bertl okay, but has one drawback, we now can reach 35, which is over limit
1258819137 M * Bertl or we switch to 4 bit shift for each bit, which in turn gives us odd multiples
1258819162 M * Bertl at least the mega is not an option with that
1258819196 M * daniel_hozac well really, mega and giga and tera flags are fine with me.
1258819250 M * daniel_hozac if they happen to be 0x1, 0x2 and 0x3 respectively, so be it :-)
1258819267 M * Bertl hmm, it would be kilo, mega and giga IMHO
1258819289 M * daniel_hozac you'd make kilo a flag?
1258819295 M * daniel_hozac so the new default would be bytes?
1258819301 M * daniel_hozac that would be bad IMHO.
1258819302 M * Bertl we have a 64bit limit, so our shift value should be between 0 and 31 bits
1258819324 M * Bertl (to shift the 32bit userspace values around)
1258819330 M * daniel_hozac right.
1258819336 M * Bertl we currently use 10bits fixed
1258819358 M * Bertl so, IMHO we could do, 0, 10, 20, 30 bits shift, with 2 bits
1258819376 M * daniel_hozac i'd prefer it not to be 'organic', in that case.
1258819391 M * daniel_hozac i.e. 0x0 is kilo, 0x1 is not-kilo, 0x2 is mega, and 0x3 is giga.
1258819414 M * daniel_hozac or whatever values you see fit.
1258819440 M * daniel_hozac as long as kilo stays as 0x0, we just need a VCI_VERSION bump to know that the mega and giga flags are supported.
1258819449 M * Bertl okay, but be aware that this complicates your en/decoding
1258819492 M * Bertl i.e. you have to handle 3/4 cases instead of blindly using the 'shift' value
1258819498 M * daniel_hozac yes.
1258819500 M * daniel_hozac i know.
1258819524 M * Bertl an no real advantage if we bump the syscmd version
1258819556 M * daniel_hozac well, what i'm suggesting is that we don't need a new version.
1258819593 M * Bertl hmm, we should change that for out of line code
1258819605 M * Bertl no, actually we need to change that anyways
1258819620 M * Bertl otherwise older tools will suddenly get shift flags from the get calls
1258819632 M * daniel_hozac the flags are ignored.
1258819644 M * Bertl yeah, but the value is already shifted
1258819671 M * daniel_hozac yes, we can simply make get read the flags first.
1258819691 M * daniel_hozac i.e. if giga is set, >> 30
1258819701 M * Bertl so you want to pass the shift value to the kernel?
1258819717 M * Bertl that sounds like a can of worms to me ...
1258819728 M * daniel_hozac i don't see the problem.
1258819739 M * Bertl I'd let the kernel calculate the proper shift value
1258819748 M * daniel_hozac what's the "proper" value?
1258819764 M * Bertl it knows about the actual 64bit values, so it shifts it down to fit the 32bit interface
1258819771 M * daniel_hozac for space_used you might not care about the gigabytes.
1258819801 M * Bertl we could use 2x2 bits?
1258819808 M * daniel_hozac if you're only checking to see how much more space was consumed by something.
1258819824 M * Bertl basically working as exponent
1258819879 M * Bertl should simplify handling in kernel and userspace dramatically
1258819991 M * Bertl we could even put the code for the mapping in the kernel header files
1258820008 M * Bertl i.e. for you the interface would 'look' like 64bit 
1258820659 M * Bertl if that sounds good to you, I'll prepare something
1258822616 Q * Chlorek Ping timeout: 480 seconds
1258824280 Q * SubZero 
1258825743 J * Chlorek cokolwiek@c.sed.pl
1258826274 M * Bertl daniel_hozac: how about that: http://paste.linux-vserver.org/13896
1258826396 M * Bertl doesn't need a new syscall command version and still keeps backwards compatibility ... and you can use those functions from userspace as well, amking your actual interface 64bit
1258826672 J * ptiphus ~guillaume@APuteaux-554-1-66-134.w82-124.abo.wanadoo.fr
1258829059 Q * theocrite Quit: Lost terminal
1258829071 J * theocrite ~Hubert@kim.theocrite.org
1258829240 M * Bertl daniel_hozac: okay, here is the full patch: http://vserver.13thfloor.at/ExperimentalT/delta-dlimit-feat02.diff
1258830277 Q * jrklein Ping timeout: 480 seconds
1258835456 Q * ptiphus Quit: leaving
1258835707 J * hijacker_ ~hijacker@87-126-142-51.btc-net.bg
1258836978 Q * Piet Ping timeout: 480 seconds
1258837346 J * Piet ~Piet__@04ZAACGHK.tor-irc.dnsbl.oftc.net
1258837797 Q * theocrite Ping timeout: 480 seconds
1258837819 J * theocrite ~Hubert@kim.theocrite.org
1258841483 Q * hijacker_ Quit: Leaving
1258841484 Q * fback Read error: Connection reset by peer
1258841504 J * fback fback@red.fback.net
1258841507 J * dna ~dna@175-195-103-86.dynamic.dsl.tng.de
1258847575 Q * bonbons Quit: Leaving