How would I run my system solely in a ramdisk after logging in (or optionally on boot)?

Question

I know how to create one-off ramdisks, but I'm not sure how to do the following:

• configure a development environment using traditional persistent storage
• next boot, have the ability to shove my home folder into a ramdisk (or the whole system)
• because the development environment has been pre-configured, I don't care if the ramdisk is lost during reboot or power-failure. Since I regularly commit to git, the only additional persistent storage I need is on git.

I understand this'll take a lot of RAM, but physical limitations a side, how would one go about configuring this?

Answer 1

You can have your environment completely in RAM, but:

• Nothing would be persistent!
• You would need an SSD-size amount of RAM: 64G would be small, 128G would be comfortable

Possibility 1: Entire system in RAM:

1. Install Ubuntu to a USB drive¹
2. Convert the USB drive¹ to an ISO file using Gnome Disks
3. Add the ISO file to grub
4. Boot that ISO file

There! An environment completely in RAM!

Possibility 2: /home in RAM:

1. Create a RAM Disk
2. Boot normally
3. Rsync all of /home into the RAM disk
4. mount bind the RAM disk to /home
5. When shutting down, you either lose everything that is in the RAM disk or you have to do the reverse of #3

So all that is technologically possible but impractical as:

• you need to do all your upgrades / system settings on the persistent USB drive¹ and convert to ISO every time you want to change a single persistent byte. (You want one option to be on in your IDE? Well... Turn it on and re-create the ISO...)
• It takes an enormous amount of RAM as you need your entire disk or entire home environment in RAM and enough RAM to run the applications you need.
• You need to rsync the data you want to be persistent.
• The time you lose doing the above would outweigh the benefits you gain.

Note 1: I'm using a USB stick as an example, it could also be a partition / disk on your PC but a USB stick would make things easier as you can also duplicate a USB stick to another USB stick to have a backup of that environment.

Answer 2

I am working on two solutions for my team who needs to use GIMP on Ubuntu. In your case, GIMP will be replaced by a set of Developer Tools.

(Note: In your case, if you wish to preserve the content of a RAM disk, you will have to use the suggestions by Fabby and Zeiss, and you no longer need to mount /tmp and /var/tmp described below as RAM disk)

Challenges I am addressing are:

1. Do not leave any traces of any files being processed by any of the applications. (In my case, I also switch off swap for the same reason). Some developer tools may need large memory so you may have to really consider how much RAM you will actually need.
2. Some programs may use /var/tmp and /tmp in addition to a home directory. No traces shall be left under any of those files without explicitly disabling sticky bit on those directories (or else some programs could break)
3. System shall always provide a clean image of a home directory -- so even configurations changes are not preserved.
4. Regular user should not have sudo privileges.
5. Must work for all distribution supported GUI programs without any hacks (else I would have simply used Docker images). Solution should also be implementable on any Linux distribution without special hacks. It must be installed and manageable by L1 Sys Admin.
6. The Admin user must have a way to upgrade the system as and when needed.

Solution 1: In-line with the suggestion by Fabby under Possibility 2 (Low Complexity)

1. Create two accounts: the first one is the default account created at the time of installation of the distribution (On Ubuntu, generally this account has sudo privileges). Say default account admin and home directory is /home/admin, while 2nd account is say developer, and home directory is set as /ramdisk. While creating the 2nd account, ensure that it does not create a home directory. developer account must not have sudo privileges. root account password must be locked, so there is no temptation to use su while working under the developer account. If you are extremely paranoid, you would like to use chroot for developer and do not retain any set-uid programs within the chrooted directory.

2. Test everything (e.g. set .gitconfig, gitignore, .bashrc and few other configuration files) till everything is working fine. Ensure that TMPDIR=/ramdisk/tmp is set in .bashrc so even temporary directories can be created on the large RAM disk by those programs which honour TMPDIR.

   Once tested, disable the auto-update feature as per instructions applicable for your distribution. This is a must because I also recommend mounting /tmp and /var/tmp on a RAM disk with the lowest possible size (see 5 below), and your auto-update programs may end up corrupting your system.

3. Copy /home/admin to a separate directory, say under /var/warehouse/devtools-home. Clean-up anything which is not explicitly required as part of pristine image from /var/warehouse/devtools-home, to keep it as small as possible. Create a ZIP file of /var/warehouse/devtools-home -- a home directory image.

4. Add an entry in /etc/fstab for a RAM disk (tmpfs) of required size, mounted on /ramdisk, and mount options as uid=developer,gid=developer,mode=700,default,noatime,nodev,nosuid,noexec.

5. Update /etc/fstab to mount /tmp and /var/tmp as tmpfs if your distribution does not use RAM disk for those directories. (I try to keep it as small as possible).

6. Add a cron job with @reboot to unzip developer home dir image under /ramdisk and chown -R developer.developer /ramdisk. You may use boot services or rc.local equivalent supported by your distribution.

7. Reboot and test everything. Login as developer for regular work. Reboot the machine, and all traces are lost, and once again, you get a fresh copy of the home directory with its default configuration.

8. When you need to make upgrades or add new tools, login as admin, unmount /tmp and /var/tmp, perform upgrades, and then reboot the server. If you wish to change defaults in home directory, follow steps (2) and (3) above, and create a new home directory image.

Solution 2: Central PXE Boot server (High Complexity compared to the solution above)

(I am currently working on this solution so all steps may not be in accurate order)

Solution 1 is good for a one-off machine. If you wish to create an entire environment for multiple desktops in a LAN, above may become too cumbersome to manage. However, you do not wish to loose power of using a high speed CPU and high RAM of modern desktops. In such case, a central PXE boot server is recommended instead of a central terminal server. Without going in too much details, what you need is as follows:

1. A central Linux server with TFTP, DHCP, NFS, central Syslog server and LDAP services.
2. Configure LDAP service with required accounts / groups.
3. Configure TFTP to serve a Linux kernel to a desktop and mountthe root partition read-only over NFS which will have an image of your distribution plus required developer tools. The NFS mounted image shall also be configured to authenticate via LDAP. You will also need /etc being mounted as a separate partition / directory per device because of possibility of a different display configuration.
4. Use disk-less desktops with high speed CPU and high RAM. Configure Desktop BIOS to use PXE Boot.
5. Ensure that the RAM disk of the required configuration gets created on the desktop and that the home directory is mounted on the RAM disk, and the home image is copied as described in Solution 1. Syslog running on Desktop shall send syslogs to a central syslog server.
6. Test everything.
7. When you wish to upgrade, update NFS based image with required developer tools, update this image on a central server, and reboot desktops. (I prefer to maintain the last and current image, so that at any point of time, I can switch back to the old version should any problem be reported in new updates).

Answer 3

Try the overlayroot package.

Overlayroot will load your system read-only, with an option for persistent local changes to be saved to a different partition...or simply discarded.

Installation is super-simple: sudo apt install overlayroot

Configure by editing /etc/overlayroot.conf. Instructions are in the file, and simply edit the line at the bottom of the file to enable. To run your system entirely in ram: overlayroot=tmpfs

And reboot. Your console login now reminds you that you are using overlayroot. Your system is now read-only.

To disable temporarily (for upgrades, etc.), pass a command at GRUB: overlayroot=disabled

To disable permanently, edit the config file again.