1323563503 N * Bertl_oO Bertl
1323563507 M * Bertl back now ...
1323563519 M * Bertl m_ueberall: so problem solved?
1323563537 M * m_ueberall yes. problem was in front of the computer. ;)
1323563569 M * Bertl happens more often than one might think :)
1323563627 M * m_ueberall btw: Do you know by when we'll see an update to the Mageia linux-vserver .src.rpm? 
1323563673 M * Bertl yeah, well, I should probably maintain the package, but everything is so complicated there
1323563711 M * Bertl it's almost like with debian (at least so it seems to me :)
1323563773 M * Bertl I can update the kernel package in 10 minutes, including testing, but I have to file a bug request to get other folks to test it, and argue why it was updated with security relevant things
1323563785 M * m_ueberall Well, I started using RedHat, then Mandrake, which became Mandriva and then followed the Mageia Fork, so I know my way around building rpms better than dealing with debs (though I'm learning, because Debian is "cleaner" with respect to virtual server configurations).
1323563801 M * Bertl then somebody (other than me) has to test it and report a successfull test
1323563824 M * Bertl then it can slowly be moved into testing, and after some while it might get into updates
1323563825 M * m_ueberall I could test it.
1323563860 M * Bertl it's easier if I upload the package somewhere and/or if you build the kernel yourself (saves us both some time)
1323563893 M * m_ueberall I'm ok with that as well, of course. :)
1323563894 M * Bertl especially as the update would already be superceeded once the process is complete
1323563951 M * Bertl as I said, if all that was needed was to update the spec file and upload the package, it would be perfect, but unfortunately that's not how it works ...
1323564049 M * Bertl similar goes for util-vserver of course, and it's a lot easier to take the tar and just rpm -tb it
1323564104 M * Bertl but the upstream .spec doesn't conform to all of the Mageia .spec rules (mostly because it works for all kind of rpm based distros), so no-go there
1323564231 M * m_ueberall IIRC, it's possible to add Mageia specifics to the .spec if one knows them without "hurting" the build for other distributions.
1323564271 M * Bertl well, not really, don't get me wrong, it builds perfectly fine on Mageia (out of the box)
1323564318 M * m_ueberall ...but their "rpmlint" equivalent complains, right?
1323564319 M * Bertl i.e. it has all the necessary #if blocks and such
1323564338 M * Bertl yes, that and there are some style guides too
1323564381 M * Bertl so basically a custom tailored .spec is required
1323564394 M * Bertl (which IMHO makes zero sense)
1323564487 M * m_ueberall I concur -- as long as the .rpm itself is compliant with the distribution-specific defaults, it should not matter.
1323564559 M * m_ueberall given the fact that a number of packages are outdated, this should be relaxated.
1323564594 M * m_ueberall but I still have my hopes up for Mageia >2 ;)
1323564656 M * Bertl feel free to 'fight the fight' with Mageia adminstration :)
1323564690 M * Bertl I always test that util-vserver rpms build (from tar) fine on Mageia
1323564732 M * Bertl if there is some request, I can also upload them on vserver.13thfloor.at
1323564774 M * m_ueberall As I said, if you need a second opinion... ;) I'd love to get my hands on the current sources.
1323564778 M * Bertl usually I do not build kernels as rpms, mostly because I hate the 'one fits all' default config
1323564843 M * Bertl m_ueberall: feel free, I'm not eager to maintain anything Linux-VServer related for Mageia ...
1323564999 M * m_ueberall Hopefully, starting next year I'm able to find myself a mentor and keep the stunnel package updated; if that works out, I might be able to work on linux-vserver as well.
1323565069 M * m_ueberall It should be possible to find another user or two for linux-vserver on Mageia. The german user group is quite active.
1323565932 M * m_ueberall gn8 for now... ;)
1323565949 M * Bertl nn
1323566479 Q * Chlorek Quit: -
1323567012 J * Chlorek chlorek@chlorek.com
1323569987 N * ensc Guest20035
1323569997 J * ensc ~irc-ensc@p4FEC7059.dip.t-dialin.net
1323570405 Q * Guest20035 Ping timeout: 480 seconds
1323573633 Q * Aiken Remote host closed the connection
1323575959 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1323579873 M * Bertl off to bed now .. have a good one everyone!
1323579879 N * Bertl Bertl_zZ
1323581009 J * DreamerC ~DreamerC@122-116-181-118.HINET-IP.hinet.net
1323592643 Q * Romster Quit: Geeks shall inherit properties and methods of object earth.
1323596852 J * bonbons ~bonbons@ppp-153-138.adsl.restena.lu
1323601872 Q * qwerty1 Remote host closed the connection
1323602636 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1323605477 N * Bertl_zZ Bertl
1323605481 M * Bertl morning folks!
1323605976 J * RudolfBob ~james@188.250.20.13
1323606231 M * RudolfBob hello.. :) i have a qnap (nas) iscsi drive... that i need to mount to access virtual machines...
1323606249 M * Bertl okay?
1323606253 M * RudolfBob does anyone know how to mount this file...
1323606316 M * Bertl so you don't know how yto mount your nas?
1323606325 M * Bertl s/yto/to/
1323606356 M * RudolfBob hello Bertl? are you real?
1323606408 M * Bertl what makes you think I'm not?
1323606435 M * RudolfBob i have a strange feling that your one of those AI bots..
1323606452 M * Bertl what makes you say that?
1323606455 M * RudolfBob I know that you are not... but.. maybe u have activated some thing..
1323606466 M * RudolfBob either way... say something a bot doenst say
1323606516 M * Bertl hmm ... do you care if a person or a bot answers your questions?
1323606545 M * RudolfBob well..i was just about to go for the subject at matter
1323606561 M * RudolfBob my nas configuration went to oblivion..
1323606573 M * RudolfBob i just haver access to the hard drive files..
1323606582 M * Bertl go ahead then, sounded more like you have a nas problem not a Linux-VServer problem :)
1323606593 M * RudolfBob yes...
1323606607 M * RudolfBob but i know you guys have knowledge of linux :)
1323606643 M * RudolfBob i have a iSCSI-??.000 and iSCSI-??.001 file..
1323606646 M * Bertl ah, so you want to hire somebody to fix your nas issue then?
1323606660 M * RudolfBob yes.. i have contacted qnap direclty...
1323606669 M * RudolfBob but only on monday..
1323606682 M * RudolfBob and company opens on monday..
1323606687 M * RudolfBob stress!
1323606716 M * Bertl I see, well, let's take that offline then, as it really isn't Linux-VServer related
1323607895 Q * RudolfBob Quit: Leaving
1323608179 J * RudolfBob ~james@188.250.20.13
1323609137 J * gucki ~gucki@84-73-206-134.dclient.hispeed.ch
1323609140 M * gucki hes there
1323609177 M * gucki can granting secure_mount and secure_remount result in a security problem?
1323609216 M * Bertl depends on the setup, but I can imagine at least some kind of denial of service scenarios with that
1323610414 M * DreamerC homebeta
1323613206 M * Bertl off for a nap ... bbl
1323613235 N * Bertl Bertl_zZ
1323614881 P * RudolfBob Leaving
1323615396 J * Hunger ~Hunger@proactivesec.com
1323615669 M * gucki Bertl_zZ: what kind of dos? (i think i'd take the guest/ client offline in such a case anyway). but no security issue like escaping the guest and accessing data of the host/ other gustes? :)
1323617708 Q * Aiken Remote host closed the connection
1323620542 N * Bertl_zZ Bertl
1323620549 M * Bertl back now ...
1323620681 M * Bertl gucki: well, mounting/unmounting in a loop will most likely cause some slowdown, and mounting over and over again will at some point deplete kernel resources
1323621205 Q * Marillion Remote host closed the connection
1323626003 Q * ccxCZ Remote host closed the connection
1323627380 J * derjohn_foo ~aj@p4FFD36ED.dip.t-dialin.net
1323628135 M * gucki Bertl: are there any counters I could check to see how many mounts a guest/ context has? there are no rlimits to limit number of mounts?
1323628168 M * Bertl not yet
1323637605 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1323639048 J * sannes ~ace@cm-84.209.106.118.getinternet.no
1323639126 Q * bonbons Quit: Leaving
1323639763 J * ghislain ~AQUEOS@adsl2.aqueos.com
1323640000 M * chrissbx gucki: I'd say (without knowing details regarding vserver) mounting will increase the attack surface for kernel bugs in filesystem / partition table parsing code
1323640041 M * chrissbx (but if you're already mounting random flash drives etc., then this is nothing new)
1323640168 M * gucki chrissbx: no, i'm not mounting any flash drives ;). I just need to give a guest the ability to use losetup so he can use quota...
1323640328 J * sweil ~stefan@p5086FF19.dip.t-dialin.net
1323640333 M * chrissbx Well what I'm saying is that if the client has access to the file it is mounting, then it can modify the backing storage of the mount (even while it is mounted), and thus possibly exploint bugs in the kernel filesystem parsing.
1323640379 M * chrissbx Every now and then such bugs are discovered, so you'll have to live with this risk.
1323640383 Q * ghislain Quit: Leaving.
1323640394 J * petzsch ~markus@p57B665F5.dip.t-dialin.net
1323640546 M * chrissbx (I haven't heard of actual such exploits publicly shared though, but then that doesn't mean much because I'm not a kernel dev.)
1323640894 J * RudolfBob ~james@188.250.20.13
1323640917 J * ccxCZ ~ccxCZ@new.webprojekty.cz
1323641438 Q * sweil Remote host closed the connection
1323641766 Q * sannes Remote host closed the connection
1323642295 Q * gucki Remote host closed the connection
1323642406 Q * petzsch Quit: Leaving.
1323642742 P * RudolfBob Leaving
1323644857 Q * WMP Quit: ZNC - http://znc.in
1323644913 J * WMP ~oftc@auburn.sored.pl