1291680442 J * achen ~Adium@63.81.0.20 1291680513 Q * achen 1291680590 J * achen ~achen@63.81.0.20 1291680660 M * achen hi, i am encountering problems with what looks like a grub2 related problem with a lucid Vserver kernel. 1291680696 M * achen upon boot up it will drop me into the recovery menu... i have performed update-grub without success 1291680724 M * achen and still continue to have the server drop into recovery mode 1291680731 M * achen any insights? 1291680810 M * daniel_hozac "recovery" mode? 1291681104 Q * imcsk8 Quit: Leaving 1291681112 M * achen yes, i would attempt to reboot the Vserver host... 1291681128 M * achen and it will drop me into the recovery menu 1291681145 J * vizz ~vizz@deadkeys.org 1291681145 M * daniel_hozac what "recovery" menu? 1291681157 M * mEDI_S "host" 1291681171 M * achen i believe it's the grub2 recovery menu... 1291681305 M * mEDI_S u men the grub shell or the initrd recover? 1291681458 M * achen i believe it is the initrd recover... it has the following options 1291681474 M * achen resume, clean, dkpg failsafeX, grub, netroot, root 1291681563 M * mEDI_S do resume work? 1291681611 M * daniel_hozac what vserver kernel are you using? 1291681645 M * achen yes, resume boots... but I do have to manually start ssh on the console 1291681706 M * achen 2.6.32-25-vserver 1291681717 M * achen x86_64 1291681823 M * daniel_hozac doesn't sound like something that'd be expected to actually work... 1291681830 M * daniel_hozac you might want to try testme and testfs on that... 1291681888 M * achen okay... I'll give testme/testfs a try 1291682086 M * achen # ./testme.sh 1291682087 M * achen Linux-VServer Test [V0.17] Copyright (C) 2003-2006 H.Poetzl 1291682087 M * achen chcontext is working. 1291682088 M * achen chbind is working. 1291682088 M * achen Linux 2.6.32-25-vserver #44~ppa2-Ubuntu SMP Wed Oct 27 21:12:19 UTC 2010 x86_64 1291682088 M * achen Ea 0.30.215 236/glibc (DSa) 1291682089 M * achen VCI: 0002:0305 236 13010fb1 (TbsPHIWD) 1291682089 M * achen --- 1291682090 M * achen [000]# succeeded. 1291682091 M * achen [001]# succeeded. 1291682091 M * achen [011]# succeeded. 1291682094 M * achen [031]# succeeded. 1291682094 M * achen [101]# succeeded. 1291682096 M * achen [102]# succeeded. 1291682096 M * achen [201]# succeeded. 1291682098 M * achen [202]# succeeded. 1291682217 M * daniel_hozac please use paste.linux-vserver.org for anything longer than 3 lines. 1291682251 M * achen okay... will do 1291682349 M * achen testfs completed successfully for ext2, ext3, and ext4 1291682373 M * achen testme ran successfully for 000, 001, 011, 031, 101, 102, 201, 202 1291682757 M * achen would you recommend downgrading the kernel to 2.6.32.24? 1291682783 M * daniel_hozac i would recommend buliding your own kernel. 1291682865 M * achen thanks daniel_hozac... 1291682874 M * achen we'll give that a try... mahalo 1291682956 J * NoHoper ~phil\@9YYAABEUZ.tor-irc.dnsbl.oftc.net 1291682956 P * NoHoper 1291683181 M * mEDI_S achen: " i have performed update-grub without success" do update-grup again ;) 1291683247 M * achen mEDI_S; i'll give the update-grub a try as well 1291683268 M * mEDI_S and validate ur /boot/grub/grub.cfg 1291683279 M * achen sure... 1291684533 M * achen mEDI_S: i was able to get an older kernel to boot cleanly... 1291684564 M * achen 26.32-24-vserver boots successfully without putting me into the recovery menu 1291684573 M * achen thanks again for your help... 1291685503 Q * achen Ping timeout: 480 seconds 1291686308 Q * manana Ping timeout: 480 seconds 1291687805 Q * cehteh Ping timeout: 480 seconds 1291688191 Q * ensc|w Ping timeout: 480 seconds 1291688353 J * ensc|w ~ensc@www.sigma-chemnitz.de 1291688595 Q * vizz Quit: leaving 1291689705 J * cehteh ~ct@pipapo.org 1291691811 J * vizz ~vizz@2001:1608:12:0:dead:beef:babe:101 1291692024 Q * vizz 1291692524 J * vizz ~vizz@2001:1608:12:0:dead:beef:babe:101 1291692888 J * vizz- ~vizz@2001:1608:12:0:dead:beef:babe:101 1291692888 Q * vizz- 1291692894 J * vizz- ~vizz@2001:1608:12:0:dead:beef:babe:101 1291697549 J * achen ~achen@c-76-126-187-170.hsd1.ca.comcast.net 1291698242 Q * vizz- Quit: leaving 1291700350 Q * padde Remote host closed the connection 1291700385 J * padde ~padde@patrick-nagel.net 1291701153 Q * vizz Quit: leaving 1291701168 J * vizz ~vizz@2001:1608:12:0:dead:beef:babe:101 1291701890 Q * vizz Quit: leaving 1291701896 J * vizz ~vizz@2001:1608:12:0:dead:beef:babe:101 1291701906 Q * vizz 1291703496 J * vizz ~vizz@2001:1608:12:0:dead:beef:babe:101 1291703643 Q * padde Remote host closed the connection 1291703667 J * padde ~padde@patrick-nagel.net 1291704775 M * Bertl off to bed now ... night folks! 1291704782 N * Bertl Bertl_zZ 1291704943 Q * achen Quit: Zzzzzzz... 1291705335 Q * vizz Quit: leaving 1291705361 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com 1291705377 J * vizz ~vizz@2001:1608:12:0:dead:beef:babe:101 1291705398 Q * vizz 1291705626 J * vizz ~vizz@2001:1608:12:0:dead:beef:babe:101 1291705751 Q * vizz 1291705780 J * vizz ~vizz@2001:1608:12:0:dead:beef:babe:101 1291706615 J * ensc ~irc-ensc@93.159.121.26 1291707001 Q * derjohn_foo Ping timeout: 480 seconds 1291708198 J * derjohn_foo ~aj@213.238.45.2 1291708584 Q * vizz Quit: leaving 1291708829 N * ensc Guest102 1291708839 J * ensc ~irc-ensc@p5DF2D2BC.dip.t-dialin.net 1291708873 Q * Romster Quit: Geeks shall inherit properties and methods of object earth. 1291709006 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com 1291709110 J * ghislain ~AQUEOS@adsl2.aqueos.com 1291709172 Q * ghislain 1291709236 Q * Guest102 Ping timeout: 480 seconds 1291709376 J * ghislain ~AQUEOS@adsl2.aqueos.com 1291709458 Q * Romster Quit: Geeks shall inherit properties and methods of object earth. 1291709479 J * vizz ~vizz@2001:1608:12:0:dead:beef:babe:101 1291709507 Q * vizz 1291709548 J * vizz ~vizz@2001:1608:12:0:dead:beef:babe:101 1291709562 Q * vizz 1291709573 J * golga ~PX2@ip72-222-225-69.ph.ph.cox.net 1291709593 J * petzsch ~markus@dslb-092-078-231-255.pools.arcor-ip.net 1291709662 J * vizz ~vizz@2001:1608:12:0:dead:beef:babe:101 1291709673 Q * vizz 1291709708 J * vizz ~vizz@2001:1608:12:0:dead:beef:babe:101 1291709722 Q * vizz 1291709832 J * vizz ~vizz@2001:1608:12:0:dead:beef:babe:101 1291710799 M * ghislain hello there 1291710838 M * ghislain http://www.nongnu.org/util-vserver/doc/conf/configuration.html is down, the great flower page shows as forbidden :) fyi 1291711241 M * hijacker hi 1291711262 M * hijacker ah, that is petty 1291711503 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com 1291711518 Q * petzsch Quit: Leaving. 1291712039 J * BenG ~bengreen@cpc2-aztw22-2-0-cust83.aztw.cable.virginmedia.com 1291712492 M * ghislain i forgot to make a copy :) 1291712554 J * nkukard_ ~nkukard@196-215-52-114.dynamic.isadsl.co.za 1291712564 M * ghislain but it is in the google cache 1291712652 J * kir ~kir@swsoft-msk-nat.sw.ru 1291712717 Q * nkukard Ping timeout: 480 seconds 1291712775 Q * golga Ping timeout: 480 seconds 1291713804 Q * ensc Remote host closed the connection 1291713817 P * kir Leaving. 1291713850 J * ensc ~irc-ensc@p5DF2D2BC.dip.t-dialin.net 1291714380 J * _are__ ~quassel@vs01.lug-s.org 1291714461 Q * _are_ Ping timeout: 480 seconds 1291714638 J * manana ~mayday090@84.17.25.149 1291716098 Q * ghislain Ping timeout: 480 seconds 1291716254 J * ghislain ~AQUEOS@LPuteaux-151-41-11-129.w217-128.abo.wanadoo.fr 1291723589 J * wibble_ wibble@vortex.ukshells.co.uk 1291723607 J * neofutur_ ~neofutur@xena.ww7.be 1291723625 J * arekm_ arekm@carme.pld-linux.org 1291723637 J * matti_ matti@acrux.romke.net 1291723637 Q * wibble reticulum.oftc.net galapagos.oftc.net 1291723637 Q * arekm reticulum.oftc.net galapagos.oftc.net 1291723637 Q * neofutur reticulum.oftc.net galapagos.oftc.net 1291723637 Q * matti reticulum.oftc.net galapagos.oftc.net 1291723637 Q * wurtel reticulum.oftc.net galapagos.oftc.net 1291723637 Q * Chlorek reticulum.oftc.net galapagos.oftc.net 1291723637 Q * ard reticulum.oftc.net galapagos.oftc.net 1291723649 N * matti_ matti 1291723680 N * matti Guest135 1291723902 J * Chlorek ~cokolwiek@c.sed.pl 1291724046 Q * BenG Quit: I Leave 1291727801 J * petzsch ~markus@dslb-092-078-231-255.pools.arcor-ip.net 1291728517 Q * Romster Remote host closed the connection 1291728641 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com 1291728696 Q * mikez Ping timeout: 480 seconds 1291728741 M * daniel_hozac ghislain: hmm. strange. 1291728748 M * daniel_hozac i haven't touched it in quite somemt ime. 1291729692 N * Bertl_zZ Bertl 1291729699 M * Bertl morning folks! 1291729906 J * BenG ~bengreen@cpc2-aztw22-2-0-cust83.aztw.cable.virginmedia.com 1291730239 Q * Romster Quit: Geeks shall inherit properties and methods of object earth. 1291730407 J * ard ~ard@gw-tweakb16.kwaak.net 1291730426 J * wurtel ~paul@gw-office.telegraaf.net 1291730612 M * ghislain daniel_hozac: strange thing happen in the internet in a router far far away 1291731508 M * daniel_hozac yeah... 1291731516 M * daniel_hozac i don't have any real access there, IIRC. 1291731529 M * daniel_hozac it's all from a CVS tree. 1291732061 M * Bertl daniel_hozac: who has access there? 1291732092 M * daniel_hozac well, i have access to the CVS tree. 1291732102 Q * BenG Quit: I Leave 1291732126 M * daniel_hozac http://www.mail-archive.com/savannah-hackers-public@gnu.org/msg03476.html seems to be what's causing the problem. 1291732209 M * Bertl shall I contact Bernie or do you want to do that? 1291732256 M * daniel_hozac the tree has symlinks in it, so i'm trying to make sure it's not just an easy fix... 1291732378 M * Bertl okay, because I think it is important to get the url working as it was ... after all the great flower page is well known to google and friends :) 1291732384 M * daniel_hozac hehe 1291732385 M * daniel_hozac yeah 1291732393 M * daniel_hozac it's definitely getting fixed. 1291732514 M * daniel_hozac i've done what i can, still doesn't work though. sent them an email. 1291733282 M * Bertl to Bernie I presume? 1291733445 M * daniel_hozac to svannah-users 1291733468 M * Bertl can you bounce me that mail, I'll contact Bernie, I know him 1291733561 M * daniel_hozac sure 1291733594 J * achen ~achen@c-76-126-187-170.hsd1.ca.comcast.net 1291733672 M * Bertl tx 1291734923 Q * achen Quit: Zzzzzzz... 1291736246 M * Bertl off for now ... bbl 1291736250 N * Bertl Bertl_oO 1291737053 J * dowdle ~dowdle@scott.coe.montana.edu 1291737644 J * achen ~achen@c-76-126-187-170.hsd1.ca.comcast.net 1291738070 Q * achen Quit: Zzzzzzz... 1291738550 J * bsingh ~balbir@122.167.175.64 1291740130 J * petzsch1 ~markus@dslb-088-075-161-157.pools.arcor-ip.net 1291740463 Q * petzsch Ping timeout: 480 seconds 1291741516 J * neutrino ~neutrino@209.106.18.95.dynamic.jazztel.es 1291741532 M * neutrino hello 1291741602 M * neutrino I am running 2.6.36-vs2.3.0.36.38 on Debian and yesterday I had a page allocation failure while doing heavy I/O over an iSCSI Network disk 1291741609 M * neutrino kworker/u:4: page allocation failure. order:4, mode:0x4020 1291741665 M * neutrino anybody can give some advice on this issue? 1291741771 M * daniel_hozac that doesn't sound entirely unexpected. 1291741776 M * daniel_hozac did it cause a problem? 1291741857 Q * Snow-Man Ping timeout: 480 seconds 1291741993 M * neutrino yes, the machine become unresponsive and it was needed to force a hard reboot 1291742069 J * Snow-Man ~sfrost@tamriel.snowman.net 1291742075 M * neutrino are there any recommended /proc/sys/vm tweaks that can help to avoid this situations? 1291742107 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1291742171 M * neutrino I set vm.vfs_cache_pressure = 1000, vm.dirty_background_ratio = 1, vm.dirty_ratio = 2 as a workaround (didn't tested yet) . But I am not sure if any more tweak will be recommended 1291742518 M * neutrino Basically I multiplied by 10 debian default vfs_cache_pressure and divided by 10 debian defaults dirty_ratio and dirty_background_ratio. With that I am telling the kernel to reclaim RAM used by the file system caches more often and to start swapping dirty pages sooner. 1291742538 J * achen ~achen@63.81.0.20 1291742991 M * Bertl_oO neutrino: the page allocation errors do not indicate that you are out of memory, they indicate that a driver needs a certain amount of _contiguous_ memory (oder 4 allocations mean 2^4 pages) 1291743052 M * Bertl_oO i.e. it looks to me like some iSCSI parameters might need some adjustments or your network card could benefit from a hardware or software change 1291743133 M * Bertl_oO order 4 allocations are hard to satisfy over time, as memory gets fragmented 1291743170 M * neutrino previously I was running the iSCSI over a link with jumbo frames enabled (MTU=8000), I lowered today too to standard 1500 to avoid the memory fragmentation 1291743278 M * neutrino is there any way to avoid memory fragmentation? 1291743792 Q * bsingh Ping timeout: 480 seconds 1291744082 J * BenG ~bengreen@cpc2-aztw22-2-0-cust83.aztw.cable.virginmedia.com 1291744173 M * Bertl_oO not really, the problem here is that for virtual memory (i.e. the stuff userspace usually uses) it doesn't matter where the pages actually are 1291744209 M * Bertl_oO but for drivers (especially those using DMA) it is quite important to have contiguous pieces 1291744244 M * Bertl_oO some drivers pre-allocate the memory as buffers, but for e.g. networking, this cannot be done easily 1291744264 N * Bertl_oO Bertl 1291744733 M * neutrino so most probably the problem is that the network driver card (sky2) is buggy, isn't it? 1291744776 M * neutrino this is what the kernel printed about pages when it happened 1291744783 M * neutrino DMA: 23*4kB 139*8kB 49*16kB 14*32kB 11*64kB 3*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3524kB 1291744789 M * neutrino Normal: 6416*4kB 916*8kB 188*16kB 6*32kB 1*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 36384kB 1291744795 M * neutrino HighMem: 987*4kB 236*8kB 3*16kB 18*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6460kB 1291744822 M * neutrino practically there where no pages of more than 64kb 1291745095 M * Bertl buggy depends on the PoV, but yes, sky2 isn't one of the high performance, high quality cards 1291745206 M * neutrino then do you think that replacing the network card with another brand (realtek/intel) will solve the problem? 1291745260 M * Bertl replacing the network card with a supported intel card will definitely improve things, but without further investigation I cannot tell if it will fix this specific issue ... 1291745337 M * neutrino I have launched the script that does heavy I/O over the iSCSI disk now while monitoring memory pages each 60 seconds via echo m > /proc/sysrq-trigger 1291745358 M * neutrino and it was 1291745370 M * neutrino HighMem: 14*4kB 35*8kB 24*16kB 11*32kB 7*64kB 7*128kB 2*256kB 4*512kB 3*1024kB 4*2048kB 54*4096kB = 237424kB 1291745372 M * neutrino 60 seconds 1291745383 M * neutrino HighMem: 17*4kB 16*8kB 9*16kB 7*32kB 4*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1204kb 1291745406 M * neutrino Normal: 3*4kB 5*8kB 1*16kB 5*32kB 4*64kB 6*128kB 5*256kB 3*512kB 3*1024kB 2*2048kB 154*4096kB = 642020kB 1291745408 M * neutrino 60 seconds 1291745419 M * neutrino Normal: 1011*4kB 406*8kB 148*16kB 73*32kB 29*64kB 3*128kB 4*256kB 3*512kB 2*1024kB 2*2048kB 1*4096kB = 27036kB 1291745421 M * Bertl well, highmem is unlikely to affect you it cannot be used for DMA or similar 1291745452 M * neutrino DMA: 1*4kB 2*8kB 1*16kB 2*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15908kB 1291745454 M * neutrino 60 seconds 1291745455 M * Bertl and you should get rid of highmem anyway, unless you have more than 3GB memory on your 32bit system 1291745466 M * neutrino DMA: 0*4kB 0*8kB 1*16kB 0*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 1*4096kB = 6096kB 1291745479 Q * BenG Quit: I Leave 1291745502 M * neutrino and how I can get rid of highmem? 1291745526 M * Bertl by selecting the proper memory split (kernel/user) in your kernel 1291745552 M * Bertl (i.e. in your kernel .config) 1291745620 M * neutrino setting CONFIG_HIGHMEM=n ? 1291745621 M * Bertl highmem is a performance and I/O killer, because it requires special handling all over the place and cannot be directly used for I/O 1291745647 M * neutrino I was using the .config provided by Debian 1291745673 M * Bertl bad idea :) 1291745720 M * Bertl distros generally include whatever they can enable in a kernel, so it is bloated and fragile 1291745757 M * Bertl custom tailoring a kernel to your actual hardware and driver/software needs often improves performance and almost always improves stability 1291745837 M * Bertl grep for SPLIT or 3GB in the config, I do not have a 32bit kernel at hand to check for the options right now 1291746202 Q * wishi Quit: leaving 1291746231 M * neutrino which one is recommended? user/kernel ? 1G/3G ? 1291746441 M * neutrino this is what the help of CONFIG_HIGMEM says 1291746444 M * neutrino If you are compiling a kernel which will never run on a machine with more than 1 Gigabyte total physical RAM, answer "off" here (default choice and suitable for most users). This will result in a "3GB/1GB" split: 3GB are mapped so that each process sees a 3GB virtual memory space and the remaining part of the 4GB virtual memory space is used by the kernel to permanently map as much physical memory as possible. If the machine has betw 1291746444 M * neutrino een 1 and 4 Gigabytes physical RAM, then answer "4GB" here. 1291746491 M * Bertl how much memory does your machine have? 1291746521 M * daniel_hozac 32-bit boxes still exist? :) 1291746531 M * Bertl yes, they do :) 1291746581 M * Bertl and considering that the big microsoft world still has troubles with 64bit machines ... I guess they'll be around for some more years :) 1291746621 M * neutrino I think that I am going to enable CONFIG_COMPACTION (Allows the compaction of memory for the allocation of huge pages) 1291746626 M * neutrino do you think is a good idea? 1291746634 M * daniel_hozac do you use huge pages? 1291746639 M * Bertl nah, not really 1291746648 M * neutrino nop as far as I know 1291746655 M * neutrino my machine has 1.5GB 1291746657 M * daniel_hozac you'd know. 1291746677 M * Bertl so then disable highmem, and enable the CONFIG_VMSPLIT_2G 1291746698 M * Bertl that will give you linear access to all the 1.5GB 1291746701 M * neutrino but perhaps the compaction of memory can solve the problem of running out of contiguous memory, no? 1291746715 M * Bertl nah, not really 1291746839 J * DarkUranium ~DarkUrani@93-103-181-50.dynamic.t-2.net 1291746841 M * DarkUranium hey 1291746864 M * Bertl hey 1291746864 M * DarkUranium I'd need some help with a Debian vserver 1291746880 M * DarkUranium the host machine has an IP (let's call it 111.111.111.111) and a subnet (123.123.123.123/29) 1291746891 M * DarkUranium how could I forward all traffic from the subnet to the vhost? 1291746918 M * DarkUranium right now, 123.123.123.123:80 (for example) loads the same page as 111.111.111.111 -- the one being hosted by the, well, host machine 1291746967 M * neutrino ok.. 1291746970 M * neutrino thanks a lot for the help bertl and daniel_hozac ;) 1291747046 M * Bertl DarkUranium: you cannot 'forward' to guests, as they are using the same network stack the host uses 1291747065 M * Bertl what you want to do is the following: 1291747068 M * DarkUranium Bertl: er, wait, what? 1291747074 M * neutrino DarkUranium: I think that your problem is that you have apache on the host machine listening on all address: 0.0.0.0 1291747083 M * Bertl restrict the host services (e.g. your httpd) to host only IPs 1291747085 M * neutrino you must make it to listen only on its own address 1291747093 M * DarkUranium ah 1291747101 A * DarkUranium goes poke into Apache docs 1291747114 M * neutrino you can check easily 1291747118 M * Bertl then (re)start the guest or the guest services, which will automagically be limited to guest assigned IPs 1291747122 M * neutrino netstat -ltan |grep 80 1291747124 M * neutrino on the host 1291747130 M * neutrino if you see 0.0.0.0:80 is it 1291747172 M * DarkUranium hang on, lemme bootup SSH and then remember the IP xD 1291747225 M * DarkUranium well 1291747233 M * DarkUranium I see the ipv6 :::80 1291747244 M * DarkUranium and tcp 0 0 0.0.0.0:5280 0.0.0.0:* LISTEN 1291747277 M * daniel_hozac so you need to restrict it. 1291747299 M * DarkUranium yeah, trying to find where xD 1291747308 M * DarkUranium also, is there a way to globally restrict all host processes? 1291747319 M * DarkUranium httpd is not the only thing running there =/ 1291747338 N * MooingLe1ur MooingLemur 1291747393 M * MooingLemur Rather than Listen 80, do Listen 10.10.10.10:80 1291747409 M * DarkUranium hmmm? 1291747425 M * DarkUranium yeah, but that only covers Apache -- what about other services? 1291747432 M * MooingLemur you'll have to do them individually 1291747440 M * DarkUranium =O 1291747443 M * daniel_hozac that's why you're not supposed to run things on the host. 1291747448 M * DarkUranium is there no other way? =( 1291747467 M * DarkUranium well, it's not my PC, I'm doing this on someone elses host >_< 1291747475 M * MooingLemur there is no facility to restrict what the host can bind to. All of the IPs on the interface are owned by the host by design 1291747476 M * neutrino on the host you have to make all services to listen only on the lan ip address (never on 0.0.0.0) 1291747482 M * neutrino on guests you can make it to listen on 0.0.0.0 1291747500 M * DarkUranium this complicates matters 1291747503 M * neutrino this applies to ssh too and all services 1291747520 M * neutrino its just change one line on your config men 1291747549 M * DarkUranium I can count at least 16 services listening on 0.0.0.0 1291747560 M * DarkUranium and that's without counting ipv6 1291747572 M * MooingLemur ntpd is an interesting beast though. There is no way to restrict it (other than by using openntpd). But I haven't cared and ntpd continues to bind to all interfaces on the host. 1291747609 M * neutrino if the host is listening on 0.0.0.0 it will overwrite ports listening on guests 1291747624 M * neutrino yes but ntpd is a software that you will only want to run on the host.. never on a guest 1291747626 M * neutrino no? 1291747634 M * MooingLemur right. 1291747671 M * DarkUranium I did mean what I could do on the host to restrict this 1291747686 M * MooingLemur configure each service only to bind to the host's IP. 1291747705 M * DarkUranium 16 services... oh god 1291747724 M * MooingLemur DarkUranium: no matter how much it upsets you, complaining about it won't change what you have to do :) 1291747732 M * DarkUranium MooingLemur: sure it will =P 1291747734 M * DarkUranium computers have ears! 1291747736 M * Bertl usually it is much simpler to move all the host services into a guest themselves 1291747736 M * DarkUranium >_< 1291747749 M * DarkUranium Bertl: well, I can't tell that to the owner of the server, now can I? >_< 1291747749 M * Bertl just leave the management (i.e. sshd) on the host 1291747767 M * Bertl if you do it correctly, he won't even notice :) 1291747771 M * DarkUranium lol right 1291747783 M * DarkUranium change the sshd to login to the vserver 1291747786 M * DarkUranium and hijack his main? 1291747788 M * DarkUranium =P 1291747789 M * Bertl correct 1291747800 M * DarkUranium that would be interesting lol 1291747809 M * neutrino for ssh: /etc/ssh/sshd_config < ListenAddress 192.168.X.Y 1291747848 M * DarkUranium you mean << 1291747848 M * MooingLemur sshd can take multiple "ListenAddress"es, just as Apache can take multiple "Listen"s 1291747854 M * DarkUranium er 1291747857 M * DarkUranium well, you get the point xD 1291747864 Q * Phoner Remote host closed the connection 1291747866 J * Phoner phoner@administrat.org 1291747867 M * MooingLemur to cover IPv6 1291747925 J * dna ~dna@dslb-088-074-207-209.pools.arcor-ip.net 1291748300 Q * derjohn_foo Ping timeout: 480 seconds 1291748424 J * mikez mike@no.phear.eu 1291748661 Q * DLange Remote host closed the connection 1291748676 J * DLange ~DLange@dlange.user.oftc.net 1291748815 M * DarkUranium hm 1291748823 M * DarkUranium do you reckon a dummy interface wouldn't work either? 1291748830 M * DarkUranium eth0 <-> dummy0 <-> vserver eth0 1291748920 M * Bertl you know what a dummy interface does? 1291748949 M * DarkUranium what do you mean by that? 1291748970 M * MooingLemur it was a direct question, perhaps implying that you might not know how it behaves. 1291749002 M * DarkUranium not completely -- what I had in mind was some sort of forwarding and then bind the vhost to the dummy 1291749007 M * Bertl the dummy interface destroys data it receives, like /dev/null and will never produce any data itself 1291749049 M * Bertl as I said, there is no forwarding involved in host-guest traffic when using Linux-VServer without network namespaces (the default) 1291749055 M * Bertl what you want is either: 1291749078 M * Bertl a) use certain public IPs for guests directly (i.e. assign them to the guest) or 1291749106 M * Bertl b) use private IPs for the guests, and S/DNAT the traffic from/to those private IPs 1291749131 M * DarkUranium well, a) is sorta what I wanted to do 1291749142 M * DarkUranium the subnet would only be used by the guest 1291749152 M * Bertl in any case, you must avoid a host service which binds to 0.0.0.0 i.e. any IP, as it will also bind the guest IPs 1291749153 M * MooingLemur neither a) or b) will prevent services running on the host from binding to interfaces that you want to belong to the guest. 1291749159 M * DarkUranium hm 1291749172 M * MooingLemur since all interfaces are always available on the host. 1291749195 A * DarkUranium will have to talk to the server owner =/ 1291749243 M * Bertl you can put host services which are not used for administrating Linux-VServer guests into network contexts, effectively restricting them to certain IPs 1291749273 M * DarkUranium that sounds kinda right 1291749289 M * DarkUranium "right" as in, what I could do 1291749309 Q * neofutur_ Quit: leaving 1291749313 J * neofutur ~neofutur@xena.ww7.be 1291749319 M * DarkUranium an ideal solution would be one which restricts all services to that one IP, but means that changing every single configuration file in them is not required 1291749413 M * Bertl well, it wouldn't be ideal for e.g. sshd 1291749421 M * DarkUranium why not? 1291749443 M * Bertl as it would limit your administrative tasks to those IPs, disallowing a guest which uses different IPs :) 1291749459 M * DarkUranium and sshd can stay outside (that's viable) 1291749470 M * DarkUranium not sure what you mean by that 1291749485 J * imcsk8 ~ichavero@189.253.64.164 1291749489 M * Bertl well, Linux-VServer is all about security contexts 1291749502 M * Bertl if you use one to limit all host services to a.a.a.a 1291749526 M * Bertl then you cannot use one of those servies to administrate (i.e. start/stop) a guest using b.b.b.b 1291749540 M * Bertl (as it would mean that you 'escaped' that security context) 1291749576 J * derjohn_foo ~aj@d073217.adsl.hansenet.de 1291749616 M * MooingLemur DarkUranium: what you propose is seems harder and more Rube-Goldbergian than just adjusting config files as needed. 1291749657 M * DarkUranium MooingLemur: since this isn't my server, I'm looking for a solution that requires the least amount of work and has the highest chances of working outright without failing (silently or not) in the process 1291749674 M * DarkUranium were it my machine, I'd go edit the config files right away 1291749710 M * Bertl well, IMHO the simplest way would be to make a copy of the host into a 'guest' dir 1291749730 M * Bertl then remove all the hardware related runlevels (we have a post install script for that) 1291749748 M * Bertl and shut down all host services (on the host) except for sshd 1291749764 M * DarkUranium perhaps, but that would need two machines (one to keep as a backup should something go wrong) then 1291749781 M * MooingLemur DarkUranium: that's not our problem :) 1291749781 M * Bertl then start the guest (all services will run and work as intended) but now limited to the IPs and the guest context 1291749803 M * DarkUranium and performance? 1291749805 M * Bertl DarkUranium: you are not destroying anything on the host 1291749810 M * DarkUranium I think he runs a shitload of stuff there xD 1291749815 M * DarkUranium Bertl: rm -rf / 1291749816 M * DarkUranium \o/ 1291749816 M * Bertl well, the performance will be the same as before 1291749854 M * DarkUranium what are the chances of something going wrong? 1291749865 M * Bertl if you notice any performance degradation when moving services into a guest, we have a bug somewhere and you should immediately report it :) 1291749868 M * DarkUranium should the whole thing be moved onto a vserver 1291749892 M * Bertl as I said, if you have the space to duplicate the host stuff, no need to (re)move it 1291749900 M * DarkUranium you mean like that: 1291749905 M * DarkUranium "Code that puts multi threading to good use: Thread.Sleep(700); // give the illusion that something significant happened" 1291749925 M * DarkUranium =P 1291749929 M * DarkUranium oh wait, that's a feature 1291749944 M * MooingLemur DarkUranium: IMO, the least disruptive thing to do would be to reconfigure things, one by one, and test. Ideally, nearly all services should be run in a guest eventually. We can only offer suggestions. We can't guarantee anything, nor come up with probabilities of success. 1291752547 N * ensc Guest209 1291752556 J * ensc ~irc-ensc@p5DF2DA46.dip.t-dialin.net 1291752830 Q * Guest209 Ping timeout: 480 seconds 1291756552 Q * imcsk8 Quit: This computer has gone to sleep 1291756622 Q * petzsch1 Quit: Leaving. 1291757148 Q * bonbons Quit: Leaving 1291757291 J * imcsk8 ~ichavero@189.253.64.164 1291757795 Q * imcsk8 Ping timeout: 480 seconds 1291757975 J * imcsk8 ~ichavero@200.95.162.219 1291759095 J * ichavero_ ~ichavero@200.95.162.199 1291759202 Q * imcsk8 Ping timeout: 480 seconds 1291759484 N * ensc Guest224 1291759494 J * ensc ~irc-ensc@p5DF2EE0C.dip.t-dialin.net 1291759614 Q * ichavero_ Quit: This computer has gone to sleep 1291759779 P * achen 1291759877 Q * Guest224 Ping timeout: 480 seconds 1291759984 Q * dna Quit: Verlassend 1291762928 Q * ghislain Quit: Leaving. 1291763032 Q * ntrs Ping timeout: 480 seconds 1291763220 J * ktwilight_ ~keliew@91.176.46.53 1291763453 Q * ktwilight Ping timeout: 480 seconds 1291763508 J * ntrs ~ntrs@vault08.rosehosting.com 1291764513 Q * neutrino Ping timeout: 480 seconds 1291764973 Q * DarkUranium Quit: Leaving 1291766137 Q * mikez Remote host closed the connection 1291766185 J * arekm arekm@carme.pld-linux.org 1291766213 Q * arekm_ Remote host closed the connection