search

tomeshnet / mesh-orange

A small ramdisk system running modern Debian to support mesh networking on ARM single-board computers
https://tomeshnet.github.io/mesh-orange/
GNU General Public License v2.0
39 stars 7 forks source link

Add configuration management #17

Closed benhylau closed 6 years ago

benhylau commented 6 years ago

See: https://github.com/tomeshnet/mesh-orange/issues/6 and https://gist.github.com/hamishcoleman/75de3d6c5040efccf392f984306ea2c2

benhylau commented 6 years ago

@hamishcoleman I haven't tested this yet, and the following two issues remain:

benhylau commented 6 years ago

Okay so the extract part works. I have:

/conf.d/00-base.tar.gz -> some.config (empty file)
/conf.d/01-more.tar.gz -> some.config ("some stuff" text, this should replace the previous)
                       -> test/ (new directory)
                       -> test/other.config (empty file)

After first boot:

root@ramdisk-2c5d7020:/etc# cat some.config
some stuff
root@ramdisk-2c5d7020:/etc# ls test/other.config
test/other.config

Then I tested config_save:

root@ramdisk-2c5d7020:/etc# echo "new stuff" >> test/other.config
root@ramdisk-2c5d7020:/etc# cat test/other.config
new stuff
root@ramdisk-2c5d7020:/etc# config_save
Checking for configuration directory on mmcblk0p1
Saving configurations to /dev/mmcblk0p1: /mnt/conf.d/50-node-config-save.tar.gz
Configurations saved to /dev/mmcblk0p1: /mnt/conf.d/50-node-config-save.tar.gz

// Power cycle

root@ramdisk-2c5d7020:/etc# cat test/other.config
new stuff

So then I tried to manually extract the tar to make sure there isn't symlink errors:

root@ramdisk-2c5d7020:/# cat /proc/partitions
major minor  #blocks  name

   1        0       4096 ram0
   1        1       4096 ram1
   1        2       4096 ram2
   1        3       4096 ram3
 179        0   15454208 mmcblk0
 179        1    1024000 mmcblk0p1
root@ramdisk-2c5d7020:/# mount /dev/mmcblk0p1 /mnt
root@ramdisk-2c5d7020:/# tar --extract -f /mnt/conf.d/50-node-config-save.tar.gz -C /etc

No errors. So, everything seems to work at least for the case when I have only a single FAT partition connected to the system.

darkdrgn2k commented 6 years ago

To identify the config partition possibly look for the boot directory that identifies the partition created by the mesh-orange instead of conf.d.

That way the conf.d files are always internal vs some other random partition that is plugged in (ie usb drive). It would also allow for pulling the sd card out and plugging it into a computer to edit the config files externally (since its the first vfat partition)

On the other hand mesh-orange image will overwrite the image and as such the config.

darkdrgn2k commented 6 years ago

During the boot sequence the tar tries to extract the files with a timestamps causing allot of warnings about future files (since there is no RTC on the board)

Possibly adding -m to the tar extraction command line could be a work around

     -m, --touch
           don't extract file modified time

Example of issue (seen on serial console)

Starting Ramdisk System

[   49.172575] mmc1: new high speed SDIO card at address 0001
Checking for configuration files on mmcblk0p1
Applying configurations from /dev/mmcblk0p1: /mnt/conf.d/50-node-config-save.tar.gz
tar: ./machine-id: time stamp 2016-11-03 17:16:42 is 1478193352.681373228 s in the future
tar: ./pam.conf: time stamp 2017-05-27 15:44:02 is 1495899792.675860228 s in the future
tar: ./dhcp/dhclient-exit-hooks.d/timesyncd: time stamp 2017-07-05 20:31:25 is 1499286635.675276894 s in the future
tar: ./dhcp/dhclient-exit-hooks.d: time stamp 2017-07-05 20:31:25 is 1499286635.674987019 s in the future
tar: ./dhcp: time stamp 2017-07-05 20:31:25 is 1499286635.674800228 s in the future
tar: ./init.d/dropbear: time stamp 2017-05-19 21:41:21 is 1495230031.674368519 s in the future

.... LOTS MORE LINES ....

tar: ./systemd/system/getty.target.wants: time stamp 2018-01-12 00:17:36 is 1515716203.932523726 s in the future
tar: ./systemd/system/sockets.target.wants: time stamp 2016-11-03 17:16:42 is 1478193349.932343685 s in the future
tar: ./systemd/system/network-online.target.wants: time stamp 2016-11-03 17:16:42 is 1478193349.93215006 s in the future
tar: ./systemd/system: time stamp 2016-11-03 17:16:42 is 1478193349.931961935 s in the future
tar: ./systemd: time stamp 2017-07-05 20:31:25 is 1499286632.931794601 s in the future
tar: ./rc3.d: time stamp 2018-01-12 00:17:20 is 1515716187.931630476 s in the future
tar: .: time stamp 2016-11-03 17:16:44 is 1478193351.931470976 s in the future
[   52.455463] ip_tables: (C) 2000-2006 Netfilter Core Team
benhylau commented 6 years ago

To identify the config partition possibly look for the boot directory that identifies the partition created by the mesh-orange instead of conf.d.

I also thought about checking for boot directory, but felt that it was an unnecessary restriction. Perhaps we have a board that won't use a file named boot, or I want my conf.d on a USB drive that I can plug into arbitrary nodes and see same behaviour.

So then I thought about making an additional identifier like .mesh-orange-use-me as a sibling to conf.d that I can search for, but then I realized conf.d is that identifier. If it's too generic, then we can rename conf.d to something like mesh.orange.conf.d then there wouldn't be unintended collisions. If two drives actually both contain mesh.orange.conf.d that probably means someone stuck in two SD cards both flashed with the mesh-orange img, in which case it is actually impossible to tell which one they intend to boot. So... we are back to conf.d, although we can debate whether the name is not unique enough.

darkdrgn2k commented 6 years ago

I also thought about checking for boot directory, but felt that it was an unnecessary restriction. Perhaps we have a board that won't use a file named boot, or I want my conf.d on a USB drive that I can plug into arbitrary nodes and see same behaviour.

Are we building a production node here or prototype node. The act of plugging a USB with config files into a device sounds like something you DONT want to do in a production model due to being a easy way to "hack" in.

Just a thought. Maybe have a production and prototype mode?

benhylau commented 6 years ago

If you have physical possession of the device, it is no different to plug a key USB or swap an SD card. I don't see being able to pick up configurations from more than one storage device being a security risk.

benhylau commented 6 years ago

Does this look right for the FAT partition of a Raspberry Pi 2 image? I stuck a conf.d in there, but the partition doesn't have a boot directory like all the other boards. This is because of the Raspberry Pi bootloader right?

$ ls -l /mnt/
total 56752
-rwxr-xr-x 1 root root    16523 Jan 12 10:27 bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root    17624 Jan 12 10:27 bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root    16380 Jan 12 10:27 bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root    50248 Jan 12 10:27 bootcode.bin
-rwxr-xr-x 1 root root       75 Jan 12 10:27 cmdline.txt
drwxr-xr-x 2 root root    16384 Jan 12 10:27 conf.d
-rwxr-xr-x 1 root root       66 Jan 12 10:27 config.txt
-rwxr-xr-x 1 root root    18693 Jan 12 10:27 COPYING.linux
-rwxr-xr-x 1 root root     2583 Jan 12 10:27 fixup_cd.dat
-rwxr-xr-x 1 root root 52579140 Jan 12 10:27 initrd
-rwxr-xr-x 1 root root  4579248 Jan 12 10:27 kernel7.img
-rwxr-xr-x 1 root root     1494 Jan 12 10:27 LICENCE.broadcom
-rwxr-xr-x 1 root root   659492 Jan 12 10:27 start_cd.elf
benhylau commented 6 years ago

@hamishcoleman Thoughts re: timestamp warnings? https://github.com/tomeshnet/mesh-orange/pull/17#issuecomment-357118267