Persistent configuration changes in TinyCore Linux

TinyCore Linux is very suitable for devices like routers that require a higher level of security. All changes made to a running TinyCore Linux system exist only in system RAM and are lost when the system restarts or is shut down. Viruses or file corruption can be removed simply by rebooting the system.

When used as part of an open-source network simulator, the TinyCore Linux appliance can be restored to a base configuration every time it is started. This means the same appliance can be reused in new simulation scenarios without having to clear configurations that may be left over from a previous simulation effort.

However, in some cases we may want to save the configuration changes we make. For example, we may wish to have a basic network configuration working at start time. Or, we may wish to build a complex simulation scenario that will be re-used by other researchers. In this post, we discuss the TinyCore Linux system architecture and how to save configuration changes.

TinyCore Linux architecture

The base TinyCore Linux architecture consists of two files: vmlinuz and core.gz.

The file vmlinuz contains the TinyCore Linux kernel. The compressed file core.gz contains the base TinyCore filesystem. When the TinyCore Linux system boots, these two files are uncompressed and loaded into the system’s memory.

Applications added to the base system are stored in the /mnt/sda1/tce/optional directory as compressed archive files ((Application archive files have the .tcz file extension)). During system boot, TinyCore Linux uncompressed and loads these files and directories into RAM if they are listed the file /mnt/sda1/tce/onboot.lst.

Configuration files created by the user are stored in the compressed archive file /mnt/sda1/tce/mydata.tgz. At boot time, TinyCore extracts the contents of this file into the $HOME and /opt directories — and any other directory specified in the hidden file, /opt/.filetool.lst.

The shell script /opt/bootlocal.sh runs after the system boot process is completed. The user may add commands to this script to create an initial configuration for the TinyCore appliance at startup (see the section on persistence, below).

Persistence in TinyCore

TinyCore Linux runs in RAM so all changes made while the system is running will be lost after a system reboot unless the user takes action to back up the configuration changes.

The TinyCore Linux filetool.sh script provides the backup function that supports persistence. The script backs up files created in the /opt and $HOME directories. The script will also back up directories containing configuration files associated with networking software like Quagga if those directories are listed in the /opt/.filetool.lst file. Network configuration changes made using Linux commands like the ip command cannot be saved. But, we can add these commands to the /opt/bootlocal.sh shell script, which runs at startup.

Once you have created the network configurations you wish to save, by editing the /opt/bootlocal.sh script and/or saving the Quagga or Openvswitch config files, back up the configuration using the filetool.sh script as follows:

$ filetool.sh -b

When the system is running, you can restore the saved base configuration by running the command:

$ filetool.sh -r

Example: TinyCore appliances in GNS3 Open-Source Simulator

In the previous post about using GNS3 to simulate a network composed exclusively of open-source routers, switches, and hosts, we used the TinyCore Linux appliances provided by the GNS3 project.

As described above, we know that filetool.sh script backs up the directories listed in the file /opt/.filetool.lst. The filetool.sh script saves the contents of these directories in the compressed archive file /mnt/sda1/tce/mydata.tgz.

Look at the contents of the /opt/.filetool.lst file to determine what directories the filetool.sh script will back up on each TinyCore Linux appliance we plan to use.

Saving Host appliance configurations

On the Host appliances (in our example, it is the Linux Core 4.7.7 appliance from the GNS3 appliances web page), we list the contents of /opt/.filetool.lst using the command:

$ cat opt/.filetool.lst
opt
home
/etc/shadow
/usr/local/etc/ssh
/sbin/dhclient

On each Host appliance, in addition to the $HOME and /opt directories, we see can save the configuration files for the DHCP client.

Saving Quagga appliance configurations

On the Quagga appliances (in our example, it is the Linux Core 4.7.7 Layer 3 Switch with Quagga and Openvswitch appliance from the GNS3 appliances web page), we list the contents of /opt/.filetool.lst using the command:

$ cat opt/.filetool.lst
opt
home
/etc/shadow
/usr/local/etc/ssh
/sbin/dhclient
/usr/local/etc/openvswitch/
/usr/local/etc/quagga
/usr/local/var/quagga/

On each Quagga appliance, in addition to the normal directories, we also see that the backup script will save the configuration files for the Openvswitch and Quagga programs.

Host-1

Add the following commands to the /opt/bootlocal.sh file on Host-1 using the vi text editor ((vi is the only text editor installed in TinyCore Linux)). These commands will run when the TinyCore Linux virtual machine starts.

sudo ip addr add 10.0.100.2/24 broadcast 10.0.100.255 dev eth0
sudo ip route add default via 10.0.100.1
sudo pkill udhcpc

Then execute the backup command:

$ filetool.sh -b

Host-2

Add the following commands to the /opt/bootlocal.sh file on Host-1.

sudo ip addr add 10.0.100.3/24 broadcast 10.0.100.255 dev eth0
sudo ip route add default via 10.0.100.1
sudo pkill udhcpc

Then execute the backup command:

$ filetool.sh -b

Host-3

Add the following commands to the /opt/bootlocal.sh file on Host-1.

sudo ip addr add 10.0.200.2/24 broadcast 10.0.200.255 dev eth0
sudo ip route add default via 10.0.200.1
sudo pkill udhcpc

Then execute the backup command:

$ filetool.sh -b

Quagga-1

Most of the network configurations on Quagga-1 are done in the quagga open-source router program. Quagga saves its configurations in the directory, /usr/local/etc/quagga. The TinyCore Linux appliance we are using is set up to save the contents of this directory ((as specified in the file, /opt/.filetool.lst)) when the filetool.sh script is run.

To configure router Quagga-1 and save the configuration, execute the following commands:

$ vtysh
box# configure terminal
box(config)# router ospf
box(config-router)# network 10.0.1.0/24 area 0
box(config-router)# redistribute connected    
box(config-router)# exit
box(config)# interface eth7
box(config-if)# ip address 10.0.1.1/24
box(config-if)# exit
box(config)# interface eth0
box(config-if)# ip address 10.0.100.1/24
box(config-if)# exit
box(config)# exit
box# write
box# exit
$

Add the following command to the /opt/bootlocal.sh file on Quagga-1.

sudo pkill udhcpc

Then save the configuration

$ filetool.sh -b

Quagga-2

To configure router Quagga-2 and save the configuration, execute the following commands:

$ vtysh
box# configure terminal
box(config)# router ospf
box(config-router)# network 10.0.1.0/24 area 0
box(config-router)# redistribute connected
box(config-router)# exit
box(config)# interface eth7
box(config-if)# ip address 10.0.1.2/24
box(config-if)# exit
box(config)# interface eth0
box(config-if)# ip address 10.0.200.1/24
box(config-if)# exit
box(config)# exit
box# write
box# exit
$

Add the following command to the /opt/bootlocal.sh file on Quagga-2.

sudo pkill udhcpc

Then save the configution

$ filetool.sh -b

Shut down TinyCore

To power off a TinyCore Linux system, use the command:

$ sudo poweroff

To reboot a TinyCore Linux system, use the command:

$ sudo reboot

Conclusion

We now understand more about how TinyCore Linux works and we created a persistent base configuration for each node in our GNS3 example so that the simulated network is able to pass traffic between networks immediately after the simulation is started, without any additional configuration.

3 thoughts on “Persistent configuration changes in TinyCore Linux”

  1. Pingback: eison.net | Technically Amusing

  2. Pingback: Using VirtualBox linked clones in the GNS3 network simulator | Open-Source Routing and Network Simulation

  3. Thanks a lot. Without this, it is really a pain to re-type all the commands over and over.

Comments are closed.

Scroll to Top