> On Linux Xen performance is really good. I am used to setup and configure jails from the host system while I can seamlessly write to the ZFS because it is under /zpool/jails/<myjail>/<timestamp>
So an upgrade is simply a stop of the jail with the old <timestamp> directory and start the new one. A /var/db/mysql gets "transferred" by changing the mountpoint. The filesystem is shared, no voodoo to increase a disk image needed. (I can use quota if there is a need) The same goes for the memory, no pre-allocation and slicing needed (resource management via rctl possible if needed). I safe diskspace because the jail filesystems are simply cloned from a template (only deltas of the filesystems per jail are written) An exact copy of the jail can be mirrored quickly on another box via zfs snapshot, zfs send | ssh zfs receive. To bring it up is a oneliner (more automagic with CARP or VRRP and heartbeats if you want) The kernel cannot be patched dynamically, that's true. But with 2 or 3 kernel security issues per year it is a bit less of a worry for many environments. 30 minutes downtime per year isn't too bad, and it's realistic without high-availability added yet. It's more than 99.99% availability. I am using VMware ESXi and CentOS7 now. It's a huge step backwards. Regards Peter On Fri, Aug 14, 2015 at 8:16 PM, Russell Coker <[email protected]> wrote: > On Fri, 14 Aug 2015 04:18:28 PM Peter Ross wrote: > > There are 2 things: > > > > 1. To add more functionality in the same tool increases complexity. > > > > Complexity never increases security. > > That depends on what you do and how you do it. If you add some complexity > to > one central place and remove it from many other places that's often an > overall > benefit. > > > Do everything once, do not make it more complex as needed, and do it > right. > > Which is the benefit of replacing /etc/init.d/ script functionality with > code > in systemd. > > > 2. Linux has cgroups and namespaces but some Linux design decisions are > in > > the way of using them as _secure_ containers. > > Greater use of cgroups and namespaces by systemd should be an incentive for > development of better kernel support. > > > FreeBSD jail(8) is in use for many years and can be considered as safe. > The > > pitfalls are known, disabled in the default setup, well documented, and > > there are no 'hopefully safe"s in it. > > I agree that having functionality like jail in the Linux kernel would be a > good thing. This is not related to systemd though. > > > "Which is still a minor issue compared to web browsers, MUAs..' > > > > They do not run on my servers, and they should not be an excuse to run > > other software which is overly complex because Russell considers it as a > > "lesser evil";-) > > Systemd is optional and as Rick has demonstrated any sysadmin who doesn't > want > it on Debian can remove it with ease. It's less optional on GNOME and most > desktop sysadmins won't even try removing it if they run KDE. So I think > that > these supposed security risks should be considered in the context of > desktop > users. > > > To go to your own stuff, e.g. SELinux: > > > > A jail script can be subject to SELinux policies so jails can be > restricted > > that way. This would apply to all jails, and nothing else. > > That's usually not what you want. You probably want to have multiple jails > with different security contexts. > > > If this is part of a larger binary which does all of init: SELinux cannot > > be applied in a similar way. > > Sure it can. The init system could request different contexts for each of > the > jails (this can be added to systemd unit files if it isn't already there) > or > the executables to run in the jails could have different contexts. > > I wrote policy for multiple chroot environments many years ago but it got > deleted in the change to the modular "reference" policy. But it would be > possible to do that again if there was demand. > > On Linux Xen performance is really good. The only situation where > something > like Docker would be a good idea is if you have ZFS storing all the data > and > don't want to be hobbled by poor NFS performance to the virtual machine. > > -- > My Main Blog http://etbe.coker.com.au/ > My Documents Blog http://doc.coker.com.au/ >
_______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
