Date: Fri, 9 Mar 2001 21:46:54 +0100 (CET) From: Attila Nagy <bra@fsn.hu> To: <freebsd-stable@FreeBSD.ORG> Subject: Re: nullfs et al Message-ID: <Pine.BSO.4.33.0103092112360.29074-100000@k2.jozsef.kando.hu> In-Reply-To: <200103091814.TAA91443@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, > What is the "proper" way to mount binaries etc. into a bunch of jail > homes? Obviously, I don't want to copy /bin, /usr/bin, /usr/lib etc. > for every jailed user. BTW, I'm using 4-stable. I have a similar problem but not with binaries. I run several jails with different services with the same data pools. > (A) Local NFS loopback mounts. Seems to work reliably. In my case it is very slow. For binaries it can be a viable option, but don't forget that you open another way to the real machine (call it TCB, Trusted Computing Base). If you trust in jail() and the other things that you use, like the other portions of the kernel and the daemons, running in TCB, for example an SSHD or a syslogd in this way you have to trust in the NFS server and the likes. > (B) NULLFS (mount_null). The manpage contains explicit > warnings, so using this is probably not a good idea. This would be the best idea, but it doesn't work. I've tried to build such a machine with nullfs. It worked until I started to use a program in the jail which did chroot(). FTP servers like to do chroot(), so I dropped this idea. > However, if the mounted directory is read-only and > all NULLFS mounts are read-only, too, does it still > cause crashes, or would this be more secure? I'm not a kernel hacker (BTW, I would glad if I could be a FreeBSD kernel hacker :), but my experiences show that this won't cause less crashes. > Apparently NULLFS has been fixed in 5-current, but I > don't want to run -current on this machine. There is one way which seems to be very hard to do: backporting the changes to -STABLE which could lead to an operating nullfs implementation. Kris Kennaway has enlighted the problems to me: there are too many changes in the kernel to do this, so this is a dead idea :( > (C) UNIONFS (mount_union), possibly with the -r option, > which seems to be pretty much the same functionality > as NULLFS. The manpage contains the same warning, > however, I've seen opinions in the list archives that > UNIONFS is more stable than NULLFS, in particular > when used read-only. Anyone with more experiences > on this? Yes. I am currently doing 500 GB per day from a unionfs mounted disk array (read only mounted data spool on ftp.fsn.hu)... ...and get reboots 2 or 3 times per day :) One of my friends told me that he uses unionfs for the same purpose as me (mounting RW directories into several jails RO) and he had success with it. But he doesn't do thousands of millions queries with that... > (D) Copy the partition data in the disklabel, so that > multiple partitions occupy the same physical space > on the disk (e.g. da0s1g and da0s1h point to the > same filesystem), then mount each of them read-only. > Would this be safe? The only thing that I don't > like about this approach is that it doesn't scale > very well, because each disklabel only holds 8 > partition entries, so I would need a slice for > every 8 jails. This should be the most stable and the fastest of all, but clearly sucks. In my reading FreeBSD is for small to midscale servers (the above machine is somewhere in the middle I think) and with the jail code it can be used for an ISP who wants to build a lot of jails and do web, or another kind of serving even with root access for the customers. This way you would need to do hundreds or thousands of partitions :( D isn't scale well, as you've said and A could be insecure (at least for me) so I would choose C if this server isn't a mission critical one, or D if you need a stable solution which is fast yet. E: use a backend-frontend model with x machines (if you need scalability and security) F: use the loopback device (man vnconfig) and mount the necessary stuff from vnode disks. This in you case (and in mine) won't help too much because you don't want to duplicate the files and I can't duplicate 100 GBs when I just have exactly that amount... ps: I know that everybody does hard work during the release cycle but if somebody could backport a working nullfs code a lot of people would be very happy on the planet... I would even offer my monthly salary, but that would be a joke for the backporter, I know :( -------------------------------------------------------------------------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSO.4.33.0103092112360.29074-100000>