Fatdog is a versatile operating system
This is a living document. I will update this when there are more use cases to show off.
1. Background
1.1 Why this article exist
1.2 How the article is structured
2. Use cases as portable operating system
2.1 Portable operating system
2.2 Portable secured operating system
2.3 Portable secured key
2.4 Rescue disc/USB
3. Use cases in distributed systems
3.1 Fatdog in training rooms
3.2 Roaming diskless desktops
3.3 Diskless Linux graphical terminals
3.4 Diskless Windows graphical terminals
3.5 Compute farms
4. Use cases in virtualised environments
4.1 Fatdog as a VM host
4.2 Fatdog as a VM guest
5. Customising Fatdog
5.1 Customising Fatdog startup/shutdown
5.2 Building your own Fatdog packages
5.3 Meta-Distribution: Building your own custom ISO
Appendix A. Fatdog Linux operating system
Appendix B. Acknowledgements
1. Background
1.1 Why this article exist
Somebody in the Puppy Linux forum recently complained to me that whenever a new feature was mooted for Puppy Linux and/or its derivaties, I often said that Fatdog can already do the feature that was being proposed. He complained that he didn't even know that particular feature of Fatdog existed, until I compared it with others; that sometime he knew of certain feature only by digging through the code. He suggested that I should write and explain more about Fatdog features rather than meddling with other people's thread.
Well, he's right about most of it. Myself and Kirk, we never explain what exactly Fatdog is capable of. In our excerpt we wrote that Fatdog is versatile, but we never explain why we think so.
We have some a collection of FAQs but they are just that, a collection of question and answers. There is no comprehensive document that really put a light on what Fatdog can actually do.
I actually had planned to write an article like this for a very long time; but I didn't do it because I thought the versatility of Fatdog was self-evident to its users. Perhaps it does; but it is probably more helpful if it is explained more explicitly.
So here we go.
1.2 How the article is structured
The article describes various use cases that Fatdog is capable of. It is not a catalogue of features or configuration settings or the like; but rather, some real-life scenarios in which Fatdog could be used for.
To make them easier to navigate, I attempt to categorise them together in some logical way.
It focuses on how Fatdog can be used for, most of the time, out of the box, without a lot of meddling or customisations. If (heavy) customisations I would point that out. Of course, with any setup, some work would be necessary on your part - e.g. some use cases deal with setting up PXE boot server for many different client machines; there must be some kind of work involved.
For each use case, I explain what the scenarios are and how Fatdog can fill the niche. I don't explain in details of how to actually do the setup or the detailed instructions and commands and boot parameters; after all they are use cases and not examples. You can mostly find what you need by reading Fatdog FAQs. If you can't find what you need, you can always ask in Puppy Linux forum that Fatdog piggy backs on.
I may write a follow-up article(s) expounding the use cases here, giving examples with detailed instructions. But no promises :)
2. Use cases as portable operating system
2.1 Portable operating system
Fatdog is installed in USB flash drive. Rest of the freespace is converted into save directory (or savefile) partition. Fatdog is configured to run using the RAM layer. Fatdog is configured so that any changes is only saved back to the USB flash drive only when you explicitly ask for it.
You have a portable operating system with your data that you can bring anywhere and boot on any 64-bit machines. It comes with all your data and customisations. Changes in a session are never saved except when you ask for it.
As a variant, you can enable multi-session. Each session changes are recorded as a separate compressed file, saving file storage; and yet you can still see exactly what the changes are (as individual files, not as undecipherable data blocks).
2.2 Portable secured operating system
Fatdog is installed into a USB flash drive. The extra free space is formatted as LUKS partition. Inside the LUKS partition, an encrypted LUKS savefile is created.
Fatdog will boot on any machines on which you can control the bootloader, and you will have your session data with you at all times in the USB flash drive. Your data is secured at all times.
2.3 Portable secured key
This is a variant of the above. You have a machine with internal storage. There is no operating system installed on that internal storage - in fact, the entire disk is partitioned as a single (or multiple) LUKS partition(s).
You have Fatdog installed into a USB flash drive, which you use to boot you the machine. Fatdog boots up and ask you for the LUKS password, then mounts the internal storage as its save directory.
As another variant, you have LUKS on the USB flash drive too which is used as a save directory (or savefile if you like). This LUKS in the drive contains files which is used as keys to decrypt the LUKS partition in the internal storage; which is now being used as a data disk instead of a save-directory disk. In this case, make sure you don't lose your USB flash drive or you can never unlock the internal drives again.
2.4 Rescue disc/USB
I know there is already a ton of specialised rescue discs. I have used them myself. But what if you encounter a situation that requires your immediate attention, and you have no time to download any of these specialised tools; and what you have with you is Fatdog USB in your pocket?
Fatdog comes with some tools which can be used to rescue borked systems:
- It comes with filesystem checker and fixers (mainly e2fsck,
but also dofsck and ntfsfix and a few others).
- It comes with Gparted for easy re-partitioning of your system.
- It comes with partimage to make a backup of your partition.
Of if you don't bother, you can use dd too.
- If restoring the borked system is not possible or not permitted
by time, you can get a portable harddisk (or another flash drive)
and copy over your valuable data off disk. Fatdog supports many
filesystems, you will be hardly pressed to find one that Fatdog
doesn't support.
- If you don't have any external media handy and you still need
to copy your files somewhere, you will be happy to know that
as a full-fledge operating system Fatdog can easily connect to
the network and Internet, which means you can backup / upload your
files to your favorite Windows shared folder or your Google Drive,
whichever floats your boat.
- If you happen to have already installed
ntpasswd, you can even
change the Administrator password of your borked Windows system.
I didn't try this on anything newer than Windows 7, though ...
I hope the tool still works :)
- And lastly it will boot on any systems - BIOS, UEFI, Secure Boot.
3. Use cases in distributed systems
Fatdog unique ability to load its basesfs and savefile from networked resources is key to these use cases.
3.1 Fatdog in training rooms
Imagine you run a training class. Each student has a PC, the instructor also has a PC. You have a server that will hold the training materials.
Before the start of every session, you need to prepare each student PC to contain the right materials (PDF of the materials, samples, podcasts, etc). Once the training is over, you need to wipe out everything clean for the next session (which may or may be the same as the previous one).
How Fatdog can help
- Configure as server as a PXE boot server, serving Fatdog.
Fatdog is easy to serve over PXE as only two files are needed: vmlinuz and initrd.
(This PXE boot server could be powered by Fatdog too). - Optionally configure it to provide read-only NBD too for faster
boot time.
(Fatdog could power this NBD server too). - Configure the server to provide CIFS shares too - map each share
to a student PC.
(This CIFS server could be running Fatdog as well). - Make copies of a pre-packaged savefile that contains training material to all shares.
- Configure student PC for PXE booting.
How it works
- Student PC boots up, fetching Fatdog from PXE files.
- Optionally the basesfs will be loaded from NBD instead of from PXE, shortening boot times.
- The PXE configuration for each student PC will attempt to connect to a specific CIFS share - to load the savefile.
- Each student PC will use its own savefile, loaded over CIFS share that will be kept for the whole of the session.
- At end of the day, student PC is powered down but all of the day's session is kept for the following days.
3.2 Roaming diskless desktops
Imagine that you need to be mobile inside the building. There are diskless desktop workstations all over the place, but they are not assigned to specific jobs or people, they are just that - workstations.
You need to be able to access your work, your data, from any of these diskless workstations.
How Fatdog can help
- Configure a server as PXE boot server for all these diskless workstations (optionally configure it to provide read-only NBD for faster booting).
- Configure CIFS share for each of the users
- Configure the diskless workstations to do PXE boot
How it works
- You come to any of the workstation, and turn it on.
- The system asks for your username and password
- If password is accepted, boot proceeds to load savefile over the CIFS shares
- You have your desktop just as he/she left it before
- You have full control over the workstation and all of its capabilities
- When done, you turn off the workstation, saving energy.
3.3 Diskless Linux graphical terminals
You have low-powered machines all over the place in the building. If they are Intel boxes, they can boot via PXE. If they are ARM boxes like Cubox-i or Odroid U2/U3, they will boot from the internal SD card.
After booted, Fatdog will auto-login but display prompts for username/ password (or other sort of credentials) which will be used to launch remote X-session (to a powerful Fatdog machine acting as multiuser X server).
3.4 Diskless Windows graphical terminals
You have low-powered machines all over the place in the building. If they are Intel boxes, they can boot via PXE. If they are ARM boxes like Cubox-i or Odroid U2/U3, they will boot from the internal SD card.
After booted, Fatdog will auto-login and display prompts for username/ password (or other sort of credentials) which will be used to launch "rdesktop" (Remote Desktop client over RDP) - connecting to a Windows virtual desktop solutions.
3.5 Compute farms
You have a bunch of machines you want to use as "compute nodes". Each "compute node" is more or less homogenous, you want to run the same set of programs on each. Compute nodes are stateless, they all start in the same state and will listen to commands once they're up.
You want to run a light operating system on these nodes so that the machine's resources are used for computing/rendering, not to run the OS overheads.
How Fatdog can help
- Configure a server as PXE boot server for the compute nodes workstations.
- Take the basesfs out of Fatdog's initrd and serve it over NBD - this makes for faster booting and less RAM usage.
- Customise Fatdog to load the software you want to use for the nodes - your specialised compute programs, GPGPU, CUDA, OpenCL, drivers, etc - either by editing the basesfs, or by providing a read-only "savedisk" over NBD.
- Configure the compute nodes to do PXE boot.
How it works
- When the compute node boots up, it will load Fatdog from PXE boot server, customise itself over its basesfs or its read-only savedisk and ready itself to listen to commands.
Once the node is up and running you will need to write some sort of scripting agent to control its behaviour. The most popular one for doing so seems to be Puppet - but in a secured environment, it may be an overkill and you can instead use busybox nc to listen to a port use it to run the scripts of your choice.
Note: You'll need to enable RAM layer if you use a read-only NBD savedisk. As an alternative, you can serve other SFS-es over NBD too and customise the basesfs to mount and load these additional NBD SFS-es at boot time.
As a variant, if the compute nodes are supposed to maintain state, you can use CIFS and use a read/write savefile instead of a read-only NBD savedisk.
4. Use cases in virtualised environments
4.1 Fatdog as a VM host
You need to setup a bunch of development servers quickly, all isolated in their own virtual servers. E.g. you need to setup version control (e.g. git, cgit), database server (e.g. postgresql), application server (e.g tomcat), webserver (apache, nginx), mail server (postfix), etc.
Fatdog supports many different levels of virtualisation, depending on your needs for separation and resources sharing.
- If the servers don't need to be fully isolated from each other,
you can use Fatdog sandbox. Fatdog sandbox runs processes
inside a "chroot", and you can keep its state in a separate "savefile".
You can run multiple sandboxes at the same time.
- If you need better separation, you can run them inside Fatdog
lxc-sandbox. Fatdog lxc-sandbox run processes inside a separate
Linux container - OS-level virtualisation, if you wish. It starts
by running a copy of Fatdog inheriting the host's state, but you can
keep its state in a separate "savefile". Needless to say, you can
run multiple lxc-sandboxes at the same time.
- If container is not good enough for you, you can step up and use UML (User Mode Linux). UML is para-virtualisation; with UML Fatdog create an separate environment that runs a specialised kernel (User-Mode Linux kernel). All processes in that environment will run under UML kernel instead of the host's kernel. This UML kernel is a real Linux kernel (not a toy one), with all features and protection that a Linux kernel provides; except that it has been modified to be able to run on top of an existing Linux kernel instead of on bare hardware.
All the above runs the processes inside the running copy of Fatdog, saving resources somewhat (they are listed from most sharing to least sharing, from lightest to heaviest load).
But if these are still not suitable, of course you can run a fully virtualised solution using KVM (qemu-KVM) and you can run any operating system. This is the heaviest of all, but of course the most flexible and provides the most separation.
All these are controlled by command line programs. If you need a GUI, you can always install VirtualBox which also provides fully virtualised environment like qemu/KVM but comes with easy to use GUI management tool. With a little effort you can install phpVirtualBox and make that GUI available remotely too, over the web.
4.2 Fatdog as a VM guest
Fatdog supports most common virtualised environments out of the box:
- VMWare
- VirtualBox
- KVM
Fatdog is lightweight and as guest will boot up very quickly. It also consumes very little footprint - ideal for use as a VM guest, either for desktop or ad-hoc server purposes.
You can make it boot even faster and consumes even lesser memory by removing the basesfs from Fatdog's initrd and tell it to load its basesfs from a shared read-only NBD server (served by the host or by other Fatdog VM) - a CLI environment will require 100MB or less, and a graphical desktop can run with 170MB or less, depending on the services you want to activate/use.
5. Customising Fatdog
5.1 Customising Fatdog startup/shutdown
A good OS does not only provide features out of the box, but is also easy to customise, easy to mold to fit your own specific needs.
- Fatdog uses "busybox init" as its init system.
This is a very simple init, all it does it run commands it finds in
/etc/inittab
. One of the entries in this file tells busybox init to run/etc/rc.d/rc.sysinit
; which will run regular "services" in/etc/init.d
and system "services" in/etc/rc.d
. This model of init is closer to BSD than SysV. There are no run-levels.There is no process supervision too. If you need them, there are a ton of programs that can do that: runit (included in Fatdog's busybox), pmtr, and many others.
- System-level services can be started by adding files in
/etc/init.d
or by editing/etc/rc.d/rc.local
. If you need to do specific things at shutdown, do it in/etc/rc.d/rc.local.shutdown
. - All-users login profiles can be added in
/etc/profile.local
or/etc/profile.d
. Per-user login profiles goes to$HOME/.profile
as usual. Of course, this depends on the shell used; Fatdog uses bash running in POSIX mode by default. - All-users auto-start CLI applications are configured in
/etc/shinit
. Per-user auto-start CLI applications are configured in$HOME/.shinit
. This also depends on the shell used. - All-users auto-start X applications are configured in
/etc/xdg/Startup
. Per-user auto-start X applications are configured in$HOME/Startup
. If you need more control over what happens when X is started, look at/etc/rc.d/rc.Xservices
. - All packages installed in Fatdog's basesfs are recorded properly. You can remove them by:
- unsquashfs-ing the basesfs
- runing
removepkg
withROOT
environment variable pointed to the path unsquashed-root - mksquashfs-ing the directory again rebuild the basesfs.
installpkg
. Or you can just use Fatdog Remaster tool.
Or you can use meta-distribution tool.
5.2 Building your own Fatdog packages
Fatdog is an independent distribution, and being maintained only by two persons, we make no excuse that our package repository is not as comprehensive compared to other big Linux distros out there - even when including contributed packages from our helpful friends.
To compensate, we provide an easy-to-use tool to build your own packages from source.
This is not just a regular ./configure && make && make install
step; this is a way to make your own installable native packages just
like Fatdog one's - including an automated way to build many packages
at once.
Load Fatdog's devx.sfs
(this contains most dev of the tools you'll
usually need such as compilers, make, auto-tools, etc in one convenient
pre-packaged SFS) and look into /usr/src/pkgbuild
.
The tool is recipe-driven, you need to write a build recipe that tells the tool how/where to download source tarballs, check integrity, and build/install the packages. At completion, it will produce a .txz package(s) which you can then install/uninstall just like native Fatdog packages. As a bonus, packages produced this way are Slackware-compatible.
To get you started, we have included the build recipes for
all of our official packages; look at /usr/src/pkgbuild/pkg
.
You can use them as examples or as a base to write your own.
5.3 Meta-Distribution: Building your own custom ISO
For most common purposes, if you want to bake your own custom ISO, you can use Fatdog Remaster tool.
But for some very specific needs, you may want to build the custom ISO (or custom FatdogArm images) from scratch - for example if you're trying to build a cut-down version of Fatdog64 and you don't want to go through the hassle of removing individual packages from the basesfs as explained above.
For this, there is the meta-distribution tool. It is a build-system that enables you to build a custom Fatdog64 ISO / FatdogArm SFS packages from a given list of packages, from the ground up.
This whole process is called as "meta-distribution" - because in addition to the released official ISO / SFS, you can now easily build your own ISO or SFS as needed.
FatdogArm was released with this support since Alpha3 release. Fatdog64 got its meta-distribution support on its 702 release, with the release of Fatdog64 ISO Builder.
Appendix A. Fatdog Linux operating system
Fatdog Linux is a family of Linux operating systems, created by Kirk and myself. There are a few variants of Fatdog, two of which are currently public and actively maintained.
- Fatdog64 Linux -
the x86_64 64-bit variant of Fatdog Linux.
This is the flagship of Fatdog Linux, and actively maintained. Today, Fatdog64 is an independent, self-hosted distribution.
Fatdog64 Linux is a small yet versatile 64-bit multi-user Linux distribution. Originally created as a "fatter" (=more built-in applications) derivative of Puppy Linux, Fatdog has grown to become an independent, mature 64-bit Linux distribution while still keeping true to Puppy Linux spirit: small, fast and efficient.From Fatdog64 site - FatdogArm Linux -
this is the 32-bit ARMv7 variant of Fatdog Linux.
It is also maintained though less actively than Fatdog64. Like Fatdog64, FatdogArm is also independent, self-hosted distribution.
FatdogArm is a port of Fatdog64 to the ARM platform. Currently in Beta release, it is based on Fatdog64 and thus shares much of Fatdog64 features. Like Fatdog64, FatdogArm is intended for desktop-style operations but on the lower-cost ARM-based systems.FatdogArm currently was originally built on A10/Mele A1000 hardware, although it can be easily adapted for other platforms. These days, FatdogArm is known to run is A20/Cubieboard, Odroid-U2, Odroid-U3, OLPC XO-1.75, OLPC XO-4 Touch, Pandora, Cubox-i i2, Cubox-i i4pro, and Google Nexus7 2012.
From FatdogARM siteThe original porting process of FatdogArm from Fatdog64 is documented in this wiki as well, here.As it turns out, the automated process used to port Fatdog64 (then version 631) to FatdogArm was later re-used to rebuild Fatdog64 (version 700) from scratch. Things has gone in full circle.
FatdogArm has been adopted for use in real-life, production industrial environment.
- Fatdog Linux -
the original x86 32-bit variant of Fatdog Linux.
This was the original Fatdog. The very first Fatdogs were "puplets" (direct derivative of Puppy Linux built using its "remaster" process).
Later versions were built using Puppy Linux's "Woof" build-system (which was in its infancy at that time - in fact Fatdog was one of the first few "puppies" built from Woof); using packages from T2-SDE.
32-bit Fatdog is no longer maintained; its last release on August 2009.
- Fatdog-Like Linux - the derivative-based Fatdog.
These will be a collection of Linux operating systems derived from popular distributions, but will behave just like Fatdog does. It is similar like "Ubuntu" is a derivative of Debian, and "Mint" is a derivate of "Ubuntu"; a Debian-based Fatdog-Like Linux will be a Debian-derivative but will work just like a Fatdog.
It is similar in concept of how today's flagship Puppy Linux are actually derivative of popular distributions; e.g. "Puppy Linux Slacko" is a derivative of Slackware, Puppy Linux "Tarhpup" is a derivative of Ubuntu Tahr, etc.
This is now currently in alpha and not public yet. Prototype versions boot to graphical desktop with wired network connection working.
Both 32-bit and 64-bit x86/x86_64 versions are planned. ARM version is a little far down the road.
Most of what is written previously will apply to any flavours of recent Fatdogs - Fatdog64, FatdogArm, and in the future, to Fatdog-Like as well.
Due to restrictions on ARM bootloaders, some features cannot be made possible (e.g. if the ARM board does not support PXE booting then obviously you can't boot FatdogARM using PXE), but in general if the system supports it, all Fatdog flavours will support it too.
Appendix B. Acknowledgements
First and foremost, I'd like to acknowledge that many of Fatdog's features and traits are inspired by original features of Puppy Linux (originally created by Barry Kauler), of which Fatdog is a spiritual (and in past versions, direct) descendant.
Puppy Linux shares many of the Fatdog's features, and many of Fatdog features are actually improvement of existing Puppy Linux features (albeit independently re-implemented over the years).
I also like to acknowledge that some of the features of Fatdog originally came from suggestions, ideas, and requests (and sometimes complaints!) raised by both Fatdog and Puppy Linux community members from Puppy Linux forum; as well as inspiration from other distributions such as Slax Linux. We leave no good ideas unused :)