1451781653 Q * dcentral Ping timeout: 480 seconds 1451782743 Q * fstd Remote host closed the connection 1451782754 J * fstd ~fstd@xdsl-87-78-18-246.netcologne.de 1451786581 J * derjohn_mobi ~aj@x590d9365.dyn.telefonica.de 1451787023 Q * aj__ Ping timeout: 480 seconds 1451792228 J * cryptonight ~cryptonig@123.108.108.143 1451792444 M * cryptonight Hi all, can anyone be so kind and point me where i can get the older vserver+grsec patch ? (i believe from 15 sep on grsec went completely commercial :() 1451793817 M * Bertl_oO the patches should be still linked on the main page 1451793877 M * Bertl_oO note that they are quite old though 1451793941 M * Bertl_oO http://people.linux-vserver.org/~harry/?C=M;O=D 1451794401 M * cryptonight thanks you Bert ! i've been there and also a few other places and seems the latest vserver+grsec is 3.2.63 but i'm guessing that kernel won't work on debian jessie 1451795061 M * Bertl_oO well, unfortunate but I see why they ended up there ... 1451795162 M * cryptonight it seems some big corporations used their work without paying them 1451795169 M * cryptonight so now everyone else has to suffer the consequences 1451795198 M * Bertl_oO well, it seems to be a little more complicated 1451795207 M * Bertl_oO https://grsecurity.net/announce.php 1451795272 J * dcentral ~IGLC@206.251.40.170 1451795307 M * cryptonight i read it i thought it boils down to that, abuse of grsecurity trademark and usage of their work against the gpl license and they never donated a dime to them :( 1451795354 M * Bertl_oO I think the GPL was not really violated, more the trademark with using sub-standard quality patches 1451795397 M * Bertl_oO the problem here is, while I understand the reasoning behind it, there doesn't seem to be a real legal issue here 1451795407 M * cryptonight oh ok 1451795432 M * Bertl_oO they took one of the "old" and incomplete patches and applied them to their kernel (without modification) 1451795447 M * Bertl_oO and now they "claim" to have a grsec hardened kernel ... 1451795471 M * Bertl_oO (which is not wrong per se, just that it is not really up to the task) 1451795531 M * cryptonight but then they simply should publish it on grsec website that company X is using an incomplete patch etc so people know it's not something done by grsec team i'd guess 1451795571 M * Bertl_oO it seems they decided to go to court instead, and failed at some point 1451795587 M * cryptonight yeah lots of money involved to go against evil corp 1451795596 M * Bertl_oO and now they are fed up and decided to not give away new patches anymore 1451795635 M * Bertl_oO not sure this is not at some point a violation of the (kernel) GPL now though 1451795646 M * cryptonight then it's weird that they expect still people to use the test patch and provide them with feedback to make it later commercial 1451795672 M * Bertl_oO because if they have a "product" where they hand out the patch or a patched kernel, then the customer is entitled to the source (of course) 1451795688 M * cryptonight using the community for testing the test patch for free to put that energy into their commercial part, really disappointing :( 1451795694 M * Bertl_oO and as the source is naturally GPL, it can be freely published (note IANAL) 1451795706 M * cryptonight i agree 1451795720 M * Bertl_oO so, all which would be required is one commercial customer who releases the patches to the public 1451795782 M * cryptonight isn't there some kind of gpl organisation which can check this ? 1451795797 M * cryptonight (i'm not that deeply familiar with gpl and who writes the rules etc) 1451795903 M * Bertl_oO the FSF (or FSFE) is the authority for such things 1451796151 M * cryptonight if you were them, how would you solve it ? just thinking of the whole situation myself, donating is no problem, but still how to deal with those evil corps 1451796182 M * Bertl_oO we had a similar problem with debian (as funny as it sounds) 1451796209 M * Bertl_oO i.e. they used outdated tools and refused to fix the problems resulting from those tools 1451796215 M * cryptonight ahh 1451796237 M * Bertl_oO we simply decided to post a clear statement that those tools should be avoided 1451796254 M * Bertl_oO and that nobody should complain to us about problems caused by those tools 1451796270 M * cryptonight yeah that's what i would have done if i was grsec 1451796271 M * Bertl_oO at some point, the tools got removed from debian and the issue was resolved 1451796296 M * cryptonight why go through all this if they can make a clear statement 1451796307 M * Bertl_oO now a few folks are maintaining tested packages for debian and everything works like a charm 1451796427 M * cryptonight that's good ! 1451803810 M * cryptonight Bertl_oO, do you recommend the stable or testing vserver utils if used on debian 8 ? thank you 1451806002 Q * dcentral Quit: Leaving 1451807998 M * Bertl_oO for debian you are probably best off with the packages from beng (latest are the best) 1451808854 M * cryptonight thank you 1451808971 M * Bertl_oO you're welcome! 1451809020 M * cryptonight btw, does the guest require sysv too ? just did a test with a new basic guest and default is systemd, didn't notice yet an issue 1451809068 M * Bertl_oO usually systemd refuses to start properly in a Linux-VServer guest 1451809090 M * Bertl_oO (because it wants too many capabilities and control over the cgroup system) 1451809256 M * cryptonight hmm this basic guest started without issues but i do notice some errors when stopping the guest, like this: 1451809292 M * cryptonight Failed to read /proc/cmdline. Ignoring: No such file or directory 1451809303 M * cryptonight Failed to reboot: No such file or directory 1451809339 M * cryptonight [FAIL] startpar: service(s) returned failure: reboot .../usr/local/share/util-vserver/vserver.stop: line 100: 5628 Killed "${IONICE_CMD[@]}" "${NICE_CMD[@]}" "${NETNS_CMD[@]}" "${CHBIND_CMD[@]}" "$_VSPACE" --enter "$S_CONTEXT" "${OPTS_VSPACE[@]}" "${OPTS_VSPACE_SHARED[@]}" -- "$_VTAG" --migrate "${OPTS_VTAG_ENTER[@]}" --silent -- $_VCONTEXT $SILENT_OPT --migrate $OPT_VCONTEXT_CHROOT --xid "$S_CONTEXT" -- "${INITCMD_STOP[@]} 1451809348 M * cryptonight is this anything to worry about ? 1451809376 M * Bertl_oO well, it doesn't look like systemd to me 1451809378 M * cryptonight (i mean it stops and starts fine, just when stopping or rebooting this basic guest it shows those errors) 1451809401 M * Bertl_oO try to start it, then enter it (or ssh into it) and see if systemctl works 1451809422 M * cryptonight i seems to think i want to reboot it while i simply tell it to stop 1451809427 M * cryptonight ok 1451809479 M * cryptonight hmm, when i execute systemctl it shows: 1451809481 M * cryptonight Failed to read /proc/cmdline. Ignoring: No such file or directory 1451809481 M * cryptonight Failed to get D-Bus connection: Unknown error -1 1451809513 M * undefined cryptonight: the missing /proc/cmdline issue was discussed here on 2014-11-28, 2015-08-24, and 2015-10-12/2015-10-13 1451809519 M * Bertl_oO so the next check is to look for a systemd process 1451809598 M * cryptonight you mean like install in the basic guest ssh for example and try to use systemctrl to control it ? 1451809624 M * cryptonight btw, is undefined a bot ? 1451809629 M * undefined hehehe 1451809638 M * undefined no, just somebody with searchable irc logs 1451809639 M * cryptonight lol ok i guess not 1451809656 M * undefined and a good memory for previous discussion topics 1451809666 M * cryptonight ah nice :) 1451809675 M * Bertl_oO congrats undefined! I also got bot status some years ago :) 1451809691 M * cryptonight looks like /proc/cmdline exists in the host but not in the guest 1451809713 M * undefined to be put in the same category as Bertl_oO is the ultimate compliment 1451809752 M * undefined cryptonight: this channel's irc logs are at http://irc.13thfloor.at/LOG/ 1451809791 M * cryptonight nice, i'll check 1451809821 M * cryptonight on the same note, i installed ssh but it's not starting, doesn't give any error 1451809841 M * cryptonight 13thfloor was a really good movie btw 1451809848 M * cryptonight still have to read the book :) 1451809848 M * Bertl_oO yes, indeed 1451809926 M * cryptonight didn't know it was based on the book simulacron from 1964 :) 1451810013 M * Bertl_oO you are lucky to know the movie, most folks do not know that either ... so knowing the book it is based on, makes you special :) 1451810047 M * cryptonight lol, i'm surprised how many movies / series last few years are based on good books 1451810068 M * cryptonight it looks like there is no more creativity and they have to feed off from the past of excellent authors hehe 1451810090 M * cryptonight not that i mind if it's a well done movie / serie 1451810697 M * cryptonight looks like i need to create some dummy bind to pass as /proc/cmdline 1451811006 M * cryptonight is this the correct way to, for testing, to create the file vprocunhide with -/proc/version in it ? 1451811047 M * cryptonight i mean + since - probably disables it 1451811176 M * cryptonight copied it from /usr/local/share/util-vserver/defaults/vprocunhide-files 1451811179 M * cryptonight i'll give it a try 1451811570 M * cryptonight got it 1451811612 M * cryptonight created dir vprocunhide put files in it with /proc/cmdline and restarted vprocunhide script then guest so /proc/cmdline shows up now 1451811740 M * cryptonight when trying to start ssh using systemctrl start ssh it shows this: Failed to get D-Bus connection: Unknown error -1 1451811768 M * cryptonight for the record, i prefer sysv , don't see much in systemd to be honest when it comes to non-desktop systems 1451811866 M * Bertl_oO yeah, I'm pretty sure you don't have systemd running properly in the guest 1451811888 M * Bertl_oO I would suggest to switch to sysv and just have the services started you want/need 1451811957 M * cryptonight exactly what i was thinking lol, i dropped systemd from the host to sysv so i guess it's best to use sysv also in the guest 1451812397 M * cryptonight Bertl_oO, just to confirm, it system if the host is on sysv then the guest must also be sysv ? (pid 1 init is shown in guest) 1451812427 M * cryptonight (ignore "it system" in above sentence) 1451812456 M * Bertl_oO no, guests are pretty independant from the host 1451812479 M * Bertl_oO but if you run the guest as sysv, it will get a "fake" blend through init process 1451812492 M * cryptonight hmm ok, the reason i ask is this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763299 1451812507 M * Bertl_oO if you configure it as "plain" then it will get its own init 1451812600 M * Bertl_oO as I said, I doubt that you have been running systemd inside the guest successfully 1451812612 M * cryptonight ok, but in this case, a brand new debian 8 guest with systemd seems to not work properly, did i maybe miss some step ? 1451812682 M * Bertl_oO unless something has changed significantly in systemd (in recent debian) it won't even start inside a properly configured guest (i.e. without giving excessive priviledges to the guest) 1451812712 M * cryptonight ahh ok 1451812724 M * cryptonight because i didn't do anything yet with privileges 1451812732 M * cryptonight so i guess that is the problem :) 1451812757 M * cryptonight dear old sysv for me :) 1451812810 M * Bertl_oO in a guest that is way better anyway, as you can save all the unnecessary overhead and make the guest really light 1451812825 M * cryptonight i really hope sysv will remain as an option for the future, can't see systemd (judging by all the hits in google) be the only thing to be 1451812854 M * Bertl_oO there is Devuan :) 1451812868 M * cryptonight my first thought when systemd came in the picture was "why in godsname deploy such beast instead of improving sysv ?" 1451812880 M * cryptonight ahh yes, read about Devuan somewhere ! 1451812904 M * Bertl_oO systemd is probably fine for your laptop, but I doubt that it makes much sense on a server 1451812942 M * Bertl_oO but as distros are lazy, they don't want to maintain two (or even more) init solutions 1451812950 M * cryptonight exactly, it's just nuts to me and i hardly understand much of systemd to be honest 1451812984 M * cryptonight bookmakred Devuan under "when shtf" :) 1451813028 P * undefined 1451813070 J * undefined ~undefined@00011a48.user.oftc.net 1451813353 M * cryptonight thanks alot for the help ! gotta go grab a bit of sleep but will hangout some more here, been too long away from irc :) 1451813372 M * Bertl_oO you're welcome! have a good sleep 1451813381 Q * cryptonight Quit: thanks ! 1451813568 M * Guy- Bertl_oO: I can reproduce the 'vps only shows MAIN, itself, and vserver enter processes' on more than one box with 4.1+vserver 1451813661 J * bonbons ~bonbons@2001:a18:22e:7701:e99c:b701:745a:13d5 1451813741 M * Bertl_oO are pid namespaces enabled? 1451822658 J * Ghislain ~aqueos@adsl1.aqueos.com 1451823827 J * bsukfh ~abcdef@41.34.80.88 1451823929 M * bsukfh ? 1451823929 M * bsukfh . 1451823931 M * bsukfh . 1451823931 M * bsukfh . 1451823933 M * bsukfh . 1451823933 M * bsukfh .did usa intel supply isis with weapons like they did with al-qaeda to justify creating wars? 1451823935 M * bsukfh does the breakout of wars and violence in the middle east represent creative chaos usa declared to make in the middle east? 1451823935 M * bsukfh iraq&syria suffered too much.plz,send others my qs ,help to limit usa&israel aggression against others. 1451823964 Q * bsukfh Killed (MoranServ (Possible spambot -- mail support@oftc.net with questions.)) 1451824044 M * Guy- Bertl_oO: yes, pid namespaces are enabled 1451824078 M * Bertl_oO that might be the reason, try to disable them 1451824089 M * Bertl_oO off to bed now ... have a good one everyone! 1451824094 N * Bertl_oO Bertl_zZ 1451825411 M * Guy- Bertl: fwiw, I have CONFIG_PID_NS enabled in 3.18.7-vs2.3.7.4 as well and vps works as expected there, so even if the problem is related to CONFIG_PID_NS, it's a regression 1451825943 Q * fstd Remote host closed the connection 1451825955 J * fstd ~fstd@xdsl-87-78-80-77.netcologne.de 1451833810 Q * FireEgl Read error: Connection reset by peer 1451834711 Q * derjohn_mobi Read error: Connection reset by peer 1451834831 J * FireEgl ~FireEgl@173-23-76-11.client.mchsi.com 1451835659 J * derjohn_mob ~aj@x4db11e4b.dyn.telefonica.de 1451854610 N * Bertl_zZ Bertl 1451854612 M * Bertl morning folks! 1451854637 M * Bertl Guy-: a regression or a feature :) 1451854664 M * Bertl the main question is if the pid namespace is unshared or not 1451855628 M * Guy- Bertl: I didn't do anything explicit to it 1451855751 M * Bertl before we dive into the details how/why the pid namespace is unshared, let's verify that this is actually the issue at hand, i.e. disable pid namespaces for the kernel and see if that fixes the issue 1451855787 M * Bertl if it doesn't fix it, it's a mood point anyway 1451855861 M * Guy- will do, but not today 1451855901 M * Guy- Bertl: if that were the problem, wouldn't vtop also be affected? 1451855922 M * Guy- because vtop shows all processes (apparently), but vps doesn't 1451856007 M * Bertl indeed, so the ps got "broken"? 1451856016 M * Guy- yes 1451856025 M * Bertl (because top should use the same interface than ps) 1451856064 M * Bertl maybe strace -fF ps inside context 1 then and see where it drops or misses the other processes? 1451856159 M * Guy- Bertl: I can see it find one of the processes in question and there are no obvious errors, so I don't know why it doesn't print it 1451856203 M * Guy- Bertl: http://sprunge.us/DENh 1451856207 M * Guy- this is the relevant part of the strace 1451856243 M * Bertl so that one is not shown yes? 1451856322 M * Bertl which means you have to dig into the source of ps to figure out why it is dropped after all the relevant data has been retrieved from /proc 1451856423 M * Guy- yuck 1451856553 M * Guy- Bertl: OK, it's the 'f' in ps axfu 1451856575 M * Guy- with just vps axu, I see the process; with vps axfu, I don't 1451856699 M * Guy- so it's probably something with the ppid 1451856843 M * Guy- it's not that it can't find the ppid 1451856941 M * Bertl well, we can agree that it is not the kernel which hides information, it is userspace (ps in particular) which considers the data not relevant or unsuitable for full format printing 1451856957 M * Guy- OK I think I have it 1451856994 M * Guy- comparing the output of vps axo user,pid,ppid,comm on 4.1 with 3.x, the difference seems to be that in 3.x, the ppid of the init processes in guests is 1, whereas with 4.1 it's itself 1451856999 M * Guy- e.g. 1451857003 M * Guy- USER PID CONTEXT PPID COMMAND 1451857008 M * Guy- root 26828 25 mail 26828 runit 1451857011 M * Guy- vs. 1451857018 M * Guy- root 7968 271 tracsvn 1 runit 1451857031 M * Guy- I think this is what confuses vps axfu 1451857207 M * Guy- Bertl: any idea why the kernel would report a different PPID for a guest init in 4.1 than in 3.x? (both have PID namespaces enabled, fwiw) 1451857470 M * Bertl you are testing on the same machine, i.e. with identical toolchains and configuration? 1451857539 M * Guy- no and yes 1451857552 M * Guy- they're different machines but both run current debian sid 1451858181 Q * sannes Quit: Leaving. 1451859038 M * Guy- also, in a sense I'm tring on the same machine because vps axfu used to work on the machines that run 4.1 now when they ran 3.x 1451859053 M * Guy- (but I can't easily reboot them into 3.x just now) 1451859132 M * Bertl well, the 4.1 ppid looks okay to me, as the "init" process doesn't have a parent 1451859197 M * Bertl the difference between 3.x and 4.x could be due to a fix in the kernel 1451859279 M * Bertl the problem I see is that ps should at least provide a switch/option to show all the acquired data instead of silently dropping the information 1451860331 M * daniel_hozac f is supposed to forest it though, and i guess that becomes a leaf node disconnected from the rest of the tree. 1451860350 M * daniel_hozac sounds like some initpid stuff might be missing. 1451860375 M * daniel_hozac are you using plain init with runit as the init? 1451860384 M * daniel_hozac or is runit just a service in your guest? 1451861518 M * Guy- daniel_hozac: plain init, with runit as the init in the guest 1451861626 M * daniel_hozac so sounds like it's something with the initpid virtualization. 1451861888 M * Bertl there is no init pid virtualization in the spectator context 1451861940 M * daniel_hozac yeah, but the inits should have the host's init as the parent. 1451861997 M * daniel_hozac so the setup of the guest init isn't right. 1451862005 Q * Ghislain Quit: Leaving. 1451862266 M * Guy- Bertl: yes, the guest init process certainly has a parent (the host init process, once the 'vserver start' process that spawns it exits) 1451863609 J * cryptonight ~cryptonig@00021703.user.oftc.net 1451863625 M * cryptonight hi all :)