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
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.
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 :)
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).
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.
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.
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:
Fatdog unique ability to load its basesfs and savefile from networked resources is key to these use cases.
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
How it works
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
How it works
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).
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.
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
How it works
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.
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.
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.
Fatdog supports most common virtualised environments out of the box:
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.
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.
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.
/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
.
/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.
/etc/shinit
. Per-user auto-start CLI applications are configured
in $HOME/.shinit
. This also depends on the shell used.
/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
.
removepkg
with ROOT
environment variable pointed
to the path unsquashed-root
installpkg
. Or you can just use Fatdog Remaster tool.
Or you can use meta-distribution tool.
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.
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.
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.
This is the flagship of Fatdog Linux, and actively maintained. Today, Fatdog64 is an independent, self-hosted distribution.
It is also maintained though less actively than Fatdog64. Like Fatdog64, FatdogArm is also independent, self-hosted distribution.
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.
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.
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.
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.
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 :)