[00:00] JonB (~jon@129.142.112.33) joined #vserver. [00:28] pflanze (~chris@80.218.23.137) joined #vserver. [00:28] Hello. [00:29] Some time ago I've read somewhere that hard links can be used between vservers to share mem/disk. [00:29] And that with the help of chattr +i (?) it can be made secure. [00:29] somehow, yes ... [00:29] I've tried it out now and am confused that it doesn't prevent me to write to such files from inside a vserver. [00:30] Is it because I'm using reiserfs, or am I doing something wrong? [00:30] you are able to write to an immutable file? that is strange ... [00:31] pflanze: how do you "write" that file ? [00:31] root@ethlife-b vserver# lsattr kontro/fun [00:31] s--i---c------ kontro/fun [00:31] [root@nathan tmp]# touch x [00:31] [root@nathan tmp]# chattr +i x [00:31] [root@nathan tmp]# echo "test" >x [00:31] bash: x: Permission denied [00:31] root@ethlife-b vserver# echo fun >> kontro/fun [00:31] eh. [00:31] pflanze: you can unlink it (aka delete it) and then write a new file with the same name' [00:31] that was from outside the vserver. [00:32] if it doesn't work this way, either vserver breaks your permission scheme for reiserfs or reiserfs isn't sane ;) [00:32] root@ethlife-b-kontro /# cat fun [00:32] hello [00:32] root@ethlife-b-kontro /# echo world > fun [00:32] root@ethlife-b-kontro /# cat fun [00:32] world [00:32] that's from inside a vserver context. [00:32] s---i---c-------- fun [00:33] and outside? [00:33] same thing. [00:33] i.e. the i bit is preserved, but doesn't seem to have any effect. [00:33] well then the perm scheme of reiserfs is broken, either by Hans Reiser or by the vserver patches ... [00:34] let me have a look at the vserver code in this regard, what kernel/patches do you use? [00:34] 2.4.22-vs1.00 [00:34] only vserver [00:34] no other patches. [00:34] stock 2.4.19 has that problem too [00:34] okay, give me a minute .. [00:34] # echo hello >fun [00:34] btw I've just realized yep. [00:34] # chattr +i fun [00:34] # echo test >fun [00:34] # cat fun [00:34] test [00:35] hmm, reiser too? [00:35] yes. [00:35] yup [00:35] (me on another machine w/o vserver) [00:35] hmm, could anybody in the meantime check if this is true for reiser _without_ vserver too? [00:35] Bertl: I ment stock 2.4.19 without vserver [00:35] oops ... [00:35] Bertl: me too, on this other machine. [00:35] so it is broken without vserver [00:36] yep, sorry for confusion. [00:36] ok, hmm .. so I am supposed to mend it then? ;) [00:36] would be genious! [00:37] the flags are reported ... and change if you do chattr +/- stuff, yes? [00:37] # lsattr fun [00:37] ---i---------- fun [00:37] I find it funny that the flag is ther but the linux vfs layer doesn't honor it - looks like the fs code itself has to check it. [00:37] Bertl: yes. [00:37] can turn it on/off. [00:38] http://www.paul.sladen.org/vserver/archives/200111/0032.html [00:38] hmm, there's that for 2.4.15 [00:39] but the state of affairs has already improved, current reiserfs *can* store those flags - they just don't seem to be honoured. [00:40] yeah [00:42] Bertl: do you take that into your hands, or should I write to lkml? [00:43] you should probably write reiserfs-list@namesys.com or reiserfs-dev@namesys.com [00:44] as those are the addresses listed in MAINTAINERS for reiserfs [00:44] hmm, you are not using noattr flag on mount, right? [00:45] I am not using it [00:45] Bertl: no. Here's what /proc/mounts says: /dev/md13 /mnt/md13 reiserfs rw 0 0 [00:45] (and fstab: /dev/md13 /mnt/md13 reiserfs defaults) [01:00] Bertl_ (~herbert@212.16.62.51) joined #vserver. [01:00] Bertl (~herbert@212.16.62.51) left irc: Read error: Connection reset by peer [01:09] hmm, am I still here? [01:10] 05:00 ## Signoff #vserver: Bertl (Read error: Connection reset by peer) [01:10] that one went away [01:16] Bertl (~herbert@MAIL.13thfloor.at) joined #vserver. [01:16] [Bertl] (~duke@PLAABEN.0804.VIP.AT) joined #vserver. [01:17] <[Bertl]> hmm anybody else experiencing enourmous lag? [01:18] Bertl_ (~herbert@212.16.62.51) left irc: Ping timeout: 480 seconds [01:18] nope [01:18] ## CTCP PING reply from [Bertl]: 0.522436 seconds [01:19] <[Bertl]> yes, but this is a different route ;) [01:19] heh [01:19] a good one :) [01:20] <[Bertl]> at the moment, yes ;) [01:22] Bertl (~herbert@MAIL.13thfloor.at) left irc: Read error: Connection reset by peer [01:22] <[Bertl]> di one of you try the 'attrs' mount option? [01:23] same results [01:23] reiserfs: cannot support attributes until flag is set in super-block [01:23] heh [01:28] <[Bertl]> it seems that there is a special flag, which probably can be set via some tools ... [01:28] yeah [01:29] <[Bertl]> now someone should look amongh the reiser utilities/tools which tool this could be ... ;) [01:37] infowolfe (infowolfe@68.33.215.209) left irc: Remote host closed the connection [01:46] <[Bertl]> hmm pflanze? [01:47] yes? [01:47] Action: pflanze reading [01:47] hm. [01:47] <[Bertl]> any new ideas regarding the 'attrib' flag stuff? [01:48] <[Bertl]> it seems that 'noattr' is default on reiser :( [01:48] looking at debian reiserfsprogs [01:50] I don't see any such tool. [01:51] I'll just ask on #kernelnewbies. [01:51] <[Bertl]> but you get the same message on mount? [01:52] <[Bertl]> or did I misunderstand something .. my connection was gone ... [01:52] hm, I've just read what MrBawb said. [01:53] MrBawb: I've never seen a 'cannot support attributes' message from reiserfs - where did you see that? [01:53] <[Bertl]> because I would suspect that a mount -o attrib,rw /dev/x /dev/y should work ... [01:53] when I used mount -o remount,attr /[mountpoint] [01:53] ah [01:53] <[Bertl]> forget about the remount ... [01:56] hm - mount -o attr /dev/md8 /mnt/md8 [01:56] mount: wrong fs type, bad option, bad superbl.. [01:56] <[Bertl]> 'attrib' it is ... [01:56] same thing. [01:56] JonB (~jon@129.142.112.33) left irc: Quit: Client exiting [01:56] maybe my mount command is too old. [01:57] <[Bertl]> nope, my fault 'attrs' it is for reiser ... [01:57] oh [01:57] ah. attrs works. [01:58] root@ethlife-b md8# chattr +i fun [01:58] root@ethlife-b md8# echo hallo > fun [01:58] bash: fun: Permission denied [01:58] yeah! [01:59] <[Bertl]> well, it all in the source ... now do this on Windoof! [01:59] :) [02:02] hm remount is not enough [02:02] <[Bertl]> thought so ... [02:02] <[Bertl]> this is very much like the tagctx option (from the implementation side) [02:03] what's this? [02:03] <[Bertl]> the context tagging for files ... [02:03] ah. there's a new vserver specific metadata for files? [02:04] <[Bertl]> it allows to track the files used/accessed by a context, which is required for quota and disk limits (per vserver) [02:04] <[Bertl]> there are 3 modes, 2 of them use the existing UID/GID to store that information ... the third adds new fields and only works on (ext2/ext3) [02:05] ah. so the first modes allow me to do quotas/limits even with reiser? [02:06] <[Bertl]> they should, but reiser isn't tested by me (yet) ... [02:06] cool. I'll check it out some time. [02:07] <[Bertl]> wait a week or so, I'll update them soon for the new releases ... [02:13] (Just to be sure: is it ok to just shut down my vserver instance, umount, mount -o attrs and vserver start?) [02:14] <[Bertl]> guess this should work ... I see no pitfall there ... [02:15] I just thought, hey if there are special infos in the files I've generated while playing... but this is reiser, so no special info anyway I guess. [02:16] <[Bertl]> probably the attributes are store but not enforced until now .. so you should scan with lsattr for 'misconfigured' files/dirs ... [02:21] umount: /mnt/md13: device is busy [02:21] lsof does not show any process with md13 in it's path. [02:21] fuser -vm /mnt/md13 [02:21] vserver 1 enter first? [02:21] <[Bertl]> what are your lsof options? [02:21] or how do I get ctx 1? [02:21] no, from the real server [02:22] lsof|grep md13 [02:22] <[Bertl]> try lsof +D /mnt/md13 [02:22] this takes forever [02:22] and lsof without any option should output md13 anyway, right?? [02:23] <[Bertl]> I see at least 5 cases which could cause this ... [02:23] <[Bertl]> - nfsd grabbed the device [02:23] no nfsd here [02:23] <[Bertl]> - some bash/tool is still in this path [02:23] would show up in lsof [02:23] AH [02:24] <[Bertl]> - you enabled quota or something similar on the device [02:24] other mounts,I silly! [02:24] <[Bertl]> - you mounted ontop of that ;) [02:24] <[Bertl]> and last but not least my favorite: a kernel bug ;) [02:24] no, no other mounts anymore. [02:24] looks like kernel bug then [02:24] ok going to reboot [02:25] <[Bertl]> well I personally doubt that this is the case ... but it's up to you ;) [02:25] no quota either [02:26] <[Bertl]> this is a vserver partition, right? [02:26] it's just a partition where I had a vserver running on, yes. [02:26] morning [02:27] <[Bertl]> okay just out of the blue try umount /mnt/md13/proc and /mnt/md13/dev/pts ... [02:27] the only vserver on this machine. [02:27] <[Bertl]> @kestrel morning! [02:27] hey herbert [02:27] too late, already rebooted. [02:27] but I did cat /proc/mounts|grep md13 and it didn't show anything else than the 'real' mount. [02:28] shit happens. [02:29] the machine doesn't come back up :/ [02:29] <[Bertl]> give it some time, probably file system checks ... [02:31] no joy. [02:33] <[Bertl]> hmm, that is bad ... did you change anything? [02:33] changed fstab with attrs, and at the same time did replace defaults with noatime. [02:34] maybe a typo. [02:34] one should not reboot a live server from home at midnight. [02:34] <[Bertl]> probably now sitting there with 'unknown mount option ... ' [02:35] <[Bertl]> now is the time to make yourself familiar with the concept of remote console and serial connections ... [02:35] yes, I wanted to do that for a long time already. [02:36] ok going to drive off there. [02:37] cu [02:37] pflanze (~chris@80.218.23.137) left irc: Quit: [x]chat [02:47] Bertl (~herbert@212.16.62.51) joined #vserver. [02:48] Action: Bertl kicks [Bertl] of the channel ... [02:48] [Bertl] (~duke@PLAABEN.0804.VIP.AT) left irc: Quit: [Bertl] has no reason [02:49] damn imposters ... 8-) [03:20] pflanze (~chris@ethlife-a.ethz.ch) joined #vserver. [03:23] ok machine up again; want to know what it was that prevented it from rebooting? [03:23] hmm, let me guess ... [03:23] but tell me what exactly you did ... [03:24] before I mean ... [03:24] one of the md devices was just mdadm'ed, and did not have an raid autodetect type in the partition table. [03:24] that was all. [03:24] fsck complained that it couldn't read the device. boot stopped. [03:24] and you entered it into the fstab ... [03:24] yes. [03:24] Without also changing the partition type. sigh. [03:25] okay .. been there done that, didn't bother to get the T-shirt ... [03:25] which t-shirt do you mean? [03:26] the 'added-a-non-auto-detect-md-device' t-shirt ... [03:26] hehe [03:26] I see. [03:26] Action: pflanze feels ashamed [03:27] Now to the other stuff: [03:27] rm fun isn't allowed anymore, which is ok. [03:27] shit happens, all the time, you just have to look at the good side ... (if you can find one) ... [03:27] :) [03:28] okay, so +i work as expected, right? [03:28] but I'm now wondering how vservers are supposed to do software upgrades? not being able to write to a file and replacing it is a different thing.. [03:28] simple, that is what Sam Vilain's ILI stuff is for ... [03:28] m [03:28] hm? [03:29] I remember having read about a script. [03:29] the magic is the Immutable Link inversion flag ... [03:29] ah. ok [03:29] there are special tools to set this flag, although not required ;) [03:30] guess the backup flag or something. [03:30] but basic idea is, you weaken the Immutable flag with that one ... [03:30] ok. [03:30] changes are not allowed as usual, but removal (unlink) is ... [03:31] basicall all package oriented distros and the majority of the tar/archive based do remove before they install ... on updates ... [03:31] jup [03:32] (or even better (would be to) write to tmp file and rename that over the current) [03:33] hmm, not a good idea, especially if /tmp is another partition ;) [03:33] but I'm missing the script that's going to find files that can be hard-linked-and-made-immutable. [03:33] tmp file in the same folder, of course. [03:33] what distro do you use on the host? [03:33] debian woody. [03:34] hmm, there is a tool for RPM packages ... and somebody started a project to do the unification for debian too ... [03:34] ah. [03:34] but I don't know where this one was lost ;) [03:35] how is it called on redhat? [03:35] basicall you could decide to unify some directories like /usr/bin etc ... [03:35] it's calle vunify ;) [03:35] s/calle/called/ [03:35] then it's not in debian. [03:35] because it doen't make much sense to read the non existing rpm database, right? [03:36] ah i see. [03:36] this tool relies on the information provided by the rpm packages themself ... [03:36] well I thought it was just guessing at the paths. [03:42] link-inversed immutable files can also still be linked or renamed, right? [03:42] s/or/and/ [03:43] hmm, well the naming is a directory operation, so yes, the link .. I guess no ... [03:45] That would probably be necessary for debian: [03:46] (maybe) [03:46] well, check it, if something is missing for debian, we can add it, if it makes sense ..;) [03:46] I'm seeing "-new" suffixes for all files that have been replaced but are still open, in /proc/pid/map, like /usr/X11R6/lib/libXext.so.6.4.dpkg-new [03:47] not 100% clear why. [03:47] Maybe some rename games. [03:47] well, doesn't matter. [03:48] But what does matter (and which I first thought of) is how the unify script securely places the files into the vserver filesystem. [03:48] If it has to put the files there before the +i flag, vservers have a chance to overwrite them! [04:03] of course it does this when the vserver is down ;) [04:05] ah. [04:05] there are too many issues when you try to update/reunify a running server ... [04:06] no others come to mind. could be that we are replacing a file that's been replaced after we read it. [04:07] but that's at least no security hole, just a very small breakage risk. [04:07] we could be replacing a file that is in use ... [04:07] but what's the problem with that? [04:07] package upgrades do that all the time.. [04:08] yeah, but from inside, without removing/adding priviledges ... [04:09] but as I said, try some approaches, show that they are secure/insecure and why ... then we talk about solutions ... [04:09] The algorithm I have in mind is: make immutable, check size+perms, if same, check md5 sum, if same, make hardlink. [04:09] did you try to hardlink an immutable file yet? [04:09] no that's why I asked above. [04:09] basically it should work, but never tried myself ... [04:09] ok. [04:10] I'm trying for some time to replace the whole immutable/ILI stuff by something smarter ... [04:10] btw I'm trying to unwrap an rpm file; maybe the script is downloadable elsewhere to make it easier? [04:10] you can get the tar.gz .. [04:11] it's on linux-vserver.org ... with the release ... [04:11] ah ok [04:11] both enricos util-vserver or jack's tools will contain it [04:20] What kind of smarter stuf do you want to do? copy-on-write? [04:21] well, I had that in mind, but this has too many side effects ... [04:21] but the following approach sounds reasonable: [04:21] and prolly not much use, since it's quite easily determinable which files may be immutable. [04:22] for quota and disk limit, we need the context tagging anyway, so why not use this information according to a simple rule ... [04:22] files 'owned' by the root context (0) and ... [04:22] having more than one link (unification) [04:23] and a immutable bit set (admin) [04:23] automatically get the linkage invert ;) [04:24] this way you lose a little option (creating immutable shared files among vserver, which can't be removed .. but who needs/wants that? [04:24] Well, the root server has a little changed semantics, too. [04:25] hmm depends, not necessarily ... [04:25] Maybe someone wants to create multilink immutable and non-inverted files. [04:25] for whatever reason:) [04:25] on the root server this can work as usual ... you lose the ILI feature there ... [04:25] ah. [04:26] ok then it doesn't sound that dangerous. [04:26] the problem with the ili stuff is, that it uses file flags assigned otherwise (in this case tail merge IIRC) and that IMHO _is_ bad ... [04:27] ok. [04:28] hmm thinking of it, this could on reiserfs result in funny things ;) [04:28] reiser has tail merging anyway or something like that [04:28] well it's disabled by default ... [04:29] ah no, wrong .. 'notail' is required to disable it ... [04:31] Did you write the vunify.cc prog? [04:31] no, I don't write C++ code ;) [04:32] that was jack (Jacques Gelinas) all blame/honors go to him ;) [04:32] ok. [04:32] looks kind of funny, not very lucent for me atm. I'll have to look into it another day. [04:33] Who was going to work on it for debian? [04:33] you have to search the archives ... (mailing list) [04:34] ok [04:54] Btw what does this mean?: [04:54] New security context is 3 [04:54] Kernel do not support chrootsafe(), using chroot() [04:54] (upon vserver enter) [04:54] this means that you use old tools ;) [04:55] ah. [04:55] hm, should I upgrade? security problem? [04:55] nope, the newer tool don't use it either, they just don't complain ... [04:56] ok. [04:57] you are still secure if you setup the 000 barrier on the vserver directory ... [04:57] huh? [04:58] well chroot() isn't safe per se ... [04:58] so vserver introduced a security enhancement, the 000 barrier ... [04:58] a directory with permission 000 can't be crossed from within a vserver ... [04:59] ah uh oh. [04:59] good to know I need that. [05:00] hrm, I guess it's on ever explanation page regarding vserver ... [05:00] well, you know now ... [05:00] Maybe I should read more again. [05:01] I read the paper about half a year ago. Then lately I suddenly needed vserver, so I just installed the debian package. [05:01] And in the debian docs nothing's written about the 000 barrier. [05:02] It even has a setup script that doesn't seem to check that. [05:02] I think the vserver projekt should offer a program that tries to break out the vserver in any possible known way, so admins can check if all's ok. [05:02] well, hopefully we get to integrating the chrootsafe() call soon ... [05:03] Kind of a test suite. [05:03] it's in enricos tools under tests ;) [05:03] ah. [05:03] another job well done, and so fast ;) [05:05] (Funny. 000 doesn't prevent a normal root user to enter it, read it, ...; wondering why chroot should be safe with it) [05:05] because vserver patches checks it ;) [05:06] ah. I almost thought that:) [05:06] try to work with it from ctx != 0 [05:08] serving (~serving@213.186.191.20) left irc: Ping timeout: 492 seconds [05:08] serving (~serving@213.186.191.20) joined #vserver. [05:09] you mean, I have to chmod 000 the directory *above* the individual vserver root dirs? [05:10] yes .. or the highest common directory ... [05:11] chmod 000 /var/lib/vserver, and /var/lib/vserver/{server1,server2,server} are u+rwx ? [05:12] yes .. this way it should work ... [05:12] basicall you do a chmod 000 /.. [05:13] because that is exactly where a chroot escape tries to go ... [05:13] ok, I see that d--------- 2 root root 96 16. Nov 22:00 /var/lib/vservers/ [05:13] the point is I made symlinks there to other places, which didn't have a 000 dir. [05:14] hmm, as I said, doing the above should be sufficient in any case ... symlink/mount/whatever ... [05:14] of course it should read chmod 000 /.. [05:14] I now 000'ed the dirs above my symlink targets as well, so fine [06:30] okay ... I go to sleep now .. have a nice whatever ... [06:30] Nick change: Bertl -> Bertl_zZ [07:23] Nick change: riel -> surriel [08:55] Simon (~sgarner@apollo.quattro.net.nz) joined #vserver. [09:33] Simon (~sgarner@apollo.quattro.net.nz) left irc: Quit: so long, and thanks for all the fish [11:46] pflanze (~chris@ethlife-a.ethz.ch) left irc: Ping timeout: 483 seconds [12:46] James (~James@ip68-96-180-27.lv.lv.cox.net) joined #vserver. [12:46] hello all? [12:47] James: Certainly hello. [12:48] Hiya Virt! [12:49] Im making progress with vserver... found out how to use newvserver tonight (had trouble creating) [12:49] Hm. RedHat? [12:49] yeah, 7.3 [12:50] found out about the right arrow in the block, by reading the script [12:50] now i just need to figure out all the ulimit tags, and ill be good to go. [12:51] I think, it'll be good if you correct documentation regarding 'right arrow'. [12:52] I will, when i get the rest figgured out (im writing up all my expiriences) [12:52] Action: virtuoso never used vservers on redhat though. :) [12:53] I just do as the boss tells me, Id prefer anything else. [12:54] Ive been looking into gentoo, since i got that email about RH dropping 7.3 [12:55] Look into debian also. A damn good thing. :) [12:56] so i hear, [12:56] hmmm, debian [12:57] if it's software packages aren't the newest and latest versions, how are bugs and patches handled? [12:58] i'm thinking between debian gentoo and rhel [12:58] Updates are made very often at least by security team. [12:58] Unstable branch of debian updates even too often. [12:59] Debian has ability for binary upgrades. Thats goal behind gentoo. [12:59] yuppers [13:00] hmm, got an error here, bbiaf [13:00] Hm? [13:00] it did not write a /etc/resolve.conf [13:01] like, say there's a bug in openssh, could be patched with the latest version, but the latest version isn't deemed to be stable enough for production, how is that handled? [13:02] zyong: Maintainer of the package applies the fixing patch to current stable and proposes an update. [13:02] Although situations may vary. [13:03] hmmm, so generally, debian packages do not neccessarily provide the latest releases but it's a sure thing that newest exploits and patches are being applied? [13:04] zyong: There's a policy stating that security updates must come in maximum 48 hours after vulnerability is announced. [13:05] maximum? sounds good [13:05] Packages in unstable branch are usually up to date. [13:07] hmmm, @ debian.org now [13:08] got a min? [13:08] who? [13:08] anyone [13:08] :) [13:09] i must have missed something about nameservers in vps... [13:09] i can ssh from vps02 to the real world, but cant resolve anything. anyone have a hint for me?? [13:12] resolve.conf? [13:12] Try tcpdump in 0 context. [13:12] wrote it myself [13:13] resolv.conf better, of course. :) [13:16] ok, it did not write the /etc/sysconfig/network-scripts/ifcfg-eth0 either [13:18] i guess its not supposed to [13:19] doesn't ifcfg-eth0 handle only ip and gateway info? [13:19] yeah [13:19] just saw that it ws missing [13:19] OH [13:19] lol [13:20] how well is commercial, the so called enterprise software, supported on debian? [13:21] bea weblogic only holds support for rhel [13:26] this ring a bell for anyone? [13:26] Can't set the ipv4 root (Invalid argument) [13:26] usr/sbin/vserver: ulimit: cannot modify max user processes limit: Invalid argument [13:29] James: Show your IPROOT and ULIMITs so we may probably tell... [13:29] say-out (~say@212.86.243.154) left irc: Read error: Connection reset by peer [13:29] say (~say@212.86.243.154) joined #vserver. [13:30] zyong: Commercial software is off of official debian, although there is plenty of unofficial repositories with almost everything. [13:30] zyong: Take a look at apt-get.org, for example. [13:30] i know, i read about that part [13:30] but does that mean that weblogic 'wun' compile on debian? [13:31] 'wun' - ? [13:31] won't [13:31] typo [13:32] Why wouldn't it compile? [13:33] haha i don't know. haven't tried any distros other than RH. [13:33] i just want to confirm that it will [13:33] Then it most likely will compile. :) [13:34] roger that [13:37] trying it again, with a rh73 full install [13:46] say-out (~say@212.86.243.154) joined #vserver. [13:46] say (~say@212.86.243.154) left irc: Read error: Connection reset by peer [13:59] serving (~serving@213.186.191.20) left irc: Ping timeout: 483 seconds [14:02] pflanze (~chris@129.132.19.124) joined #vserver. [14:28] James (~James@ip68-96-180-27.lv.lv.cox.net) left irc: Ping timeout: 480 seconds [15:51] serving (~serving@213.186.191.21) joined #vserver. [16:12] zyong (zyong@bb-203-125-7-187.singnet.com.sg) left irc: Read error: Connection reset by peer [17:23] Nick change: unriel -> riel [17:34] Nick change: Bertl_zZ -> Bertl [18:01] say (~say@212.86.243.154) joined #vserver. [18:01] say-out (~say@212.86.243.154) left irc: Read error: Connection reset by peer [18:02] hi say! [18:16] shuri (~ipv6@207.236.226.187) joined #vserver. [18:17] hi shuri! [18:17] hi [18:17] :P [18:17] ipv6 server is down... [18:17] :( [18:18] bad, really bad ... [18:18] lol [18:20] what tools i use with 1.1.3? [18:21] the ones on the same page as the patch ;) [18:21] actually util-vserver 0.24 or later ... [18:22] ok [18:23] compile time [18:52] so you are 'the' ipv6 guy, right? ;) [18:53] humm [18:53] maybe: [18:53] well, for sure you can explain me some basics ... [18:53] yes [18:54] okay, assume that I know ipv4 from a user/admin perspective and at the protocol level (ip(v4)) nothing else ... [18:55] ok [18:55] how/why would I switch to ipv6 for example ... [18:56] well you know that for now is Link encap:IPv6-in-IPv4 [18:56] so you got ipv4 and ipv6 [18:56] probably to tunnel ipv6 over ipv4 ... [18:56] yes [18:56] you got a suffix 48 with this [18:57] that mean a lot of ips [18:57]