Multi-Session live USB (Fatdog 8)

[rufwoof]

Multi-session usb. Very similar to cd/dvd, where you can boot entirely from a usb stick with a bootloader installed and all system and multi-session save files contained within that; Remove the usb stick once booted and only reinserting the usb again if you want to perform a save.

http://murga-linux.com/puppy/viewtopic. ... 56#1028256

To 're-burn' ... its as easy as moving all of the multi-session files off the usb (or even just delete them) and click the Save-Session icon.

[Flash]

Thanks for pointing that out.

So each session is saved in a separate directory on the USB stick. I could examine a particular session for suspected malware, or skip that session when booting? (As with a multisession CD or DVD.)

[rufwoof]

From my perspective, exactly the same Flash. But not directories, each save is a sfs file, so you can just click to open each/any of those. (Isn't that the same as with CD/DVD ?).

You can also boot with the 'skip' parameter i.e. if there are 20 saves you could set the skip number to 5 to omit loading the last 5. It's the very last parameter of the savefile boot parameter, for instance my Fatdog normal grub4dos menu.lst kernel line is ...

kernel /vmlinuz rootfstype=ramfs video=640x400 savefile=direct:multi:sda1::

so setting it to skip 5 as above means it would look like

kernel /vmlinuz rootfstype=ramfs video=640x400 savefile=direct:multi:sda1::5

Rather that booting a DVD, blanking it, burning a new image and then saving the current session to that, for a usb multi-session you can just delete (or move) the existing saves and then click the desktop Save Session icon - to in effect combine all of those multiple prior saves down to one. Or a variant of that if you use two usb's in a similar manner to how I believe you rotate between using two DVD's.

And of course you can fit more than 4GB of history onto a USB. Mine is 8GB for instance so twice as much room for save files. In practice however most likely you'd never get anywhere near even the 4GB DVD space limit - let alone multiples of that.

[rufwoof]

A neat feature of usb multi-session is that its quick and easy to jig thing. For instance I installed Google Chrome which in Fatdog also means gtk-3 being installed, saved that to a multi-session then later I realised that save also included the 65MB or so install file having been stored in /root and hence in the save ... that wasn't wanted. So I just deleted that save sfs, and resaved without the google install file in /root. I guess I could even have unsquashed a copy of that save sfs, deleted the unwanted file and re-squashed it again as a alternative approach.

Yes in some respects that greater flexibility could also be considered a risk factor, but if you pull out the usb after having booted that risk is pretty much mitigated.

[rufwoof]

Booted the 8GB USB I've been using for multi-session, which being the first to boot showed as sda1 on the desktop. Removed the usb once booted (so no sda1 desktop icon showing anymore), inserted another 16GB USB and used Fatdog's gparted to remove existing partitions on the USB and created a single ext3 partition (I used all available space for that partition). Also used gparted Manage Flags to set (tick) the boot flag option. That then showed as being sda1 on the desktop.

Fatdog also includes grub4dos installer, so used that to install grub4dos onto the USB. Plugged in my other 8GB usb that I'd used to boot from and copied over the menu.lst, initrd (that has fd64.sfs i.e. the main sfs integral within that initrd), and vmlinuz from that 8GB to the 16GB usb stick. That was slow, so I guess a better way would have been to have copies of those files on HDD and have copied them to the 16GB from HDD. Once the copying had finished I removed my 8GB stick that I'd copied from and clicked the Save Session desktop icon. That 16GB now boots/runs fine, in effect a duplicate of the 8GB stick and its saves (Fatdog configuration changes) but having just the two multi-session save files (base and save) - in effect having condensed down the 6 or so multi-session save files that were on the 8GB stick into just the single multi-session save file(s).

[tallboy]

rufwoof, on a multisession CD, the saves are not .sfs, but ordinary folders with the save date attached. If there are several save-folders, the latest one is read first, so that files in older folders cannot overwrite a newer version when they are copied with cp. I guess it also save some time.

[rufwoof]

[tallboy]

In a multisession CD/DVD bootup, you can use the boot parameters puppy pfix=n, where n is the number of saved session folders that you want to exlude from beeing loaded, starting with the latest. That places a file named .badfolders in /, and if you save the session without remembering to remove the invisible file, it permanently disable loading of the folder(s) at bootup.

I have almost always booted from a live Puppy on a multisession CD-R, or, at a few occations, from a DVD-R, and have been satisfied with that solution.
I now have a frugal install to a HDD on this PC, and it annoys me that it runs in pupmode 12, which means that it continuously save everything, almost as if it was a full install. I tried to fool the system to use pupmode 13, by using a fake entry of SSD, and specified save at shutdown and no automatic saves, but then the save2flash button on the desktop did not save everything it should save, and it made a real mess of everything.

[rufwoof]

With a single ext3 formatted usb stick partition, along with grub4dos installed onto that, and a menu.lst of

Code: Select all

 
title Fatdog USB Multi-session  
  root (hd0,0)
  kernel /vmlinuz savefile=direct:multi:sda1::
  initrd /initrd

Note no rootfstype=ramfs kernel boot parameter ... so the above is using tmpfs - which includes support for using swap as part of tmpfs (that does however mean that is smaller ram systems Fatdog might not boot (I'd guess if less than 2GB of available RAM)).

I've also set up a HDD linux-swap partition, 16GB on the second partition (first partition is used for storing data). And at the end of /etc/rc.d/rc.local I've added

Code: Select all

# Need to be careful as sda,sdb etc are somewhat dynamic, so here
# we check that our intended sdb2 swap partition is actually present
# as sdb2
CHK=`sfdisk -l /dev/sdb | grep swap | grep sdb2`
if [ ! -z "$CHK" ]; then
	# Create the encrypted swap /dev/mapper ...
	cryptsetup open --type plain --key-file /dev/urandom /dev/sdb2 cswap
	mkswap /dev/mapper/cswap 
	swapon /dev/mapper/cswap

	# My swap partition is 16GB, so I resize pup_save and tmp to match that
	mount -o remount,size=16G /aufs/pup_save
	mount -o remount,size=16G /tmp
fi

In Event Manager I've set the save duration to 0 (zero), which means once the laptop has booted I can pull out the usb and all system and saves are stored in ram (only need to reattach the usb if a save is being made).

On my first HDD partition that I use for storing data, I created a top level folder and used Fatdog's rox right click Encrypt Folder option to secure that. So all data/files stored within that are secure in the event of the laptop being lost/stolen.

That's all working incredibly well. Boot, pull USB and all runs in ram, with data safe in a encrypted HDD folder. As a test for the encrypted swap I created a 14GB file in /root (dd if=/dev/zero of=bigfile bs=1G count=14) and not only did that run through relatively quickly (being run in 'ram'), but the system continued running reasonably well (did slow some due to using swap, but comfortably/usable slowed, not impatiently/crippled slowed).

So we ...

1. Boot using usb stick, that also contains our 'saves' and where the usb is removed after bootup, so there's no way for a cracker to crack a running system and modify any of the boot, system or save files.

2. We only save dot (configuration changes), and only after booting a 'clean' version, making the changes and creating a 'save' of those changes. Otherwise we just boot, use, shutdown without saving. That way we keep a 'clean' system that is booted each/every time.

3. If the usb is lost/stolen, it only contains openly available stuff anyway. Fatdog system files, plus our save files that just contain configuration changes (dot files).

4. Our data is stored on HDD, under a encrypted folder. So if the laptop is stolen that data is within a encrypted folder (secure - excluding if the encryption is broken/cracked).

If the usb and/or laptop is stolen, we're still relatively secure.

Whilst online, if a session is cracked, then that cracker cannot modify any of the boot, OS, configuration files, as they're on usb - that is physically disconnected. They could destroy our data folder/content, so its important to maintain disconnected backups of that. For online banking we can boot a clean session, go directly to our banks web site, nowhere else before or after, and reboot again afterwards. Even with outdated software (browser etc.) that is pretty safe/secure.

Yes a single session could have userid/passwords used for sites revealed via a crack. But that's comparable if not lower risk than a site having all of its userids/passwords (and other) data cracked/stolen. Where that is low risk site stuff however, not our banking userid/password, then that's a commonly accepted risk factor.

Whilst all being relatively simple to setup and use. Fatdog is great in the respect it comes ready out of the box and typically works very well 'as-is'. All pre-setup as a desktop system for the things most people do/use without having to learn the in depth things required to otherwise install/configure programs.

[tallboy]

I guess I'll have to test a Fatdog!
The problem is that those dogs are very fat! My oldest PCs don't have enough memory for loading the whole live CD into RAM, but I'll test on a newer PC.

[rufwoof]

On my 4GB laptop Fatdog works very well (I've also set a 16GB encrypted swap for that on HDD). On another 2GB desktop it also works very well. https://distro.ibiblio.org/fatdog/web/ states 1GB minimum.

[tallboy]

My old boxes are 32-bit, with 500 or 756 Mb RAM...

[rufwoof]

Scenario : Boot fatdog from usb, with fd64.sfs extracted from initrd and re-squashed using lz4 (faster decompression/extraction) and that new fd64.sfs stored on hdd. Multi-session saves, saving back to the usb. When save session interval is set to zero you can unplug the usb once booted so that your MBR/bootloader/kernel and saves are physically isolated from the running system (that's running totally in ram). HDD can also be unmounted.

A good (IMO) choice of menu.lst entry for that arrangement is as outlined in this post ... http://murga-linux.com/puppy/viewtopic. ... 32#1033432