syncopt - A Flexible and Simple Approach to Package Install Last modified: Jun 4 11:03
Overview
The syncopt script and its associated work practices are yet another approach to the standard sysadmin problem of keeping multiple machines' software installations up to date. It is independent of the vendor's packaging scheme and thus you can use either your vendor's system or syncopt, or both!
Also see the manual entry: syncopt.1.html.
The core notion is that the install is done once on a central machine and then syncopt takes care of attaching that to every client, often via cron.
Like most such solutions, syncopt has to achieve a few goals:
- easy to use
- flexible enough to permit control of what is installed locally on a machine and what is served remotely from a central server (for disc space or other reasons)
- keep out of the way of the ``vendor's namespace'', to avoid treading on the vendor's install and conversely to protect our additions from damage by vendor upgrades and patches
As implemented, syncopt achieves this with the following advantages:
lightweight
If a package is not to be installed local to a client then the burden is usually just two symlinks on the client.
optional
You can install packages with syncopt or with the vendor's packaging scheme, or both!
permits trial installs
Under syncopt you can install multiple versions of the same package for trial or legacy purposes.
centralised
The default package version is controlled by a symlink on the master host; change that and all the clients will follow suit next time they run syncopt.
customisable
Clients can control which packages are local and also override which version is their default for a given package.
It presumes you have a ``large'' main machine which can have an instance of everything installed on it and that your other machines generally have mostly-local core installs of the OS and main packages and probably run most of the optional stuff from the main server via NFS or other network filesystem.