1324946696 Q * ghislain Quit: Leaving.
1324949909 Q * hparker Quit: I've fallen off the 'net and can't get up
1324949923 M * Bertl off to bed now .. have a good one everyone!
1324949930 N * Bertl Bertl_zZ
1324951549 J * Romney2012 ~Rapeseed@187.184.66.18.cable.dyn.cableonline.com.mx
1324951707 Q * Romney2012 autokilled: Do not spam. Mail support@oftc.net with questions (2011-12-27 02:08:27)
1324953289 M * macmaN sup guys
1324953348 M * macmaN so im basically trying to figure out what approach to take to this exact thing
1324953350 M * macmaN http://www.paul.sladen.org/vserver/archives/201108/0076.html
1324953359 M * macmaN Re: [vserver] [WISHLIST] Routing traffic through network when multiple vservers are in different vlans on the same vserver host
1324953372 M * macmaN reading up on netns now
1324953404 M * macmaN since it doesnt look like i will be able to override the 0 priority local routing table
1324953479 M * macmaN it is either going to be the send-to-self patch (which seems to apply cleanly on my 3.0.7) or netns
1324953535 M * macmaN but i seem to be failing finding any docs on netns + vserver, esp. the "ip netns" commands in iproute2-3.1.0+ 
1324953567 M * macmaN anyone here touched this stuff yet?
1324954334 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1324955118 Q * Romster Quit: Geeks shall inherit properties and methods of object earth.
1324955183 J * derjohn_foo ~aj@p4FFD268A.dip.t-dialin.net
1324955254 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1324955568 Q * derjohn_mob Ping timeout: 480 seconds
1324963561 Q * Romster Quit: Geeks shall inherit properties and methods of object earth.
1324963701 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1324963745 Q * Romster 
1324963927 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1324965473 Q * geos_one Remote host closed the connection
1324969491 J * ncopa ~ncopa@3.203.202.84.customer.cdi.no
1324969632 Q * urbee 
1324971077 N * Bertl_zZ Bertl
1324971081 M * Bertl morning folks!
1324971153 M * Bertl macmaN: not sure what the actual question is?
1324971202 J * sannes ~ace@cm-84.209.106.118.getinternet.no
1324971761 J * ghislain ~AQUEOS@adsl2.aqueos.com
1324972487 A * sladen looks around
1324972530 M * Bertl morning paul! how's life?
1324972669 M * sladen about to head off in a few hours to 28C3 in Berlin
1324972889 M * theocrite 28c3 \o/
1324974285 N * ensc Guest21853
1324974295 J * ensc ~irc-ensc@p54ADE9C7.dip.t-dialin.net
1324974716 Q * Guest21853 Ping timeout: 480 seconds
1324976156 Q * ensc|w Remote host closed the connection
1324976164 J * ensc|w ~ensc@www.sigma-chemnitz.de
1324980952 J * geos_one ~chatzilla@chello080109195117.4.graz.surfer.at
1324981133 Q * Romster Quit: Geeks shall inherit properties and methods of object earth.
1324981283 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1324982816 M * macmaN Bertl: trying to figure out what actually works in my scenario, or what is the lower-maintenance approach
1324982863 M * macmaN im gonna write and draw a description of the situation
1324982958 J * BenG ~bengreen@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com
1324983752 M * Bertl okay, off for a nap .. bbl
1324983769 N * Bertl Bertl_zZ
1324986040 Q * Romster Quit: Geeks shall inherit properties and methods of object earth.
1324986413 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1324986536 Q * Aiken Remote host closed the connection
1324986766 M * macmaN :/
1324987732 Q * Romster Quit: Geeks shall inherit properties and methods of object earth.
1324987970 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1324992193 Q * eyck_ Ping timeout: 480 seconds
1324995719 J * eyck ~eyck@77.79.198.60
1324996835 N * Bertl_zZ Bertl
1324996842 M * Bertl back now ...
1324997971 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1325000220 J * nuba ~nuba@pauleira.com
1325000247 M * macmaN is the guy that started http://linux-vserver.org/util-vserver:SplitSharedNetworks also sitting here?
1325000287 M * Bertl no idea
1325000377 M * nuba hi folks, freebsd expat on linux lands, lost jails but found vserver! old-time sysadmin, but a total vserver newbie now, will hang around to learn and chime in here and there once i'm wiser :D and thanks for linux vserver!
1325000446 M * Bertl welcome to the channel!
1325000480 M * macmaN its art breemen: http://permalink.gmane.org/gmane.linux.vserver/18805
1325000704 J * dowdle ~dowdle@scott.coe.montana.edu
1325001518 M * ghislain welcome nuba
1325001569 M * ghislain what is the espected lsxid result on a mounted FS that has no "tag" ? on one server i have xid 0 and another i have !!ERR!!
1325001644 M * Bertl same util-vserver version?
1325001674 M * ghislain oh no i use the latest utils from the time i install a server so never the same
1325001713 M * Bertl well, that probably causes the difference then
1325001719 M * ghislain one is 0.30.216-pre2906 , the other 0.30.216-pre2914
1325001763 M * Bertl hmm, both quite old, but IMHO they all should show ERR
1325001864 M * ghislain ok, those systems were tagged but i had quite some issue wuth tag+quota
1325001881 M * ghislain ( quota was desynchronised and working randomly) so i untagged them
1325001888 M * ghislain remounted untagged i mean
1325001902 M * Bertl you cannot remount the tag opÃtion
1325001910 M * Bertl *option
1325001948 M * ghislain umount /part; mount /part with removing the "tag" on the fstab
1325001976 M * Bertl that works, but only if it is the 'last' namespace mounting it
1325002020 M * ghislain i dont understand what you mean by 'last' namespace
1325002045 M * macmaN in the case of multiple vservers i guess?
1325002051 M * macmaN there is a first and a last
1325002104 M * ghislain i mount those partition from the host bafore starting the servers
1325002104 M * Bertl if a guest namespace has the filesystem mounted, you won't be able to change the tagging
1325002126 M * Bertl always check with /proc/mounts
1325002138 M * ghislain oh ok,  i done this: 1/ stop the vserver 2/ umount 3/ edit fstab 4/ remount 5/ restart vserver
1325002147 M * ghislain for each
1325002190 M * ghislain i remember having some issue when i done that but i do not remember what
1325002213 M * ghislain i think i had to remount them tagged then chxid -c 0 or something like this
1325002241 M * Bertl where 'remount' means unmount and mount, I presume :)
1325002292 M * ghislain yes it is using french way of speaking in english term so that do not work. Yes remount= umount, sleep 1, mount
1325002372 Q * nou Ping timeout: 480 seconds
1325002450 M * Bertl well, if filesystem, mount options (as shown via /proc/mounts), kernel/patch/config match, there shouldn't be a difference in the two util-vserver versions IMHO
1325002471 M * Bertl (in regard of lsxid showing ERR)
1325002508 M * Bertl when it shows !!ERR!! it means that there is no tag support present, if it gives 0, it just means that the file itself is not tagged
1325002561 M * ghislain ext3 rw,noatime,errors=continue,barrier=0,data=writeback,usrquota,grpquota vs   ext3 rw,tag,noatime,errors=continue,data=writeback,usrquota,grpquota
1325002570 M * ghislain there is barrier option that change
1325002592 M * Bertl and there is #tag# in the second
1325002611 M * ghislain DAM ! am i so blind
1325002620 M * ghislain but mount show it unttagged !
1325002626 M * ghislain cannot trust those dam tools :p
1325002631 M * Bertl mount shows whatever in /etc/mtab is
1325002651 M * Bertl put bertl_knows there and it will show it :)
1325002662 M * ghislain lol
1325002670 M * ghislain ok that explains the differences
1325002726 M * ghislain next time i'll use grep, at leat grep is not blind enough to miss it
1325002837 M * Bertl np
1325002849 M * ghislain is there anyneed to chxid -c 0 files before doing the umount /mount process ?
1325002872 M * Bertl depends on the tagging and what you plan to do
1325002894 M * Bertl if your tagging uses one of the uid/gid modes, you better switch to tag=0
1325002935 M * Bertl otherwise you might end up with 'funny' uid/gid :)
1325002992 M * nuba Bertl, ghislain: thank you :)
1325005522 J * bonbons ~bonbons@2001:960:7ab:0:c970:4a0a:f2f5:a173
1325006947 Q * BenG Quit: I Leave
1325007353 M * Bertl translocating .. bbl
1325007359 N * Bertl Bertl_oO
1325007584 M * macmaN darn
1325007591 M * macmaN :>
1325010206 Q * eyck Remote host closed the connection
1325010677 J * eyck ~eyck@77.79.198.60
1325012008 M * macmaN so here's what i'm trying to accomplish with vserver networking isolation: https://docs.google.com/document/d/1E564hAU-6DdMEp5fxkOm8UHCBTzoWriAj0eoYODgVGQ/edit
1325012157 Q * eyck Remote host closed the connection
1325012421 M * macmaN doc is freely editable, no google account needed, if anyone has anything, comments welcome both in-doc and here
1325012510 M * macmaN i will put results of this in the wiki for sure
1325012944 J * eyck ~eyck@77.79.198.60
1325014610 N * Bertl_oO Bertl
1325014616 M * Bertl back now ...
1325015159 M * Bertl macmaN: what's the purpose of those bridges?
1325016540 M * macmaN Bertl: to have wifi available for both trusted and untrusted users
1325016604 M * Bertl how does that relate to the Linux-VServer host? or is the bridge somewhere else?
1325016620 M * Bertl it's hard to tell from the picture where one ends and the other starts
1325016657 M * macmaN yeah blockdiag / nwdiag doesnt draw the best pictures :>
1325016666 M * macmaN there's just two boxes
1325016668 M * macmaN router and host
1325016685 M * Bertl okay, and the host doesn't have any briges, yes?
1325016692 M * macmaN nope, not yet
1325016697 M * macmaN host is the only concern here
1325016701 M * macmaN router works fine 
1325016713 M * Bertl okay, so host has two interfaces, and guests hanging on one of them
1325016743 M * macmaN "not yet" as in host *could* have them if they are needed for anything. right now it doesnt.
1325016748 M * Bertl the eth1:0: actually depicts an alias, yes?
1325016775 M * macmaN well the first ip is the real ip, im guessing if i start up more, they will get aliases
1325016800 M * macmaN but for claritys sake, i could have a dummy ip for the nic and make all vservers get aliases
1325016804 M * Bertl that depends on your setup, but a basic Linux-VServer setup for this case would not use aliases
1325016846 M * Bertl i.e. you would have a primary IP for the host, and a bunch of secondaries for the guests, using simple network isolation, each guest will only show the assigned IP(s)
1325016897 M * macmaN uh, "secondary" meaning..? i dont know of any other way to assign multiple ips to interface
1325016901 M * macmaN other than aliases
1325016941 M * Bertl just do 'ip a add 192.168.3.20/24 dev eth1 on the host and you'll get a secondary
1325016970 M * Bertl usually util-vserver will do that for you on guest start and remove the IP on guest stop
1325017056 M * macmaN hmmm, i'm googling "ip alises vs secondary", not seeing immediate results that would explain the difference between them
1325017099 M * Bertl the difference is that aliases are 10 years old and secondaries are a more modern way to handle multiple IPs on the same interface
1325017125 M * Bertl i.e. they were introduced 10 years ago and now have become standard
1325017232 M * macmaN oic oic
1325017253 M * macmaN ok thats fine with me, im not hung up on either, whatever works
1325017300 M * macmaN i guess then we get to the "using simple network isolation" part
1325017312 M * Bertl so, that sounds like a typical, straight forward, Linux-VServer setup without any special tricks to me
1325017353 M * macmaN so how about the problems 1 and 2
1325017372 M * macmaN just ip add doesnt give me isolation does it
1325017425 M * Bertl well, if you only assign external IPs to the guests, they will not be able to bind ports on 'internal' IPs
1325017447 M * Bertl assuming that you do not want to reach the host's internal IP, you should not have any problems there
1325017476 M * Bertl the host's internal IP of course is host local, so will not go via the firewall unless you do some tricks
1325017524 M * macmaN vservers will have dmz ips, 192.168.3.x
1325017534 M * Bertl the guests accessing other guests via the host network is IMHO not a problem, as you won't get a different behaviour from a setup with several physical boxes connected to the same network
1325017624 M * macmaN well yes its the tricks i believe i need
1325017633 M * macmaN binding is not issue
1325017661 M * macmaN just plain network access to services on "internal" subnet
1325017676 M * macmaN because of them both being local to host
1325017681 M * Bertl a simple firewall rule on the host should block that
1325017716 M * macmaN yes, right, solution option 4.  should def be iptables
1325017776 M * macmaN i am wondering though could this be done at a lower level
1325017777 M * Bertl the network namespace won't help you much, unless you route them via vlans and switch them separately (which is doable, but IMHO overkill)
1325017844 M * Bertl what isn't clear from the diagram is the actual traffic you expect/want
1325017888 M * Bertl i.e. which traffic is supposed to happen between internal and dmz?
1325017918 M * macmaN internal can initiate anything towards dmz
1325017954 M * macmaN but dmz can only access some stuff in internal strictly defined by firewall.
1325017985 M * Bertl on the router, I presume
1325017995 M * macmaN right now all the dmz devices are coming in through wifi on the router, so they all hit the firewall no problems
1325018035 M * Bertl what's the purpose of the internal IP for the host?
1325018051 M * macmaN you mean 192.168.1.2?
1325018062 M * Bertl yup
1325018084 M * macmaN thats what all the important internal services bind to
1325018096 M * Bertl which internal services?
1325018104 M * Bertl and what do they bind to?
1325018120 M * macmaN httpd, sshd, imap, smtpd, etc etc. bind to 192.168.1.2 eth0
1325018131 M * Bertl why's that?
1325018151 M * Bertl I mean, why do you want to run that on the host?
1325018158 M * macmaN i only have one box
1325018164 M * macmaN i dont want to build another for vservers
1325018176 M * Bertl yeah, but you could put those into guests as well, no?
1325018194 M * Bertl 'internal' guests
1325018236 M * Bertl now, as I see it, there are three kinds of traffic which are supposed to happen
1325018249 M * macmaN you are right, i could. and i have indeed thought about virtualizing the services. but i cannot afford to bring that migration work into the schedule at this time.
1325018279 M * Bertl traffic from outside to dmz and from dmz to the outside
1325018306 M * Bertl traffic from outside to internal and more importantly from internal to the outside
1325018316 M * Bertl and traffic from internal to the dmz
1325018324 M * macmaN but even if i virtualize those services, if both internal and dmz vservers live in one box, dmz vservers will still need to re-firewalled again on host
1325018336 M * macmaN because of the link local access ability
1325018361 M * macmaN yes traffic analysis is correct
1325018376 M * Bertl I'm not sure why the dmz guests would actually want/need to contact the internal guests or the other way round?
1325018406 Q * dowdle Remote host closed the connection
1325018410 M * Bertl normally dmz is done to provide somewhat secured services to the outside
1325018475 M * macmaN internal -> dmz is mostly admin work
1325018491 M * Bertl so that could happen with dmz IPs
1325018504 M * macmaN but the other way around is just possibly curious people snooping around too much and perhaps being able to access stuff that i just have not been able to secure well enough
1325018545 M * Bertl so, if the other way round isn't wanted, a simple iptables drop rule for all traffic from dmz to internal should suffice
1325018564 M * Bertl maybe with a log, if you want to know who is doing bad things
1325018580 J * dowdle ~dowdle@scott.coe.montana.edu
1325018590 M * Bertl IMHO you want to keep it simple
1325018615 M * Bertl put 'internal' services into 'internal guests'
1325018641 M * Bertl put external services into external guest, block traffic between both in general
1325018774 M * macmaN what about isolating dmz vservers from each other and possible other dmz devices. can that be done with a universal iptables rule or will i need to start adding iptables rules for dropping traffic from each new vserver.
1325018824 M * Bertl all 'local' traffic will use 'lo' so you can simply block any traffic between dmz IPs via lo
1325018872 M * Bertl all outgoing traffic will use eth1 instead
1325019059 M * macmaN so youre suggesting dropping the routing level ideas and just going with iptables 
1325019139 M * Bertl as I said, it's probably simpler, if what you actually want is two separate machines in one box, then something like xen/kvm splitting between eth0 and eth1 (with several cpus) is probably simpler
1325019156 M * Bertl you can then run Linux-VServer on each 'partition' and have completely separate domains
1325019241 M * macmaN yeah, the only thing would be another layer of OS management for the "vserver host"
1325019294 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1325019585 M * Bertl well, OS level isolation isn't the proper tool for partitioning
1325019604 M * Bertl (not saying that partitioning is what you need in your case :)
1325019620 M * macmaN it feels so close
1325019632 M * macmaN vserver already does most of the work, just gotta block the network access
1325019668 M * Bertl as I said, just 'blocking' local traffic is simple and straight forward and doesn't need any deep knowledge about the guest IPs
1325019689 M * Bertl just simply block 'local' traffic except for 127.x
1325019730 M * macmaN so two firewalls is an inevitability
1325019766 M * Bertl you can't really call an iptables rule a 'firewall' IMHO
1325019791 M * Bertl a firewall does a lot of management and connection tracking stuff
1325020703 M * macmaN good point
1325020740 M * macmaN but other than iptables, which approach would you take as next-best
1325020780 M * Bertl I'm not sure what you mean, please rephrase the question
1325020803 M * macmaN send-to-self patch or network namespaces. i so far think both accomplish the isolation goals with some added complexity, did you at any point say that these will not work at all?
1325020881 M * Bertl no, they probably will, but with a lot of added administrative efford with little to none benefit
1325021705 Q * cuba33ci Read error: Connection reset by peer
1325021757 J * cuba33ci ~cuba33ci@114-36-228-191.dynamic.hinet.net
1325021770 Q * bonbons Quit: Leaving
1325021807 M * macmaN okay. thanks a lot for sticking with me here. i guess the only thing left is that i'd probably still like to find out how to do this with network namespaces to get a better understanding of applications of that beast.
1325021830 M * macmaN until then it looks like i'm gonna hit up iptables on host
1325021881 M * Bertl well, I'd also appreciate an example setup with network namespaces on the wiki, so go ahead and give it a try
1325022620 M * macmaN definitely. where do you suggest i ask questions about it as i go along. some iproute2 ml rather? looking at the vserver ml it doesnt look like theres people that are doing this.
1325022653 M * Bertl well, there definitely was at least somebody who already completed a setup
1325022667 M * Bertl (like a few months ago, but obviously without much documentation)
1325022713 M * Bertl IMHO lxc would be the proper place to ask about network namespaces in general, but not regarding Linux-VServer integration of course
1325022730 M * Bertl for the latter, this channel (and the ML) is probably the best place
1325024600 Q * sannes Remote host closed the connection
1325024762 J * petzsch ~markus@p57B67F9B.dip.t-dialin.net
1325025558 Q * petzsch Quit: Leaving.
1325027526 J * petzsch ~markus@p57B67F9B.dip.t-dialin.net
1325027566 Q * hparker Quit: I've fallen off the 'net and can't get up
1325029347 J * theocrit1 ~Goddefroy@87.98.217.168
1325029364 Q * theocrite Ping timeout: 480 seconds
1325029446 J * theocrite ~Hubert@kim.theocrite.org
1325029464 Q * theocrit1 
1325029815 Q * ghislain Quit: Leaving.
1325029823 Q * disposable Remote host closed the connection