[00:11] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Remote host closed the connection [00:25] ccooke (~ccooke@spc1-walt1-4-0-cust238.lond.broadband.ntl.com) joined #vserver. [00:36] miller7 (none@213.239.180.106) left irc: Ping timeout: 501 seconds [01:08] ccooke (~ccooke@spc1-walt1-4-0-cust238.lond.broadband.ntl.com) left irc: Ping timeout: 501 seconds [01:34] Nick change: Bertl_oO -> Bertl [01:34] back. [02:22] kestrel (athomas@dialup51.optus.net.au) left irc: Ping timeout: 492 seconds [02:52] click (~click@virtualdesignz.net) left irc: Quit: be right back - fixing something [02:54] click (click@gonnamakeyou.com) joined #vserver. [04:12] mexcell (~root@65.126.127.3) joined #vserver. [04:12] hi mexcell! [04:12] Hi! [04:12] How's life everybody? [04:13] fine .. [04:14] Bertyl: By the way, I am talking with my board about 2.6 sponsorships - equipment, cash - you already have my time. . . :-) [04:15] hey, sounds great! [04:15] frz (~frz@213.235.213.90) joined #vserver. [04:16] No prob - our company has gained a lot from open source - we need to give some back whenever we can. [04:16] hi frz! [04:16] frz (~frz@213.235.213.90) left irc: Remote host closed the connection [04:16] frz (~frz@213.235.213.90) joined #vserver. [04:16] So, can I help with the hostname virtualization? [04:17] That and the util-vserver directory stuff seem to be the last major things keeping my 2.6 installation from production. [04:18] hmm, well hostname stuff isn't that hard .. but I guess there is a lot of testing required, until this is production, but YMMV [04:19] frz (~frz@213.235.213.90) left irc: Remote host closed the connection [04:19] Testing I can do. In this case, the "production" server is an internal dev box - we use vservers to keep developers from destroying each other's filesystems. . . [04:20] Same with the other x86_64 box - the one running the 64 bit kernel. [04:20] did you master the proc security yet? [04:20] Yep. [04:20] it is a little strange, though [04:20] hmm, please elaborate ... [04:20] context 1 only needs uptime and meminfo - the other contexts need a few other things. [04:21] in order for ps to work, at least. [04:21] I have a list somewhere that I was collecting about what is needed for ps in the others - I misplaced it. I'll gather it again tomorrow. [04:21] hmm, well you can adjust that ... right? [04:22] absolutely. I just can't figure out why the other contexts need more than ctx 1. [04:22] Go figure. [04:23] hmm, there are some tool (basically it depends on the distro ;) which use some parts of the /proc, as I mentioned some time ago, most *info and the stat* stupp is required ... [04:23] RIght. But this is the same tool - ps - in context 1 and say, 1001. [04:24] Well, my wife is calling - I'm going to a family birthday party tonight. I'll look into it further tomorrow and drop a line to the list if I can't catch anyone here. [04:24] Thanks again! [04:24] have a nice party ... [04:24] cu [04:24] Always - Tchau! [04:24] \quit [04:25] mexcell (~root@65.126.127.3) left irc: Quit: Leaving [05:08] okay, I'm off to bed, have a nice whatever, cu all tomorrow ... [05:09] Nick change: Bertl -> Bertl_zZz [07:16] noel- (~noel@pD9FFAA9D.dip.t-dialin.net) joined #vserver. [07:24] noel (~noel@pD952C425.dip.t-dialin.net) left irc: Ping timeout: 504 seconds [09:41] Doener_zZz (~doener@pD9588FD4.dip.t-dialin.net) left irc: Quit: Leaving [09:51] kestrel (athomas@home.swapoff.org) joined #vserver. [09:51] re [11:57] AHTOH (~Anton@212.1.230.115) joined #vserver. [12:07] [HvD] (~guess@hollomey.com) joined #vserver. [12:56] AHTOH (~Anton@212.1.230.115) left irc: Ping timeout: 492 seconds [12:56] AHTOH (~Anton@212.1.230.115) joined #vserver. [14:43] Surreal (~surreal@CPE000532af64af-CM013309900192.cpe.net.cable.rogers.com) joined #vserver. [14:44] Anyone have the demo login the the PHP Based V-Server Control PBVSC? [14:49] miller7 (none@213.239.180.106) joined #vserver. [14:49] hello [15:04] Surreal (~surreal@CPE000532af64af-CM013309900192.cpe.net.cable.rogers.com) left irc: Quit: later [15:15] miller7 (none@213.239.180.106) left irc: Read error: Connection reset by peer [16:17] virtuoso (~shisha@ip114-115.adsl.wplus.ru) left irc: Read error: Connection reset by peer [16:33] kestrel (athomas@home.swapoff.org) left irc: Ping timeout: 480 seconds [16:38] kestrel (athomas@home.swapoff.org) joined #vserver. [16:52] virtuoso (~shisha@ip114-115.adsl.wplus.ru) joined #vserver. [17:08] miller7 (none@213.239.180.106) joined #vserver. [17:08] hi again [17:27] serving (~serving@213.186.190.24) left irc: Read error: Connection reset by peer [17:51] AHTOH (~Anton@212.1.230.115) left irc: Quit: Client exiting [18:23] loger joined #vserver. [18:23] Nick change: _shuri -> shuri_awa [19:22] serving (~serving@213.186.190.24) joined #vserver. [19:28] hi guys :) [19:28] hi serving [19:28] I am runing 2 vservers on a1 box. One of them is very slow specialy on network connectiosn [19:29] check your DNS settings :) [19:29] the other 2 have the same settings and they are "fast" [19:30] what IPs you have? public? [19:30] is there a firewall/nat/iptables/ipchains in the middle? [19:30] The root server is running redhat firewall noting else [19:31] what happens when you disable it? [19:31] does the vserver run fast? [19:32] no . it has no effect on the slow vserver [19:32] the slow vserver is a copy of another one? [19:33] it has a public ip, right? [19:34] yes [19:35] Hm i had that, i had to change my /etc/resolve.conf in the vservers since i had changed the root /etc/resolve.conf :) [19:35] have you looked for duplicate IP assignment? [19:36] the /etc/resolve.conf is same on root and vservers. [19:42] TamaPanda (~Tamama@193.173.84.237) left irc: [20:02] box A has vserver with problem. Box B is runing LDAP [20:03] tcpdump on Box B shows that requests from A are coming abd are v=being answered. [20:03] tcpdump on A show request leaving but nothing is comeing back [20:04] the other 2 vservers on A are working fine [20:24] [HvD] (~guess@hollomey.com) left irc: Ping timeout: 480 seconds [20:38] Nick change: Bertl_zZz -> Bertl [20:38] hi everyone! [20:39] hello! [20:39] hi dan! [20:42] *burp!* [20:43] hmm, hi click! [20:57] loger joined #vserver. [21:10] ensc: are you around? [21:10] yep [21:10] I read about the vs_get_version() ? [21:10] what do you mean? [21:12] formerly, I accepted an argument (category) but since COMPAT is supported only and the category macros are not available in userspace, I removed it [21:13] vc_get_version(uint32_t id) [21:13] { [21:13] return VCI_VERSION; [21:13] } [21:13] yes, 'id' is unused [21:13] hmm, why should this 'only' support COMPAT then? [21:14] currnetly all 'versions' are synchronized, but that might change .. not that I plan to do so atm ... [21:14] when there is really a difference, I will add this parameter back. But currently this causes too much problems [21:15] okay, where was it used anyway? [21:15] I mean except for getting the 'main' version with id=0 [21:18] btw, is it intentionally that __NR_vserver is 273 for each arch in your patch, but the Twiki mentions different numbers? [21:18] depends on the version ... the wiki shows the 'latest' assignments, which are either for 2.6 or for 2.4.25 ... [21:19] so 1.3.x test versions should use the appropriate numbers .. as well as the 2.6 versions should ... [21:20] but not 1.24 [21:20] 1.24 is a bugfix release of 1.20 .. [21:21] (never change a running system ;) [21:23] by the way, what is your opinion, should we test/use the barrier stuff, or 'just' wait for se linux? [21:26] I do not know, how much code this is. In any case, I would make it selectable at kernel configtime [21:26] yeah, that is the next point on my todo list ... [21:26] (the configuration at compile time) [21:27] I just had to do the separation step, almost completed in 1.3.6 ... [21:29] okay, what are your next steps? what do you plan? [21:36] btw, I can't reproduce the 'endless loop' matt mentioned ... [21:37] using util-vserver-0.27 gives sane output on 2.6.2-rc2-vs0.06 ... [21:41] Bertl: the endless loop happens when: there is one context read, and the get_task_xid() syscall returns -1 (error). [21:42] hmm, how and when would that happen? [21:44] perhaps with the new syscall, and there is a race too (read /proc entries, and then call get_task_xid() for pid) [21:44] the 0.27 vserver-stat does not use the new syscall [21:47] see 3rd hunk in http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/src/vserver-stat.c.diff?r1=1.7&r2=1.8 [21:51] hmm, okay ... [21:52] what would be the easisest way to verify a working chroot barrier? the escapechroot stuff? [21:55] and how do we proceed regarding the visibility states and immutable/iunlink flags? [22:05] infowolfe (~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net) joined #vserver. [22:05] Bertl, what's the "current" vroot patch? [22:07] or is it depreciated? [22:10] Bertl: ping? [22:10] no it's not depreciated, but it is included in all recent versions [22:11] so 1.24, 1.3.6 does include it ... [22:11] 1.24? [22:11] ok [22:11] see the changelog, if you want to know when it was included ... [22:13] when doesn't really matter :-p [22:13] i was just kinda confused and a little tired.. [22:13] hmm, how so? [22:13] so i didn't see it [22:13] had a long day? [22:13] i was used to seeing it in 1.3x [22:13] no, just woke up from a 4hr nap :-p [22:14] i have a server i need to deploy today that i just got all the hardware for last night [22:18] Bertl: yes, barrier can be tested with escaperoot; regarding ILI, I think that SELinux will be the better choice for 2.6; for visibility I do not know an application currently [22:19] hmm, okay, maybe you can elaborate how SE linux replaces the IMMUTABLE and IUNLINK flags? [22:20] and visibility is used atm by procfs as security feature (which 'might' be replaced by SE linux in 2.6 ;) [22:22] Bertl: As I said already, label the reference server so that vserver_t can read,unlink,lock,rename,... the files. The vserver_manager_t role can write them too [22:24] but you have to do that on a per file basis, which requires marking each link which must not be modified ... [22:24] yes [22:24] and how will this marking be done in se linux? [22:25] 'make relabel' in /etc/security/selinux is doing it, and probably there can be done something with domains too. But I do not know enough about selinux to tell details [22:29] okay, so when will the se-linux aware util-vserver tools be available? [22:29] (replacing IUNLINK, IMMUTABLE and procfs visibility? [22:29] after 2.4.25... else I would waste too much time in repairing my filesystems [22:30] okay, as we are in 2.4.25-pre7 this means near future? [22:30] but there won't be much to do... I will have just to comment out the vc_*setattr() calls [22:30] yes [22:30] well, vunify has to take care of that, right? [22:31] no, vunify will be executed as vserver_manager_t [22:31] hmm and what about vproc? [22:31] you could do 'cp -al refserver vserver' too ;) [22:32] vproc does not exist; setattr and showattr become obsolete perhaps [22:32] which would be the worst solution, because all log files would be unusable ... [22:33] okay, but that means a lot of documentation which describes how to replace existing functionality by se-linux/lsm [22:34] yes, vunify will stay since 'cp' does not know exclude lists [22:35] well, and what about in vserver hardlinks vs intra vserver hardlinks [22:35] and who would decide which files have to be tagged ass IUNLINK? [22:36] -s [22:36] you could allow 'link' too [22:36] well link is curently allowed for iunlink but not for immutable files? [22:36] yes, this will be a change [22:38] to be honest, I don't believe that se-linux will be a viable alternative for immutable/iunlink and such stuff ... because you probably need a phd to configure basic security ... [22:39] which is currently done quite well by the vserver tools ... [22:40] so either there is a utility which does all this for your, and builds secure, shared vservers from references or descriptions with se-linux setup, or it won't be of any use ... [22:40] -r [22:40] Red Hat thinks that they can make it usably for the end-user; Fedora Core 2 (April 2004) will have full SELinux support [22:42] hmm, and this will include support for vserver, I don't think so ;) [22:44] secure chroot() support is already there, and the ILI stuff "will be a one-line-rule" (citing Russell Coker) [22:44] is that line somewhere? [22:45] probably not... [22:46] okay, is there somebody who will write that line? [22:46] (and make sure that it works/is applicable)? [22:47] how would I test SElinux on 2.6.2? [22:47] it will something like 'allow vserver_t refserver_t:file { read,link,unlink,lock,rename }' [22:48] what does the refserver_t mean in this regard? [22:48] Bertl: best way to test it would be probably Fedora Core Development [22:48] it has already SELinux policies [22:49] refserver_t is the type of the files in the refserver [22:50] hmm, what if I have no 'refserver'? [22:50] (consider two servers, unified against each other) [22:50] alpha util-vserver are requiring a refserver [22:51] but unifications doesn't right? [22:51] ?? [22:51] the unification, per se doesn't require a reference server ... [22:51] you have to configure (at least) one refserver to make 'vunify' work [22:52] yes, but that reference has no rights over the 'clone' [22:52] you can specifiy plain paths too, but loses e.g. the powerful exception list features [22:52] how do I get se-linux support with vanilla kernels? 2.6.x [22:53] the files there are labeled to be type 'refserver_t' [22:53] you can enable it somewhere in the security menu [22:53] securiy options -> Enable different security models [22:53] ah yeah, found that ... [22:54] This enables the NSA SELinux Multi-Level Security (MLS) policy in [22:54] what is that? [22:55] I would not turn this on ;) [22:55] very experimental and the RH tools are not working with it [22:55] okay [22:58] might it be possible to replace the vserver network stuff by slm/se-linux? [22:58] s/slm/lsm/ [22:59] afaik, currently the selinux network stuff is not implemented yet (at least in 2.6; the 2.4 patch has it). But I do not think that it can replace it [22:59] the implicit bind(...ip...) is not security related [23:00] CONFIG_SECURITY_NETWORK: [23:00] This enables the socket and networking security hooks. If enabled, a security module can use these hooks to implement socket and networking access controls. If you are unsure how to answer this question, answer N. [23:01] might become an option ... [23:02] dunno, Russell mentioned that "James Morris is working on better management for TCP/IP networking" [23:04] and what about the 2.4 line, do you plan to abandon support for 2.4 vserver? [23:05] no; I just meant that the 2.4 and 2.6 SELinux code are different [23:05] http://tresys.com/selinux/selinux-addinfo.html has good SELinux links [23:06] well, the 2.4 se linux is not present atm ... or am I wrong? [23:07] no, it is not. But there are existing patches; but 2.6 does not use them but has an own implementation [23:07] okay, is there a 'recent' patch for 2.4.24 or 2.4.25-pre? [23:08] http://www.nsa.gov/selinux/download.html [23:10] hmm, 2.4.23 seems to be latest ... [23:14] and that gives 28 rejects to 2.4.25-pre7 :( [23:14] so it seems that they are not updating their patches very often ... [23:14] and the 2.4 selinux version is different from the 2.6 regarding the interface? [23:15] yep [23:15] so it wouldn't make things easier to patch in selinux support for 2.4, right? [23:16] selinux is much more invasive than vserver and people would not accept it, imo [23:17] okay, enrico, we have to find a direction where we want to go in the future, and how we should do it, I have no problem with se-linux, but it seems to me, like it is an option, not a solution, and maybe we should see it like this ... [23:18] I have no problem with 2.4/2.6 synchronised vserver implementation/tools and an additional se-linux branch, by the way ... [23:21] what I don't want is separate 2.4/2.6 vserver versions with no (or only very complicated) migration path(es) ... [23:21] ask the uses; but I would freeze the current 2.4 implementation and concentrate on 2.6 development. And there, you have SELinux which can solve lots of work and is more powerful than some small vserver hacks [23:22] who will do the se-linux userspace stuff? the docu? will you do that? [23:23] currently, I do not have an idea how much work this will be [23:23] me neither ... [23:25] markl (~mlawren@69-56-241-204.theplanet.com) joined #vserver. [23:25] hi mark! [23:25] Ay currmba, did that take me a while to et on... [23:25] well, you are here, right? [23:26] Herbert, you wrote irc.oft.net in the mail... which actxually resolves, but is not irc... :) [23:26] oops, sorry ;) [23:26] No worries! [23:26] Are you all in the middle of a disucssion? [23:26] well, no not really ... [23:27] we are dancing around the 2.6/se-linux issues ... [23:27] So, could I quickly recount my network blackout issue? [23:27] yep, sure .. go ahead ... [23:28] Box was completely normal.... hang on, I've just realised I haven't checked this kernel on the box without the vserver patch. [23:28] hmm, good idea ;) [23:28] I upgraded the kernel and patched with vserver at the same time. [23:28] So, let me do that again, and then get back online :-) [23:28] okay ;) [23:29] Ok, Tschuss! [23:29] markl (~mlawren@69-56-241-204.theplanet.com) left irc: Client Quit