1222301240 Q * dowdle Remote host closed the connection 1222302200 Q * almak Remote host closed the connection 1222302210 J * almak ~almak@proxy-sjc-2.cisco.com 1222302309 Q * almak 1222302584 J * trippeh atomt@uff.ugh.no 1222302678 M * trippeh daniel_hozac: Btw, the script fails on files with '(' and ')' in their names 1222302698 M * trippeh I fixed those by hand 1222302931 M * trippeh Other than that it seems to have worked ;) 1222303351 Q * esa Ping timeout: 480 seconds 1222303412 Q * trippeh Remote host closed the connection 1222303444 J * trippeh atomt@uff.ugh.no 1222303948 Q * balbir_ Ping timeout: 480 seconds 1222304614 J * balbir_ ~balbir@122.167.79.50 1222305085 J * cryptronic1 ~oli@p4FD2C25E.dip.t-dialin.net 1222305451 Q * cryptronic Ping timeout: 480 seconds 1222306843 J * derjohn ~derjohn@80.69.41.3 1222309637 J * ntrs_ ~ntrs@77.29.71.0 1222309826 Q * derjohn Ping timeout: 480 seconds 1222309905 Q * quinq Remote host closed the connection 1222310123 Q * ntrs_ Ping timeout: 480 seconds 1222310444 J * derjohn_foo ~aj@p5B23D95A.dip.t-dialin.net 1222310875 Q * derjohn_mob Ping timeout: 480 seconds 1222312232 J * esa bip@62.123.8.12 1222312254 M * Bertl okay, off to bed now .. have a good one everyone! 1222312259 N * Bertl Bertl_zZ 1222312291 J * derjohn ~derjohn@80.69.41.3 1222313406 Q * shuri Quit: Leaving 1222318041 Q * hparker Quit: Read error: 104 (Peer reset by connection) 1222321406 Q * balbir_ Ping timeout: 480 seconds 1222322796 M * hijacker_ night Bertl_zZ 1222323403 Q * larsivi Remote host closed the connection 1222323833 J * ntrs_ ~ntrs@77.29.71.0 1222324161 J * balbir_ ~balbir@59.145.136.1 1222326073 J * ktwilight ~ktwilight@87.66.202.61 1222326226 Q * ktwilight__ Ping timeout: 480 seconds 1222327214 Q * ag- Ping timeout: 480 seconds 1222327287 J * ag- ~ag@fedaykin.roxor.cx 1222328507 J * ntrs__ ~ntrs@77.29.79.86 1222328670 J * Bruno ~Bruno@dsl-10-148-187.b2b2c.ca 1222328918 Q * ntrs_ Read error: Operation timed out 1222328940 Q * BrunoXLambert Ping timeout: 480 seconds 1222329127 Q * trippeh Quit: hehe! 1222329437 J * trippeh atomt@uff.ugh.no 1222329489 Q * derjohn_foo Ping timeout: 480 seconds 1222330605 J * tramjoe_merin ~tramjoe@193.41.238.151 1222334055 Q * tramjoe_merin Remote host closed the connection 1222334825 N * pmenier_off pmenier 1222334932 J * tramjoe_merin ~tramjoe@193.41.238.151 1222335532 J * dna ~dna@128-216-dsl.kielnet.net 1222336559 J * friendly ~friendly@ppp118-208-155-154.lns10.mel4.internode.on.net 1222338527 Q * Aiken Quit: Leaving 1222338562 J * Aiken ~Aiken@ppp118-208-28-181.lns2.bne1.internode.on.net 1222338947 J * quinq ~quinq@quinq.eu.org 1222341325 J * BenG ~bengreen@92-238-216-179.cable.ubr20.aztw.blueyonder.co.uk 1222341367 M * BenG herbert 1222341482 Q * Bruno Quit: Leaving 1222342958 M * BenG hi all 1222343257 N * Bertl_zZ Bertl 1222343261 M * Bertl morning folks! 1222343541 Q * ntrs__ Ping timeout: 480 seconds 1222343935 M * fb hello Bertl :) 1222344309 J * BrunoXLambert ~Bruno@modemcable188.10-70-69.static.videotron.ca 1222344473 J * derjohn_foo ~aj@51.42.69.80.in-addr.net-lab.net 1222344546 Q * Aiken Quit: Leaving 1222344671 Q * friendly Quit: Leaving. 1222345384 J * ^jan ~jan@138.Red-83-36-112.dynamicIP.rima-tde.net 1222345387 M * ^jan hi all 1222345460 M * Bertl hi 1222345487 M * ^jan is there any web application that manages multiple vservers available anywhere? 1222345567 M * Bertl IIRC, OpenVCP does that 1222345580 M * ^jan well, we are doing one of this for our hosting company... still under development... just wondering if it already exist something similar 1222345616 M * ^jan but now we have a problem, so I come here to ask you something else... 1222345635 M * ^jan I have a very strange situation in my virtual servers (even with different host servers), when no outbound open connections from the vserver in ESTABLISHED status exists, netstats inside the vserver, doesn't show any information, it shows everything empty, even hidding the connections in LISTEN state 1222345671 M * Bertl sounds strange, what kernel version? 1222345691 J * ntrs ~ntrs@77.29.79.86 1222345725 M * ^jan 2.6.22.16-vs2.2.0.6 #6 SMP Thu Sep 11 13:12:10 CEST 2008 i686 GNU/Linux 1222345753 M * Bertl update to the latest stable then 1222345761 M * Bertl any additional patches? 1222345776 M * ^jan but it also happens in 2.6.22.19-vs2.2.0.7 #1 SMP Sat Aug 9 17:07:28 CEST 2008 i686 GNU/Linux 1222345778 J * kwowt ~quote@pomoc.ircnet.com 1222345778 M * kwowt hi 1222345779 M * kwowt =) 1222345792 M * Bertl ^jan: really, very interesting ... 1222345809 M * ^jan no, any additional patches 1222345813 M * kwowt Where do i set which is the primary IP address and which is the secondary? 1222345825 M * Bertl kwowt: the first one is the primary 1222345834 M * kwowt like, 0 in interfaceS? 1222345861 M * Bertl kwowt: with 'promote secondaries' enabled, the first secondary will become the new primary when the primary is removed 1222345888 M * Bertl kwowt: whatever ip is first added (might be the one in '0' :) 1222345910 M * kwowt i've got 3 added right now, but its using the wrong one as primary 1222345911 M * kwowt :/ 1222345945 M * kwowt so i remove the one i dont want primary, and then add it again 1222345948 M * kwowt ? 1222346010 M * Bertl given that you have 'promote secondaries' enabled, that should work 1222346022 M * Bertl if not, you'll have to add back all of them 1222346214 M * kwowt i thought vserver uses the one in 0 as primary 1222346220 M * kwowt i add and remove with ip addr right? 1222346368 M * Bertl Linux-VServer uses whatever the mainline kernel provides (for networking) 1222346393 M * kwowt i removed both ip's i dont want from interfaces 1222346396 M * kwowt and kept only the one i want 1222346400 M * kwowt deleted both with ip addr 1222346411 M * kwowt but when i restart the server, it starts using the one i dont want again 1222346430 M * kwowt eh 1222346432 M * kwowt nvermind:p 1222346543 M * ^jan we just detect that /proc/net/tcp shows no results when enterying a vserver via vserver [name] enter 1222346563 M * ^jan but if we enter using SSH it shows the info 1222346628 M * Bertl what util-vserver version? 1222346659 M * ^jan is relevant to get results from /proc/net/tcp file, to have attached to the process a /dev/ptsX device? 1222346677 M * ^jan because another monitorizing daemon that runs in daemon mode, cannot also get results from that file 1222346727 M * ^jan util-vserver-0.30.214 1222346737 M * Bertl try with 0.30.215 1222346757 M * ^jan ok 1222346778 M * Bertl I do not remember similar issues, but I do not see them here on any guest 1222347266 J * yarihm ~yarihm@guest-docking-nat-1-138.ethz.ch 1222347295 M * yarihm Hi everyone 1222347449 M * yarihm I got one that is not that easily googlable as it seems. On Debian Lenny (that's 2.6.26, don't know the exact vserver-patch-version) it happens rather frequently that i do something like: vserver-stat (everything looks normal), then say vserver foobar enter and then i get the message: 1222347450 M * yarihm 'vserver ... suexec' is supported for running vservers only; aborting... 1222347483 M * yarihm now, looking at vserver-stat again, the vserver is displayed but without name, something like: 1222347484 M * yarihm 40019 4 17.7M 2.2M 0m01s59 0m03s16 16d01h59 mailrelay0.cognita.c 1222347484 M * yarihm 40020 65 261.3M 40.8M 1h08m08 7m01s45 16d01h59 trac.cognita.cust 1222347484 M * yarihm 40021 2 7M 600K 0m12s22 0m02s27 2d13h32 1222347509 M * yarihm the vserver itself is kind of dead afterwards, you can't connect to it anymore 1222347548 M * yarihm the thing is only resolvable by reboot AFAICT ... Is this a known one or is it once again me being stupid? 1222347634 M * BenG there must be processes running that server 1222347648 M * BenG I've seen something like that before, but not with a missing name 1222347670 M * BenG vkill --xid 40021 -s TERM 1222347670 M * BenG vkill --xid 40021 -s KILL 1222347675 M * BenG do anything for you yarihm ? 1222347689 M * yarihm lemme try 1222347751 M * yarihm BenG, well yes. Thanks, that shuts down the vserver ... very nice indeed :) i'll re-start it, that's at least a quickfix. Stupid me, could have thought of that, too 1222347790 M * BenG cool 1222347802 M * BenG glad to be helping and not asking a question 1222347805 M * BenG ! 1222347826 M * Bertl yarihm: what util-vserver version? 1222347884 M * yarihm Bertl, 0.30.216~r2772-2 1222347897 M * yarihm whatever the tag behind the tilda means ... 1222347906 M * Bertl prerelease version 1222347936 M * yarihm ahum ... should I write something to someone? (dhozac or micah maybe?) 1222347980 M * Bertl well, the fact that the name disappears, sounds like something is removing the reverse links 1222347991 M * Bertl (in /var/run/...) 1222347994 M * yarihm Bertl, see, there are things which I should probably not do. first of all, I do not set the context manually but let it be allocated automagically. and then (maybe) it is a problem that I have somewhat long vserver-names 1222348008 M * yarihm Bertl, I'll check that the next time the problem appears 1222348015 M * Bertl hmm? 1222348017 M * yarihm the long names bit me with the interface-names, e.g. 1222348043 M * Bertl I hope the context numbers are static for each guest 1222348077 M * yarihm well, they are, each context has a /etc/vservers//context-file, but I do not set those numbers by hand ... don't know where they come from 1222348098 M * Bertl they are allocated by util-vserver, and that should be fine 1222348108 M * yarihm ok then, so that's not the issue ... 1222348167 M * Bertl just check that there isn't something cleaning up /var/run or so 1222348259 M * yarihm well, that something would probably be util-vserver or /usr/sbin/vserver specifically ... the thing works with vserver-stat | grep && vserver enter ; vserver-stat | grep 1222348273 M * yarihm what I meant to say is that this command will have $?=1 or something 1222348336 M * Bertl util-vserver messing with /var/run is fine, I was thinking of some over-eager script cleaning up stuff there 1222348392 M * yarihm yes, I know what you mean, but my point is that the probablility that a cronjob is messing around there within that time-frame is very small 1222348417 M * yarihm however, next time the issue arises, i'll see whether the links under /var/run/ are indeed missing 1222348712 M * Bertl okay, off for now .. bbl 1222348715 M * yarihm cu Bertl 1222348717 N * Bertl Bertl_oO 1222348828 Q * yarihm Quit: This computer has gone to sleep 1222349037 J * hparker ~hparker@linux.homershut.net 1222349472 J * mrfree ~mrfree@host1-89-static.40-88-b.business.telecomitalia.it 1222350005 Q * BenG Quit: I Leave 1222350125 J * ntrs_ ~ntrs@77.29.72.54 1222350186 Q * mattzerah Read error: Operation timed out 1222350548 Q * ntrs Ping timeout: 480 seconds 1222350985 J * mattzerah ~matt@pool1-180.dyn.winshop.com.au 1222351466 J * dna_ ~dna@81-226-dsl.kielnet.net 1222351529 M * ^jan Bertl_oO: mmm... problem fixed.. seems that when we do a fork();setid();fork(); to create a daemon, then /proc/net/tcp does not shows correct information... but then removing the setid(); all seems to run well 1222351880 Q * dna Ping timeout: 480 seconds 1222352352 M * meebey someone an idea what would prevent setfacl usage inside a vserver as root? the fs is part of the host fs mount via bind 1222352374 M * meebey outside the vserver setfacl works 1222352410 M * cehteh strace it --- maybe missing capability 1222352432 M * meebey I am playing with caps already, like FOWNER 1222352433 M * meebey or DAC_* 1222352439 M * cehteh here it works, used acls before in vserver 1222352454 M * cehteh without changing caps 1222352493 M * cehteh maybe the --bind mount drops acls? 1222352498 M * meebey setxattr() = -1 EPERM (Operation not permitted) 1222352506 M * meebey cehteh: oh! 1222352510 M * meebey cehteh: not again :( 1222352519 M * meebey I had that issue with noatime already... 1222352523 M * cehteh heh 1222352535 M * meebey I hate that bind drops call options feature... 1222352542 M * cehteh i like it 1222352555 M * meebey so let me add acl to the bind :) 1222352561 M * cehteh well inheriting and then altering it would be nicer .. but just make it explicit 1222352589 M * cehteh i only guessing anyways 1222352609 M * meebey I am trying with bind,acl to see if it makes a difference 1222352628 M * meebey the "host fs" is a nfs mount in my case, so that could make things more "special" 1222352638 M * cehteh indeed 1222352677 M * meebey bind,acl didnt help.. hm 1222352690 M * meebey getxattr() works, but setxattr() not, odd 1222352783 M * meebey cehteh: so did you test setting acls inside a vserver? 1222352816 M * cehteh i actually using/used them 1222352829 M * cehteh but its a old kernel .. 1222352831 Q * balbir_ Remote host closed the connection 1222352846 M * meebey 2.6.18 here 1222352849 M * cehteh local fs .. forgot which one 1222352852 M * cehteh yes .18 1222352899 M * meebey isn't grep Cap /proc/self/status the correct way to verify set caps? 1222352911 M * cehteh xfs 1222352917 M * meebey someone the mask is not changing for me when I add caps to bcapabilities 1222352922 M * meebey s/one/how/ 1222352946 M * cehteh you restart the vserver? 1222352958 M * meebey vserver foo stop; vserver foo start 1222352969 M * meebey vserver foo enter\ngrep Cap /proc/self/status 1222352982 M * meebey same values before I added something 1222353043 M * cehteh CapPrm: 00000000344c04ff 1222353043 M * cehteh CapEff: 00000000344c04ff 1222353057 M * meebey yeah same value here :) 1222353075 M * cehteh maybe nfs issue then 1222353086 M * cehteh could you try with a local fs just for a test? 1222353112 M * meebey testing 1222353148 M * cehteh mhm my vserver dir is not even a bind mount there 1222353190 M * meebey hm cant test, the root fs of the vserver is on nfs 1222353203 M * meebey so its part of the issue :-P 1222353246 M * meebey root@dms_merkel:/# setfacl -m group::rwx foo 1222353246 M * meebey setfacl: foo: Operation not permitted 1222353262 N * Bertl_oO Bertl 1222353287 M * meebey executing the setfacl on the nfs mount on the host works though 1222353304 M * meebey so NFS shouldn't be the issue here 1222353325 M * Bertl meebey: does your guest have the necessary capability? 1222353342 M * meebey Bertl: which cap does it need for setxattr? 1222353371 M * Bertl you are trying to change acls, what relevance would xattr have? 1222353374 M * meebey Bertl: I was trying CAP_FOWNER CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH 1222353392 M * meebey Bertl: because thats what setfacl does according to strace 1222353406 M * meebey Bertl: getxattr() calls succeeds, setxattr() fails 1222353459 M * Bertl is your NFS tagged? (check with /proc/config.gz) 1222353460 M * meebey Bertl: http://paste.debian.net/17960/ 1222353504 M * meebey # CONFIG_XID_TAG_NFSD is not set 1222353513 M * ^jan Bertl: I already fix my problem, as I posted before.. thank you for your help... c'ya 1222353538 M * meebey Bertl: about the caps, I think they are not applied, the cap mask doesnt change in /proc/self/status 1222353560 M * Bertl ^jan: ah, thanks! 1222353590 M * Bertl ^jan: that might be a security feature of the kernel 1222353603 M * Bertl IIRC, it can be enabled on recent kernels 1222353633 M * Bertl meebey: what does it show? 1222353679 M * ^jan (despite we have fixed our daemon, still we have problems to cat /proc/net/tcp when enter as "vserver <> enter" in some machines, just for your knowlegment) 1222353707 M * ^jan have to go.. pardon, bye 1222353710 M * Bertl ^jan: with recent kernel/tools? 1222353723 M * Bertl ^jan: no problem, maybe tomorrow or so? 1222353725 M * ^jan yeah, still with latest util-vserver 1222353737 Q * mrfree Quit: Leaving 1222353763 M * ^jan sure, I will contact you soon to show our web manager that is near to complete, almost for basic running 1222353764 M * Bertl ^jan: could be a kernel bug, we should try to narrow it down when you got some time 1222353814 M * ^jan sorry, I have to go to catch my children from school :-S.. Im late.. 1222353822 Q * ^jan Quit: Quagmire .gz. 1222354013 M * nox i get "no space left on device" errors within my guests on one of my vserver, but neither / nor /tmp is full. Any ideas? 1222354175 M * Bertl shared memory, semaphores? 1222354196 M * Bertl the question is _when_ do you get that message? 1222354546 M * nox had it when entering a guest and trieing to update package list (apt-get update) and when crontab wrote to /tmp 1222354605 M * Bertl so maybe /tmp is full then? 1222354616 M * Bertl what does 'df' tell you? 1222354635 M * nox /dev/hdv1 46540808 31597140 12579508 72% / 1222354635 M * nox none 16384 4 16380 1% /tmp 1222354683 M * Bertl so unless your crontab uses up all of tmp, that shouldn't be the cause 1222354742 M * nox never had probs before with that, and didn?t change anything vserver related on this server 1222354773 M * nox pretty strange, try to dig deeper 1222354828 M * nox just hoped that it is a known problem :) 1222354844 M * Bertl nope, not known to me 1222355658 J * dowdle ~dowdle@scott.coe.montana.edu 1222355773 M * meebey Bertl: http://paste.debian.net/17963/ 1222355786 M * meebey Bertl: not sure, but it doesnt seem to apply the caps... 1222356165 M * Bertl well, the capabilities you are giving are there 1222356202 M * Bertl are you root inside the guest? 1222356254 M * meebey Bertl: yes using vserver dms enter 1222356283 M * Bertl what kernel version? 1222356298 M * meebey Bertl: 2.6.18 1222356317 M * Bertl vs2.0/2/3? 1222356346 M * meebey something I can check? its the vserver kernel flavor in etch 1222356373 M * Bertl well, probably the changelog or ask some debian devel 1222356410 M * meebey hold on 1222356436 M * Bertl I assume 2.6.18.5-vs2.2.x for now 1222356475 M * meebey * Update vserver patch to 2.0.2.2-rc9. (closes: #402743, #403790) 1222356492 M * Bertl so vs2.0, quite old ... but so be it 1222356516 M * meebey lenny is in work, but not ready yet :-P 1222356552 M * Bertl have to see if I have a kernel tree around which is that old :) 1222356569 M * meebey hehe 1222356591 M * Bertl filesystem is? 1222356600 J * mel ~melina@tor-irc.dnsbl.oftc.net 1222356605 M * mel hello I'm horny call me at +32485949510 1222356680 M * meebey Bertl: the setup is like this: host runs nfs client and mounts /srv/foo, vserver guest uses that fs via mount bind in vserver config 1222356686 M * meebey Bertl: the host fs is ext3 1222356697 M * meebey Bertl: nfs fs is ext3 too 1222356717 M * meebey Bertl: running setfacl outside the guest in the host (the nfs mount) works 1222356734 M * meebey getfacl inside the guest works 1222356904 M * meebey the issue become visible when my daemon server inside the guest was getting EPERM from open() with CREATE and READ/WRITE, which seems to be related to the ACL that is automatically set (default ACL) but rejected from the vserver. failing setfacl inside the guest acknowledged that guessing... I even traced the NFS protocol and that seems to be happy (I am not NFS protocol expert) 1222356930 A * mel thinks meebey has a sexy voice 1222356941 M * meebey annoying spam bot 1222357133 F * ChanServ +o Bertl 1222357141 Q * mel Killed (tjfontaine (Do not spam our network. If this is in error mail support@oftc.net.)) 1222357154 M * Bertl too slow :) 1222357162 F * Bertl -o Bertl 1222357174 J * mel ~melina@tor-irc.dnsbl.oftc.net 1222357179 F * ChanServ +o Bertl 1222357182 M * meebey haha 1222357184 K mel Bertl mel 1222357189 J * thomasbl ~thomasbl@88.198.154.162 1222357194 P * thomasbl Leaving 1222357199 J * mel ~melina@tor-irc.dnsbl.oftc.net 1222357204 F * Bertl +b *!*melina@*.dnsbl.oftc.net 1222357204 K mel Bertl mel 1222357366 M * Bertl meebey: I'd suggest to update to a more recent kernel and try again 1222357376 M * Bertl even if it is a kernel bug, it is unlikely to be fixed 1222357394 M * Bertl okay, dinnertime, off for now ... bbl 1222357400 N * Bertl Bertl_oO 1222357416 M * meebey hm there is no security support for a more recent kernel... I am more lookig for a workaround... 1222357438 M * meebey I will try NFSv4 and see if that solves the issue 1222358756 J * ghislainocfs21 ~Ghislain@LPuteaux-151-41-11-129.w217-128.abo.wanadoo.fr 1222359031 N * Bertl_oO Bertl 1222359038 M * Bertl meebey: security support? 1222359061 Q * micah Remote host closed the connection 1222359069 J * micah ~micah@micah.riseup.net 1222359099 M * meebey yep works with NFSv4, but thats probably because NFSv4 has its own ACL implementation 1222359101 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1222359112 M * meebey I could try NFSv3 again and trying to disable ACL support (if possible) 1222359122 M * meebey as the nfs client doesnt really need to see the ACls 1222359134 M * meebey Bertl: security support in debian 1222359166 M * meebey Bertl: can't maintain security support myself for > 30 servers 1222359187 M * Bertl and what kind of security support does that ancient kernel get? 1222359237 M * meebey Bertl: from great work from the debian security team 1222359262 M * Bertl you sure? when was that kernel last updated? 1222359330 M * meebey -- dann frazier Mon, 18 Aug 2008 01:43:55 -0600 1222359344 M * micah Bertl: see the resolved issues section on this page: http://security-tracker.debian.net/tracker/source-package/linux-2.6 1222359354 M * meebey Bertl: http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-22etch2/changelog 1222359368 M * Bertl and that is the kernel you use? 1222359383 M * micah actually aug. 30 was the last update 1222359412 M * meebey Bertl: yes that kernel image 1222359430 M * meebey Bertl: the vserver flavor comes from the same debian source package as the normal debian kernel 1222359451 M * meebey Bertl: thats the huge advantage you get for using those images 1222359466 M * meebey Bertl: I counted 27 updates of the kernel since debian 4.0 released 1222359485 M * Bertl well, for sure they didn't update Linux-VServer issues since 10th December 2006 :) 1222359506 M * Bertl that is when we released the vs2.0.2.2-rc9 patch ... 1222359545 M * meebey Bertl: I counted 3 updates related to vserver 1222359638 M * meebey Bertl: so if I would compile my own kernel, I would have needed to build and re-deploy the kernel 27 times (if I wanted to keep up with at least the security issues that are solved in debian stable) for > 30 servers 1222359654 M * meebey Bertl: and thats the reason I stick to the debian vserver kernel image 1222359674 M * Bertl well, debian provides more recent kernels in backports for a good reason 1222359709 M * meebey Bertl: other software in debian doesnt work with it though... backports only includes a small part of the archive 1222359728 M * meebey Bertl: other software as in, packages that are bound to the kernel version... 1222359744 M * Bertl anyway .. the choice is yours ... but you have to complain to the debian folks if you have issues with that kernel 1222359782 M * meebey Bertl: right... I didnt complain though :) 1222359812 M * meebey NFSv4 is pretty buggy in etch for sure.. the reason I avoided it and with NFSv3 I get a different set of bugs :-P 1222359947 M * Bertl I don't think that NFSv4 is supported in that kernel anyways 1222360246 M * meebey nice there is a no_acl export option in NFS *testing* 1222360287 M * meebey Bertl: do you remember the issue I had with devices inside the vserver would be seen as normal files? messages like "/dev/null: file exists" popping up on vserver start.. 1222360311 M * meebey Bertl: happens if the vserver itself is hosted fully in NFSv4, but not with NFSv3... 1222360333 M * Bertl well, maybe you have a nodev option on the mount? 1222360357 M * meebey Bertl: nope, I can start the vserver if I do "ls -l /vservers/foo/dev" once :) 1222360371 M * meebey Bertl: to me it looks like a caching issue... 1222361504 M * Bertl possible .. translocating now ... bbl 1222361510 N * Bertl Bertl_oO 1222361688 Q * tramjoe_merin Remote host closed the connection 1222361944 Q * pmenier Quit: Konversation terminated! 1222362270 Q * micah Remote host closed the connection 1222362283 J * micah ~micah@micah.riseup.net 1222362338 Q * quinq Remote host closed the connection 1222362694 J * quinq ~quinq@quinq.eu.org 1222362699 J * Loki_muh loki@satanix.de 1222362712 Q * ktwilight Remote host closed the connection 1222362712 Q * Loki|muh Remote host closed the connection 1222362712 N * Loki_muh Loki|muh 1222362717 J * ktwilight ~ktwilight@87.66.202.61 1222363646 Q * kwowt Read error: Connection reset by peer 1222364295 J * SlackLnx ~Lee@bl7-145-214.dsl.telepac.pt 1222364646 Q * derjohn_foo Ping timeout: 480 seconds 1222365025 Q * SlackLnx Remote host closed the connection 1222365225 J * trippeh_ atomt@uff.ugh.no 1222365225 Q * trippeh_ 1222366946 J * red ~red@86.90.16.29 1222366950 M * red hello 1222366965 M * red i have a server with 3 vservers with each it's own external ip 1222367000 M * red but al the three vservers use one ip to connect through the internet 1222367008 M * red is it possible to let each vserver use it's own ip ? 1222367029 M * daniel_hozac have you configured NAT? 1222367053 M * red no 1222368586 M * red each vserver has configured it's own external ip 1222369679 M * daniel_hozac so we'd need some basic info, e.g. vserver-info; ip a; ip r; iptables -t nat -nvL; cat /proc/virtnet//info 1222369689 M * daniel_hozac please use paste.linux-vserver.org for anything longer than 3 lines. 1222370086 M * red http://paste.linux-vserver.org/12500 1222370089 M * red :-) 1222370190 M * daniel_hozac you have 65 identical NAT rules on there. 1222370206 M * red yes i see 1222370212 M * red weird :S 1222370263 M * red i cleaned the nat tbale 1222370266 M * red table* 1222370279 M * red it's empty now 1222370301 M * daniel_hozac and, do your guests use the correct source addresses now? 1222370322 M * red trying 1222370380 M * red yes 1222370382 M * red fixxed 1222370384 M * red thanks :-) 1222370430 M * daniel_hozac you're welcome. 1222370575 M * Bertl_oO back now 1222370579 N * Bertl_oO Bertl 1222370588 F * Bertl -o Bertl 1222370746 J * Loki_muh loki@satanix.de 1222370746 Q * Loki|muh Read error: Connection reset by peer 1222370753 N * Loki_muh Loki|muh 1222370769 J * padde_ ~padde@patrick-nagel.net 1222370769 Q * padde Read error: Connection reset by peer 1222370776 N * padde_ padde 1222370796 J * Slydder ~chuck@user-pic.planet-ic.de 1222370823 Q * red Quit: using sirc version 2.211+KSIRC/1.3.12 1222371745 J * ntrs__ ~ntrs@77.29.64.245 1222371813 Q * Slydder Read error: Connection reset by peer 1222371849 J * Slydder ~chuck@user-pic.planet-ic.de 1222372176 Q * ntrs_ Ping timeout: 480 seconds 1222373476 Q * xdr Ping timeout: 480 seconds 1222374298 J * yarihm ~yarihm@77-56-182-18.dclient.hispeed.ch 1222374361 Q * Slydder Quit: Leaving. 1222374361 J * harry ~harry@d51A461B4.access.telenet.be 1222374399 M * harry haha... /me back in full frontal nudity!^W^Wforce! 1222374545 M * fb harry :) 1222374736 J * ktwilight_ ~ktwilight@87.66.202.61 1222374749 Q * ktwilight Ping timeout: 480 seconds 1222376512 J * Aiken ~Aiken@ppp118-208-28-181.lns2.bne1.internode.on.net 1222377160 T * * http://linux-vserver.org/ |stable 2.2.0.7, devel 2.3.0.34, grsec 2.2.0.7|util-vserver-0.30.215|libvserver-1.0.2|vserver-utils-1.0.3| He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the Wiki, and we forget about the minute. 1222377160 T * ChanServ - 1222377701 Q * BrunoXLambert Remote host closed the connection 1222378656 J * androsch ~androsch@dslb-084-060-217-229.pools.arcor-ip.net 1222378799 Q * bonbons Quit: Leaving 1222379970 Q * dna_ Quit: Verlassend 1222380197 Q * ntrs__ Ping timeout: 480 seconds 1222380217 J * doener ~doener@i577B87BF.versanet.de 1222380323 Q * doener_ Ping timeout: 480 seconds 1222380812 J * derjohn_foo ~aj@e180202195.adsl.alicedsl.de 1222382065 Q * androsch Read error: Connection reset by peer 1222384037 Q * dowdle Remote host closed the connection 1222384739 J * androsch ~androsch@dslb-084-060-216-041.pools.arcor-ip.net 1222385295 Q * yarihm Quit: Leaving 1222386099 Q * quinq Remote host closed the connection 1222386200 J * quinq ~quinq@quinq.eu.org 1222386685 J * Hollow_ ~hollow@proteus.croup.de 1222386902 Q * FireEgl synthon.oftc.net weber.oftc.net 1222386902 Q * jkl synthon.oftc.net weber.oftc.net 1222386902 Q * MooingLemur synthon.oftc.net weber.oftc.net 1222386902 Q * Hollow synthon.oftc.net weber.oftc.net 1222386925 N * Hollow_ Hollow 1222387021 J * jkl jkl@c-75-70-178-175.hsd1.co.comcast.net 1222387066 J * MooingLemur ~troy@shells195.pinchaser.com