We are experimenting with saving some state information on the LiveUSB even if no persistence is enabled. Currently we save the desktop setting (window manager and icon manager), the alsa volume settings, and wireless networks and passwords. The alsa settings are saved on a machine by machine basis. Otherwise there will be conflicts and error messages because the alsa settings contain machine dependent information.

This should be transparent to you. What you may notice is that your choice of desktop, your wireless passwords, and your volume settings survive across reboots even if persistence is not enabled. There will also be messages about"saving state file ..." and"restoring state file ..." at startup and shutdown.

The files are stored under subdirectories in /antiX/state/ on the LiveUSB. The LiveUSB is normally mounted at /live/boot-dev when you are running Live. This directory should be created automatically the first time you boot the LiveUSB. You can control which files get saved by editing the files:These will be also be automatically created on the first LiveUSB boot. The defaults are:

machine-state-files:

/var/lib/alsa/asound.state

general-state-files:

/etc/wicd/*.conf
/etc/NetworkManager/system-connections/*
/etc/network/interfaces
/etc/network/interfaces.d/*

You can turn this off temporarily with the"nousbstate" cheat. You can turn it off permanently by touching the file /antiX/state/no-state. In the next release, the cheat code will change to"nosavestate" and"savestate". These will also touch and remove the no-state file so any change you make to enable or disable this feature with boot codes will survive reboots.

General state files are saved across all machines. This is being used to remember wireless networks and passwords. Machine state files are saved and restored on a machine by machine basis. If you only use the LiveUSB on one machine then they act like general state files but if you move the LiveUSB between machines then machine state files will only be restored to the machine they were stored on.

The reason for this is a conflict between making the LiveUSB work on different machines and saving the alsa volume. The file that stores the alsa volume also contains hardware specific information and will cause errors if it is used on a machine that has different hardware. To make a LiveUSB that has persistence general purpose (so it works on more than one machine) then we need to delete the volume information. Machine dependent state files keep a separate copy of the asound.state file for each machine the LiveUSB is run on. Machine are identified by a machine-id which is a hash of the files /sys/class/dmi/id/board_*.

The restoration of general state files and of the desktop session file is disabled if persistence is enabled. But the files are stilled stored at shutdown and will be available on the next non-persistent boot. The machine state files aways get used unless saving state is disabled. This should prevent alsa error when you move the LiveUSB between machines.

Sounds like a great idea.
Thanks!

This system can also potentially resolve the problem that of machines with wired on ethX and wireless on ethX in the same machine.

background: / etc/udve/70-persistent-net.rules keeps track of what interface (by MAC address) is assigned what label. This caused problems on the liveusb w/ persistence because evertyime you changed machines, you had to reset either wicd or ceni to use the correct interfaces. Our past solution was to simply not save 70-persistent-net.rules by default, so that for most users with ethX and wlanX, the names are always eth0 and wlan0. makes the cool conky net monitor stuff work as well.

but some combinations of hardware result in ethX for the wired and ethX for the wireless. and since we weren't saving the 70-persistent-net.rules file, udev was renaming these every boot. but udev allows for EITHER of the devices to be eth1 or eth0 (basically whichever it gets to first is eth0), and its not necessarily the same from boot to boot. which plays havoc with the live w/persistence setup on such machines, forcing users to manually reconfigure the interfaces when the labels switch.

procedure:
adding this line to the machine-state save file
and commented out that line in the two liveusb persistence excludes files (now accesible via control center, thank you!).

Now instead of simply resetting the interface names every boot, the system remembers what names go with what interface card, and and what machine.

Since I don't have interfaces with this issue, I've been using tracker text in the udev 70-persistent-net.rules file to make sure the file is going back and forth from the machine save to the proper machine, and it is. IMO, much more useful than saving the volume state.

dolphin_oracle wrote:... adding this line to the machine-state save file

Code: Select all

/ etc/udev/rules.d/*-persistent-net.rules

and commented out that line in the two liveusb persistence excludes files (now accesible via control center, thank you!).

Thanks! I will make it so. Should we do this with all of the *-persistent-*.rules files? That is what I will do unless told otherwise.

BTW: this saving state mechanism might be a bit of a security risk since you can use it to inject a file almost anywhere. Of course, you need to be root to do this and once you have root it is game-over security-wise. OTOH, the root password for the live system is well known. As we make the live system work more and more like the installed system, the security of the live system becomes more and more like that of the installed system.

One way to make saving state a little more secure is to do away with the config files that let the user specify which files get saved. This makes a security breach a little less trivial once someone has root but it won't stop a determined attacker.

We could greatly increase the defense against network attacks by forcing users to change the root and demo passwords. If you have root persistence enabled then I believe you can do this now with the pw=root,demo cheat but I have not tested this recently. We could also create random passwords for root and demo that get displayed on the screen. I'm not suggesting we do this now but I think it is good to look for a path forward that makes the Live system more secure. A few years ago I experimented with running the Live system from an encrypted partition. We might want to have a more secure version of antiX/MX but not for antiX-15. I will try to make sure the pw=... boot parameter works even if root persistence isn't enabled. We could even add this to the F4-Options menu. H'mm. We could then add the / etc/shadow and / etc/passwd files to the list of state files so the new passwords are remembered across reboots. Just thinking aloud here.

I *think* we could make it work so the user is forced to change the passwords just once and then the shadow and passwd files will be saved as state files. We could do this with a cheat like"secure" or"securepw" or"forcepw". I like the idea of keeping the convenience of well-known passwords as the default but providing an easy security upgrade via a boot parameter. Forcing people to change the passwords on a LiveUSB system (or maybe even any Live system) could even be an option in the remaster and snapshot programs.

Thanks! I will make it so. Should we do this with all of the *-persistent-*.rules files? That is what I will do unless told otherwise.

I don't think it would hurt anything, but the 70-persistent-net.rules file is the only one generated in / etc/udev/rules.d on my system(s)

BTW, the 70-persistent-net.rules file is apparently created/update by /lib/udev/write_net_rules.

dolphin_oracle wrote:... commented out that line in the two liveusb persistence excludes files (now accesible via control center, thank you!).

I'm glad it was useful. There is a slight problem though. I believe that button is in the"Live" tab and that tab goes away on installed systems so there will no longer be a button to edit iso-snapshot-excludes.list on installed systems. Maybe we can add another button on a different tab for editing that one file.

... the 70-persistent-net.rules file is the only one generated in / etc/udev/rules.d on my system(s)

That is the only one I've seen too but wonder if it makes sense to save all of the *-persistent-* rules: Maybe should erase all of these rules files except persistent-net. Also, The persistent-net rules file should definitely go on the machine dependent list (I'm pretty sure you already knew that). It looks like persistent-net is the only one that is auto-generated.

I'm not sure about these. I'm showing these in /lib/udev/rules.d. Do they actually store any information? If they are truly just rules and don't store any particular system information between boots, then saving them doesn't hurt, but probably doesn't do anything either. I'll poke around them tonight and see what I find.

dolphin_oracle wrote:I'm not sure about these. I'm showing these in /lib/udev/rules.d. Do they actually store any information?

Excellent point!