Mike Castle wrote:

and so on, it is time to explore solutions. I only have four systems
at the moment (two physical and two virtual), so I don't think I need something too fancy.

My first thought was to simply add a `Files:` section to *.control
files I use for my metapackages. After all, for configs going into
*.d directories, they are usually easy to just drop in and remove, no
editing in place required. But, that is when I discovered that all
files under `/etc` are treated specially.

I've found a lot of documentation out there, but, of course, much of
it is out of date. https://wiki.debian.org/ConfigPackages , for
example, seems to recommend slightly old to really old tools. Tools
like `ansible`, `puppet` and so on seem, at first blush, aimed at
larger installations than mine. But maybe other's experience with
them will show they scale down fine?

Anyway, suggestions based upon actually experience would be appreciated.

Chef or Puppet are good, but probably not worth the bother for
4-5 systems. Definitely worthwhile for 10+ systems, and scalable
to thousands. https://cinc.sh is producing a fully open release
of Chef (with the new name, Cinc is not chef). I use Chef at
work.

The easy end of single-machine is etckeeper, which just checks
your /etc (and whatever else you specify) into a local git. The
high end of single machine is Nix, which has a complete language
designed to capture the complete configuration of a system (and
has spawned NixOS, a complete distribution).

The easy end of multi-machine systems is cdist and itamae. You might be
quite happy with those, and itamae is reputedly very Chef-like.


-dsr-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

and so on, it is time to explore solutions. I only have four systems
at the moment (two physical and two virtual), so I don't think I need something too fancy.

I am in the same situation with an extra constraint: some are laptops
and not always connected.

My first thought was to simply add a `Files:` section to *.control
files I use for my metapackages. After all, for configs going into
*.d directories, they are usually easy to just drop in and remove, no editing in place required. But, that is when I discovered that all
files under `/etc` are treated specially.

The limitation of this is that you cannot modify existing configuration
files, which is required sometimes.

Anyway, suggestions based upon actually experience would be appreciated.

The easy end of single-machine is etckeeper, which just checks
your /etc (and whatever else you specify) into a local git. The
high end of single machine is Nix, which has a complete language
designed to capture the complete configuration of a system (and
has spawned NixOS, a complete distribution).

The easy end of multi-machine systems is cdist and itamae. You might be
quite happy with those, and itamae is reputedly very Chef-like.

I can also mention ansible which is ubiquitous nowadays and is relevant
even for a single machine. I've worked around my laptop deployment
requirement with a wrapper script around ansible-pull and a systemd timer
to regularly pull the conf from a git repository. It works well but
the complete configuration is known to all machines.

The Nix mention is highly relevant, but I did not get the chance to play
with it yet. The big advantage over ansible and probably many others
is that if you remove a package installation from your configuration,
it will get removed from the host upon configuration deployment. Whereas
with ansible, you must add a explicit uninstallation rule. This is fine
for cloud host deployment where you always start from scratch, but for
physical machines and user laptops, Nix enforces consistency (but then
you need to learn something that is not Debian...).

Cheers,

Alex

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Thu, Apr 18, 2024 at 05:05:14PM -0700, Mike Castle wrote:

Anyway, suggestions based upon actually experience would be appreciated.

As others have mentioned, Ansible can be a good choice for as little
as one machine as long as you don't object to installing Python and
a bunch of Python apps. Probably best to do it in a Python
virtualenv rather than try to use OS packages as it does still
change quite often, but I've found backwards compatibility to be
decent.

I used Puppet for quite a few years. It was a nicer, more expressive
and powerful language. It's also a lot faster than Ansible when you
have tens of hosts. It probably does not make sense for only a
couple of hosts though.

I stopped using it because the rate of change (requiring changes to
its server and client on all hosts) was too much for me.

These days I think the original developers consider it "done" and
have moved on, selling the lot to Perforce who I suspect will just
coast along milking the community for what it can. I would not
consider Puppet for a new setup at this time, mainly for that
reason.

Chef, never used it but did consider it when wanting to move away
from Puppet. Again probably not make sense for small number of
hosts. Likely has more of a future than Puppet considering Cinc.

We all hear great things about Nix, but I want something that
manages Debian packages, not replaces Debian packages.

Ansible is still viable for me but I fully expect Red Hat to ruin it
one day in search of profit. Which is their right.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/04/2024 08:40, Mike Castle wrote:

One thing Linux-Fan mentioned was `config-package-dev`. In my OP, I commented about ``slightly old to really old tools'', and that was one
I was thinking of. It looks like it hasn't been touched in seven
years, and I wasn't sure if it still worked. But that drive by
comments lends some hope. Using it would help address Alex's concern
about modifying existing config files. That debhelper extension is
designed precisely for that situation. But, its age is pretty much
what inspired me to start this thread.

I've been using config-package-dev for some years now - to add some customized configs to existing installed packages - and it still seems to be working perfectly. It's just a wrapper on top of dpkg diverts so there's not all that much to go wrong.

--
John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 18 Apr 2024, Mike Castle wrote:

Now, I would like to expand that into also setting up various config
files that I currently do manually, for example, the `/etc/apt/*`
configs I need to make the above work. For a single set of files,
manual isn't bad, but as I want to get into setting up LDAP, autofs,
and so on, it is time to explore solutions. I only have four systems
at the moment (two physical and two virtual), so I don't think I need something too fancy.

I do this - but it needs a bit of thought as to how you want to do it.

I'm assuming you don't care about debian policy ...

I do one of four things in packages depending on what I want to achieve
and what the package I'm configuring supports.

1.(easiest) - just drop a config file into a conf.d directory. I
use this for maintaining sources.list. Back in the buster days I was
using openssh from backports that supported this as maintaining the
config is so much easier than any of the other ways and so much easier
to fix bugs in your packages - a failing postinst script can be a pain
to resolve.

apt-mirror@aptmirror19:~ (none)$ apt-cache search bookworm-sources bookworm-sources - Meta-package to pull in list of apt-sources for debian

(I generate these packages automatically from what is available on deb.debian.org.)

FWIW, I also have a dev repo and a fast repo - the dev repo is a clone
where I can test out substantial changes and the fast repo only has a
couple of packages but can rebuild "the world" very quickly when I'm
testing. So I have a number of extra levels of indirection to support
this:

$ apt-cache depends bookworm-sources
bookworm-sources
Depends: bookworm-local-sources

That is the normal package that I would install.

apt-mirror@aptmirror19:/mnt/mirror/local/main/o (master)$ apt-cache depends bookworm-dev-sources
bookworm-dev-sources
Depends: bookworm-dev-main-sources

That lets me use the dev repo - and thanks to pinning, the packages in
it will replace (even downgrade) packages from local.

Ditto for my fast repo.

2. (next easiest) - add a file in /usr/share/ and then overwrite the
file in /etc by copying in postinst.

3. edit the config file without diverting it using a sed script.

4. divert the config and edit/replace it in the package.

3. and 4. in particular can make upgrades more difficult if/when you
find bugs in the way you're handling diversions and uninstalls.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/22/24 11:33, Dmitrii Odintcov wrote:

Hi all,

Sorry to resurrect an old-ish thread, but I am facing the exact same
task, minus the know-how.

Basically I am looking to pre-configure a number of Debian setups -
let's say, "server", "laptop" and "PC" - that would contain sets of
packages to install (or uninstall), configuration files (including but
not limited to /etc/), and possibly arbitrary scripts to execute upon installation (e.g. to make more precise edits to configs).

I would like to store these in some central, git-controlled location
where I could pull them from to my target machines. This kind of setup
could be rather low-level, such as configuring APT sources and
preferences, installing and configuring systemd-networkd, etc.
Ideally, I would also be able to incorporate these into a Debian
installer so I could get a new machine "up and running" with my
defaults in one go.

It is worth adding that I am not looking to build an "infrastructure",
and no setup *between* these machines (networking, file sharing, etc.)
is necessary.

Generally, I would rather avoid complicated tools like Ansible and
those with large dependencies such as interpreted languages (except
Perl).

So far, equivs and config-package-dev appear most relevant, but the
former is somewhat lacking in documentation (or I am in
documentation-finding ability), and the latter seems to be focused on
config editing/deployment rather than package installation.

Would be grateful for some advice!

I think the "best" answer depends upon the scale of your installation.


I have a SOHO network with a dozen or so Debian, Windows, macOS, and iOS clients, a FreeBSD/ZFS CVS, SSH, and Samba server, and a FreeBSD/ZFS
backup server. For system administration, including configuration
management, I have gone down the do-it-yourself (DIY) path using lowest-common-denominator FOSS command line tools.


After the network, ssh(1), and rsync(1), the most valuable tool for
system administration (including configuration management) has been a
version control system. I prefer CVS over Git because CVS provides monotonically-increasing MAJOR.MINOR version numbers via keywords (e.g. $Revision$) that can be included inside managed plaintext files. I
create a CVS project for everything I want to manage. For OS's, I check
in a sysadmin log file with my notes and console sessions, a list of
packages installed, various reports that I have run, and any system configuration files that I have modified, added, or deleted.


After version control, the next most valuable tool has been scripting.
Over the years, I have written numerous scripts to automate repetitive
chores. When the needs are simple, I write Bourne shell scripts. When
I want more power, I upgrade to Perl. All of the scripts are checked in
to CVS.


I expect Ansible, Puppet, etc., would work at my scale, but are designed
for large installations.


David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)