1416787321 J * l0kit ~1oxT@0001b54e.user.oftc.net 1416790613 Q * Ghislain Quit: Leaving. 1416791849 J * fstd ~fstd@xdsl-87-78-15-194.netcologne.de 1416814944 J * Ghislain ~aqueos@adsl1.aqueos.com 1416816320 N * Bertl_zZ Bertl 1416818088 N * Bertl Bertl_oO 1416818130 J * beng_ ~BenG@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net 1416824139 J * jakobsg_ ~chatzilla@62.116.207.125 1416824349 M * jakobsg_ Hi. I am having doing a maturity check on LXC. We use vserver at the moment. One of the most important features for us in vserver is the ~single_ip nflag. Do any of you guys know if something similar is supported in LXC? 1416824661 J * jakobsg ~chatzilla@62.116.207.125 1416824994 Q * jakobsg_ Ping timeout: 480 seconds 1416827815 Q * jakobsg Remote host closed the connection 1416828561 Q * beng_ Remote host closed the connection 1416831051 J * soooga ~soooga@101.205.8.166 1416831292 Q * soooga 1416834026 J * fstd_ ~fstd@xdsl-87-78-231-142.netcologne.de 1416834162 Q * Aiken Remote host closed the connection 1416834474 Q * fstd Ping timeout: 480 seconds 1416834474 N * fstd_ fstd 1416835413 M * ard this is pretty weird... 1416835494 M * ard I have a vserver with a seperate network namespace... 1416835513 M * ard upon boot, the sshd of the host gets started in that network namespace... 1416835523 M * ard ahhhh wait... 1416835600 A * ard sighs 1416835610 M * ard sshd is started from ifupdown 1416836096 M * Ghislain jakobsg_: well , better ask in a LXC chanel i guess, the lxc website has no doc at all so you will have to test to know i guess 1416836130 M * ard lxc does not support that 1416836144 M * ard single_ip is a network context thing, and not a network namespace thing 1416836189 M * ard for lxc to work, or generic network namespaces (also for vserver) you have to create macvlan in bridge mode and assign the macvlan to the correct network namespace 1416836209 M * Ghislain macvlan, is it irish ? 1416836238 M * ard more scottish? 1416836248 M * Ghislain ah yes sorry ! :s 1416836248 M * ard not even mc, but mac even :-) 1416836272 A * ard sighs 1416836272 M * Ghislain ;p 1416836302 M * ard to work around my sshd problem, I have to create and assign the interfaces in the host, and somehow make the vserver run ifup -a 1416836329 M * ard So the sshd that is started is not from the host but from the vserver itself 1416836347 M * ard But then I have to assign appropriate rights to the vserver 1416836350 M * ard meeh!! 1416836387 M * Ghislain network namespace seesm tricky 1416836501 M * Ghislain hum let me rephrase that, network is tricky ! 1416836840 M * gnarface ard: what's the separate namespace do? 1416836891 M * gnarface ard: this isn't something you can fix by simply having the host sshd_config bind to its own ip specifically instead of "0.0.0.0" ? 1416837903 M * Bertl_oO yeah, macvlan is very scottish :) 1416838533 M * Ghislain eheh 1416839991 J * Wermwud ~Wermwud@69-29-150-18.stat.centurytel.net 1416840532 M * ard gnarface : a network namespace is just a seperate ipstack 1416840541 M * ard And it really is, fully... 1416840562 M * ard It can do forwarding and iptables while all others don't 1416840619 M * ard depending on how you do it, it can also leave you open to guests changing ips and such 1416840647 M * Ghislain yes i must say iptables on guest is something i would like but no time to test all this 1416840649 M * ard so you have to create the namespace and the interfaces with the capabilities of the host 1416840674 M * ard I have a firewalling vserver... 1416840689 M * Ghislain :) 1416840698 M * ard But I only now noticed the sshd problem :-) 1416840739 M * ard For a firewall it is ok to set up ip and such, so I can actually do the ifupdown within the vserver after the host has given the vserver the devices 1416840781 M * ard But sometimes you want to not let the vserver do that, but just do vspace -e --net ifup --class vserver-net 1416840785 M * ard something like that 1416840890 M * ard a collegeau is now addressing the maintainer... 1416840905 M * ard for other reasons, but he just got one more ;-) 1416840920 J * bragon ~alex@tobold.bragon.info 1416841150 M * ard My biggest problem with network namespaces is a reference count leak somewhere in interfaces, which prevents a normal reboot, since it is waiting for the interfaces to go down :-( 1416841166 M * ard And my BMC does not support break, so I have to ipmi reset it :-( 1416841254 A * ard hates those security researchers 1416841276 M * ard 4 years ago, you could just log in as root on your bmc, install iptables and picocom 1416841311 M * ard 1 year ago you could log into a weird shell, but then say shell /bin/sh, and you still got root, and could fix everything 1416841346 M * ard 4 months ago you could download the configuration tar, decrypt it, untar, install your scripts, tar and encrypt and upload it. 1416841381 M * ard Now the configuration tar is encrypted in a way I can not decrypt it. 1416841394 M * ard So the BMC is broken and stays broken :-( 1416841439 M * ard this time I only wanted to add static ipv6 configuration with a default gateway 1416841600 M * ard does Bertl_oO already have bitcoin? 1416841650 M * Bertl_oO no, he doesn't 1416841742 M * ard Bah... I just wanted to test out cryptokit... 1416841803 Q * fstd Remote host closed the connection 1416841918 J * fstd ~fstd@xdsl-87-78-231-142.netcologne.de 1416842316 J * beng_ ~BenG@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net 1416842515 M * gnarface is there a difference between ata66 and ata100 cables? 1416842654 M * gnarface Bertl_oO: when i get that hard lockup error in dmesg, for the second time now it was also accompanied by the dropping of the ata bus speed from 100 to 66, automatically. do you know if that means its the harddrive controller conclusively, or, since its an nforce chipset (which is also running the onboard ethernet) could it still be either? 1416842882 M * ard wtf... 1416842885 M * gnarface most the time it doesn't do that, and it still goes for days without doing it so i can't really trace the cause to a software event 1416842911 M * ard you must have the 80 wire cable... 1416842956 M * gnarface ard: but, there's no difference then between an 80-wire ata66 cable and an 80-wire ata100 one right? 1416842958 M * ard But that it still exists today, it should have died 5 years ago at least 1416842970 M * ard not that I know of 1416843005 M * ard ata is a "digital" connection, so it wasn't intended for those kind of cables at all... 1416843032 M * gnarface yea, i am just trying to make use of old hardware. i might plug it into a sata->pata adapter just to avoid the problem 1416843040 M * ard the 80 wire just means there is 40 wires of grounding between the signal wires :-) 1416843074 M * ard If you lived in NL I could have given you hardware... 1416843085 M * gnarface but as far as i know, it could as easily be a problem with the onboard ethernet (when i shelved this motherboard a few years back i had been runinng a pci ethernet card in it but i don't remember exactly why) or something in my kernel config that the clock doesn't like 1416843089 M * ard scsi ultra 320 disks with controllers :-) 1416843132 M * gnarface *this* time when it dropped the ata speed from 100 to 66, it also killed ntpd 1416843147 M * gnarface i wasn't running ntpd last time 1416843159 M * ard I think the speed drop is due to the lockup, messing with timing... 1416843184 M * gnarface hmm. makes sense i guess, the issues do seem to coincide with severe clock drift (hence installing ntpd) 1416843185 M * ard But it might be the other way around 1416843193 Q * undefined Quit: Closing object 1416843212 M * ard You must remove the ntp drift values, and reboot... 1416843227 M * gnarface no no, that was *before* i installed ntpd 1416843237 M * gnarface no drift with it 1416843246 M * ard But is it variable? 1416843249 M * ard or a constant? 1416843251 J * undefined ~undefined@75-141-158-50.dhcp.mdfd.or.charter.com 1416843254 M * gnarface well, actually without it, it seemed to drift 20 minutes to half an hour all at once 1416843277 M * gnarface or at least in a short amount of time. so that suggests to me the issues may be related 1416843280 M * ard Because no clock is good, and a pc clock has variations... 1416843289 M * ard that doesn't sound right... 1416843295 M * gnarface yea ... this one was never great, but its very badly behaved now 1416843316 M * ard 5 minutes an hour is ok, especially if it always is 5 minutes 1416843329 M * ard because you use ntpd for that 1416843348 M * gnarface there was a kernel config i enabled, something about dynamic ticks... that couldn't cause something like this, could it? 1416843348 M * ard But if the drift varies, you better start looking for another mobo ;-) 1416843376 M * ard It should not, because it recalculates the "missing" ticks 1416843384 M * ard NOHZ... 1416843672 M * gnarface there were like 3 settings 1416843681 M * gnarface one was regular ticks, one was partial, one was completely none 1416843683 M * gnarface or something like that 1416843700 M * gnarface i picked the middle one 1416843918 M * gnarface Idle dynticks system (tickless idle) 1416843920 M * gnarface that's the one 1416843926 M * gnarface NO_HZ_IDLE 1416843949 M * gnarface (as opposed to HZ_PERIODIC or NO_HZ_FULL) 1416844024 M * gnarface but now that i'm going over this again, there's a lot of things that look suspicious 1416844043 M * gnarface i enabled CONFIG_RCU_FAST_NO_HZ, for example.... not sure that was wise either 1416844078 M * gnarface hmm 1416844081 M * gnarface [65629.512591] [sched_delayed] \x014CE: hpet increased min_delta_ns to 11521 nsec 1416844091 M * gnarface Bertl_oO: this look bad? ^ 1416848611 J * bonbons ~bonbons@2001:a18:201:5a01:25d0:b847:3e44:9e07 1416849485 J * zerick ~eocrospom@190.117.185.146 1416851104 Q * fstd Remote host closed the connection 1416851502 J * fstd ~fstd@xdsl-87-78-231-142.netcologne.de 1416852099 Q * fstd Remote host closed the connection 1416852825 Q * beng_ Quit: I Leave 1416852879 J * hlew_ ~hlew@2601:9:4c01:a00:e4ba:eadc:d3b:bb08 1416853159 Q * hlew Ping timeout: 480 seconds 1416856375 J * fstd ~fstd@xdsl-87-78-231-142.netcologne.de 1416859329 J * Aiken ~Aiken@d63f.h.jbmb.net 1416865099 Q * bonbons Quit: Leaving 1416868668 J * FireEgl ~FireEgl@173-23-76-11.client.mchsi.com 1416873272 Q * fstd Remote host closed the connection