I've got 3 servers and several teams that use the servers. They want to use different distros (Ubuntu, Debian, ...) with different settings. Virtual machines cannot be used because of the tasks. Is there a way to use every system from every machine with the same settings applied? So if I install something on Ubuntu on Server1 and the next day I use Ubuntu on Server2 everything will be there.

Network boot seems a nice option, but I don't know how to save changes if it's possible at all. We can install every system on every server, but how to keep them synchronized?

  • 3
    The question is confusing, your goals are not clear and you seem to try to grasp and mix multiple concepts in a single question. Have a look at shared storage, contemplate hiring a professional to have a robust working infra-structure. Commented Jun 28, 2018 at 10:58
  • Our aim is hiding the computers from the users, so they can just boot their system and use it on every server. The difficulty is saving the changes, so if they continue the work the next day on another computer they can boot the system there too. Commented Jun 28, 2018 at 11:05
  • Consider giving each user a virtual machine (which should run on "real" servers, where no user logs in), and use thin clients for the users, where they can sit down each day, login and are connected to their virtual machine via X or some other remote desktop protocol.
    – dirkt
    Commented Jun 28, 2018 at 11:14
  • Unfortunately, VMs are out of the game, because of the tasks. Commented Jun 28, 2018 at 11:25
  • By "install something", do you mean an application built by the users and stored in a private or group directory, or do you mean something provided by the distro vendor such as tomcat? Commented Jun 28, 2018 at 15:07

1 Answer 1


For what you're trying to do, it sounds like you want docker containers for each "functional unit". It doesn't solve "I installed an app today from the CLI." It does solve "We need each box deployable on any available hardware."

You can keep manually installed apps in a shared folder, but that means they have to be monolithic installs or a container for each app. You can also use AMIs for this if you use AWS.

It means the hardware doesn't matter, but there is initial cost to set everything up the "right way" out of the gate. The more complex the project is, the more complicated getting a single working container will be, and the more twisted up inter-dependencies will become.

As an example, this toy project is a pretty great way to do things. So, if your nginx guy likes alpine, but your sanic guy likes debian and your postgres guy likes ubuntu - the containers just derive from different templates and can be moved from machine to machine at any time.

Again, it means starting with "deployable images" from the very beginning. It gets harder and harder as time goes on to work out what you need for an image to be deployable.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .