Score:0

Installing, maintaining and updating multiple Ubuntu installations

cn flag

I have several computers in my network which (should) all run an identical version of Ubuntu. I have a number of applications, some of which run on only one machine, others of which run on more than one. I use the term "application" here in a very broad sense (e.g. network management, network monitoring, OpenHAB, ...) and assume that they also include such additional Ubuntu packages as they need.

I get fed up with updating each machine individually, the more so because I also have my own configuration defaults that I would like to be identical on each machine. And, of course, each time I update a single machine the chances increase that the different versions diverge. I would also like to channel all my log files to a single central point (part of my local configuration defaults).

Can anyone recommend an approach whereby I can maintain on a central server:

  • one copy of the OS,
  • one copy of my local configuration defaults,
  • and one copy of each application

and boot a combination of these layers on each machine as appropriate? I cannot imagine that I am the first person who ever wanted to do this.

I am aware of overlayroot, overlayFS and their ilk and can boot Ubuntu over NFS. I know that I need some local storage on each machine for the upper overlay in addition to the lower overlays. And I have discovered that the the upper overlays cannot be an NFS device, which doesn't make things easier.

If there were some way of having a single OS image but specifying for each machine a different /etc/fstab I think most of my aims would be achieved. Or I can imagine setting up a load of systemd mount units and somehow switching them on and off at boot time via kernel parameters.

Can anyone suggest how to proceed? Are there products that do this?

Artur Meinild avatar
vn flag
This sounds like what Ansible seems to solve. Try looking into that.
Stephen Winnall avatar
cn flag
@ArturMeinild Thanks for the suggestion. What I forgot to mention was that the clients are all diskless. I probably also didn't make it clear that I don't want to make *any* copies of the OS: as I understand it, Ansible works by making copies of a central repository. However, I have solved the problem for my immediate needs and will document it below in an answer to my own question.
Score:1
cn flag

I seem to have a knack for asking questions that elicit very little response...

I have, however, solved the problem for my purposes and would like to document the basic solution here.

What I was asking for – just to clarify, because it might not have been crystal clear – was how to boot multiple diskless clients over the network from a single central copy of the operating system, whilst sharing my local admin conventions on all those clients, but providing different services depending on the the purpose of the individual client.

As a diagram, it looks like the following:

+------+   +------+       +------+
| App1 |   | App2 |       | Appn |
+------+   +------+       +------+
|Admin |   |Admin |  ...  |Admin |
+------+   +------+       +------+
|  OS  |   |  OS  |       |  OS  |
+------+   +------+       +------+

where each tower represents a virtual root filesystem consisting of – in this case – 3 layers each. Because of the layers I think of these as being ogres.

I originally tried – and failed – to create the virtual root filesystems on the clients using Ubuntu's overlayroot package, which uses the overlay filesystem (a type of union filesystem) to construct virtual filesystems out of layers consisting of other filesystems.

I then realised that it would be easier to construct the ogres virtual root filesystems on the server-side. My server is a Synology NAS and it provides the aufs union filesystem, so I did the following:

mount -t aufs -o br=.../App1:.../Admin:.../OS none /hosts/host1
mount -t aufs -o br=.../App2:.../Admin:.../OS none /hosts/host2
mount -t aufs -o br=.../Appn:.../Admin:.../OS none /hosts/hostn

and exported the mount points with NFS. I can boot the clients by specifying the relevant ogre to import and using it as the root filesystem.

In the simplest case this works well. I'm still testing it the more esoteric aspects, but I'm quite pleased with the results so far.

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.