Installed bundles defined in /etc

Hi all,

Not sure if this should be a feature request on github or here.

I love the stateless nature of ClearLinux.

One problem that appears to me is the way in which bundles are installed. If I git my /etc/ directory I can then keep definition of the configuration of the system. The one thing that is not covered is the bundles that are installed. That means if I do a fresh install of clearlinux on a new machine and sync the etc directory I would still have to install the bundles per hand. So I could have my webserver defined but still have to install web-server-basic by hand.

Would it not better to have a file like /etc/bundles where I can then define which bundles are installed. The auto updater would then install them. Obviously I could make my own systemd service (saved in etc) but still would be useful for most users.

You can export the the installed bundles by

sudo swupd bundle-list > bundle.list

To install,

sudo swupd bundle-add $(cat bundle.list)
1 Like

Yes, you can do that.

My point is that which bundles are installed effectively part of the configuration of the system. So it would make sense to treat it as such and have a file in etc.

I think you mean something like pip lockfile or npm lockfile from which you can reconstruct a environment. This kind of feature request can be made on GitHub in clearlinux/swupd-client repository. But it may take a while until this feature is added if it’s adopted.

I think actually the clr-installer.yaml has the information that I need. One could update the bundles defined in it to recreate the system. Possibly by saving it in ect (keeping it in git).

My only question is what is the nature of the hash for the password?

I’m not sure if this is what you’re asking, but encrypt.go indicates a random salt using SHA512.

Sorry, what I wanted to know that if someone got hold of the hash that the password would be safe.

If you look in /usr/share/clear/bundles you’ll find all the bundles installed on your system. In /var/lib/swupd/bundles are all the bundles you manually (potentially via the installer so it may include things you don’t know about) added.

1 Like

The hash is using a random salt so the password isn’t going to be recoverable in practice.

2 Likes

I had previously read the source code for clr-installer and the function to generate the random salt explicitly require the programmer to return the generated salt to a unnamed special variable _ to avoid misuses. This design makes it impossible to recover the salt even by the programmer (and thus very secure).

Looking at clr-installer.yaml there are two types of bundles.

bundles: [c-basic, desktop-autostart, git, openssh-server, os-core, os-core-update,
      vim, NetworkManager, user-basic, sysadmin-basic, python3-basic, libreoffice, editors,
      desktop-apps, kbd, boot-encrypted]
userBundles: [user-basic, sysadmin-basic, python3-basic, libreoffice, editors, desktop-apps]

What is the difference between the two of them? Is that merely as they are set differently in the tui/gui?