1418774427 Q * zerick Ping timeout: 480 seconds
1418776756 Q * Ghislain Quit: Leaving.
1418778003 Q * fstd Remote host closed the connection
1418778045 J * fstd ~fstd@xdsl-87-78-180-43.netcologne.de
1418788015 M * Bertl off to bed now ... have a good one everyone!
1418788024 N * Bertl Bertl_zZ
1418788522 J * zerick ~eocrospom@190.118.16.131
1418788594 Q * zerick Read error: Connection reset by peer
1418790774 Q * Hayro Read error: Connection reset by peer
1418790826 J * Hayro ~Hayro@195.142.230.52
1418790864 Q * Hayro Read error: Connection reset by peer
1418790870 J * Hayro ~Hayro@195.142.230.52
1418792167 Q * Hayro Read error: Connection reset by peer
1418792177 J * Hayro ~Hayro@195.142.230.52
1418792254 Q * Hayro 
1418793108 J * Aiken ~Aiken@quarry.jbmb.net
1418795212 Q * hlew Ping timeout: 480 seconds
1418795773 J * hlew ~hlew@173-164-198-18-SFBA.hfc.comcastbusiness.net
1418799277 Q * derjohn_mob Ping timeout: 480 seconds
1418800302 J * Ghislain ~aqueos@adsl1.aqueos.com
1418802677 J * derjohn_mob ~aj@firewall01.talentformation.kunden.net-lab.net
1418802775 Q * Ghislain Quit: Leaving.
1418803440 J * Ghislain ~aqueos@adsl1.aqueos.com
1418804287 Q * derjohn_mob Ping timeout: 480 seconds
1418805626 J * derjohn_mob ~aj@firewall01.talentformation.kunden.net-lab.net
1418807507 Q * derjohn_mob Ping timeout: 480 seconds
1418807795 J * beng_ ~BenG@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net
1418809819 N * Bertl_zZ Bertl
1418809821 M * Bertl morning folks!
1418810841 M * Ghislain yop
1418810969 M * Ghislain i really do not like systemd as it seems to be. It seems to wanted to be a container system on his own but not as an option, just as core
1418811004 M * Ghislain i can understand it could want to have support for containing system but i cannot understand why this is a core thing and not an option
1418811152 M * Ghislain this can be a cool tool but it clearly want to do the container thing on its own so it will be really hard to make it work with  system like vserver without delegating a lot of the security to systemd meaning to the guest
1418811198 M * Bertl check out uselessd, it might soon be a viable, lightweight replacement
1418811499 M * beng_ are people having the practical trouble with systemd? I'm running servers on Debian Jessie and not seeing any boot issues
1418811551 M * beng_ the system is not booting with systemd though
1418811560 M * beng_ I don't need it to
1418811719 M * Bertl I'm pretty sure people have all kinds of trouble with systemd :)
1418811781 M * beng_ surely, but not me with my Debian Jessie guests
1418811803 M * Bertl good to hear :)
1418811816 M * beng_ I'm asking because I want to see some errors that people are having
1418811831 M * beng_ I've heard a lot of wingeing, but no pastebin
1418811858 M * Bertl I think most problems arise from the fact that out of the box guest installs do not work when they are systemd based
1418811882 M * Bertl and as nobody (except lennart) really knows why systemd fails, it isn't that simple to fix
1418811892 M * Ghislain mainly nothing works when using systemd as innit in a guest
1418811944 M * Ghislain you nedd to give it admin rights, device creation rigths etc.. and even with that i was not able to make it work and had hard time having any error message
1418811945 M * beng_ I don't appear to have any trouble not using systemd on my jessie guests
1418811955 M * Ghislain you miss the point
1418811975 M * beng_ no I understand, I've not tried to create a jessie guest from scratch yes
1418811984 M * Ghislain we try to make it work, of course it works not to use it, the point is to make it work :p
1418811985 M * beng_ I'll try soon
1418812019 M * Ghislain i spend only a few hours trying it then murphy sms me about issues so i had to switch but...
1418812022 M * beng_ sure Ghislain, I do also understand peoples frustration with systemd
1418812074 M * Ghislain i understand its use, what i do not understand is why it has no bult in way to work in container, not like it was created in a era that know nothing about those and vserver and lxc and docker etc...
1418812107 M * beng_ have we bugs in progress with the major distros about this?
1418812117 M * beng_ filed bugs?
1418812128 M * fback Ghislain: with sysvinit, vserver build script disables all the init scripts but the few needed
1418812136 P * undefined 
1418812151 M * fback Ghislain: you have to do the same with systemd units by hand
1418812155 M * Bertl it is claimed that systemd works inside a container, but it seems that it only works inside containers it created
1418812190 M * Ghislain hard to fill bugs when the first requirement is: give the container sysadmin rigth..well you ask me to loose all security of the continer then why use one ?
1418812198 M * Bertl but as debugging systemd is a major PITA, nobody worked on that (yet)
1418812210 M * Ghislain bertl: it works if you give it all the host rights, well allmost all
1418812232 M * Ghislain yes it is i had not any success  having an error reported to me
1418812259 M * beng_ having to give the host all rights to install a system is most certainly a bug
1418812285 M * Bertl well, you can discuss that with Lennart ... good luck :)
1418812296 M * beng_ if there are no existing bugs, I'll at least file a few for Debian
1418812306 M * Ghislain will try again as soon as i will have time but for now this do not work for me :( , beng_: their page state this mknod and sysadmin right are necessary
1418812340 M * beng_ where's the page Ghislain?
1418812406 M * beng_ "it works fine, just give every container complete control of your system"
1418812415 M * beng_ that's not an actual quote
1418812598 M * beng_ Ghislain, which page is this that says to use sysadmin?
1418812836 M * beng_ TBH, my  feeling with this is that we shouldn't have to be fixing their init system to work with our containers, that should be their job. Debian has shown willing in the past to make fixes allowing the correct building of containers, I don't see why they would drop this now
1418812870 M * beng_ hope uselessd project comes on quickly
1418813183 M * Ghislain http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/
1418813218 M * Ghislain Do not drop CAP_MKNOD from the container., Do not drop CAP_SYS_ADMIN from the container.
1418813705 M * Ghislain beng_: agreed this container part should be an option not a core forced feature
1418813797 M * beng_ that page has irritated me, feels like its saying that if you aren't doing their prescribed take on containers, you aren't doing them right
1418813845 M * beng_ not sure what we can do with an attitude like that
1418813915 M * beng_ well next stage for me is to try this all out
1418813963 M * beng_ I'll have a go at getting Debiam Jessie installed
1418814101 M * beng_ Bertl, do you have patches for any newer kernels in the works?
1418814160 M * Bertl yes, still work in progress
1418814266 Q * PowerKe Quit: Reconnecting
1418814277 J * PowerKe ~tom@d54C6A573.access.telenet.be
1418814345 M * beng_ which kernels are you working on Bertl ?
1418814381 M * Bertl 3.18 currently
1418817723 Q * sannes Ping timeout: 480 seconds
1418818105 Q * Aiken Remote host closed the connection
1418818247 A * ard uses systemd-shim and sysv-core
1418818263 M * ard as none of my systems are bootable with systemd
1418818285 M * ard as systemd has it's own opinion about the /etc/fstab file
1418818360 M * ard And of course systemd can't handle LABEL=.... in the fstab, and it can't handle /dev/disk/by-label since udev has not been started at that time
1418818449 M * beng_ this is for your vserver guests ard, or hosts too?
1418818456 M * ard for my arm environment I use a home build lxc, since debian lxc more or less requires systemd, which can not be used for booting
1418818461 M * ard beng_ : just hosts...
1418818477 M * ard on guests I haven't seen systemd, since they mostly are wheezy+backports
1418818508 M * ard or ubuntu 14.04 which work flawlesly right now in lxc
1418818517 M * ard so they probably work on vserver too
1418818531 M * beng_ really looking like a hard release cycle for Debian/Ubuntu
1418818541 A * ard had a rough time installing ubuntu a few years back
1418818544 M * ard due to upstart
1418818561 M * ard But upstart is now pretty stable...
1418818578 M * beng_ but they are dropping it for systemd
1418818594 M * ard Yes, next year...
1418818601 M * ard 14.04 will be there a long time
1418818616 M * ard and when that needs to be upgraded, we have uselessd
1418818620 M * ard :-)
1418818639 M * beng_ I'm hoping I can hold out until there's a less intrusive system for sure
1418818642 M * ard or maybe systemd then finally is a bit stable and better behaved
1418818653 M * ard sysv-core is installable...
1418818669 M * beng_ it's really not looking like systemd is progressing to being better behaved
1418818677 M * ard on jessie you don't need to run systemd, but you must be very careful to always install sysv-core
1418818687 M * beng_ top tip ard, thanks
1418818709 M * ard I got 3 systems hosed like that... do an upgrade, not paying attentions, and boom, not bootable anymore
1418818719 M * beng_ sysvinit-core do you mean?
1418818727 M * ard yes, I think so
1418818732 M * ard sysvinit-core and systemd-shim
1418818879 M * ard systemd-shim will install a cgroup manager thing, which is incompatible with the debian build lxc.
1418818915 M * ard the debian lxc maintainer and the cgroup manager maintainer and upstream lxc maintainer have differing opinions
1418818916 M * beng_ so basically Debian arm doesn't upgrade safely to Jessie at the moment?
1418818931 M * ard It does I think...
1418818939 M * ard just make sure about the sysvinit-core
1418818951 M * ard I had to unplug my emmc, and fix it in another arm...
1418818979 M * ard or did I boot with bin/bash
1418819007 M * beng_ "the debian lxc maintainer and the cgroup manager maintainer and upstream lxc maintainer have differing opinions" - I have honestly never known such a mess around something so fundamental as an init system in the Linux community
1418819008 M * ard fortunately this ARM has a real serial console
1418819032 M * ard debian lost 4 good people on the systemd debacle
1418819047 M * ard 2 from the pro side, and 2 from the freedom side
1418819268 M * beng_ I hope there's some massive release delay that lets this get a bit more sorted
1418819289 M * beng_ filing bugs for all associated systemd problems is really the start
1418819351 M * ard debian has lost its server touch...
1418819372 M * ard I miss a lot of fcoe utilities...
1418819407 M * beng_ fibre channel?
1418819432 M * ard sshd that get's restarted on every interface that is configured (on a firewall with 100 interfaces...)
1418819440 M * ard fibre channel over ethernet
1418819456 M * ard if you use the vn2vn version it is very lightweight
1418819466 M * ard especially compared to iscsi...
1418819499 M * ard the fcoe initiator is created by echoing the name of the nic somewhere in /sys
1418819507 M * beng_ so for example this package  is not in jessie: https://packages.debian.org/sid/fcoe-utils
1418819518 M * ard well, it wasn't :-)
1418819527 M * ard it is not in jessie
1418819533 M * ard and that package is I think very old
1418819572 M * ard and it is only available for m68k ...
1418819600 M * beng_ is this a complaint? "sshd that get's restarted on every interface that is configured (on a firewall with 100 interfaces...)" - surely that's easy to change?
1418819617 M * ard personally I am a bit hesistant to become a debian-maintainer...
1418819636 M * ard yes, you have to just enter exit 0; in some if-up.d/ script
1418819679 M * ard restarting is only necessary if you bind sshd to certain ip addresses, so it is not totally stupid
1418819697 M * beng_ if you do have packages available you want distributing, I have a repo you can use to host
1418819699 M * ard but if you bind to 0.0.0.0, you don't need the restart
1418819722 M * beng_ sure
1418819745 M * beng_ but binding to 0.0.0.0 breaks vserver, amongst other things
1418819749 M * ard I was considering setting up a repo myself...
1418819757 M * ard not on my installations ;-)
1418819765 M * beng_ how come?
1418819779 M * ard https://github.com/ardje/tem-vserver
1418819792 M * ard I use network namespaces...
1418819806 M * ard so the host and the vservers already have split ip stacks
1418819838 M * ard on some installations I use a shared ip stack per DMZ, but the host is like an out-of-band management thing
1418819877 M * beng_ good setup, I still haven't tried network namespaces, despite their availability for some time
1418819916 M * ard Well, the thing is, there are 1000 ways to rome, but you all have to implement them yourself :-).
1418819953 M * ard my current scripts assume always a 2 vserver setup, with the second vserver having an ip +1 of the first.
1418819959 M * beng_ shame, would be good to have them an OOTB option
1418819969 M * ard mac addresses are generated from the ip
1418819990 M * ard you can use that package...
1418820004 M * ard But it still needs a lot of work
1418820019 M * ard it does run production however...
1418820101 A * ard has a firewall inside a vserver
1418820112 M * ard working, complete with ipvsadm and such
1418820194 M * beng_ :)
1418820195 M * ard and let's not forget, with l2 failover ;-)
1418820201 M * beng_ also :)
1418820242 M * ard I just create vrrp-gw devices configured and all, and when a failover occurs I just up the devices....
1418820265 M * ard combine that with ipv6 radvd, and all switches are updated with the new location of the mac address :-)
1418820598 M * beng_ I've not used radvd, looks useful
1418820893 M * ard beng_ : what do you use to make debian repositories?
1418820918 M * ard Of course I want something easy, but it never is :-)
1418820968 M * ard I have to serve armhf for exynos5 and for exynos4, amd64 and all, for trusty, wheezy and jessie
1418820983 M * beng_ reprepro
1418821023 M * beng_ it's relatively easy, pretty much create one file to spec the repo, then start adding package
1418821044 M * beng_ getting the signing right it probably the hardest bit
1418821169 M * beng_ https://wiki.debian.org/SettingUpSignedAptRepositoryWithReprepro
1418821201 M * ard So I can say wheezy-odroid and then aptitude install -t wheezy-odroid ...armsoc
1418821203 Q * fstd Remote host closed the connection
1418821213 M * ard to install a working x11 armsoc driver?
1418821221 M * ard sounds good :-)
1418821244 J * fstd ~fstd@xdsl-84-44-221-131.netcologne.de
1418821261 M * beng_ yes repos can be called whatever, I use a wheezy-internal type one, which through apt pinning means it's easy to get Debian to choose my own packages over theirs
1418821300 M * ard beng_ : you just made my debian experience a little less dreadful.. thanks!
1418821323 M * ard (as all distributions suck, debian sucks less, but now even more less...)
1418821343 M * beng_ I agree with that statement wholeheartedly
1418821358 M * beng_ well, sort of
1418821375 M * beng_ I'm backing down form the wholeheartedness
1418821389 M * ard well, if you are the positive kind of guy, you would have said that debian is the best 8-D
1418821469 M * beng_ I'm really holding back on judgement until this init system stuff is sorted
1418821544 M * beng_ but in terms of appraisal of OS, the degree of lack of suck is much better measure than greatness
1418821550 M * Guy- it's remarkable how quickly they went from "systemd is supported, but is just one possible choice" to "systemd is the default on new installs" to "alternative init systems are not supported"...
1418821567 M * beng_ indeed
1418821584 M * beng_ the current situation cannot be stable
1418821588 M * ard wait, what? alternatives are not supported?
1418821618 M * beng_ that's not quiet the wording of the resolution is it?
1418821626 M * beng_ quite
1418821661 M * ard I thought, that alternatives are more or less supported, unless you want to run dramas like gnome3
1418821682 M * ard would be fun to install gnome3 just to see my system refuse to boot
1418821730 M * ard maybe procd and netifd from openwrt should just be packaged and used ;-)
1418821756 M * ard As the network department of debian needs a major overhaul...
1418821767 M * beng_ the trouble for me is that I don't want to be waiting to see if  Uselessd and Devuan prove fruitful before I strategise the next 5 years
1418821798 M * ard I think sysvinit-core will be very long supported in server environments
1418821816 M * beng_ good
1418821823 M * ard if not, alternate repos will pop up, like in a week http://debian.kwaak.net/ or so :-)
1418821842 M * beng_ 503 Service Unavailable
1418821844 M * ard desktop is a little different
1418821852 M * ard I said in a week!
1418821874 M * beng_ I'm so impatient!
1418821880 M * ard you just told me reprepro... i am not that fast, and I still need to fix a HA openvpn in a vserver solution (with ipv6)
1418821914 M * ard currently actually busy to make handing out .ovpn files easier
1418822140 J * derjohn_mob ~aj@firewall01.talentformation.kunden.net-lab.net
1418824026 Q * Guest1402 Quit: Ex-Chat
1418825160 N * Bertl Bertl_oO
1418825945 J * undefined ~undefined@00011a48.user.oftc.net
1418826382 Q * derjohn_mob Ping timeout: 480 seconds
1418826855 M * glen any ideas why kernel which supposed to have vserver support says enosys?
1418826856 M * glen http://sprunge.us/OheZ
1418826864 M * glen http://sprunge.us/JejE
1418826902 M * glen http://sprunge.us/ddIb
1418827173 M * undefined glen: got a patch
1418827176 M * undefined and a test case
1418827184 M * undefined need you to try it, but it should work
1418827211 M * undefined (about to test 3.14.27 right now)
1418827220 M * undefined but i have 3.14.26 working
1418827257 M * glen undefined: but arekm said he got 3.14 working
1418827259 M * undefined http://archives.linux-vserver.org/201412/0001.html
1418827272 M * glen http://sprunge.us/PBAZ
1418827277 M * undefined yes, i have 3.14 working
1418827302 M * glen so just 3.14.27 is problematic?
1418827308 M * undefined no
1418827312 M * glen i mean 3.14.19
1418827323 M * undefined anything >= 3.14.19
1418827333 M * glen but my testcase is 3.14.19 and it fails
1418827341 M * glen ah =
1418827356 M * glen but then again, arekm has 3.14.22 and works for him
1418827389 M * glen so, i should try the same 3.14.22 kernel arekm is using?
1418827403 M * undefined it appears you have the "remove caps" problem which was introduced in 3.14.19
1418827436 M * undefined you should use whatever works for you (arekm's or otherwise), but i what i detail in that email (link provided above) is what works for me
1418827464 M * glen ok. i'll try latest 3.14 which i have available
1418827497 M * undefined i'm about to test 3.14.27, but it at least didn't have any new patch failures or compilation failures
1418827522 M * glen i will go likely with 3.14.26
1418827545 M * glen so the problem was fixed by this pathc? http://git.pld-linux.org/?p=packages/kernel.git;a=commitdiff;h=02242d31f3d4c0b3c01b295dfc66ecab2637228b
1418827691 M * undefined yes, which looks strangely identical to http://archives.linux-vserver.org/201410/att-0050/patch-3.14.17-19-remove_caps-vs2.3.6.13.diff which is what is linked to in the email
1418827951 J * derjohn_mob ~aj@tmo-108-92.customers.d1-online.com
1418828376 M * undefined 3.14.27-vs2.3.6.13 tested out fine
1418828467 M * glen undefined: are you undefined@pld ? or some other undefined?
1418828479 M * undefined i'm undefined@pobox.com
1418828488 M * undefined (like in the email i referenced)
1418828504 M * glen this probably means you are not undefined from pld...
1418829845 M * undefined 3.10.63-vs2.3.6.8 tested out fine too
1418832408 J * derjohn_mobi ~aj@tmo-110-143.customers.d1-online.com
1418832497 Q * derjohn_mob Ping timeout: 480 seconds
1418836619 J * bonbons ~bonbons@2001:a18:22e:fb01:84d8:b392:6ffe:deb6
1418838849 Q * derjohn_mobi Read error: Connection reset by peer
1418839542 Q * beng_ Remote host closed the connection
1418840059 J * derjohn_mobi ~aj@firewall01.talentformation.kunden.net-lab.net
1418844713 Q * Ghislain Quit: Leaving.
1418844845 J * Aiken ~Aiken@pa49-182-29-246.pa.nsw.optusnet.com.au
1418847547 M * Guy- ard: well, non-systemd init isn't a first-class citizen anymore; for example, you can't install a debian system using debootstrap without systemd unless you patch debootstrap
1418847702 Q * derjohn_mobi Ping timeout: 480 seconds
1418850790 J * Hayro ~Hayro@195.142.230.52
1418851021 Q * bonbons Quit: Leaving
1418859652 J * tootsie_roll ~tootsie_r@149.154.67.28
1418859870 Q * tootsie_roll autokilled: Do not spam. mail support@oftc.net  (2014-12-17 23:44:30)