You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you for this repo I think it's extremely important. I read your blog article and appreciate the technical detail it provided but in it you failed to mention some of the major benefits chroots have over containers.
For example I'm writing a utility called glusterchroot which runs Gluster, a distributed file system, within a chroot. With chroots the files Gluster edits stay isolated within the chroot, making management easier, but it doesn't isolate Gluster from the host's namespaces. In Gluster's case it's very important to not be isolated from the mount namespace because it needs to manage disks. Additionally, debian's schroot utility has some additional useful features like managing fstab and running daemons from within a chroot which make life even easier for glusterchroot but that's beyond the scope of your article. Now consider that if I had to do this within a container I would have to give the container so many permissions that it would essentially become a chroot. I would also have to tell multiple programs running within the container that they actually can access disks, /dev/, /proc/ and other base system management features which becomes a huge headache especially with programs like lvm and dm. Essentially I would have to hack everything off of a container except the chroot functionality and we would end up with a very complicated version of this repo. I used Glusterchroot as an example because it's my repo and I know it well, but there are many others (like cockpit) that could similarly benefit from chrun.
Now consider a developer who just wants to compile their code in an isolated environment (similar to sbuild). They don't care about security, they just want a clean system. That work flow becomes over-complicated with the volume permissions issues, networking and other "features" in docker. Yes these days there are some work-arounds for this but your chroot solution is a much simpler approach.
With the entire industry from ALP to Kubernetes becoming completely container-obsessed I'm glad someone gave chroots the attention they deserve.
The text was updated successfully, but these errors were encountered:
Thank you for this repo I think it's extremely important. I read your blog article and appreciate the technical detail it provided but in it you failed to mention some of the major benefits chroots have over containers.
For example I'm writing a utility called glusterchroot which runs Gluster, a distributed file system, within a chroot. With chroots the files Gluster edits stay isolated within the chroot, making management easier, but it doesn't isolate Gluster from the host's namespaces. In Gluster's case it's very important to not be isolated from the mount namespace because it needs to manage disks. Additionally, debian's schroot utility has some additional useful features like managing fstab and running daemons from within a chroot which make life even easier for glusterchroot but that's beyond the scope of your article. Now consider that if I had to do this within a container I would have to give the container so many permissions that it would essentially become a chroot. I would also have to tell multiple programs running within the container that they actually can access disks,
/dev/
,/proc/
and other base system management features which becomes a huge headache especially with programs likelvm
anddm
. Essentially I would have to hack everything off of a container except the chroot functionality and we would end up with a very complicated version of this repo. I used Glusterchroot as an example because it's my repo and I know it well, but there are many others (like cockpit) that could similarly benefit from chrun.Now consider a developer who just wants to compile their code in an isolated environment (similar to
sbuild
). They don't care about security, they just want a clean system. That work flow becomes over-complicated with the volume permissions issues, networking and other "features" in docker. Yes these days there are some work-arounds for this but your chroot solution is a much simpler approach.With the entire industry from ALP to Kubernetes becoming completely container-obsessed I'm glad someone gave chroots the attention they deserve.
The text was updated successfully, but these errors were encountered: