Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The chroot Technique – a Swiss army multitool for Linux systems

livesys.se

Post reply on HN
Print view View original

51–60 of 123 posts

Re: The chroot Technique – a Swiss army multitool for Linux systems

#51

Post by adrian_b »

slicktux wrote: post #29
znpy wrote: post #6

Earlier quoted context omitted.

Gentoo’s stage3 would like to say a word

I remember first installing Gentoo…printed the whole manual and followed along. After a failed attempt and second successful install I learned enough to know that I could use a LiveUSB of my choosing and chroot into the install. Good times!

On Gentoo, it is also simple to install a completely new system in a chroot environment, even if it is intended for a computer with a different, but compatible architecture.

This is frequently very convenient if you want to install Gentoo by compiling everything from sources on a cheap and small computer, e.g. one with some Intel Atom CPU.

Instead of compiling anything on the resource-constrained computer, you install a fresh Gentoo system for it, in a chroot environment on a fast desktop computer, which supports a superset of the ISA of the small computer, so you can still execute the programs intended for the target computer.

Then you just copy the installation result over the SSD/HDD of the destination computer. If you have many identical computers, you can copy the installed Gentoo over all of them without any problems, removing the need for multiple installations.

If desired, you can keep the chroot environment with the installation result and perform any later updates on it. Then you synchronize the updated Gentoo from the chroot with the one or more target computers.

Re: The chroot Technique – a Swiss army multitool for Linux systems

#52

Post by whalesalad »

znpy wrote: post #6
smallpipe wrote: post #2

The arch linux install has a little wrapper around chroot, used to configure the installed system without booting it. https://wiki.archlinux.org/title/Installation_guide#Chroot

Gentoo’s stage3 would like to say a word

Debian's debootstrap would also like to participate in this discussion

Re: The chroot Technique – a Swiss army multitool for Linux systems

#54

Post by paulddraper »

paulddraper wrote: post #20
dicroce wrote: post #4

I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.

Apples and oranges. Among many other things, Docker (and Podman etc) has 1. Images and OverlayFS 2. Networking 3. User namespace mappings 4. Resource management --- If all you want is file system isolation, then docker (and postman, etc) is massive overkill chroot is correct.

*podman, etc

Re: The chroot Technique – a Swiss army multitool for Linux systems

#58

Post by foresto »

alphazard wrote: post #25
dicroce wrote: post #4

I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.

There seems to be a fundamental mismatch between how sane people think about sandboxing, and how linux manages namespaces. A linux-naive developer would expect to spawn a new process from a payload with access to nothing. It can't see other processes, it has a read only root with nothing in it, there are no network devices, no users, etc. Then they would expect to read documentation to learn how to add things to the…

> There seems to be a fundamental mismatch between how sane people think about sandboxing, and how linux manages namespaces.

What bothers me most about sandboxing with linux namespaces is that edge cases keep turning up that allow them to trick the kernel into granting more privileges than it should.

I wonder if Landlock can/will bring something more like FreeBSD jails to the table. (I haven't made time to read about it in detail yet.)

Re: The chroot Technique – a Swiss army multitool for Linux systems

#59

Post by shagie »

sgt wrote: post #55

Once I had to rescue a SunOS system and edit /etc/vfstab but I only had ed to my disposal. At that point I had never touched ed before, so that was a bit of a learning exercise, for sure.

In a computer lab I hung out in back in college...

We used rcp to keep passwords in sync. Add the account on the main machine, rcp the password file to the other machine. sudo rcp /etc/password other:/etc/passwd was muscle memory.

One day, someone was getting added to the groups file to be able to work in the server web project. sudo rcp /etc/group other:/etc/passwd

Ooops. Couldn't log in to fix it.

"Is anyone logged into the other machine?" (someone said yes). "Type while 1 sync" ... (ok) ... And we flipped the power switch and brought it up in single user mode (since the password file was invalid). Next, need to establish a minimal /etc/passwd ... emacs /etc/passwd (nope) vi /etc/passwd (nope - invalid terminal 300h not in termcap). "Uhm... cat > /etc/passwd ?" (possible, but a PITA when there is a typo in transcription)

I was a wizard on a lpmud. "I know ed".

And we got a minimal password file restored while reading the hashed values over (no way where we going to have root::0:0:... as the file even for a second) and then rcp'ed the proper /etc/passwd and /etc/group file over to the other machine.

https://www.gnu.org/fun/jokes/ed-msg.txt

Re: The chroot Technique – a Swiss army multitool for Linux systems

#60

Post by NexRebular »

duped wrote: post #15
dicroce wrote: post #4

I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.

what would "better chroot" do?

what Solaris and now illumos zones do[1]

[1] https://www.usenix.org/legacy/event/lisa04/tech/full_papers/...

Post reply on HN