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/
Introduction to Immutable Linux Systems
141–150 of 164 posts
Re: Introduction to Immutable Linux Systems
#142How 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.…
Re: Introduction to Immutable Linux Systems
#143Earlier 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.
Re: Introduction to Immutable Linux Systems
#144 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
#145Re: Introduction to Immutable Linux Systems
#146In 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
#147I 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…
It’s solid and simple, unlike these other immutable Linux distros
Re: Introduction to Immutable Linux Systems
#148I 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…
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
#149I 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…
Re: Introduction to Immutable Linux Systems
#150Is 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.