Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Son of Thunderbeast
Sep 21, 2002
I'll try the forking option, thanks! And yeah it's set up as a user service

Adbot
ADBOT LOVES YOU

Lifroc
May 8, 2020

I'm here to once again spread the world of immutable Linux. Today I'm test driving uBlue, which is a small layer on top of immutable Fedora to add conveniences such as pre-installed hardware acceleration packages, distrobox, and other small packages.

The beauty of it is that you just need a simple
code:
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/VARIANT:38
and Bob's your Uncle. I've switched from Fedora Kinoite (immutable KDE) to its equivalent ublue-os/bazzite-main and it's smooth sailing. More details at https://github.com/ublue-os/main

Apparently they have this uBlue Beyond project which is a thin layer on top of stock GNOME by Cassidy James Blaede, the previous lead dev of ElementaryOS, to make is a little less opinionated, so comes with dash-to-dock and other little niceties out of the box: https://github.com/ublue-os/beyond

Man, immutable Linux is like living 5 years in the future.

Saukkis
May 16, 2003

Unless I'm on the inside curve pointing straight at oncoming traffic the high beams stay on and I laugh at your puny protest flashes.
I am Most Important Man. Most Important Man in the World.

Son of Thunderbeast posted:

code:
Loaded: loaded (/home/thunderbeast/.config/systemd/user/cliappservice.service; disabled; vendor preset: enabled)
Active: inactive (dead)

systemd[1006]: Started CLI App Service
cli-app[2155]: Error: unknown command "configfile.json" for "cli-app"
cli-app[2155]: Run 'cli-app --help' for usage.
e: I'll just keep troubleshooting, I'll figure it out eventually

Can you show us what cli-app --help lists? For me it feels that 'cli-app --service --config configfile.json' would be the correct syntax.

Nitrousoxide
May 30, 2011

do not buy a oneplus phone



Lifroc posted:

I'm here to once again spread the world of immutable Linux. Today I'm test driving uBlue, which is a small layer on top of immutable Fedora to add conveniences such as pre-installed hardware acceleration packages, distrobox, and other small packages.

The beauty of it is that you just need a simple
code:
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/VARIANT:38
and Bob's your Uncle. I've switched from Fedora Kinoite (immutable KDE) to its equivalent ublue-os/bazzite-main and it's smooth sailing. More details at https://github.com/ublue-os/main

Apparently they have this uBlue Beyond project which is a thin layer on top of stock GNOME by Cassidy James Blaede, the previous lead dev of ElementaryOS, to make is a little less opinionated, so comes with dash-to-dock and other little niceties out of the box: https://github.com/ublue-os/beyond

Man, immutable Linux is like living 5 years in the future.

Make sure to follow the instructions to reset ostree reset first since if you have any overrides and the new image doesn't have those applications anyway I think it can bork things.

Voodoo Cafe
Jul 19, 2004
"You got, uhh, Holden Caulfield in there, man?"

Son of Thunderbeast posted:

I'll try the forking option, thanks! And yeah it's set up as a user service

Just write a shell script that invokes it correctly and have systemd call that instead

e.g. in /home/thunderbeast/bin/launch_cli-app

code:
#!/bin/bash

/bin/cli-app service config /path/to/config/file
chmod +x /home/thunderbeast/bin/launch_cli-app

Test running the service with /home/thunderbeast/bin/launch_cli-app to make sure it works

Then in your systemd service:

code:
[Unit]
Description=Description
After=network.target

[Service] 
ExecStart=/home/thunderbeast/bin/launch_cli-app 

[Install] 
WantedBy=default.target RequiredBy=network.target
and systemctl --user enable --now your service

Klyith
Aug 3, 2007

GBS Pledge Week

Lifroc posted:

I'm here to once again spread the world of immutable Linux.

So one question I have about immutable stuff is, how do you do system level config changes?

Like, I made a .rules file in /etc/udev/rules.d/ to stop my mouse from waking up the PC when it's asleep. How do immutable systems handle that, is there a separate location for config that's layered over the top?

That would be kinda cool actually. Here's all the stuff I've done to configure the system in one place, easy for backups and troubleshooting if something I did before is now bad.

BlankSystemDaemon
Mar 13, 2009



Immutable works for kiosk systems, not for personal computers. :colbert:

Last Chance
Dec 31, 2004

BlankSystemDaemon posted:

Immutable works for kiosk systems, not for personal computers. :colbert:

Tell that to apple, which I believe has made macOS mostly immutable?

Nitrousoxide
May 30, 2011

do not buy a oneplus phone



Klyith posted:

So one question I have about immutable stuff is, how do you do system level config changes?

Like, I made a .rules file in /etc/udev/rules.d/ to stop my mouse from waking up the PC when it's asleep. How do immutable systems handle that, is there a separate location for config that's layered over the top?

That would be kinda cool actually. Here's all the stuff I've done to configure the system in one place, easy for backups and troubleshooting if something I did before is now bad.

/etc and /var (and /temp of course) are mutable in ostree.

It's still shipped in the image, but it will overlay any changes you make to it on top of and overwrite the standard files.

It also keeps track of the changes you made to it compared to the defaults so if you run
code:
ostree admin config-diff
you should be able to see what is different from the image's copy of /etc if you need to roll something back because you hosed up a config.

Here's a more detailed article on the directory structure

https://ostreedev.github.io/ostree/adapting-existing/
Edit and this is a more regular english version:
https://docs.fedoraproject.org/en-US/fedora-silverblue/technical-information/

BlankSystemDaemon posted:

Immutable works for kiosk systems, not for personal computers. :colbert:

Remarkable how wrong one person can be.

Nitrousoxide fucked around with this message at 17:44 on Jun 30, 2023

BlankSystemDaemon
Mar 13, 2009



Last Chance posted:

Tell that to apple, which I believe has made macOS mostly immutable?
I stopped using macOS more than half a decade ago, so I have no real opinions on it.

Kibner
Oct 21, 2008

Acguy Supremacy

Last Chance posted:

Tell that to apple, which I believe has made macOS mostly immutable?

And Valve with the Steam Deck.

F_Shit_Fitzgerald
Feb 2, 2017



This is dumb, but: how do you rm and mv files using variables in bash?

I use Music on Console, which I really like. But when I modify a playlist, I have to add the song, save the new playlist with a garbage name (e.g: aa.m3u), then cd to my Music directory and delete the old playlist and replace it with aa.m3u. I'd like to use a bash script to automate this somewhat but my test script that uses
rm ${name}.m3u
mv aa.m3u ${name}.m3u

doesn't work.

Volguus
Mar 3, 2009

Nitrousoxide posted:


BlankSystemDaemon posted:

Immutable works for kiosk systems, not for personal computers. :colbert:

Remarkable how wrong one person can be.

Yes, BlankSystemDaemon is obviously wrong. It's not only kiosk systems, but also appliances. Single purpose systems. Such as, as we can see, Steam Deck. The immutable OS makes perfect sense there, there is absolutely no reason why it wouldn't be. Chromebook would be another one as well (no idea if they're immutable, but it would fit).

For a workstation that I would want to actually, you know, use? That's, of course, laughable.

Computer viking
May 30, 2011
Now with less breakage.

Though on the other hand, making a FreeBSD system where the base system is immutable (except select parts of etc and var), but the packages are free to clobber each other, would make a lot of sense. Boot environment based upgrades are already most of the way there, you'd just need to mount select parts RO at boot.

waffle iron
Jan 16, 2004

F_Shit_Fitzgerald posted:

This is dumb, but: how do you rm and mv files using variables in bash?

I use Music on Console, which I really like. But when I modify a playlist, I have to add the song, save the new playlist with a garbage name (e.g: aa.m3u), then cd to my Music directory and delete the old playlist and replace it with aa.m3u. I'd like to use a bash script to automate this somewhat but my test script that uses
rm ${name}.m3u
mv aa.m3u ${name}.m3u

doesn't work.

Put quotation marks around file names, i.e.
code:
mv aa.m3u "${name}.m3u"
Without them spaces in the variable will break things.

BlankSystemDaemon
Mar 13, 2009



Volguus posted:

Yes, BlankSystemDaemon is obviously wrong. It's not only kiosk systems, but also appliances. Single purpose systems. Such as, as we can see, Steam Deck. The immutable OS makes perfect sense there, there is absolutely no reason why it wouldn't be. Chromebook would be another one as well (no idea if they're immutable, but it would fit).

For a workstation that I would want to actually, you know, use? That's, of course, laughable.
Kiosk systems are a subset of appliance systems, but sure let's expand the definition to that.
ChromeOS also fit the definition of appliance systems, and the same is true for OrbisOS and XBoxOS.


Computer viking posted:

Though on the other hand, making a FreeBSD system where the base system is immutable (except select parts of etc and var), but the packages are free to clobber each other, would make a lot of sense. Boot environment based upgrades are already most of the way there, you'd just need to mount select parts RO at boot.
If select parts of a system aren't immutable, how is the system immutable?

Kibner
Oct 21, 2008

Acguy Supremacy

BlankSystemDaemon posted:

If select parts of a system aren't immutable, how is the system immutable?

How far do we want to go with that? If the whole system has to be immutable, including configuration, how do users work?

e: not a callout or anything, but I think it could be a good point of discussion. How far does an "immutable" system have to go to be considered "immutable"?

Nitrousoxide
May 30, 2011

do not buy a oneplus phone



BlankSystemDaemon posted:

If select parts of a system aren't immutable, how is the system immutable?

Yeah! How dare someone call a distro/OS immutable if something like /temp or /var is mutable. The system should only be able to read the image and do nothing with it whatsoever.

BlankSystemDaemon
Mar 13, 2009



Kibner posted:

How far do we want to go with that? If the whole system has to be immutable, including configuration, how do users work?

e: not a callout or anything, but I think it could be a good point of discussion. How far does an "immutable" system have to go to be considered "immutable"?
Well, OrbisOS pretty much does this - aside from installing games and doing a bit of customization on your profile, you're locked out of changing pretty much everything.

NanoBSD is another example, though it's perhaps less well-known. Configuration data is kept on /cfg, which is then copied to /etc at boot-up, with that and /var being md(4) devices.

Nitrousoxide posted:

Yeah! How dare someone call a distro/OS immutable if something like /temp or /var is mutable. The system should only be able to read the image and do nothing with it whatsoever.
I guess I'm distinguishing things that're part of hier(7) as being separate from the immutable, whereas since Linux has never really had a hier(7) that's been adopted by everyone, it's not really a concept anyone else would recognize.

Volguus
Mar 3, 2009

Nitrousoxide posted:

Yeah! How dare someone call a distro/OS immutable if something like /temp or /var is mutable. The system should only be able to read the image and do nothing with it whatsoever.

Well, appliances are not made for work, so "just reading the image" makes perfect sense. Of course, you can allow the user to write things, let's say in /tmp, which are lost upon reboot. Perfect for a public facing appliance. Let's just expand the definition of immutable to /var as well, since you do want logs (for support & diagnose things), and maybe could have /var/etc/ with overridden configuration changes (to the extend you let the user change their configuration).

Anything outside of that is, forbidden. IMO such a system can still be considered immutable. Beyond that, no.

Kibner
Oct 21, 2008

Acguy Supremacy

Volguus posted:

Well, appliances are not made for work, so "just reading the image" makes perfect sense. Of course, you can allow the user to write things, let's say in /tmp, which are lost upon reboot. Perfect for a public facing appliance. Let's just expand the definition of immutable to /var as well, since you do want logs (for support & diagnose things), and maybe could have /var/etc/ with overridden configuration changes (to the extend you let the user change their configuration).

Anything outside of that is, forbidden. IMO such a system can still be considered immutable. Beyond that, no.

Does the Steam Deck not count, in this case, because it allows for multiple users and install Flatpaks into their personal /home/{user} directories, which all persist across reboots?

NihilCredo
Jun 6, 2011

iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

"Immutable" distros (and I use one) would be more accurately described as "version-controlled".

You still write poo poo into /etc and install or upgrade packages, the difference is your mutations get captured into an atomic, reversible commit.

But "immutable" seems to have become the accepted slang term, however imprecise.

NihilCredo fucked around with this message at 19:06 on Jun 30, 2023

Nitrousoxide
May 30, 2011

do not buy a oneplus phone



Volguus posted:

Well, appliances are not made for work, so "just reading the image" makes perfect sense. Of course, you can allow the user to write things, let's say in /tmp, which are lost upon reboot. Perfect for a public facing appliance. Let's just expand the definition of immutable to /var as well, since you do want logs (for support & diagnose things), and maybe could have /var/etc/ with overridden configuration changes (to the extend you let the user change their configuration).

Anything outside of that is, forbidden. IMO such a system can still be considered immutable. Beyond that, no.

Neat, that's what OSTree does, mostly. Etc isn't symlinked to /var/etc though the original /etc is in /usr/etc/ so it can be restored any time.

Vavrek
Mar 2, 2013

I like your style hombre, but this is no laughing matter. Assault on a police officer. Theft of police property. Illegal possession of a firearm. FIVE counts of attempted murder. That comes to... 29 dollars and 40 cents. Cash, cheque, or credit card?

NihilCredo posted:

"Immutable" distros (and I use one) would be more accurately described as "version-controlled".

You still write poo poo into /etc and install or upgrade packages, the difference is your mutations get captured into an atomic, reversible commit.

But "immutable" seems to have become the accepted slang term, however imprecise.

Thank you. I've been unclear on what "immutable" really meant, what collection of properties it referred to, and this clarifies things ... some.

cruft
Oct 25, 2007

Yeah, it seems like the term got sort of expanded to mean things that it doesn't actually mean. When people talk about an immutable desktop OS, they're talking more about something like ChromeOS, where the base system is immutable, and then you overlay changes on top.

OSTree is a slightly different take on it that, to me at least, feels even further away from "immutable". But if we use the term "DJ" for someone who hits play on an iPod, and also for a soup-to-nuts music composer, producer, and performer; then we may as well let immutable mean all these things.

BlankSystemDaemon
Mar 13, 2009



Computer viking posted:

Though on the other hand, making a FreeBSD system where the base system is immutable (except select parts of etc and var), but the packages are free to clobber each other, would make a lot of sense. Boot environment based upgrades are already most of the way there, you'd just need to mount select parts RO at boot.
Also, minor nit, but I just remembered that I forgot to mention this.
FreeBSD is already "immutable" in the sense that pkg(8) doesn't touch any of the base system.

Volguus
Mar 3, 2009

Kibner posted:

Does the Steam Deck not count, in this case, because it allows for multiple users and install Flatpaks into their personal /home/{user} directories, which all persist across reboots?

We can call mickey mouse immutable if we want.

Klyith
Aug 3, 2007

GBS Pledge Week
I feel like the sense that the system is immutable is "even if you have root you can't alter any OS files".

Not "the machine runs off a SD card with the slider set to read-only".

Computer viking
May 30, 2011
Now with less breakage.

BlankSystemDaemon posted:

Also, minor nit, but I just remembered that I forgot to mention this.
FreeBSD is already "immutable" in the sense that pkg(8) doesn't touch any of the base system.

Well yes, that's why I think making the base system read-only outside logs and config overrides would be a fairly simple thing to do - if you want to update the base system, write to a new boot environment and reboot into that instead of changing the existing files. It doesn't seem against the spirit of Boot Environments, and at the same time it fits the "making updates atomic checkpoints" description of an immutable system from NihilCredo.

Apart from the packages. But it seems like you could do the same thing to /usr/local if you really wanted - clone it, update the clone, reboot with the clone at /usr/local. You'd have to do some work with /usr/local/etc and with packages that expect to write to some sort of data folder outside the user's home directory, but in a way that's work already done by nanoBSD.

Computer viking fucked around with this message at 21:06 on Jun 30, 2023

ExcessBLarg!
Sep 1, 2001

Volguus posted:

Chromebook would be another one as well (no idea if they're immutable, but it would fit).
Chrome OS has always been immutable with A/B images. Part of the immutability is that sensitive files in the file system are signed as part of the verified boot process (for verified mode and enterprise enrolled devices).

ExcessBLarg!
Sep 1, 2001

Lifroc posted:

Man, immutable Linux is like living 5 years in the future.
It's weird, I haven't specifically used immutable Linux outside of Chrome/Steam OSes. But my primary desktop is a Chromebox, so in another sense I've been using an immutable OS for the past decade. I'm just not the one janitoring it. Which may be the point, actually.

Son of Thunderbeast
Sep 21, 2002

Voodoo Cafe posted:

Just write a shell script that invokes it correctly and have systemd call that instead
Thanks for this! This approach (combined with a bunch of other stuff) got me up and running!

The other key was learning about the journalctl command. By running journalctl --user -xeu cliappservice -b I was able to see what the actual error was preceding the help output, and learned that it was failing a stat /path/configfile.json which led me to checking permissions on all involved files, as well as the entire directory tree. Added read capability to the all users group for /home/thunderbeast/ which didn't have it.

THEN, for some reason, the error started saying it couldn't stat the configfile in a directory I didn't even specify anywhere (one level up from where it actually is and where I was pointing at). After trying to wrestle with that for a bit, I said gently caress it and moved configfile.json into /home/thunderbeast/ and holy poo poo it finally loving worked lmao

Final config:

cliappservice.service
code:
[Unit]
Description=Description
After=network.target

[Service]
ExecStart=/home/thunderbeast/bin/agentstart
Type=forking

[Install]
WantedBy=default.target
RequiredBy=network.target
agentstart:
code:
#!/bin/bash

/home/thunderbeast/bin/cli-app service config ./bin/configfile.json
You may note that I still have ./bin/configfile.json even though it apparently doesn't need it, because the service is actually using the file one level up in /home/thunderbeast/. I do intend to fix that at some point, but for right now I'm just stoked it's finally fuckin working, I'll figure out the specifics of why later lol

Thanks for the help!

Son of Thunderbeast fucked around with this message at 22:08 on Jun 30, 2023

olives black
Nov 24, 2017


LENIN.
STILL.
WON'T.
FUCK.
ME.
Speaking of FreeBSD, how many of Theo de Raadt's criticisms hold up 10 years later? (Starts @1:21)

https://youtube.com/watch?v=OXS8ljif9b8&feature=shareb

BlankSystemDaemon
Mar 13, 2009



Computer viking posted:

Well yes, that's why I think making the base system read-only outside logs and config overrides would be a fairly simple thing to do - if you want to update the base system, write to a new boot environment and reboot into that instead of changing the existing files. It doesn't seem against the spirit of Boot Environments, and at the same time it fits the "making updates atomic checkpoints" description of an immutable system from NihilCredo.

Apart from the packages. But it seems like you could do the same thing to /usr/local if you really wanted - clone it, update the clone, reboot with the clone at /usr/local. You'd have to do some work with /usr/local/etc and with packages that expect to write to some sort of data folder outside the user's home directory, but in a way that's work already done by nanoBSD.
It isn't really different from how netbooted FreeBSD is configured by default, and it's fairly easy to do with ZFS as you just need to set readonly=yes on a few datasets:
pre:
NAME                                              USED  AVAIL  REFER  MOUNTPOINT
tank                                              384K   832M    96K  /tank
zroot                                             154G  61.2G    96K  /zroot
zroot/swap                                       17.0G  77.2G   960M  -
zroot/tmp                                        8.63G  61.2G  8.63G  /tmp
zroot/usr                                        23.2G  61.2G    96K  /usr
zroot/usr/doc                                     733M  61.2G   733M  /usr/doc
zroot/usr/home                                   15.1G  61.2G  15.1G  /usr/home
zroot/usr/ports                                  4.59G  61.2G  4.59G  /usr/ports
zroot/usr/src                                    2.77G  61.2G  2.77G  /usr/src
zroot/var                                         785M  61.2G    96K  /var
zroot/var/audit                                    96K  61.2G    96K  /var/audit
zroot/var/crash                                   779M  61.2G   779M  /var/crash
zroot/var/log                                    1.48M  61.2G  1.48M  /var/log
zroot/var/mail                                   5.05M  61.2G  5.05M  /var/mail
zroot/var/tmp                                      96K  61.2G    96K  /var/tmp
As far as installing into boot environments go, src/tools/build/beinstall.sh takes care of that already.

So fun, I guess?

Computer viking
May 30, 2011
Now with less breakage.

This is one of those things where the more I think about it, the less foreign it feels. An immutable FreeBSD would hardly take more than tying together a few existing parts, and could even end up feeling ... reasonable?

The heaviest work would be to make pkg upgrade work in a clone and swap over at reboot (spiritually similar to BE), I guess - plus the fallout from a lot of ports expecting all of /usr/local to be rw at runtime.

Voodoo Cafe
Jul 19, 2004
"You got, uhh, Holden Caulfield in there, man?"

Computer viking posted:

This is one of those things where the more I think about it, the less foreign it feels. An immutable FreeBSD would hardly take more than tying together a few existing parts, and could even end up feeling ... reasonable?

The heaviest work would be to make pkg upgrade work in a clone and swap over at reboot (spiritually similar to BE), I guess - plus the fallout from a lot of ports expecting all of /usr/local to be rw at runtime.

Isn't FreeNAS/TrueNAS basically an immutable FreeBSD? As far as i remember, it boots a read only image and applies any changes made in the UI as an overlay of some sort

edit: it is very much an appliance though, not a general purpose distro

BlankSystemDaemon
Mar 13, 2009



Computer viking posted:

This is one of those things where the more I think about it, the less foreign it feels. An immutable FreeBSD would hardly take more than tying together a few existing parts, and could even end up feeling ... reasonable?

The heaviest work would be to make pkg upgrade work in a clone and swap over at reboot (spiritually similar to BE), I guess - plus the fallout from a lot of ports expecting all of /usr/local to be rw at runtime.
I'm not sure what it'd get you, though - if you're actually using the system, you don't want immutability because of the slight annoyances it introduces, and if you're using it in a setting where it makes sense to have it truly immutable, then you probably need to do way more to it to turn it into a proper appliance OS.

Voodoo Cafe posted:

Isn't FreeNAS/TrueNAS basically an immutable FreeBSD? As far as i remember, it boots a read only image and applies any changes made in the UI as an overlay of some sort

edit: it is very much an appliance though, not a general purpose distro
Well, strictly speaking the answer is no. FreeNAS and forks/descendants are appliances that include a lot more code than just FreeBSD - but it's not completely wrong either.
It's using a descendant of the NanoBSD scheme mentioned above, that originally got implemented in m0n0wall.

It also gets used in pfSense and its forks, because that itself a fork of m0n0wall.

BlankSystemDaemon fucked around with this message at 00:34 on Jul 1, 2023

Lifroc
May 8, 2020

For immutability to work on any OS you need:

* An agreed-upon set of standard software to make your base desktop

* Easy and flexible container system

* A containerised App Store-like for userspace applications.

Linux has all three: standard DEs like KDE/GNOME, Linux namespaces, and Flatpak.

I haven't used FreeBSD in 20 years, but AFAIK it doesn't have Flatpak/Flathub or its Jails equivalent.

It's not immutable if you install all your software through a regular package manager into /usr.

NihilCredo
Jun 6, 2011

iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Context: I want to run some web services that are a bit too heavyweight for my Raspberry Pi. I did some napkin math and figured that even purchasing the cheapest mini-server on the second-hand market would take 3-4 years to break even in costs, compared to simply running my gaming/coding desktop 24/7 and sucking up the electricity prices, which would also be more convenient in other ways (less stuff around the house, fewer devices to admin, better perf). So I'm now looking at how I can get it to idle as cheaply/quietly as possible.

Question: I have noticed that, by physically disconnecting the GPU from the turned-off monitor, the power draw at the wall goes down by 15-20W (compared to turning off the monitor but leaving the cable connected). Can this behaviour be toggled via a script? I.e. set/unset a flag that tells the GPU "pretend your cable is disconnected"? The GPU is an AMD RDNA3 model, if relevant.

Adbot
ADBOT LOVES YOU

Hadlock
Nov 9, 2004

Maybe look at a used laptop. They're practically free

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply