1242087536 J * scientes ~scientes@97-113-122-26.tukw.qwest.net 1242091587 Q * imcsk8 Quit: This computer has gone to sleep 1242091998 Q * linux225 Quit: Leaving. 1242094011 J * hparker ~hparker@2001:470:1f0f:32c:290:96ff:fe50:40fa 1242094759 J * ousado__ ~johnny@frnk-5f7423de.pool.einsundeins.de 1242094775 J * sdfw ~ok@tor-irc.dnsbl.oftc.net 1242095176 Q * ousado_ Ping timeout: 480 seconds 1242099334 Q * hparker Quit: Read error: 104 (Peer reset by connection) 1242103200 Q * geb Quit: Quitte 1242108925 J * imcsk8 ~ichavero@189.155.75.144 1242110585 Q * imcsk8 Quit: This computer has gone to sleep 1242111207 J * BenG ~bengreen@94-169-110-10.cable.ubr22.aztw.blueyonder.co.uk 1242111372 J * davidkarban ~david@193.85.217.71 1242113001 J * balbir_ ~balbir@122.172.37.252 1242113120 P * tobbez 1242113288 J * cga ~weechat@194.244.1.35 1242113597 J * dna ~dna@186-204-103-86.dynamic.dsl.tng.de 1242113761 J * harobed ~harobed@pda57-1-82-231-115-1.fbx.proxad.net 1242113798 J * ktwilight_ ~ktwilight@238.248-64-87.adsl-dyn.isp.belgacom.be 1242114146 Q * ktwilight__ Ping timeout: 480 seconds 1242114886 Q * BenG Quit: I Leave 1242116190 J * Konsar qupsyti@ip-193-46-68-10.eltronik.net.pl 1242116203 M * Konsar hi 1242116294 M * Konsar i have problem on my vservers 1242116303 M * mrfrenzy noted 1242116428 M * Konsar my kernel sends messagess vxW: [-ls-,5554:#40001|40001|0] did lookup hidden md3:f1472850[#0,408] -/usr/share-. 1242116448 M * Konsar where is problem ? 1242116503 M * mrfrenzy I've actually never seen that, did you paste the exact message? 1242116529 M * Supaplex i've never seen anything close to that. how odd. 1242116537 M * Supaplex uname -a ? 1242116600 M * Konsar 2.6.29.2 + vs2.3.0.36.10(patch) 1242116691 M * Konsar distro : Debian lenny 1242116737 M * mrfrenzy what kernel package did you install? 1242116774 M * Konsar no, i have kernel from kernel.org 1242116800 M * mrfrenzy you probably made some strange settings when you configured your kernel 1242116809 M * mrfrenzy it's more reliable to just install the kernel with aptitude 1242116856 M * mrfrenzy aptitude search linux-image | grep vserver 1242116864 M * mrfrenzy then just install whichever you like of those 1242116991 M * Konsar this is not solution 1242117069 M * mrfrenzy why not? 1242117328 M * Konsar because is good kernel 1242117364 M * mrfrenzy what feature do you need that is not in the debian vserver-kernel? 1242117559 M * _Shiva_ mrfrenzy: maybe he just need a functioning kernel... Debian vserver Kernel are b0rked.. 1242117579 M * _Shiva_ . o 0 ( and so are util-vserver shipped by Debian .. ) 1242117605 M * Konsar because 2.6.29.2 is more security :) 1242117651 M * mrfrenzy _Shiva_: what is borked? I have been running debians vserver packages for over a year without problems 1242117679 M * mrfrenzy Konsar: debian backports all security patches to their kernels. just because it has a lower version number doesn't mean it's insecure 1242117706 M * _Shiva_ Konsar: have you updated util-vserver by hand? or is it still the Debian package 1242117711 M * mrfrenzy but if you want to build your kernel yourself you are ofcourse free to do so. You will just have to learn how to do it properly 1242117721 M * _Shiva_ mrfrenzy: Debian Lenny vserver ist broken - period 1242117734 M * mrfrenzy _Shiva_: what is the problem with it? 1242117746 M * Konsar my util is util-vserver_0.30.213-1_i386.deb 1242117769 M * _Shiva_ Konsar: so that's Etch richt? not Lenny 1242117778 M * _Shiva_ s/richt/right/ 1242117861 M * Konsar host Lenny, guest Etch 1242117876 M * _Shiva_ mrfrenzy: Bertl knows better ;-) but the Debian folks made a bad choice while picking this particular patch to backport it to their 2.6.26.. 1242117901 M * _Shiva_ Konsar: you don't need util-vserver in the guest.. 1242117916 M * mrfrenzy I'm looking forward to hearing it from him then 1242117927 M * Konsar i not using util-vserver in guest mode 1242117939 M * _Shiva_ Konsar: and util-vserver on Lenny should be (a broken) 0.30.216 something 1242117984 M * nox _Shiva_: not anymore -6 is fine 1242118012 M * nox 0.30.216~r2772-6 1242118063 M * nox which meanwhile came to lenny :) 1242118067 M * _Shiva_ nox: ok thanks :-) 1242118139 M * _Shiva_ Bertl_zZ: how about adding a big-red-and-yellow box to the linux-vserver.org frontpage about Debian and recommended package versions..? 1242118150 M * nox hehe 1242118188 M * mrfrenzy do you mean that there are broken versions availible in stable repositories at the moment? 1242118190 M * _Shiva_ nox: anything new about Kernel? or with "Lenny-and-a-half"? 1242118204 M * nox never used debian kernel 1242118218 M * nox just utils is pretty comfortable 1242118266 M * nox never used bloated, overpatched distriekernel at all 1242118275 M * nox not only debian 1242118285 M * nox <3 vanilla 1242118312 M * mrfrenzy yeah, I also used to build my own kernels, only compiling the needed stuff. That felt like well spent time when I had 16MB of ram ;) 1242118373 M * nox and waiting 5h+ 1242118436 M * mrfrenzy I would like to see you have a noticeable performance gain from using the vanilla kernel vs just installing the standard debian kernel 1242118529 M * nox neither performance nor memusuage is an issue anymore 1242118534 J * pmenier ~pme@LNeuilly-152-22-8-5.w193-251.abo.wanadoo.fr 1242118566 J * gnuk ~F404ror@217.19.56.132 1242118589 M * nox but patches better work against vanilla and it is nice to decide what you want 1242118817 M * nox and slightly more back to topic: you are able to use the newest, shiniest (devel) version of linux-vserver, what in general is a good choice :) 1242118942 M * _Shiva_ nox: devel? you mean: experimental ;-) 1242119001 M * nox ack 1242119718 J * cluk ~cluk@p5B17F8A4.dip.t-dialin.net 1242119944 M * Konsar ok i find problem :) 1242119987 M * Konsar my LANG value is not support in guest mode 1242123057 N * Bertl_zZ Bertl 1242123061 M * Bertl morning folks! 1242123182 M * Bertl _Shiva_: I think, it wouldn't be nice to make a big warning that currently all debian versions are broken or incomplete ... I was actually hoping that this would be fixed sooner or later ... but it seems that not enough users complain to the debian folks (maybe they prefer a broken version fro whatever reason? maybe they just don't care) 1242124138 Q * Konsar 1242124599 M * _Shiva_ Bertl: maybe their thinking is full-disclosure... not.. ;-) 1242124661 M * _Shiva_ Bertl: but nox stated, that util-vserver-0.30.216~r2772-6 has entered the stable tree which ought to be correct 1242124687 M * _Shiva_ Bertl: now the only thing missing is the Kernel... 1242124740 M * Bertl well, with a recent kernel, the 0.30.216~r2772-6 tools won't work either ... so be prepared :) 1242124769 M * Bertl funny thing is, the older tools will work (like 0.30.213 or so) 1242125208 M * ex Bertl, i've just installed lenny (0.30.216~r2772-6 tools) with custom kernel 2.6.29.2-vs2.3.0.36.12, and it's working fine 1242125222 M * ex should be there any problems? 1242125261 M * Bertl did you run the testme.sh script on the host? 1242125337 M * ex nope, sec 1242125361 M * ex all succeeded 1242125395 M * Bertl okay, what does "hostname' show now? 1242125486 M * ex http://pastebin.com/m6bd7f576 1242125529 M * Bertl okay, looks indeed good .. thanks 1242125976 M * nox same here (same kernel and utils) 1242125994 M * nox and result :) 1242126034 M * mrfrenzy Bertl: If I noticed that it was broken, I would ofcourse complain. Could you tell me *what* is the problem? 1242126089 M * mrfrenzy currently using util-vserver 0.30.216~r2772-6 and linux-image-2.6-vserver-amd64 2.6.26+17+lenny1 without any problems 1242126114 M * Bertl I thought I remembered that it didn't unshare namespaces properly, but it seems it does, nevertheless, daniel_hozac has all the details what those utils are missing 1242126139 M * Bertl mrfrenzy: note that if you switch to any other kernel, you need to fix your xattrs for barrier and unification 1242126277 M * mrfrenzy I'm assuming if util-vserver 0.30.216~r2772-6 only works with this kernel, the dependencies would prevent me from installing another without upgrading util-vserver to one with "fixed xattrs" 1242126325 M * Bertl nah, the problem is the kernel, is has a wrong/broken conception of those attributes 1242126356 M * Bertl every time you switch to/from that kernel (2.6.26.x) you need to fix up the xattrs of your entire guest filesystem 1242126370 M * Bertl (regardless of the tools) 1242126417 M * fb Bertl: it includes some patches (thus -6 added) 1242126430 M * _Shiva_ Bertl: see? that's why I've proposed to add this FAQ to the Wiki :-) so you don't have to repeat yourself :-) 1242126443 M * mrfrenzy I'm reading a few bugreports about it from 2005, but I'm not quite getting a grip on it 1242126509 M * _Shiva_ mrfrenzy: actually choosing 2.6.*26* had been wrong in the first place... <=2.6.25 is working and >=2.6.27 is 1242126577 M * mrfrenzy If I understand correctly, there is a problem with guests being able to access files they should not while switching from or to that kernel? 1242126593 M * Bertl or simply escaping the guest confinement 1242126593 J * BenG ~bengreen@94-169-110-10.cable.ubr22.aztw.blueyonder.co.uk 1242126633 M * mrfrenzy well that's obviously bad. The util-vserver should check this upon booting a guest 1242126633 M * Bertl unless you are using very recent util-vserver (i.e. a lot newer than what's in debian) 1242126687 M * Bertl mrfrenzy: tell that to the debian folks, even if we added such a check (which would simply tell you not to use a 2.6.26 kernel :) it wouldn't help the debian users, would it? 1242126734 M * mrfrenzy well the test could just fix the xattrs if it determined they were incompatible with the running kernel`? 1242126763 M * Bertl that requires to run a script on the 'other' kernel first 1242126793 M * Bertl besides, that doesn't change my point, that no debian person would benefit from, it 1242126799 M * Bertl *from it* 1242126813 M * Bertl and nobody except a debian person uses a 2.6.26 kernel :) 1242126840 M * mrfrenzy well if you did make a fix to something which is a serious security flaw, I'm sure the debian security team would push it out 1242126884 A * SpComb is a debian person and uses 2.6.26! 1242126889 M * BenG mrfrenzy, have you report the flaw to Debian? 1242126901 M * _Shiva_ Bertl: but actually, that _is_ a security problem that users are not aware of.. so (even!) Debian has to fix that.. even if that means to backport half a 2.6.27 kernel to their shiny-do-not-touch-the-version-number-in-stable-2.6.26 1242126905 M * Bertl mrfrenzy: the fix is to upgrade the kernel and avoid 2.6.26.x 1242126909 M * mrfrenzy BenG: no, I didn't even know about it, and I still don't understand when it applies 1242126944 M * mrfrenzy so you are saying it's impossible to make vserver work properly with 2.6.26? 1242126944 M * Bertl mrfrenzy: let me explain it in a quite understandable way, but promise to add it to the wiki and report it (once again) to debian, yes? 1242126972 M * mrfrenzy Bertl: why don't you just write it to the wiki? otherwise it will just be second hand information 1242126986 M * mrfrenzy and I really don't have time for anything like this this week :( 1242127005 M * BenG Bertl, I'll write it on the wiki, give us the explanation 1242127038 A * BenG has the wiki open in a browser... 1242127098 M * BenG I would add it to the following page: http://linux-vserver.org/Installation_on_Debian 1242127102 M * Bertl okay, just give me a minute to get the facts straight 1242127111 M * BenG no probs, cheers 1242127288 M * Bertl all the supported filesystems (ext2/3, xfs, jfs, reiser, ..) support xattrs (not to be confused with Extended Attributes), which allow for example to make a file immutable 1242127300 M * BenG mrfrenzy, are you also aware of the SQLite regressions in 2.6.26? Fairly nasty. 1242127353 M * Bertl now, we utilize the same mechanism for creating the barrier (on directories) and adding the immutable-unlink flag to unified files 1242127372 M * Bertl looking at the barrier, we have the following flag definition: 1242127378 M * Bertl +#define FS_BARRIER_FL 0x04000000 /* Barrier for chroot() */ 1242127417 M * Bertl (in 2.6.22.19-vs2.3.x as well as in 2.6.27.21-vs2.3.x) 1242127430 M * Bertl but in the 2.6.26 kernel in question, we have: 1242127440 M * Bertl +#define FS_BARRIER_FL0x10000000 /* Barrier for chroot() */ 1242127481 M * Bertl now, those xattrs are stored in a flag field on the filesystem, i.e. each file has such a set of xattr flags stored on the disk 1242127527 M * Bertl if you create the barrier with 2.6.22, and then switch to 2.6.27, everything is fine (as expected), but if you switch to the 2.6.26 one, the flag is gone 1242127541 M * BenG yoiks 1242127544 M * Bertl (same happens when you switch back, after 'repairing' the flags) 1242127577 M * Bertl if you create all your guests with 2.6.26 and stick to it forever ... it's fine, no problem there 1242127664 M * Bertl note that the 'other' kernel will not even see (and thus, will not be able to report) those 'wrong' flags 1242127757 M * BenG so this problem will affect anyone using vhashify, or any method of unifying files between guests? 1242127783 M * Bertl and all others, as the barrier is crucial for security for the tools supplied by debian 1242127817 M * Bertl it could be easily fixed by just changing the flags in the kernel they use, btw 1242127856 M * BenG using 0x04000000 presumably, so that flags match between kernel versions 1242127925 M * Bertl yes, and the other flag not mentioned above (for iunlink) 1242128120 M * BenG could you tell me the lines for that flag? 1242128135 M * BenG I'm downloading the Debian source now 1242128411 M * Bertl just grep for FS_BARRIER and FS_IXUNLINK 1242128466 M * BenG Bertl, is this in the vserver patched code only? 1242128540 M * Bertl yes, mainline does neither have a barrier nor an immutable link inversion 1242128693 M * BenG you've basically given me the fix for Debian kernel there 1242128717 M * BenG except there's a problem for users who've created guests with 2.6.26 1242128758 M * Bertl or unified them, or 'repaired' the xattrs :) 1242128775 M * BenG yuck 1242128792 M * BenG is the process of repairing xattrs simple? 1242128825 M * Bertl for the barrier, yes, you simply remove all barrier flags on the filesystem, then set the barrier anew on /path/to/guest/.. 1242128859 M * Bertl for the unification, I suggest to break all links and re-unify them (basically make a copy and remove the original) 1242128876 M * Bertl all that needs to be done with the guests stopped, of course 1242128928 M * BenG for the barrier issue, what commands would actually set that, I've no experience of messing with these flags at all 1242128955 A * BenG has a lot of wiki write up to do 1242128977 M * Bertl http://linux-vserver.org/Secure_chroot_Barrier 1242128996 M * Bertl (see the 'Solution' part) 1242129090 M * BenG a very tidy solution indeed! 1242129166 M * BenG the unusual flag value is definitely in the Debian patch 1242129240 J * starcode ~starcode@62.245.254.80 1242129250 M * BenG is this IRC weblogged anywere, so I can point to this conversation from the wiki page? 1242129287 M * Bertl http://irc.13thfloor.at/LOG/2009-05/LOG_2009-05-12.txt 1242129314 M * BenG cheers 1242131320 M * BenG http://linux-vserver.org/Installation_on_Debian#Issues_with_the_current_2.6.26_Kernel 1242131365 M * BenG if anyone would like to give that a look over for correctness/validity please go ahead 1242131504 M * Bertl "and/or immutable links will not function correctly" actually means that they will become immutable and will not break when somebody tries to write to them 1242131549 M * BenG i had guessed that was what would happen, should I be more specific then 1242131555 M * Bertl another issue (if you list issues) is that the TB Extension is not present in that kernel, i.e. do not expect hard cpu limits to work on debian 1242131571 M * BenG good point 1242131584 M * BenG it's make a fair mess trying IIRC 1242131591 J * kir ~kir@swsoft-msk-nat.sw.ru 1242131721 M * BenG I have in the Debian patch FS_IXUNLINK_FL 0x01000000 /* Immutable invert on unlink */ 1242131729 M * Bertl there are probably some other issues too, I remember we fixed mutexes and xfs after that as well as the uptime issue (which might not have been in 2.6.26) 1242131745 M * BenG :) 1242131761 M * BenG okay, so there's been a lot of fixes! 1242131781 J * thierryp ~thierry@zanzibar.inria.fr 1242131789 M * Bertl but I'm sure, if you spend some time on reading the irc logs, and grepping for 'debian' you'll find them 1242131903 M * BenG the flags issue is a serious security one though, so I think I'll start by chasing that one 1242131955 M * BenG i think rather than chasing all these issues though actually getting together a repository of packaged newer vserver kernels for Debian would be a time better spent 1242131971 M * Bertl sure, if you need me to check a patch/fix for the issues, just let me know 1242131993 M * BenG great cheers 1242134171 Q * scientes Ping timeout: 480 seconds 1242136157 N * Bertl Bertl_oO 1242136162 M * Bertl_oO off for now ... bbl 1242138161 Q * Kamping_Kaiser Ping timeout: 480 seconds 1242138323 J * geb ~geb@AOrleans-253-1-24-227.w92-140.abo.wanadoo.fr 1242138641 Q * davidkarban Quit: Ex-Chat 1242138797 Q * BenG Quit: I Leave 1242138829 J * Kamping_Kaiser ~kgoetz@ppp121-45-195-23.lns10.adl2.internode.on.net 1242139371 J * dowdle ~dowdle@scott.coe.montana.edu 1242142243 P * kir Leaving. 1242143149 Q * cga Quit: got a DELL??? update you BIOS with http://github.com/cga/dellbiosupdate.sh/tree/master ;) 1242144195 M * harry waaaaaaaaah... 1242144203 M * harry i had no time to fix the patch!!! 1242144210 M * harry my deepest appologies! 1242145288 Q * ktwilight_ Remote host closed the connection 1242145482 Q * Piet Remote host closed the connection 1242145571 J * Piet ~piet@tor-irc.dnsbl.oftc.net 1242145707 Q * harobed Ping timeout: 480 seconds 1242145862 J * ktwilight ~ktwilight@238.248-64-87.adsl-dyn.isp.belgacom.be 1242145911 Q * ktwilight Remote host closed the connection 1242145921 Q * _gh_ Ping timeout: 480 seconds 1242146669 Q * ousado__ Remote host closed the connection 1242147535 J * Floops[w]2 ~baihu@205.214.201.176 1242147588 N * pmenier pmenier_off 1242147931 Q * Floops[w]1 Ping timeout: 480 seconds 1242149227 Q * thierryp Ping timeout: 480 seconds 1242149647 Q * cluk Quit: Ex-Chat 1242150057 Q * gnuk Quit: NoFeature 1242150577 J * Sebboh ~hobbes@ip68-13-125-163.om.om.cox.net 1242150836 M * Sebboh Hi. I built a debian etch vserver on my ubuntu Jaunty host. When I start it up (vserver php4 start) the command returns silently, but then vserver php4 status returns "Vserver 'php4' is stopped"... Where do I find logs? 1242150889 J * doener ~doener@i59F5B560.versanet.de 1242150992 Q * doener_ Ping timeout: 480 seconds 1242150992 J * imcsk8 ~ichavero@148.229.1.11 1242151345 M * fb Sebboh: you have any service running inside guest? 1242151567 M * Sebboh Uh, probably not. It's a fresh install, I've never started it. 1242151667 M * Sebboh vserver php4 enter ..returns "'vserver ... suexec' is supported for running vservers only; aborting...". 1242151698 N * Bertl_oO Bertl 1242151720 M * Sebboh It's possible that I don't understand how these things work... What am I supposed to do directly after using the vserver script to build a vserver via the debootstrap method? 1242151736 M * Bertl Sebboh: that is kind-of expected for non persistent guests ... the thing is, your guest doesn't leave a single process running when you 'started' it, so the context is auto disposed 1242151764 M * Bertl Sebboh: grab recent util-vserver, or enable at least one service inside the guest (like e.g. syslog or sshd) 1242151787 M * Bertl (recent util-vserver will activate the syslog inside a newly installed guest) 1242151787 M * Sebboh how about logind? 1242151800 M * Sebboh and I'm using the latest util-vserver. 1242151801 M * Bertl whatever you like, as long as it keeps running :) 1242151857 M * Bertl so, you have 0.30.216-pre2833 installed? 1242151871 M * Sebboh 0.30.216~r2772-6 on ubuntu jaunty. I got the package from linux-vserver.org 1242151882 M * Sebboh Ah, nope, I'm a few revisions behind. 1242151936 M * Bertl but as I said, enabling any service which keeps running will suffice 1242151946 M * Bertl (alternatively you can make the context persistent) 1242151992 M * Sebboh where are logs? I found the /var/log inside the vserver itself, and there are only some zero byte files.. as if it had never started. ? 1242152110 M * Bertl all guest related logs are inside the guest, all output of the startup is given on the shell you execute it from ... you can add --debug to the command to get more information 1242152302 M * Sebboh ah, --debug, I'll try that. ..Cause, I just did echo ^38 >> /etc/vservers/php4/ncapabilities ..and tried to start it again, still nothing. :) 1242152333 M * Bertl hmm, what did you expect from that? 1242152398 M * Bertl you need at least to add the same for the process context 1242152405 M * Sebboh .. I did it wrong, that's a flag, not a capability .. Or something. I'd never heard of this five minutes ago. 1242152411 M * Bertl (and it would be preferable to use the name instead) 1242152430 M * Bertl cflags/nflags is the correct place 1242152461 M * Sebboh Ok. You said.. process context. What is that? 1242152461 M * Bertl http://www.nongnu.org/util-vserver/doc/conf/configuration.html 1242152522 M * Bertl a task belongs to several namespaces (to group them into guests), one is the process context, the other one the network context (there are several more but they are not relevant here) 1242152616 M * Sebboh Maybe I should take a moment to ask a different question :) 1242152690 M * Bertl go ahead :) 1242152745 M * Sebboh My goal is to keep a spare PHP4 lamp server around. I could easily do this with spare hardware, or machine-level virtualization, but I don't have spare hardware or ram. ..So, I thought, well, I'll just build a little debian etch (old-stable version) machine inside this vserver thing. ..And I imagine logging into it via ssh, starting and stopping apache, etc. 1242152796 M * Sebboh I don't need (or want) PHP4 every day.. but every once in a while a client has some old code that will only run there, and my job would likely be to upgrade it. :) 1242152809 M * Sebboh So is vserver for me? 1242152814 M * Bertl sounds like a perfect match 1242152824 M * Sebboh excellent. 1242152846 M * Bertl once you get the grip of it, you might keep several versions around (maybe even unified) to test with them when required 1242152977 M * Bertl just forget (almost) everything you learned about virtual machines and such, you are using an isolation technique, something like a chroot on steroids 1242153001 M * Sebboh I had exactly that idea. :) And yeah, --debug shows that the .. the thing is starting, doing some stuff, and going into cleanup. So I'll just jump into the /etc/ directory of the guest.. er, the context? and manually add some service in there, eh? 1242153015 M * Sebboh What runlevel is this thing being given? 1242153051 M * Bertl 'guest filesystem' is the correct term, the runlevel can be adjusted via the config, default is 3 1242153122 M * Sebboh Right, I grok chroot. I picture vserver as .. running multiple copies of init. *shrug* Is that about right? 1242153151 M * Bertl at your current config (which is by default sysv init style) you do not even run an init in the guest 1242153178 M * Bertl i.e. just the services, the host init is 'shown' in a blend-through way to make some tools happy 1242153196 M * Bertl you could switch to 'plain' init style, which would start an init inside the guest 1242153288 M * fb Sebboh: you probably want to chroot into your guest and install / configure apache so it runs persistent, then vserver start this instance 1242153356 M * fb Sebboh: just installing apache inside the guest is probably sufficient, it has some sane defaults afair 1242153534 M * Sebboh Hm. chrooting into my guest would be OK? My host is bleeding edge Ubuntu, and my guest is 5+ year old Debian. 1242153649 M * Bertl that's fine, just be careful not to start stuff 1242153673 M * Bertl processes will run without confinement 1242153798 M * Sebboh The implication is that it's OK to chroot into this guest filesystem and run apt-get install? ..And that's not 'starting stuff'? .. heh.. really? 1242153833 M * Bertl well, I'd use vapt-get (which does the proper stuff for you) 1242153895 M * Sebboh ! never heard of it, but I have it installed on guest. Thanks, looking into it. 1242153902 M * Sebboh I mean on host 1242153912 M * Bertl yep, it is part of util-vserver 1242154351 M * Sebboh- vapt-get also wants a running vserver. Well I'll dig into the startup scripts. Thank you, Bertl and fb. 1242154356 J * cga ~weechat@82.84.191.5 1242154470 J * ktwilight ~ktwilight@238.248-64-87.adsl-dyn.isp.belgacom.be 1242154547 M * fb Sebboh: you can just chroot into, just don't start any service when chrooted :) 1242154581 M * fb Sebboh: and if postinst script does this for you, just stop it with /etc/init.d/service_name stop 1242154761 M * Sebboh- apt isn't installed in guest. dpkg is... dpkg -l apt* in guest shows un apt .. uh..any chance that my debootstrap didn't work properly? 1242154822 M * Bertl yes, that's why I suggested to get a new util-vserver 1242154845 M * Bertl but it is partially correct, as the database is externalized 1242154860 M * Bertl you could internalize it, but that requires a running guest too 1242155180 M * Sebboh uh, sorry, you suggested 0.30.216-pre2833 and I have 0.30.216~r2772-6. So the features you recommend were added very recently? I should upgrade? 1242155227 M * Bertl it's more that debian/ubuntu changed and the 'old' version doesn't have the updated information 1242155251 M * Bertl don't ask me why they didn't update util-vserver too :) 1242155323 Q * MooingLemur Quit: leaving 1242155331 J * MooingLemur ~troy@shells195.pinchaser.com 1242155345 M * fb Bertl: btw, any progress with ipv6? 1242155362 M * Bertl nope, no real time yet .. unfortunately 1242155378 M * fb Bertl: because there's some sudden interest in anything running ipv6 lately ;) 1242155394 M * Bertl yeah, well, it is supposed to work fine :) 1242155418 M * fb and they keep me bogging, hey, you took another class, get it running! ;-) 1242155469 Q * sdfw Ping timeout: 480 seconds 1242155537 M * Sebboh I got my vserver kernel and my util-vserver from here: http://linux-vserver.org/Installation_on_Ubuntu .. these packages were built 1.5 months ago. .. Just want to confirm that these are too old, before I go building my own util-vserver, 'cause I'm rapidly getting into this situation: http://xkcd.com/349/ 1242155640 M * Bertl hehe, well, just link the syslog runlevel script into runlevel 3 (or adjust the runlevel) and be done 1242155643 M * fb Sebboh: maybe just download aptitude into host, copy it into /var/lib/vserver/vserver_name/root 1242155681 M * Bertl Sebboh: but when you get around it, update util-vserver so that new guests are created properly 1242155694 M * fb or, if you have sysklogd already installed, just run update-rc.d when chrooted 1242155728 M * Sebboh fb, guest and host aren't the same distro, not even close. I'm afraid I can't bring myself to try that. :) 1242155747 M * Sebboh the aptitude thing I mean 1242155769 M * fb Sebboh: download .deb package, not install it 1242155784 M * fb then chroot and dpkg -i it 1242155802 M * Sebboh fb, oh, yeah. Sure. That's no problem. 1242155815 M * fb but if you have sysklogd installed, you can just chroot into the future guest 1242155844 M * fb and then do update-rc.d sysklogd start 10 3 1242155887 M * fb then exit, and vserver guestname start should work as expected 1242157807 M * Sebboh Success! installing sysklogd (and klogd) resulted in the update-rc.d thing being done automagically. P.S. the update-rc.d command requires a . at the end. 1242157815 M * Sebboh Thanks again fb and Bertl. 1242158017 M * Sebboh Hah, there are exactly 7 packages installed on this guest, not counting the two I just added. ..Thank goodness dpkg is one of them. :) 1242158193 M * Bertl you're welcome! have fun! 1242158246 M * fb Sebboh: btw, vserver project has great support here, mainly provided by Bertl 1242158274 M * Sebboh hehe, yes, I've had a good support experience thus far. :) 1242158277 M * fb Sebboh: and he's main developer of the kernel part of the vserver 1242159620 Q * doener Ping timeout: 480 seconds 1242163554 M * geb hi 1242163560 M * geb i have something strange 1242163562 M * geb http://paste.linux-vserver.org/12920 1242163643 M * geb kernel: debian 2.6.26-2-vserver-amd64 (yes i know ! will build a kernel soon) and util-vserver: 0.30.216~r2772-6 1242163674 M * Bertl what do you expect, the debian kernel/utils are broken 1242163769 M * geb :) 1242163878 M * geb i did have the same problem with 2.6.28.7-grsec2.1.13-vs2.3.0.36.7 (see http://paste.linux-vserver.org/12793) but i was thinking the problem was from grsecurity 1242163891 M * geb do you think the problem may be from the utils ? 1242163910 M * Bertl very likely, get recent ones and check again 1242164100 M * geb ok thanks :) 1242164117 M * geb i just don't understand why i have the problem with only one vserver 1242164141 M * Bertl different config, most likely 1242164222 M * geb they are exactly the same as others vservers 1242164250 M * Bertl I doubt that .. but if you upload the entire config dir, I'll have a look 1242164594 M * geb https://admin.gebura.eu.org/vservers-cfg.tar.gz 1242164597 M * geb :) 1242164714 M * geb maybe i am just wrong but i don't see any difference 1242164725 J * MooingLe1ur ~troy@shells195.pinchaser.com 1242164727 Q * MooingLemur Read error: Connection reset by peer 1242164737 M * Bertl certificate common name `gebura.eu.org' doesn't match requested host name `admin.gebura.eu.org' :) 1242164845 M * geb added one another line to the TODO, thanks :) 1242164908 Q * cga Quit: got a DELL??? update you BIOS with http://github.com/cga/dellbiosupdate.sh/tree/master ;) 1242165132 M * geb wildcard sll certs are difficult to handle, i don't have any problem with firefox but wget don't like them... 1242165633 Q * dna Quit: Verlassend 1242165927 J * thierryp ~thierry@home.parmentelat.net 1242167311 Q * ard Ping timeout: 480 seconds 1242167349 J * scientes ~scientes@97-113-122-26.tukw.qwest.net 1242167361 Q * FireEgl Quit: Leaving... 1242168331 M * Marillion i have a Kernel basic .config for "Linux 2.6.27.15-grsec-2.1.12-vs2.3.0.36.4" and can i upload to vserver project for contribution them? 1242168437 M * Bertl well, that's nice, but I doubt not many will have the same hardware as you have .. so the config will differe for somebody else 1242168451 M * Bertl s/not many/that many/ 1242168565 M * Marillion ok, this is a good point :/ 1242169061 A * Marillion it was a bit too hasty 1242169141 M * Sebboh I don't suppose that the vserver kernel modifications are available as a module? :P 1242169151 M * Bertl Marillion: np, maybe provide the .config somewhere if somebody wants to look at it 1242169161 M * Bertl Sebboh: not really, they are core modifications 1242169180 M * Marillion Bertl: :) 1242169233 Q * dowdle Remote host closed the connection 1242169521 M * Sebboh Question about the kernel images here: http://ppa.launchpad.net/christoph-lukas/ppa/ubuntu/pool/main/l/linux/ (via here: http://linux-vserver.org/Installation_on_Ubuntu ) ... Are these ubuntu sources + vserver patches, or stock sources + vserver patches? 1242169671 A * Marillion provide vanilla + main patches from the vserver project 1242169970 M * Marillion bedtime, gn8 all together 1242169990 M * Sebboh rest well, Marillion. 1242170610 Q * SauLus Ping timeout: 480 seconds 1242170646 Q * imcsk8 Quit: This computer has gone to sleep 1242170812 J * saulus ~saulus@c207206.adsl.hansenet.de 1242171460 J * glen ~glen@elves.delfi.ee 1242171475 M * glen can i do pkgmgmnt internalize on running vserver, i mean manually? 1242171505 M * Bertl what do you mean by 'manually'? 1242171515 M * glen like mv /etc/vservers/NAME/apps/pkgmgmt/base/rpm/state/* /vservers/NAME/var/lib/rpm; touch /etc/vservers/NAME/apps/pkgmgmt/internal 1242171535 M * Bertl why would you want to do that? 1242171537 M * glen manually by not using vserver NAME pkgmgmt internalize, which requires vserver restart 1242171545 M * Bertl does it? 1242171551 M * glen i don't want to restart vserver 1242171575 M * glen it says: Can not operate on running vservers; please stop 'NAME' and retry again... 1242171575 M * Bertl I don't think it requires a restart 1242171606 M * Bertl okay, well, yes, basically you can do the steps manually at runtime 1242171629 M * glen but it seems to have some weird bind mounts 1242171666 M * glen as i did those step, and inside vserver /var/lib/rpm was different than seen outside vserver 1242171706 M * glen ahm, i should also kill /var/lib/rpm symlink? (it points to /.rpmdb) 1242171803 M * glen yep. that was the case, which i didn't realize 1242171871 M * glen why the internalize command requires vserver stop? 1242171933 M * Bertl you have to ask daniel_hozac for the details there ... 1242171959 M * glen altho rpm behaves weird inside vserver, like it can't see /bin/sh deps 1242171996 M * glen rpm --rebuilddb altho fixed that shortcoming