Live data from Hacker News

Introduction to Immutable Linux Systems

dataswamp.org

141–150 of 164 posts

Re: Introduction to Immutable Linux Systems

#141

Earlier quoted context omitted.

> spinning rust Weird phrasing. Haven't seen that before.

They mean hard drives. I found Torvalds saying it: https://www.wired.com/2012/10/linus-torvalds-hard-disks/

I figured, but it's still a weird phrase.

Re: Introduction to Immutable Linux Systems

#142
post #61

How would you approach making immutable live-cd like Linux? No persistence at all, just boot it and run some app - think some kind of presentation panel which shows predefined program/URL. Ideally net booted to avoid having storage at all.

Ideally, Kali is meant to be used this way, so you can use it to perform forensics on a potentially compromised system without inadvertently changing anything and destroying evidence. You can really trivially do this with any Live CD by putting it on write-once read many media. You typically need at least /var and /tmp to be writeable, but that can be accomplished via tmpfs so they only write to memory and not disk.…

Thanks I'll look into the arch links.

Re: Introduction to Immutable Linux Systems

#143

Earlier quoted context omitted.

If you Google it, it's a pretty common phrase referring to magnetic disk as opposed to SSD. Could even be applied to drum, I suppose, if you could still find any...

Can't be that common since I've never come across it in 20+ years.

https://xkcd.com/1053/

Re: Introduction to Immutable Linux Systems

#144
It don't understand what's the big deal about it. To make the system immutable, isn't it enough during boot to just

    1. create a ram-backed filesystem
    2. copy `/`s contents to that new filesystem
    3. Optional: Unmount `/`
    4. Mount the ram-backed filesystem on `/`
?

You can easily do that from the initramfs during booting. I'm applying this patch to the roofs created by debootstrapping Debian Buster. You can use the system just fine and make changes as you please. But when you shut it down, it's all lost. Everything I want to keep (like the permanent storage this system makes available over sshfs, NFS) is on seperate disks anyway. Sure, you need enough RAM to hold the entire rootfs (1.2G in case of Debian Buster) and it increases boot time a bit. For server applications, I don't care at all.

    --- a/usr/share/initramfs-tools/scripts/local   2021-11-05 12:50:23.541088057 +0100
    +++ b/usr/share/initramfs-tools/scripts/local   2021-11-05 13:02:14.483203576 +0100
    @@ -180,9 +180,20 @@
     
        # Mount root
        # shellcheck disable=SC2086
    -   if ! mount ${roflag} ${FSTYPE:+-t "${FSTYPE}"} ${ROOTFLAGS} "${ROOT}" "${rootmnt?}"; then
    -       panic "Failed to mount ${ROOT} as root file system."
    -   fi
    +   #if ! mount ${roflag} ${FSTYPE:+-t "${FSTYPE}"} ${ROOTFLAGS} "${ROOT}" "${rootmnt?}"; then
    +   #   panic "Failed to mount ${ROOT} as root file system."
    +   #fi
    +
    +   mkdir --parents /tmp/diskroot
    +   mount -t ${FSTYPE} ${roflag} ${ROOTFLAGS} ${ROOT} /tmp/diskroot
    +
    +   mount -t tmpfs -o size=6G none ${rootmnt?}
    +   chmod 755 ${rootmnt}
    +
    +   cp --force --archive --verbose /tmp/diskroot/* ${rootmnt}
    +
    +   umount /tmp/diskroot
    +   rm -r --force /tmp/diskroot
     }
     
     local_mount_fs()

Re: Introduction to Immutable Linux Systems

#146
I feel pretty strongly against the idea of immutable infrastructure when you're "infrastructure" (shared systems, running other people's software), but this article isn't about that.

In my observation (and in datasets that I have access to), computers systems tend to follow the "infant-mortality" curve. This means that if they run for a little bit, they're likely to run for a long time (and in addition, if you have many of them, they tend to die around the same time). My conjecture is that many computer systems have initialization routines which are not as thoroughly tested as the normal operating state of the system. Due to this, we tend to run into more issues in "immutable" systems than you otherwise would in "mutable" systems.

Re: Introduction to Immutable Linux Systems

#147

I got into Tinycore this summer. Useful complement to the security philosophy "One OS, one function" which is kinda the thing behind Qubes, Tails and Whonix we talked about here a few days ago. It's so light, you can spin up VMs, one for a mail-server, one for a database, one for a firewall/router, each in a couple of seconds. Tinycore is itself immutable, so you add a vdisk with a "package" and some config, mark it…

Yeah TinyCore is always missing from these intros to immutable Linux… it’s been around a while and has a great design (though the implementation leaves some to be desired, and probably has no corporate backing to explain people not knowing about it…)

It’s solid and simple, unlike these other immutable Linux distros

Re: Introduction to Immutable Linux Systems

#148
post #146

I feel pretty strongly against the idea of immutable infrastructure when you're "infrastructure" (shared systems, running other people's software), but this article isn't about that. In my observation (and in datasets that I have access to), computers systems tend to follow the "infant-mortality" curve. This means that if they run for a little bit, they're likely to run for a long time (and in addition, if you have m…

This could be used as an argument in favour of immutability. If you effectively spin up a "new" computer every time you restart a box, then it forcibly surfaces any issues with your deployment or first-run.

It's not like you don't have all the same issues with deploying your long-lived mutable systems -- you're just feeling the pain less frequently, and postponing all the work to debug them until you're in e.g. a disaster recovery scenario.

Re: Introduction to Immutable Linux Systems

#149
post #29

I think the definition should be: Installing any number of packages, then removing them in any order, at any future point(s) in time, is equivalent to never having installed them at all. This leaves some distros out, but I feel like it’s the important part of the concept.

As far as I can tell, her point is this is effectively impossible, at least for a user-facing system. Do you want all the files you wrote in your word processor program or text editor gone when you uninstall those? All the files you downloaded from your browser gone if you uninstall it? If not, there is no reliable way to tell what files are created by a program automatically and which are created by a human using th…

I'm saying that installing and removing packages is equivalent to not installing them at all, not that if your boyfriend leaves you, uninstalling LibreOffice should undo it.

Re: Introduction to Immutable Linux Systems

#150

Is anyone running diskless Alpine in production? It seems optimal to me but extremely uncommon. In the past I’ve tried running a small USB drive in rented bare metal w/ diskless alpine, but the machine seemed to reboot randomly IIRC.

I am using this for my home lab. Extremely useful.
Post reply on HN