Hi, On Wed, Jul 21, Paul Graham wrote:
Hi,
I had a couple of questions that I was hoping someone could give me some guidance or opinions on.
First, I have a use case where I would like to run some embedded systems with MicroOS on a private network. Do you have any guidance on how I should mirror various repositories so I can update those machines regularly while they are on the private network?
Cameron gave you already some hints. Since MicroOS is using the Tumbleweed repositories, which are really big, there is another way: - Download the new ISO image - loopback mount it - Export it via http/https/ftp/nfs/... You can automate the download of the image and the setup easily with a shell script.
From what I can tell, the repos that are being used to perform software installs and updates can be found in /etc/zypp/repos.d. If I had mirrors for the repositories listed in that directory and updated
I have run across tools like Pulp (https://pulpproject.org/) that might help in creating the mirrors, but I haven't tried it out yet. the .repo files in /etc/zypp/repos.d to point to my mirrors, do I need to do anything else? Any pointers to documentation or other suggestions are welcomed.
Should be enough.
The second question is related. If I wanted to push updates to the individual systems rather than have them pull updates from repository mirrors, would it be possible to use a single "golden" system for managing the configuration for a collection of identical systems and then use "btrfs send" to update that collection of systems with updated software for the OS? In other words, I could see how you might perform an update on the "golden" system and then use the new snapshot that was created by the "transactional-update" tool in a "btrfs send" operation to push the changes to other systems.
I understand that this is probably not compatible with the "transactional-update" tool on the receiving end, but it might be a nice way to push updates to systems, taking advantage of the fact that only snapshots are being sent and, ideally, they would represent only the differences from previous snapshots (a natural way of handling the deltas between two file systems).
If "btrfs send" isn't the right mechanism for pushing updates, is there a better mechanism?
The idea with "btrfs send/receive" is not new. The biggest problem I see is, that /etc is part of the root filesystem (else it wouldn't be possible to do a rollback of the configuration files, too), and this directory contains host specific data, which you should never share with other uses. Like the unique machine-id. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)