1110067258 M * wishes good mornin 1110067269 M * wishes well afternoon even ;] 1110068008 N * Bertl_oO Bertl 1110068039 M * Bertl good afternoon wishes! 1110068073 M * Bertl hi ola! 1110068351 Q * ndim Ping timeout: 480 seconds 1110068575 J * ndim hun@helena.bawue.de 1110068593 Q * shuri Read error: Connection reset by peer 1110070717 M * jd86 Bertl: when i setup new servers how do i have it copy over from a template install? 1110070775 M * Bertl there is an experimental tool called vserver-copy, but basically you can use cp, tar, dump or rsync 1110070874 M * jd86 ah 1110070879 M * jd86 so theres no special thing 1110070880 M * jd86 alright 1110070926 M * Bertl if you want to utilize unification, vunify a will help you .. 1110071578 M * jd86 unification? 1110071596 M * jd86 how do you view all started vservers? 1110071622 M * Bertl vserver-stat 1110071624 M * jd86 thx 1110071837 M * jd86 Bertl: the man page of vserver is that on the site so i can print it, i'm kind of looking for the help for build also, 1110072074 Q * erwan_ho Read error: Operation timed out 1110073233 M * Bertl jd86: hmm? 1110074316 M * Bertl okay, off now .. maybe back later ... 1110074323 N * Bertl Bertl_oO 1110075482 Q * prae Quit: Pwet 1110079605 J * enum ~enum@cpe-24-175-6-109.houston.res.rr.com 1110079682 M * enum yo. can anyone point me to an installation document that is not distro specific? Or complete? 1110079740 M * enum The docs that I have found either state that they are incomplete, or they are distro specofoc 1110079805 M * daniel_hozac the installation procedure is distro specific though. 1110079832 M * enum so what do you do if you use another distro? 1110079839 M * enum for example I use CentOS 1110079839 M * daniel_hozac (or i guess it depends on what you mean by "insallation document") 1110079851 M * daniel_hozac s/insallation/installation/ 1110079865 M * daniel_hozac installation of the tools and kernel, or installation of vservers? 1110079867 M * enum I need a document that explains the procedure of installing vserver 1110079876 M * enum as a whole 1110079881 M * enum host & guest 1110079905 M * daniel_hozac CentOS is one of the RHEL respins, right? 1110079911 M * enum yes 1110079928 M * enum \cept.. I strip the hell out of it 1110079938 M * enum I run a minimal install, and then remove like 50+ packages 1110080000 M * daniel_hozac you'll need to be able to compile a kernel and util-vserver. 1110080041 M * enum k, I assumed as much 1110080748 Q * enum Quit: Leaving 1110088913 Q * sannes Read error: Connection reset by peer 1110090421 N * phreak_zZz DaPhreak 1110095491 Q * micah Ping timeout: 480 seconds 1110095727 J * micah micah@micha.hampshire.edu 1110095807 J * sannes ~ace@home.skarby.no 1110096710 Q * micah Ping timeout: 480 seconds 1110096887 J * micah micah@micha.hampshire.edu 1110103198 Q * PazZzzzooo Ping timeout: 480 seconds 1110103947 J * erwan_ho ~erwan@lns-vlq-39f-81-56-133-136.adsl.proxad.net 1110107442 J * Tbery ~tb@84.242.127.4 1110107449 M * Tbery HI all 1110108102 J * mhepp ~mhepp@r30s12p13.home.nbox.cz 1110109698 Q * Tbery Quit: Ukončuji 1110113498 Q * flock Read error: Operation timed out 1110113520 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il 1110115399 Q * _are_ Read error: Operation timed out 1110116108 Q * flock Read error: Connection reset by peer 1110116129 J * _are_ ~are@dsl-084-056-138-226.arcor-ip.net 1110117735 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il 1110118095 M * Seraph re 1110118118 M * Seraph Bertl_oO: do i see correctly that 0.30.203 does not yet have the 64/32bit compatibility interface? 1110118158 M * Seraph at least i don't see anything in the changelog so far.. 1110118238 M * _are_ what is a compability interface there? for the syscall numbers? 1110120061 Q * flock Remote host closed the connection 1110120133 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il 1110120186 Q * mhepp Quit: KVIrc 3.0.1.99 'Realia' 1110120306 M * Seraph _are_: for running a 32bit i386 userland with a 64bit x86_64 kernel 1110120451 M * daniel_hozac yep, that's still missing. 1110120584 M * Seraph ok 1110121845 Q * flock Remote host closed the connection 1110121935 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il 1110124329 J * mhepp ~mhepp@r30s12p13.home.nbox.cz 1110126651 J * prae ~prae@sherpadown.net 1110126655 M * _are_ Seraph: i run a dual 64bit opteron with vservers, some of them on 32 bit and I have not noticed problems so far 1110126721 N * Bertl_oO Bertl 1110126754 M * Bertl Seraph: yes, util-vserver needs to be compiled 64 bit, rest of userspace can be 32bit as well, no problem with that ... 1110126780 M * Bertl (i.e. for the vservers it doesn't matter, for the util-vserver tools, it does) 1110126893 M * _are_ ah, now I slowly get the problem. :-) 1110127743 N * Doener_zZz Doener 1110127801 M * Doener morning! 1110127815 M * Bertl morning Doener! 1110127980 M * erwan_ho lo Bertl 1110127980 M * Seraph Bertl: yep and it might help to introduce a flag to prefix "linux32" to chbind for these 32bit vservers :-P 1110128233 M * Doener i thought about the arp stuff... we currently bind the neighbours to the virtual netdevices... what about adding them to the real device and adding a virtualization layer within the neigh stuff? we could modify that to take tip into consideration, tag the neigh's and check with inet_addr_type(tip, neigh->nfxid) which neigh we should return on a lookup... but would probably cause problems with shared ip addresses... 1110128249 Q * mhepp Quit: KVIrc 3.0.1.99 'Realia' 1110128285 M * Doener back in a few minutes... 1110128288 N * Doener Doener|gone 1110128712 Q * ntrs_ Ping timeout: 480 seconds 1110128826 J * ntrs ~ntrs@Dardeene-68.188.50.87.charter-stl.com 1110129488 M * Bertl Seraph: hmm, please elaborate?! 1110129692 N * Doener|gone Doener 1110129845 M * Bertl wb Doener! 1110129851 M * Doener thx 1110129869 M * Bertl hmm .. what about vservers having the same ip(s) and/or communicating with the same hosts? 1110129876 M * Doener any opinions on the idea? my brain just spitted it out while i changed my nick ;) 1110130050 M * Doener of course we could just do a lookup on the context's fibtable too, as we just want to see if it's local 1110130094 M * Bertl okay, and another one ... 1110130115 M * Bertl in the future, we might want to 'allow' or 'deny' crosstalk between certain vservers 1110130140 M * Bertl this can basically done by 'not' providing the arp exchange between them right now 1110130154 M * Bertl (there is just no mechanism yet to controll that) 1110130181 M * Bertl and a final point, on ifdown a callback removes the local neigh entry, how to handle that? 1110130266 M * Bertl but granted, I thought about that too, it just had too many 'but what ifs' attached and I didn't find a good solution for most of them ... 1110130296 J * DuckMaster ~Duck@dyn-83-157-137-90.ppp.tiscali.fr 1110130371 M * Doener sharing ip addresses: no idea; communicating with same host: hm, if we take the tip (target ip) of the arp reply into consideration there should be no problem; deny crosstalk: good question; ifdown: ok, dump the idea ;) 1110130412 M * Doener i saw some traces of netfilter arp hooks in the code. what about that? just delayed or basically dropped? 1110130426 Q * DuckKing Read error: Operation timed out 1110130455 M * Bertl I think it would be a good solution to do the following (at a future point) for the arp stuff: 1110130476 M * Bertl - make some 'global' neigh waiting for reply list 1110130509 M * Bertl - have each arp-reply verified agains 'the rules' 1110130540 M * Bertl - send the reply for (arp_)process(ing) to the allowed contexts 1110130561 M * Seraph Bertl: well, point is that when you have an i386 vserver on an x86_64 system.. then you might want that vserver to think it's on a 32bit system.. thus running it with "linux32" will do that trick 1110130566 M * Bertl Doener: (outgoing requests could be allowed/denied by a chain check) 1110130603 M * Bertl Seraph: hmm, what does linux32 do? please enlighten me ... 1110130614 M * Seraph Bertl: i'm not entirely sure that will propagate to its children aswell, but that vserver for sure shouldn't try to allocate above the 4GB limit and shouldn't see the x86_64 machine type.. 1110130632 M * Seraph Bertl: it does limit the memory reporting and "fix" the uname -m 1110130645 M * Bertl machine type is trivally done with utsname stuff (see vutsname) 1110130688 M * Seraph ftp://ftp.x86-64.org/pub/linux-x86_64/tools/linux32 1110130693 M * Seraph would be its home btw. 1110130695 M * Bertl hmm, for memory reporting or such we might add a 32bit flag ... but I need some details about that linux32 ... 1110130699 M * Seraph just in case you wanna have a glimpse.. 1110130704 M * Bertl sure 1110131019 M * Bertl ah, that changes the personality! 1110131037 M * Bertl yeah, we can do that I guess (for an entire vserver) 1110131089 M * Bertl Seraph: could you try to 'hack' that into the vserver start process? 1110131122 M * Bertl basically as last command before the 'real' exec ... 1110131137 M * Seraph Bertl: well, it'd for sure be feasible to get that to work.. yet i still ain't sure it'll propagage as should.. 1110131144 M * Bertl and see if that distributes into ssh and such 1110131159 M * Bertl yes, that's the question!, because if not we can support that from the kernel side 1110131185 J * root ~root@rev.193.226.233.3.euroweb.hu 1110131187 M * Bertl hmm, so basically a simple check like: 1110131189 M * root hi folks :) 1110131193 M * Bertl hey root! 1110131193 M * Seraph Bertl: which "real" line? 1110131222 N * root rusty` 1110131222 M * Bertl Seraph: linux32 ... /bin/bash -c '/bin/sh' 1110131225 M * rusty` oops 1110131227 M * rusty` sorry for my name 1110131262 M * Seraph root@nyx:/etc/vservers# linux32 /bin/bash -c '/bin/sh' 1110131262 M * Seraph sh-2.05b# uname -m 1110131262 M * Seraph i686 1110131263 M * Seraph sh-2.05b# 1110131269 M * Seraph looks like it's working.. 1110131274 M * rusty` Bertl: do you know the LIDS kernel patch? (www.lids.org) 1110131279 M * Bertl yep 1110131315 M * rusty` does it works with vserver patch? 1110131324 M * rusty` or it's incompatible? 1110131339 M * Bertl no idea, never tried to combine them ... 1110131355 M * Bertl but give it a try ... 1110131767 M * rusty` ok, i give it a try... and provide the results later... 1110131862 Q * rusty` Quit: Leaving 1110131923 J * rusty` ~root@rev.193.226.233.3.euroweb.hu 1110131926 M * rusty` re 1110131936 M * rusty` i have an other quastion... :) 1110132013 M * Bertl go ahead! 1110132016 M * rusty` Bertl, what do you think about LIDS? do you think, it is a good security solution? 1110132050 M * Bertl well intrusion detection is no security solution at all ... 1110132083 M * Bertl it might be part of some security compromise avoidance system ... 1110132135 M * Bertl otoh, LIDS has grown far beyond intrusion detection ... so 1110132171 M * Bertl it might be a good 'addon' to improve vserver security ... 1110132273 M * Bertl I guess some stuff will clash, like the capability changes ... 1110132316 M * Bertl probably most of the file specific stuff will cause horrors too ... but as I said, never tried ... 1110132385 M * rusty` i see 1110132473 M * rusty` what do you think about security patches for the vanilla kernel (ex. grsec, etc...)? what are you suggest to use? 1110132500 M * rusty` what do you prefer, if you use any? :) 1110132574 M * Bertl hmm, good questions: I guess I 'prefer' to fix issues in mainline (if there are issues) and although I consider the various 'security' enhancements an interesting breeding ground, I do not consider most of them worth the efford ... 1110132599 M * Bertl let me put it this way: 1110132631 M * Bertl the best grsec or whatever will not protect you if your system allows root access with a weak (guessable) password ... 1110132664 M * Bertl it will just give you false security which in turn might even weaken your systems 1110133247 M * rusty` i agree with that, but i'm trying to view the situation from kernel side; the local security issues it's another quastion... :) 1110133459 M * rusty` let me put it this way: unfortunetly i'm not a kernel hacker, so i need to use patches like that becouse i can't resolve the problem for myself... 1110133497 M * Bertl yeah, but do you think that Linus or Adrew would leave real kernel issues unfixed, just for fun?! 1110133568 Q * prae Quit: Pwet 1110133575 J * prae ~prae@sherpadown.net 1110133658 M * rusty` no, i sure they won't do that... 1110133662 M * rusty` :) 1110133718 M * Bertl so what 'deficiencies' do the 'security' patches fix now? 1110133755 M * Bertl I mean out of the box, without special configuration 1110133906 M * rusty` but this patches is not bugfixes, i think... only they provide some automatic security restrictions.. not? 1110133964 Q * micah Quit: leaving 1110133969 J * micah micah@micha.hampshire.edu 1110133975 M * Bertl see, that's the point, you 'expect' it to increase security without you doing anything but patch it ;) 1110134020 M * Bertl if that would be the case (i.e. adding such a patch would instantly increase security, whatever that means) wouldn't then Linus or Andrew add them to mainline without a second thought? 1110134109 M * SiD3WiNDR not if it complicates or disables other things, perhaps 1110134120 M * SiD3WiNDR or maybe they're only wanted by 1% of the kernel users 1110134124 M * SiD3WiNDR just like vserver ;) 1110134183 M * Bertl good point, so let's find the places where such security patches add/improve security for linux-vserver and integrate them into the kernel patch ... 1110134272 M * Bertl don't get me wrong, I'm neither against improving security, nor am I against existing 'security' patches .. just I do not want folks to make the mistake to think hacking in such a patch makes it 'secure' (whatever that would mean) ... because this has two bad sideeffects 1110134304 M * Bertl a) other folks might think linux-vserver without that patch is not secure (which should not be the case, and if so, we have to fix something ;) 1110134345 M * Bertl b) the folks patching grsec/lids/whatever think that their system _is_ secure, and do not consider the maybe even lowered security they have now ... 1110134375 M * rusty` i don't believe that any patch can help to improve the security without the right knowledge to use it (fortunetly i'm not that lame) ... :) 1110134410 M * Bertl okay, so let's take the LIDS example you are looking at ... what security features are you going to use, and how? 1110134524 M * Bertl Doener: do you ahve a few minutes to spare for Q&D testing hack (userspace)? 1110134541 M * Doener q&d? 1110134548 M * Bertl Quick and Dirty ;) 1110134576 M * Doener ah ok, yep about 30 of them (minutes that is ;) 1110134596 M * Bertl excellent, I'd need a variation on cpuhog ... 1110134614 M * Bertl which does change in random intervals between three states 1110134634 M * Bertl a) cpu hogging, b) sleeping, c) I/O hogging ... 1110134687 M * Bertl I have code for all three states, so just the randomization needs to be done 1110134779 M * Doener how long should the intervals be? a few seconds? 1110134802 M * Bertl yeah, something in the range of 0.5 - 5 seconds should be sufficient 1110134817 M * Bertl could be even shorter, the idea is to test the hard scheduler= 1110134936 M * Bertl http://vserver.13thfloor.at/Experimental/TOOLS/vstress-0.03.tar.bz2 <-- should have the hogging code ... 1110135019 M * rusty` Bertl: don't get me wrong (my english is not the best, so maybe that's why you missunderstand me) ... i never said the linux vserver is not secure enough, becouse 1.: i don't have the right to say that (becouse i don't fully understand how it works), 2.: it is one of the coolest thing i know in the linux world, 3.: i'm only learning & experiencing security solutions, that's why i'm asking people like you about them... 1110135090 M * rusty` so what security features i'm going to use with LIDS? i'm interesting in the filesystem ACL solution... 1110135124 M * rusty` to set file permissions... 1110135214 M * Bertl on the host system or on the guests? and will you be the one administrating the guests? 1110135318 M * rusty` i'm implementing a firewall machine with services in vserver envirement, and with intrusion detection (Snort, maybe LIDS... :)) 1110135349 M * Bertl okay, so you will basically controll every part of the system, right? 1110135370 M * rusty` which part do you mean? 1110135383 M * rusty` i'm controlling only the firewall machine... 1110135391 M * Bertl every ;) I mean you'll controll host and vservers 1110135401 M * rusty` yes 1110135419 M * Doener Bertl: where's the iohog? syshog? 1110135430 M * Bertl yep 1110135432 M * Doener ok 1110135491 M * Bertl rusty`: so I would cherry-pick the features you want to add to your system (to improve security) and then look which patch does implement them the way you like best 1110135580 M * rusty` do you mean kernel patches? 1110135622 M * Bertl yep, precisely ... 1110135688 M * rusty` i see 1110135750 M * rusty` thanks for the converstation. it was very interesting... 1110135775 M * rusty` i own you another... :) 1110135782 M * Bertl you're welcome! 1110137094 Q * flock Read error: Operation timed out 1110137372 Q * rusty` Remote host closed the connection 1110138080 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il 1110138377 A * Doener .oO( hm, hm... why is that stupid signal handler not called... ) 1110138426 M * Bertl hmm, maybe we could just 'adjust' the loop values with the random=? 1110138451 M * Bertl (it's not that we need special precision there ;) 1110138771 M * Doener ah, dumb me... 1110138894 M * Doener ok, works now... 1110138919 M * Bertl excellent, url? 1110138924 M * Bertl and thanks a lot! 1110138931 M * Doener sec, gotta look up my ip address... 1110138948 M * Doener http://doener.homeip.net/doener/vserver/random_hog.c 1110138966 M * Doener the #define's at the top should make it configurable enough i guess 1110139015 M * Doener {MAX,MIN}_INTERVAL is in msec, so is SLEEP_TIME 1110139015 M * Bertl Connecting to doener.homeip.net[10.0.1.128]:80... 1110139025 M * Doener argh, damn firefox... 1110139051 M * Doener http://217.88.141.213/doener/vserver/random_hog.c 1110139124 M * Bertl yeah, looks good, thanks again! 1110139136 M * Doener np 1110139141 M * Doener off now, gf demands me ;) 1110139144 N * Doener Doener|gone 1110139149 M * Bertl send greetings! 1110141664 J * DaCa ~danny@mail.limehouse.org 1110141829 M * Bertl welcome DaCa! 1110141848 M * DaCa hi Bertl 1110142351 M * DaCa did anyone merge grsec 2.1.2 with vserver 1.2.10 for linux 2.4.29 yet? 1110142370 M * Bertl no idea, did you check the usual places? 1110142458 M * DaCa I checked the wiki yes :) 1110142462 M * Bertl http://www.sandino.net/parches/vserver/ 1110142468 M * Bertl (from the wiki ;) 1110142548 M * DaCa haha, great! 1110143506 J * Rusty ~root@rev.193.226.233.3.euroweb.hu 1110143508 N * Rusty rusty` 1110143511 M * rusty` hello folks 1110143519 M * rusty` Bertl: are u here? 1110143588 M * DaCa Bertl: any idea why he adds -KB-2 to it? 1110143710 M * rusty` testme.sh gives me error 011. anyone know what this error means? 1110143722 M * Bertl yep, try -v 1110143745 M * Bertl DaCa: no, maybe Kungfu Build .... 1110143810 M * Bertl rusty`: look for a /tmp/x file/node 1110143822 M * Bertl remove it if it is there and try again ... 1110143848 M * rusty` if i run the script again, it works fine :) 1110143852 M * Bertl (it basically means that --secure has too many capabilites) 1110143863 M * rusty` strange 1110143864 M * Bertl rusty`: yes, you ahve to remove the /tmp/x file 1110143885 M * Bertl feel free to improve the script ;) 1110143935 N * Doener|gone Doener 1110143940 M * Doener re 1110143947 M * Bertl hmm, wb Doener! 1110143996 M * Doener gf has an exam tomorrow so she has to get up early ;) 1110144015 Q * DaPhreak Quit: bed, night everyone 1110144477 M * Bertl okay, I'm off for now ... most likely back a little later ... 1110144482 M * Doener cya 1110144486 N * Bertl Bertl_oO 1110144744 Q * rusty` Quit: Leaving 1110150757 Q * prae Quit: Pwet 1110152383 Q * erwan_ho Quit: Leaving