1143937072 J * matt1 ~matta@c-68-32-202-140.hsd1.pa.comcast.net 1143937490 Q * matta Ping timeout: 480 seconds 1143937786 J * Gerden ~Danger@20150151196.user.veloxzone.com.br 1143937789 P * Gerden 1143938516 J * ray6 ~ray@vh5.gcsc2.ray.net 1143938527 M * ray6 reee 1143939267 Q * ivan_w Quit: -- Bye bye .. I Will return ! 1143940847 J * matta ~matta@c-68-32-202-140.hsd1.pa.comcast.net 1143941085 N * Bertl_oO Bertl 1143941089 M * Bertl back now ... 1143941139 M * ray6 reee Bertl :) 1143941281 Q * matt1 Ping timeout: 480 seconds 1143942531 M * Bertl daniel_hozac: any results regarding 'adjusting' shiny9 for x86_64 and new gcc? 1143942730 M * daniel_hozac Bertl: no, sorry, i've been focused on other issues with that box. 1143942742 M * Bertl np 1143942780 M * Bertl do you know what scheduler interface 0.30.210 is supposed to use? 1143942809 M * daniel_hozac v3. 1143942892 M * Bertl I'm just wondering because it doesn't seem to set the mask properly, or something else fails 1143942987 M * daniel_hozac hmm, it should set it correctly. 1143943014 M * daniel_hozac but the syscall wrapper does some funky things to determine if the structures are identical, i guess that could be failing. 1143943147 M * Bertl nah, seems to be a strange issue in the kernel ... will investigate 1143943377 M * Bertl ah, found it ... 1143943999 M * Bertl daniel_hozac: I assume the rlimit issue is fixed by adding an __attribute__ ((packed)) to the vcm struct 1143944108 M * Bertl but we should probably restructure the interfaces with this issue in mind 1143944149 M * daniel_hozac shouldn't it be as packed as possible already? 1143944175 M * Bertl well, with 32bit at the beginning, and 3 64bit values, I assume x86_64 adds padding 1143944217 M * daniel_hozac ok, i buy that. but how does that explain the value? 1143944250 M * Bertl 0x600000000 ? 1143944261 M * daniel_hozac right. 1143944300 M * Bertl no idea 1143944391 M * daniel_hozac oh, i guess the 6 is part of the 4 bytes immediately after the structure in userspace? 1143944424 M * Bertl hmm, yeah, probably 1143944450 M * Bertl the question is, how should that be addressed atm? 1143944474 M * Bertl I could do a 32bit remapping packed vs unpacked 1143944509 M * Bertl we could just ignore it for now, and have a new (insensitive) structure later? 1143944510 M * daniel_hozac that's rather ugly. 1143944530 M * daniel_hozac couldn't we just add __attribute__((packed))? 1143944532 M * Bertl we could also change it in both kernel and userspace to be packed 1143944548 M * Bertl yeah, but that breaks binary compatibility 1143944555 M * daniel_hozac hmm, yeah, true. 1143944558 M * daniel_hozac that would be bad. 1143944587 M * Bertl I guess the fixup is the only way for now 1143944600 M * daniel_hozac yeah, i guess. 1143944626 M * daniel_hozac how many other structures are affected? have you checked? 1143944697 M * Bertl dlimit requires a fixup because of the pointer 1143944705 M * Bertl (older dlimit that is) 1143944718 M * Bertl but already has it 1143944728 M * daniel_hozac vcmd_vhi_name_v0? 1143944747 M * Bertl iattr_v1 pointer 1143944767 M * daniel_hozac i have no idea how gcc handles structures... 1143944798 M * Bertl net_addr_v0 1143944801 M * Bertl maybe 1143944813 M * Bertl but I guess the 2x16 are padded 1143944832 M * Bertl sched_v2 1143944886 M * Bertl the vhi stuff is clean 1143944907 M * Bertl the types are usually 'type size' aligned 1143944921 M * Bertl i.e. 32bit type, 4 bytes alignment 1143944966 M * Bertl so the rlimit is probably the only one 1143945562 J * mkhl ~mkhl@200.148.40.159 1143945629 M * Bertl wb mkhl! 1143946432 Q * eyck Ping timeout: 480 seconds 1143948688 J * blander5 ~blander5@tor-irc.dnsbl.oftc.net 1143948698 M * Bertl welcome blander5! 1143953229 J * locksy ~locksy@mrtg.sisgroup.com.au 1143953424 M * Bertl welcome locksy! 1143953862 Q * Hollow Quit: SIGTERM 1143956143 M * ray6 n8 :) 1143956174 M * Bertl night ray6! 1143956293 J * eyck eyck@ghost.anime.pl 1143957775 M * Bertl okay, off to bed now ... have a good one everyone ... cya tomorrow! 1143957782 N * Bertl Bertl_zZ 1143960464 J * doener ~doener@i5387FA84.versanet.de 1143960946 J * Smutje_ ~Smutje@xdsl-84-44-185-246.netcologne.de 1143961052 Q * Smutje Ping timeout: 480 seconds 1143961052 N * Smutje_ Smutje 1143962056 Q * softi42 Ping timeout: 480 seconds 1143962537 Q * blander5 Quit: leaving 1143962609 J * softi42 ~softi@p549D628D.dip.t-dialin.net 1143963605 J * cr0n cn@dsl-146-244-23.telkomadsl.co.za 1143965435 J * meandtheshell ~markus@85-125-225-141.dynamic.xdsl-line.inode.at 1143965702 M * cohan is there a "simple", for example proc-basd, interface to vserver stats? 1143965784 J * inflation ~air@tor-irc.dnsbl.oftc.net 1143965810 M * cohan i'd like to check all vservers user- and systime periodically, and times like "5d46h3" and "m10.23" are not very suited for parsing, and not accurate enough for relative measuremnt 1143967005 J * bonbons ~bonbons@83.222.39.180 1143967870 J * Hollow ~hollow@home.xnull.de 1143968069 J * cehteh foobar@cehteh.homeunix.org 1143968908 J * Viper0482 ~Viper0482@p54975B77.dip.t-dialin.net 1143969469 Q * mire Ping timeout: 480 seconds 1143970010 J * mire ~mire@231-166-222-85.COOL.ADSL.VLine.Verat.NET 1143970810 J * DavidS ~david@chello062178045213.16.11.tuwien.teleweb.at 1143971027 M * DavidS hi, vserver suexec accepts a user_name_ without warning and executes the command as root in the vserver ... some might consider that a security hole. this can be traced to atol() usage in src/vcontext.c; opinions? 1143971027 J * _are_ ~are@dslb-084-057-163-105.pools.arcor-ip.net 1143971304 Q * cr0n Quit: 1143971337 M * doener DavidS: you should report that to enrico, he'll probably take care of that ASAP 1143972519 M * DavidS I'll CC him the debian bug report ... 1143973914 M * daniel_hozac DavidS: https://savannah.nongnu.org/patch/?func=detailitem&item_id=4966 1143973998 M * DavidS ah, great... 1143974059 M * daniel_hozac it was also reported as a bug about a month ago, https://savannah.nongnu.org/bugs/?func=detailitem&item_id=15996 1143974455 M * DavidS sent, should arrive at http://bugs.debian.org/util-vserver within the hour ... 1143974946 M * doener daniel_hozac: hm, doesn't make that patch the assumption that you have already chroot'ed? 1143975042 Q * kir Quit: Leaving 1143975050 M * daniel_hozac doener: the chroot happens before the uid is used. 1143975081 M * daniel_hozac but yeah, for when you use --uid and not --chroot, it won't do the right thing. 1143975243 M * doener ah, right the chroot stuff is in there... but maybe the name to uid resolution could be done by some other tool in the chain and have only "vserver" accept names, while vcontext just gets some checks to ensure that the uid is a valid number 1143975309 M * doener the other tool could receive the path to the vserver (or look it up) and use fgetpwent 1143975320 M * daniel_hozac the resolution would have to happen after vcontext. 1143975434 M * doener why? 1143975536 J * lilalinux ~plasma@dslb-084-058-212-129.pools.arcor-ip.net 1143975584 M * doener http://www.13thfloor.at/~doener/vserver/tools/vexec-0.03.c -- resolution happens first 1143975919 M * daniel_hozac i guess the optimal solution would be one that executes id inside the vserver. 1143976074 M * daniel_hozac as that would work even for nss_ldap and such. 1143976586 M * DavidS daniel_hozac: while i agree, that the resolution should happen within the context, I can't image how that should work in a generic fashin (does id/getent exist everywhere?) 1143976654 M * daniel_hozac right, which is why my patch does it sort-of-inside. 1143976924 M * DavidS i would have expected suexec to use "su" from the vserver ... 1143977121 M * daniel_hozac well, if you can't expect id to be present, you can't expect su to be present either :) 1143977518 M * DavidS daniel_hozac: touche :) 1143977564 M * DavidS then it should probably be something in the apps/ config? how-to-{change,map}-uid ? 1143977576 M * DavidS with id/su as good defaults 1143977740 M * daniel_hozac well, you can already use vserver ... exec su ... 1143977770 M * daniel_hozac vserver ... suexec implies it's something that the utils themselves do. 1143977810 M * DavidS then you can't ever resolve a _name_ 1143977826 M * daniel_hozac hmm? 1143977826 Q * shedi Quit: Leaving 1143977905 M * DavidS where is the difference between using lib_nss, reading /etc/passwd or using id/su/getent? 1143977918 M * DavidS (everything from the vserver of course) 1143977958 M * DavidS resolving a name within the vserver without using information (executable or otherwise) from the vserver is impossible ... 1143977973 M * daniel_hozac we can't do the first, parsing /etc/passwd and /etc/group manually when there are already functions to do so invokes the lazyness in me, and the third, well, you can already do that. 1143978004 M * daniel_hozac my patch will use getpwent and initgroups for usernames. 1143978149 M * DavidS i've seen it .. ah, that was the dietlibc ifdef ... preventing to use glibc/nss 1143978179 J * shedi ~siggi@dsl-220-183.hive.is 1143980385 Q * Hollow Remote host closed the connection 1143980417 J * Hollow ~hollow@home.xnull.de 1143980896 J * phedny ~mark@volcano.p-bierman.nl 1143981611 Q * virtuoso Ping timeout: 480 seconds 1143981676 Q * eyck Ping timeout: 480 seconds 1143984128 M * phedny oeh, I found virt_mem, virt_uptime and virt_load 1143984132 M * phedny looks really nice now :) 1143985785 J * yarihm ~yarihm@84-74-23-214.dclient.hispeed.ch 1143986764 J * tek_ ~tek@ADijon-151-1-91-5.w83-196.abo.wanadoo.fr 1143986813 P * tek_ 1143987278 Q * Viper0482 Quit: bin raus, 1143987693 Q * shedi Ping timeout: 480 seconds 1143987701 J * eyck eyck@ghost.anime.pl 1143988267 J * shedi ~siggi@dsl-220-183.hive.is 1143989961 Q * Hollow Remote host closed the connection 1143989996 J * Hollow ~hollow@home.xnull.de 1143990274 M * phedny Hollow: are you the same Hollow as from #wl500g ? 1143990285 M * phedny other network though 1143990290 M * Hollow no 1143990293 M * phedny okay :) 1143990300 M * phedny as he's also from .de :) 1143990457 J * sladen paul@starsky.19inch.net 1143991829 Q * shedi Quit: Leaving 1143992526 J * Skram ~mark@admins.sentiensystems.net 1143992529 M * Skram Anyone around? 1143992542 M * Skram how does vdlimit work? does it take affect when rebooted? is it a hard limit? 1143992551 M * Skram Linux hercules 2.6.14-vs2.0.1-gentoo #1 SMP Fri Feb 3 18:04:56 UTC 2006 i686 Intel(R) Xeon(TM) CPU 3.20GHz GNU/Linux <<-- Box. 1143992749 M * daniel_hozac it's a hard limit. it needs to be re-set after each reboot. 1143992780 M * daniel_hozac but if you put the disk limits in /etc/vservers//dlimits, util-vserver will take care of everything for you. 1143992796 M * daniel_hozac (this, of course, assumes you have util-vserver 0.30.210+) 1143992912 M * Skram * sys-cluster/util-vserver Latest version available: 0.30.210-r6 Latest version installed: 0.30.210-r4 1143992917 M * Skram So I do. 1143992935 M * Skram daniel_hozac: okay, but like.. i set it, and then was able to download a file bigger than the limit? 1143992936 M * daniel_hozac Bertl_zZ: http://daniel.hozac.com/vserver/i386-x86_64-structs.diff looks like you were right. just sched_v2 and rlimits. http://daniel.hozac.com/vserver/check-structs.c created the output 1143992946 M * Skram We are using lvm for /vserver is that okay? 1143992967 M * daniel_hozac sure, as long as the filesystem is mounted with tagxid, everything should work fine. 1143992967 M * Skram and is it true with our current kernel i cant setup swaps? 1143992974 M * Skram tagxid? 1143992978 M * Skram oh, the vps that is? 1143992996 M * Wonka is tagxid necessary with ext3? 1143993008 M * daniel_hozac yes, tagxid is necessary with all filesystems. 1143993019 M * daniel_hozac Skram: what? 1143993021 M * Skram and is it true with our current kernel i cant setup swaps? 1143993029 M * Wonka what badness happens when it's left out? 1143993029 M * Skram I can do RAM hardlimits, will softlimits work? 1143993033 M * daniel_hozac why wouldn't you be able to setup swaps? 1143993042 M * Skram how do I? 1143993044 M * daniel_hozac Wonka: there will be no tagging of files. 1143993048 M * Skram *shrug* 1143993056 M * Wonka daniel_hozac: why is that bad? 1143993056 M * Skram rlimits, right? 1143993057 M * daniel_hozac Skram: oh, you mean limiting it? 1143993061 M * Skram daniel_hozac: yes. 1143993065 M * Skram in each vps 1143993069 M * daniel_hozac Skram: no, there's nothing like that. 1143993086 M * daniel_hozac in devel you have the softlimit that will increase the likelyhood of that guest's pages being swapped out. 1143993088 M * Skram i want to do limiting on RAM, but HARD limits doesnt do the job becuase if it reached the max, it wont let an ssh session spawn. 1143993106 M * Skram daniel_hozac: so only hard limits in.. 2.6.14-vs2.0.1-gentoo ? 1143993114 M * daniel_hozac Wonka: you won't be able to tell which file belongs to which context. 1143993128 M * daniel_hozac Wonka: hence, limiting disk space becomes pretty much impossible. 1143993132 M * daniel_hozac Skram: yes. 1143993140 M * Wonka daniel_hozac: mmh. the vservers only have access to their own directory... 1143993149 M * Wonka daniel_hozac: how would one tag them afterwards? 1143993185 M * Skram daniel_hozac: how do i make sure that vpsxtags or whatever are in effect? 1143993186 M * daniel_hozac Wonka: chxid, but note that this is only relevant if you want disk limits or similar. 1143993215 M * daniel_hozac Skram: what? tagxid? grep tagxid /proc/mounts on the host should do it. 1143993218 M * Wonka daniel_hozac: we possibly want later 1143993238 M * Skram hercules vservers # cat /proc/mounts | grep tagxid 1143993238 M * Skram hercules vservers # 1143993241 M * Skram uh oh? 1143993248 M * daniel_hozac Wonka: see http://linux-vserver.org/Disk+Limits 1143993261 M * daniel_hozac Skram: so you didn't mount anything with tagxid. disk limits will not work on any filesystem. 1143993272 M * Skram how do I? 1143993279 M * Skram I dont quite totally understand, Sorry 1143993280 M * daniel_hozac Skram: see the link above. 1143993281 M * Wonka # mount -o remount,tagxid /var/lib/vservers 1143993282 M * Wonka mount: /var/lib/vservers not mounted already, or bad option# mount -o remount,tagxid /var/lib/vservers 1143993285 M * Wonka mount: /var/lib/vservers not mounted already, or bad option 1143993285 M * Wonka aargh 1143993290 M * Wonka only one of them 1143993291 M * daniel_hozac tagxid mustn't be used on remount. 1143993302 M * Wonka mh 1143993309 M * daniel_hozac you have to unmount, and the mount again with tagxid. 1143993315 M * Wonka i'll do it on the next kernel change, then 1143993325 M * Skram daniel_hozac: i would have to unmuount all my vservers? 1143993346 M * daniel_hozac to set tagxid, yes. 1143993364 M * Skram hercules vservers # mount | grep vserver 1143993364 M * Skram /dev/mapper/data-vservers on /vservers type reiserfs (rw,noatime) 1143993364 M * Skram hercules vservers # #mount -o tagxid,rw /dev/data-vservers /vservers 1143993366 M * Skram Like that? 1143993370 M * Skram Please just confirm 1143993396 M * daniel_hozac assuming you'd umount first, and then add the mapper/ to the device node path, yes. 1143993418 M * daniel_hozac i guess you'd want the noatime option too. 1143993426 M * Skram device node path? 1143993444 M * daniel_hozac /dev/mapper/data-vservers vs. /dev/data-vservers 1143993445 M * Skram you mean 1143993447 M * Skram yeah okay 1143993468 M * Skram of course 1143993469 M * Skram sorry 1143993494 M * Skram if i unmount, all vps would crash so i might as well stop all vservers, right? 1143993517 M * daniel_hozac you can't unmount it until all processes using it are stopped, so yes. 1143993551 M * Skram crap-a-zappa 1143993563 Q * mkhl Quit: 1143993566 M * Skram i thought so. 1143993567 M * Skram :( 1143993788 J * doener_ ~doener@i5387FB30.versanet.de 1143993832 M * Skram daniel_hozac: know any stats for the new logo at all? 1143993855 M * daniel_hozac i have no idea whatever happened to that. 1143994002 Q * sladen Ping timeout: 480 seconds 1143994081 J * sladen paul@starsky.19inch.net 1143994197 Q * doener Ping timeout: 480 seconds 1143996760 J * trash trash@databerlin.org 1143996985 N * Bertl_zZ Bertl 1143996989 M * Bertl morning folks! 1143997054 M * doener_ morning Bertl 1143997073 M * micah morning 1143997075 M * DavidS moin :) 1143997081 M * Bertl ah, full house :) 1143997082 M * ray6 morning Bertl :) 1143997094 M * micah DavidS: I'm just applying the vcontext patch to the util-vserver package for the bug you reported 1143997114 M * Bertl hmm? url? 1143997121 M * micah DavidS: although I fail to see how its a security problem, as you have to be root on the host to run this in the guest 1143997126 M * micah Bertl: https://savannah.nongnu.org/bugs/?func=detailitem&item_id=15996 1143997144 M * micah Bertl: suexec from the host with an invalid uid runs as root in the guest 1143997164 M * Bertl ah, an admin bugfix ... 1143997169 M * DavidS micah: it doesn't work as expected ... security is expectation management ... 1143997170 M * micah (ie. a userspace util-vserver fix) 1143997208 M * Bertl DavidS: what would be the fix in your opinion? 1143997208 M * DavidS where "invalid" is everything not [[:digit:]]+ 1143997239 M * DavidS not running as root when uid=="david" 1143997269 M * Bertl okay, makes sense ... patch is where? 1143997277 M * micah Bertl: daniel_hozac's patch fixes it: https://savannah.nongnu.org/patch/?func=detailitem&item_id=4966 1143997314 M * Bertl ah, already have that in my packages, good :) 1143997324 M * DavidS everything else is icing on the cake ... after the discussion earlier today I feel that even _trying_ to resolve a name inside the vserver is not a good idea, but that's only a problem when the parser can be exploited ... so I won't press it .. 1143997330 M * DavidS s/press/argue/ 1143997346 M * Bertl yep, that's the problem here 1143997371 M * Bertl if you want guest side resolving, just enter as root (if you must enter at all :) and su to the proper user 1143997424 M * Bertl micah: so if that isn't in the debian packages, you might be interested in the other patches too 1143997426 M * daniel_hozac Bertl: i think i misunderstood what you meant yesterday re: shiny9 changes required for x86_64. 1143997452 M * Bertl daniel_hozac: let's hear ... 1143997471 M * daniel_hozac Bertl: adding #define __sysc_save and #define __sysc_aout "=a"(__res) causes compile failures. 1143997549 M * micah Bertl: I've just added the vcontext patch and I was going to ask you about the other changes 1143997567 M * daniel_hozac micah: http://cvs.hozac.com/viewcvs/util-vserver/fedora-5/?root=rpms FYI 1143997604 M * Bertl does it complain about the 'register'? 1143997613 M * Bertl could be that x86_64 doesn't use =a 1143997614 M * daniel_hozac Bertl: no, it seems __sysc_load never gets defined. 1143997633 M * Bertl okay, will look into it shortly ... 1143997640 M * micah daniel_hozac: thanks 1143997640 M * Skram Hey Bertl 1143997670 M * Bertl hey Skram! 1143997703 M * micah daniel_hozac: what does the bmask patch resolve? 1143997704 M * Bertl micah: I have the following patches in my packages: bmask, context-uid, delete, chcontext-secure and shiny9 1143997720 M * Bertl btw, I had to adjust one patch to 'work' properly 1143997720 M * daniel_hozac micah: vattribute --set --xid ... --ccap ... doesn't reset bcaps. 1143997805 M * daniel_hozac hmm? 1143997816 M * daniel_hozac work as in apply or work as in work? which patch? 1143997833 M * Bertl just looking which one, it was one of the helpers, which didn't add the stuff to the makefile, so it didn't get installed later 1143997884 M * phedny now debootstraps fails :( 1143997900 M * Bertl phedny: any error message? 1143997930 M * phedny dpkg: error processing /var/cache/apt/archives/base-files_3.1.2_i386.deb (--install): wait for dpkg-split failed: No child processes 1143997931 M * daniel_hozac Bertl: delete i guess. 1143997933 M * phedny Errors were encountered while processing: /var/cache/apt/archives/base-files_3.1.2_i386.deb 1143997936 M * phedny Processing was halted because there were too many errors. 1143997939 M * phedny W: Failure trying to run: chroot /etc/vservers/.defaults/vdirbase/newserver dpkg --force-depends --install /var/cache/apt/archives/base-files_3.1.2_i386.deb /var/cache/apt/archives/base-passwd_3.5.9_i386.deb 1143997940 M * daniel_hozac Bertl: IIRC the latest version should work though. 1143997954 M * Bertl daniel_hozac: ah, okay, so I can consider that fixed 1143997974 A * phedny is trying to solve it 1143997997 M * Bertl phedny: check the default links and dirs 1143998036 M * phedny i'm now trying the "normal" way (doing a vserver name build from a shell) 1143998082 M * phedny because previous time i ran it from a C prog with execvp() but that should be a problem I guess 1143998097 M * phedny wel, it is a problem 1143998100 M * phedny as it is working now 1143998101 M * phedny :/ 1143998126 M * Bertl check permissions (user/caps) and environment (path) 1143998197 M * phedny the program is running a setuid root binary that resets real and effective user and group to 0 1143998199 M * Skram Sup? 1143998207 M * phedny only environment might be different, i'll check that 1143998231 M * Bertl double check the (e)uids and capabilities too 1143998258 M * phedny would debootstrap fail if there is no SHELL set? 1143998334 M * Bertl I guess this one goes to the debian expert here :) 1143998352 M * phedny who's the debian expert? :) 1143998354 M * micah daniel_hozac: your shiny9 patch doesn't really have anything in it 1143998374 M * Bertl phedny: I'd say micah 1143998392 M * phedny second_stage_install () { 1143998392 M * phedny x_core_install () { 1143998392 M * phedny smallyes '' | in_target dpkg --force-depends --install $(debfor "$@") 1143998392 M * phedny } 1143998394 M * DavidS debootstrap shouldn't fail on such a triviality ... 1143998398 M * daniel_hozac micah: well, that one is straight from Bertl. it fixes some optimization gcc issues on i386 too. 1143998416 M * micah daniel_hozac: odd, nevermind 1143998421 M * phedny <-- that part from /usr/lib/deboostrap/scripts/sarge seems to be the error point 1143998425 M * micah daniel_hozac: when I first viewed it in my browser it was completely empty 1143998532 M * Bertl micah: expect a shiny10 soon (for x86_64 and new gcc) 1143998560 M * Bertl daniel_hozac: would appreciate a test-run of this one: http://vserver.13thfloor.at/Experimental/delta-rlimit-fix01.diff 1143998568 M * phedny Bertl: how can I found out what capabilities a process has? 1143998584 M * Bertl daniel_hozac: it compiles and boots here (on QEMU x86_64) but 32bit userspace segfaults in QEMU 1143998591 M * micah Bertl: soon, as in today? 1143998604 M * daniel_hozac phedny: cat /proc//self 1143998608 M * micah Bertl: btw. the dietlibc fixes were applied and uploaded in the debian package yesterday 1143998618 M * daniel_hozac Bertl: ok, i'll give it a try. 1143998621 M * Bertl micah: yes, as in 'withing the hour' 1143998631 M * Bertl micah: excellent! 1143998649 M * micah Bertl: ah, ok, I'll wait to apply shiny9 until then 1143998661 M * daniel_hozac Bertl: hmm, for 2.1.1, i guess? 1143998676 M * Bertl yep, but should work for 2.0.2 too, IIRC 1143998687 M * daniel_hozac no, i got rejects in kernel/vserver/limit.c. 1143998687 P * k3mper 1143998753 M * daniel_hozac no worries, i'll build a 2.1.1 kernel (i haven't tested those on x86_64 yet anyway). 1143998758 M * phedny CapEff: 00000000fffffeff 1143998769 M * Bertl that looks good! 1143998783 M * Bertl the inherited mask is the same, I guess? 1143998799 M * phedny exactly 1143998804 M * phedny i'm going to try with a SHELL env set 1143998809 M * Bertl daniel_hozac: ah, right, we added the soft limits and checks to 2.1.1 1143998824 M * Skram phedny: eh? 1143998846 J * Viper0482 ~Viper0482@p54975B77.dip.t-dialin.net 1143998851 M * Bertl welcome Viper0482! 1143998888 M * phedny Skram: debootstrap doesn't work when I start it from my management program, I'm trying to figure out how to fix it 1143998994 M * Bertl micah: IIRC, some distros package the testme.sh and testfs.sh with the utils, is that true for debian? 1143999062 M * Bertl daniel_hozac: what did fail with shiny9 on x86_64? 1143999078 M * Bertl daniel_hozac: i.e. how could I test that? 1143999101 M * daniel_hozac utilvserver_checkCompatVersion got miscompiled again. 1143999121 M * daniel_hozac i.e. it would override %rax by calling __errno_location before saving it to the variable. 1143999144 M * micah Bertl: its included in this version I am preparing, yes 1143999291 M * phedny dpkg: error processing /var/cache/apt/archives/base-files_3.1.2_i386.deb (--install): wait for dpkg-split failed: No child processes 1143999299 M * phedny <-- that seems to be the source of the problem 1143999329 M * phedny but if wait() fails with "No child process", then what does that mean? 1143999335 M * micah it seems like the umlaut in Bertl's name causes my browser to be unfriendly with that shiny9 patch 1143999379 M * Bertl micah: lol! 1143999400 M * Bertl micah: okay, just make sure that the testme.sh and testfs.sh are _always_ up-to-date 1143999459 M * micah Bertl: they currently are now, before things get frozen i will find a way to keep them updated 1143999597 M * phedny are ignored signals inherited by child processes? 1143999607 M * phedny SigIgn: 0000000000011000 1143999622 M * phedny i don't know how to interpret this line from /proc/self/status 1143999635 M * phedny but the two 1's are not in the value when started from the shell 1143999639 M * micah Bertl: shiny10 will include the mips syscall fixes too right? 1143999654 M * phedny and i know i ignore the SIG_CHLD and SIG_PIPE signals from the main program 1143999671 M * phedny which might cause "No child processes" for wait() 1143999684 M * phedny but i'm not an expert at this part of the game 1143999685 M * daniel_hozac phedny: i guess you'll want to reset that for the child process. 1143999720 M * Bertl micah: as shiny9 already does, yes 1143999730 M * daniel_hozac i.e. after fork() == 0, signal(SIGCHLD, SIG_DFL); signal(SIGPIPE, SIG_DFL); 1143999751 M * phedny I'll do that 1144000065 M * phedny whow, that solved it :) 1144000077 M * phedny thanks! 1144000105 M * phedny I: Base system installed successfully. 1144000321 A * phedny is going afk -- early day tomorrow 1144000575 M * Skram Bertl: what happened to the new logo? 1144000802 M * Skram ? 1144001106 Q * Viper0482 Quit: bin raus, 1144001347 M * bonbons Hi Bertl, some news on CoW? 1144001501 M * daniel_hozac http://vserver.13thfloor.at/Experimental/delta-cow-fix01.diff ? or were there more issues? 1144001675 J * matt1 ~matta@c-68-32-202-140.hsd1.pa.comcast.net 1144001735 M * bonbons looks like this one is not for the chmod, chown, utime and similar calls, so yep there is something more :) 1144001757 M * daniel_hozac ah, you meant that. 1144001761 J * lonewolf1 lonewolff@adleman.lonewolff.info 1144001768 Q * lonewolff Read error: Connection reset by peer 1144002051 Q * matta Ping timeout: 480 seconds 1144002209 Q * DavidS Quit: Leaving. 1144003542 N * lonewolf1 lonewolff 1144003618 M * Bertl Skram: well, the 'logo competition' was not really serious (unfortunately) 1144003647 M * Bertl i.e. many suggestions weren't even displayed 1144003662 M * Bertl Skram: but feel free to use any of them 1144003700 M * Bertl bonbons: yes, no public patches for those yet 1144003849 J * shedi ~siggi@inferno.lhi.is 1144003913 M * Skram Bertl: hrmm 1144003928 M * Skram becuase i was going to add it to http://www.sentiensystems.com/technologies.php 1144004181 M * micah someone needs to take on the logo contest, make it a complete and be the responsible party for following it through to completion 1144004193 Q * matt1 Ping timeout: 480 seconds 1144004315 M * micah Bertl: do you know a reliable method to test for the --barrier flag being set? showattr returns 0 no matter what things are set to 1144004522 M * micah the only way i can think of is to actually change to the VROOT and do a showattr -d . | grep B and then test $? 1144004692 M * daniel_hozac wouldn't showattr -d /var/lib/vservers | grep -q B do the same thing? 1144004729 M * micah daniel_hozac: the problem is if /var/lib/vservers is a symlink it will fail 1144004752 M * micah daniel_hozac: you could readlink that directory to try and determine the actual location, but even that could also be a symlink 1144004761 M * daniel_hozac readlink -f. 1144004804 M * micah yes, I had some reason why that wasn't sufficient, but now I cannot recall it 1144004895 M * Bertl micah: huh? @ showattr? 1144004909 M * micah daniel_hozac: and the only reliable way to tell where the VROOT is would be to read /etc/vservers/.defaults/vdirbase 1144004933 M * micah Bertl: whats the q? 1144004950 M * Skram is it possible for multiple vpses to share like a gcc install, etc. 1144004954 M * Bertl micah: no, the _only_ really reliable way would be to check for _all_ guests /path/to/guest/dir/.. 1144004958 M * Skram so i dont have to upgrade each every time? 1144004971 M * Bertl Skram: yes 1144004981 M * Skram How? 1144005010 M * Bertl daniel_hozac, micah: here is something to test, but as the changes are quite intrusive, we should retest on most archs: http://vserver.13thfloor.at/Experimental/SYSCALL/syscall_shiny10.h 1144005024 M * micah ah I see because some guests might be symlinked outside of the vroot 1144005036 M * Bertl Skram: well, you can for example --bind mount to your guests 1144005055 M * Bertl Skram: or use unionfs as many folks with such needs do# 1144005077 M * Bertl Skram: or on rpm based systems use vrpm to update 1144005118 M * Skram uh,, 1144005124 M * Bertl micah: and because checking the 'vroot dir' is always the wrong way 1144005126 M * Skram any vrpm related for gentoo? 1144005138 M * daniel_hozac vemerge. 1144005149 M * Bertl yes? is that there/available? 1144005168 M * daniel_hozac IIRC the ebuilds have it. 1144005185 M * micah Bertl: ok, so something like testing the result code from: showattr -d `readlink -f $VROOT`/*/.. |cut -d\ -f1 | grep -q b 1144005193 M * Bertl great! what about vdpkg? 1144005197 J * f_ ~f_@83-215-237-1.seek.stat.salzburg-online.at 1144005222 M * Bertl micah: you could check the output, not sure about the return codes 1144005230 M * Bertl welcome f_! 1144005231 M * Skram daniel_hozac: sample syntax for emerging gcc at once on two vservers (running gentoo) 1144005240 M * f_ hi, Bertl :) 1144005247 Q * FireEgl Ping timeout: 480 seconds 1144005281 M * daniel_hozac Skram: i'm not a gentoo person. but if it follows the syntax the others use, vemerge -- should do it. 1144005318 M * Skram hercules / # vemerge sentien-shells sentien-support dev-lang/php 1144005319 M * Skram Calculating dependencies 1144005319 M * Skram emerge: there are no ebuilds to satisfy "sentien-support". 1144005320 M * Skram no 1144005323 M * Skram only for one vps 1144005324 M * Skram weird 1144005364 Q * eyck Read error: Connection reset by peer 1144005370 J * eyck eyck@ghost.anime.pl 1144005388 M * bonbons Skram: the way I'm solving that 'issue' is to use a common packages dir, and on each guest emerge -bk ... 1144005392 M * Bertl daniel_hozac: please let me know if shiny10 fixes the x86_64 userspace issues .. it seems to work fine with gcc 4.0.1 here 1144005420 M * bonbons never tried vemerge, only doing things from within the guests 1144005442 M * Bertl might become a PITA once he has 10 guests though 1144005461 M * daniel_hozac Skram: might want to bug the Gentoo folks about that. 1144005495 M * daniel_hozac Bertl: i'm rebooting into the rlimit-fix01 kernel right now. 1144005508 M * Bertl ah, great! 1144005516 M * bonbons Skram: looking at vemerge source it just enters the guest and executes emerge from there 1144005523 M * Skram right 1144005546 M * Skram :( 1144005553 M * Skram so it cant do what i want 1144005605 M * bonbons Skram: if you tell what exactly what want, maybe we can find a solution! 1144005630 M * Skram i want two vpses to share a gcc install. 1144005633 Q * Smutje Ping timeout: 480 seconds 1144005648 M * Skram i guess 1144005650 M * bonbons I guess you want to do the vemerge with optional unification of installed packages... 1144005720 M * Bertl Skram: you could as well --bind mount all stuff required for your gcc (in the worst case scenario, one bind mount per file :) 1144005721 M * bonbons so emerging things from source on each guest is not the way to go (too many binaries get different as they include buid-date) 1144005742 M * daniel_hozac Bertl: hmm, no go. still 25769803776. 1144005777 M * Bertl daniel_hozac: okay, then we need to do some debugging there 1144005797 M * Bertl i.e. dump structure size and such (userspace and maybe kernel space) 1144005819 M * Bertl maybe the 'packed' attribute didn't work out as expected 1144005830 M * daniel_hozac i'll rerun my check-structs. 1144005872 M * bonbons Skram: would something like normal emerging on first guest and then emerging binary copies to all other guests be fine for you? 1144006082 J * FireEgl Atlantica@2001:5c0:84dc:: 1144006155 M * daniel_hozac Bertl: ugh, i'm sorry. i forgot to move the patch to the right directory before building :| 1144006197 Q * mire Read error: Connection reset by peer 1144006266 M * Bertl daniel_hozac: well, I take that as good news then :)# 1144007059 J * mire ~mire@254-166-222-85.COOL.ADSL.VLine.Verat.NET 1144007068 M * Bertl welcome mire! 1144007208 M * daniel_hozac Bertl: shiny10 works on x86_64. 1144007344 M * Bertl good! 1144008230 M * daniel_hozac btw, according to the check-structs output, the rlimits fix should do the trick. 1144008245 M * daniel_hozac i'm still building the new kernel with the right patch applied... 1144008471 M * Bertl sounds promising 1144008614 M * harry Bertl: a q 1144008647 M * harry is it possible to make nfs mounts in a vps comming from the vps ip ? 1144008690 M * Bertl yep, basically mounts _inside_ should be restricted by default, those outside can use a src option, IIRC 1144008731 M * harry they are restricted 1144008751 M * harry but the "source" is allways the hosts ip (from what i've seen/firewalled) 1144008864 M * Bertl hmm, that probably is part of the routing decisions 1144008876 M * harry not really 1144008881 M * Bertl you could try to configure a separate routing table for that 1144008897 M * harry i could... or a separate "storage" interface ;) 1144008906 M * Bertl but I have to admit, I didn't check the nfs code for that yet 1144008929 M * harry if you need help... i could allways try 1144008931 M * harry but ... not now 1144008942 M * harry it's sunday, i'm tired and my hands are ... broke :) 1144008945 M * harry broken 1144009003 M * Bertl okay, np 1144009804 M * micah Bertl: I'm wondering how to test more architectures for shiny10, i've only got i386 and your parisc available to test accurately 1144010067 M * Bertl I'll test ppc on my laptop 1144010077 M * Bertl daniel_hozac already tested x86_64 1144010097 M * Bertl together with the parisc that should be good enough 1144010106 M * daniel_hozac i might be able to test sparc too. 1144010113 M * Bertl even better 1144010127 M * Bertl would be nice to check with the vcmd tool too 1144010374 M * Bertl parisc with vcmd and shiny10 is working fine 1144010423 M * Bertl micah: let me know when you have some tools to test (e.g. when you need access to the machine) 1144010458 M * micah Bertl: what tests should be done with the tools? 1144010492 M * Bertl well, I'll update the kernel to support the latest changes/fixes 1144010509 M * Bertl then basically we should check the testme stuff and rlimits (just to make sure) 1144010589 M * micah i should have a package done here in just a couple mintues 1144010821 M * Bertl waldi: there will be an rc15 release pretty soon, with some fixes, JFYI 1144010846 M * waldi Bertl: which sort of fixes? 1144010862 M * derjohn Bertl, which fixes (in short) ? 1144010866 M * waldi which means soon? i intend to do a new release tomorrow 1144010869 M * derjohn waldi:wasfaster ;) 1144010879 M * daniel_hozac http://vserver.13thfloor.at/Experimental/delta-* ? :) 1144010910 M * derjohn waldi, on which rc do you base the debian linux-ima.*-vserver.* ? 1144010935 M * waldi derjohn: current rc14 1144011007 M * waldi Bertl: is ml-loop-fix01.diff an upstream problem? 1144011018 M * daniel_hozac yes. ml == mainline. 1144011043 M * Bertl waldi: if everything goes fine, within 5 hours 1144011060 M * Bertl waldi: yes, the ml patch is a mainline fix 1144011191 M * micah Bertl: I'm ready to test parisc whenever you are 1144011222 M * waldi Bertl: shouldn't the struct in delta-rlimit-fix01.diff be alligned at 4 bytes instead of packed? 1144011243 M * Bertl waldi: the x32? 1144011253 M * waldi yes 1144011265 M * Bertl no, that's the compatibility part 1144011287 M * Bertl but we do not know if it works as expected yet 1144011304 M * waldi the original struct is not packed 1144011304 M * Bertl daniel_hozac should have the results shortly 1144011308 M * daniel_hozac i'm just about ready to reboot. 1144011331 M * waldi so it is alligned at wordlength 1144011334 M * Bertl waldi: problem is, 32bit does not align on 8 bytes (inside structs) 1144011374 M * waldi Bertl: i386 allignes 64bit integers at 32 bit, correct 1144011375 Q * f_ Quit: This computer has gone to sleep 1144011389 M * Bertl waldi: while x86_64 does not 1144011389 M * waldi any other arch does not 1144011411 M * Bertl not sure about ppc yet 1144011424 M * waldi ppc uses correct alignment 1144011428 M * Bertl we probably have to check the 'fix' for ppc/64 and sparc/64 too 1144011441 M * waldi as i said, only i386 is effected 1144011542 Q * shedi Quit: Leaving 1144011549 M * Bertl hmm, that would make the issue worse than I thought 1144011553 M * waldi so this "fix" breaks anything except i386 1144011589 M * Bertl waldi: are you 100% sure about that? 1144011609 M * Bertl because it would make sense to me to align to 32bit on 32bit archs 1144011622 M * Bertl (as there can be no larger value) 1144011649 M * daniel_hozac Bertl: it works fine. 1144011710 M * waldi Bertl: no 1144011730 M * waldi Bertl: variables are always alligned according to there size 1144011757 M * waldi except i386 and 64bit integer 1144011769 M * waldi (don't know about floating point) 1144011834 M * Bertl okay, so I suggest we simply make that compat part optional for x86_64 now and change the interface immediately, i.e. padd the second 32bit value 1144011850 M * waldi (reasons are rather clear, even 32 bit machines are sometimes able to read longer values but only if correct alligned) 1144011851 M * Bertl will take a new revision and some time till the tools accept that 1144011871 M * Bertl until then we leave the x86 hack in place 1144011885 M * Bertl waldi: thanks a lot for the input! 1144011958 M * waldi Bertl: attribute((packed)) makes it worser anyway 1144011973 M * waldi it changes the allignment of the complete struct to 1 1144012030 M * Bertl okay, but attribute ((aligned 4)) probably doesn't do what we want, no? 1144012075 M * waldi take a look into the compat functions in fs/compat* 1144012081 M * Bertl anyways the struct isn't used except for 'copying' the data from userspace in compat case , so the alignment should not be a problem 1144012123 M * waldi __attribute__((alligned(4))) should work 1144012162 M * waldi the compiler is allowed to do some assumptions 1144012357 M * waldi but anyway, I hate that compatibility stuff, even if I have to write them 1144012663 Q * bonbons Quit: Leaving 1144014495 J * mkhl ~mkhl@200-148-41-115.dsl.telesp.net.br 1144014817 Q * mkhl Quit: 1144016230 P * meandtheshell 1144016842 M * micah just to verify, setattr --barrier $VROOTDIR/*/.. is the best way to make sure the chroot barrier is set on all vservers (takes into account vservers that are symlinked elsewhere) 1144016853 M * micah assuming $VROOTDIR is set to an actual directory (and not a symlink itself) 1144016862 M * Bertl no, not really 1144016875 M * micah ok, thats why I wanted to ask :) 1144016878 M * daniel_hozac /etc/vservers/*/vdir/.. 1144016887 M * Bertl yup, that's it 1144016905 M * micah ok, thats the best way 1144016929 M * Bertl vservers should never be symlinked in the /vservers dir 1144016942 J * mkhl ~mkhl@200-153-181-157.dsl.telesp.net.br 1144016951 M * Bertl if you place them somewhere else, you do that by redirecting the vdir symlink in the config 1144016990 M * micah if vdir -> /etc/vservers/.defaullts/vdirbase/ and /etc/vservers/.defaults/vdirbase -> /var/lib/vservers and you do 'setattr --barrier /etc/vservers/*/vdir/..' wont that fail to work properly as setattr cannot set on symlinks 1144017018 M * Bertl .. is supposed to be a dir, not a symlink 1144017277 M * micah so to be safe it would be better to do: 'for vserver in `ls /etc/vservers`; do vdiractual=`readlink -f /etc/vservers/$vserver/vdir`; setattr --barrier $vdiractual/..; done 1144017321 M * micah i know a lot of people who use symlinks to move large data stores around without realizing that could affect the security of their chroot 1144019094 N * _are_ are|afk 1144019218 J * lilalinux_ ~plasma@dslb-084-058-205-003.pools.arcor-ip.net 1144019281 Q * click Ping timeout: 480 seconds 1144019459 Q * runedude Read error: Connection reset by peer 1144019656 Q * lilalinux Ping timeout: 480 seconds 1144019751 J * runedude ~runedude@pool-71-245-164-73.bltmmd.fios.verizon.net 1144019759 M * Bertl wb runedude! 1144019798 M * Bertl daniel_hozac, waldi: so what about that one? http://vserver.13thfloor.at/Experimental/delta-rlimit-fix02.diff 1144019824 M * runedude ty 1144019853 M * daniel_hozac looks sane. 1144019876 M * Bertl would be great if you could give it a try (if it works :) too :) 1144020004 M * waldi Bertl: CONFIG_IA32_SUPPORT for ia64? 1144020157 Q * yarihm Ping timeout: 480 seconds 1144020339 M * Bertl should have the same constraints no? 1144020599 M * waldi better forget it, ia32 emulation on ia64 is not used often 1144020625 M * Bertl I meant, it should probably work out of the box with those changes, don't you think so? 1144022064 J * matta ~matta@c-68-81-35-243.hsd1.pa.comcast.net 1144022274 J * insomnia1 ~insomniac@slackware.it 1144022274 Q * insomniac Read error: Connection reset by peer