Re: Current best practices for system configuration management?
On Sat, Apr 20, 2024 at 4:40 PM Mike Castle wrote:
> Thanks for all of the commentary so far.
>
> Once I get something working, I will *try* to remember to follow up
> here with what I've managed to cobble together.
I have done quite a bit of research and experimentation and finally
settled on a solution that seems like it will work for me:
Plain old debian/* control files along with config-package-dev.
Effectively, I've abandoned `equivs` and now just using plain old
`debhelper` with a small wrapper script.
One thing I've learned along the way is that debian/control files can
build multiple .deb files. But the "control" files that `equivs` uses
are not really the same as regular control files, so need one per
package. Since I created a hierarchy of packages, I needed several
configs for equivs. Now, I can use just one, and it is MUCH faster
(about 8 seconds total).
I'm still working on replacing my old equivs stuff, but, I do have
some things I'm installing now. Essentially my setup looks like this:
debian/control:
Maintainer: Mike Castle
Source: mrc
Build-Depends: debhelper-compat (= 12), config-package-dev
Rules-Requires-Root: no
Standards-Version: 4.5.1
Section: metapackages
Priority: optional
Package: mrc-base
Architecture: all
Depends: ${misc:Depends},
bc,
cron,
...
zip,
Package: mrc-mozilla
Architecture: all
Description: MRC's Mozilla apt configuration
Lots of files under /etc/apt.
Depends: ${misc:Depends},
Package: mrc-desktop
Architecture: all
Description: MRC's desktop installation
Graphical stuff.
Depends: ${misc:Depends},
mrc-base,
mrc-games,
mrc-python,
mrc-mozilla,
... more meta packages ...
Package: mrc-mars
Architecture: all
Description: MRC's host mars
Host specific deps.
Provides: ${diverted-files}
Conflicts: ${diverted-files}
Depends: ${misc:Depends},
mrc-desktop,
mrc-development,
mrc-virtual-machines,
... most host packages ...
A few other debian control files:
$ find debian/ -type f
debian/source/format
debian/mrc-mars.install
debian/mrc-mars.displace
debian/mrc-mozilla.install
debian/copyright
debian/changelog
debian/rules
debian/control
$ cat debian/rules
#!/usr/bin/make -f
%:
dh $@ --with=config-package
The files that match .* are the magic. For example:
$ cat debian/mrc-mozilla.install
files/mozilla/* /
$ find files/mozilla -type f
files/mozilla/usr/share/lintian/overrides/mrc-mozilla
files/mozilla/etc/apt/sources.list.d/mozilla.list
files/mozilla/etc/apt/preferences.d/mozilla
files/mozilla/etc/apt/keyrings/packages.mozilla.org.asc
The etc/apt files come from
https://support.mozilla.org/en-US/kb/install-firefox-linux#w_install-firefox-deb-package-for-debian-based-distributions
and the lintian overrides is:
$ cat files/mozilla/usr/share/lintian/overrides/mrc-mozilla
mrc-mozilla: package-installs-apt-sources
mrc-mozilla: package-installs-apt-preferences
For the host packages, it is slightly more complicated, but not much
once I figured it out. Again, a basic "copy in everything under this
directory" install file:
$ cat debian/mrc-mars.install
files/mars/* /
which is currently this:
$ find files/mars -type f
files/mars/etc/hostname.mrc
Then the interesting bit:
$ cat debian/mrc-mars.displace
/etc/hostname.mrc
This "dispace" file is something that the `config-package` addon takes
care of. It sets up backing up the existing file name (/etc/hostname)
and symlinks in my version:
$ ls -l /etc/hostname*
lrwxrwxrwx 1 root root 12 May 27 08:57 /etc/hostname -> hostname.mrc
-rw-r--r-- 1 root root 5 May 27 06:52 /etc/hostname.mrc
-rw-r--r-- 1 root root 6 May 27 07:37 /etc/hostname.mrc-orig
If I purge mrc-mars, then /etc/hostname.mrc-orig is moved back to /etc/hostname.
(The way config-package-dev works is, it takes the first portion of
the package names, in this case "mrc", to identify what file names to
use.)
To drive it all, I currently use a simple wrapper script:
$ cat doit.sh
#!/bin/bash
set -e
work_dir=$(mktemp -d)
find -depth | cpio -pdm ${work_dir}/work
cd ${work_dir}/work
debuild --no-conf --no-sign --lintian-opts --info
OUTPUT=/srv/deb/packages
rm -rf $OUTPUT
mkdir -p $OUTPUT
cp ${work_dir}/*.deb $OUTPUT
cd $OUTPUT
dpkg-scanpackages . > Packages
echo "work_dir was ${work_dir}"
Not the fanciest, but "works for me" (so far). Essentially it builds
things in /tmp because the debian packaging tool chain always drops
the files into the parent directory and leaves things that *I*
currently do not care about littering my disk. Also, it drops
intermediate files into the debian/* directory, making it more
difficult to know what needs to go under SCM. With this approach,
"git status" will be easier to read.
The only drawback so far, over my previous approach of one `equivs`
config per package, is that now, all built debs share the same version
number. With the individual approach, I could add one package to a
metapackage, and when I do "apt update && apt upgrade", only the
single package (and its new deps) are processed. Now,
Re: Current best practices for system configuration management?
Mike Castle writes: Hah! https://lists.debian.org/debian-user/2013/08/msg00042.html Yes, that was me > 10a ago. Transitioning from these scripts to ant allowed came with a few improvements: * I switched all package building to `debuild` in favor of using more low-level tools for `raw` packages before. * I was able to establish some sort of “buld upon new commit” poor man's local CI -- I experimented with some fully-fledged systems like Concurse CI and GitLab, too, but they were all too much for my local-first activities * When resources were required from external locations (e.g. source code downloads), that set of scripts did not provide for any automatism in this regard. One of my continuous goals is to split between “my settings” and some re-downloadable files. It was only achieved partially back then and the ant-approach takes it much further :) Still, in many ways the ant does not do much more than the scripts linked at the message above. If you are about to create your own scripts (which is probably a better idea than trying to use my scripts anyways :) ) the shellscripts may be easier to understand. HTH Linux-Fan öö pgpEtXWCbBgkx.pgp Description: PGP signature
Mesh VPN on Debian (Was Re: Current best practices for system configuration management?)
Hi, On Sat, Apr 20, 2024 at 04:40:24PM -0700, Mike Castle wrote: > Like Alex, one of my physical machines is a laptop that is not always > on the home network. Though I'm usually connected to *something*. > I'm still debating whether to bother with a VPN or trying something > like a tailnet. For mesh VPN I really like Yggdrasil (packaged in Debian, but widely available). It does quite a lot of the things that people use Tailscale for, but has the advantages of: - Completely FOSS - No need to contact a central authority - your nodes all self-organise - Thus no limit on how many nodes you can have for free (though Tailscale's limit is very generous) Like Tailscale it will detect other instances of itself on your LAN so local traffic remains local (avoid a VPN hairpin) while you still use the same Yggdrasil IP addresses to talk to things. Downsides compared to Tailscale are things like: - Not as polished a product so no hand-holding; you need to read the docs - Not available on as many platforms. It is a single static Go binary so it's not hard to deploy if you can compile it, but I don't know what the story is on things like mobile platforms, whereas there's Tailscale apps for everything. - I don't have personal experience but possibly it's more energy intensive than Tailscale which would matter a lot on mobile devices There is a good introduction and comparison with some other solutions here: https://www.complete.org/easily-accessing-all-your-stuff-with-a-zero-trust-mesh-vpn/ I still wouldn't want to automated a config push/pull to a laptop over a mesh VPN I think, but others have mentioned that you can do Ansible in a pull mode. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Current best practices for system configuration management?
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.
Re: Current best practices for system configuration management?
Hah! https://lists.debian.org/debian-user/2013/08/msg00042.html
Re: Current best practices for system configuration management?
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
Re: Current best practices for system configuration management?
Thanks for all the suggestions so far. Like Alex, one of my physical machines is a laptop that is not always on the home network. Though I'm usually connected to *something*. I'm still debating whether to bother with a VPN or trying something like a tailnet. Heck, before I adopted Debian and ran my own Linux-from-Scratch-started-before-LFS-or-Debian-existed "distribution", I used to run $HOME over NFS over WiFi. Sharing configs that way would be acceptable for me. I also used to keep my configs in CVS and pushed them using rsync-over-ssh-as-root, hence "current best practices". :-> Linux-Fan's MDVL stuff looks interesting. Everything can always be solved by one more layer of redirection. :-> I just have to suss out the Java and Ant stuff to understand the basics. Personally, I'm a big fan of NIH-Syndrome (otherwise I wouldn't have run a LFS type system for ~15 years). So it is likely I would reinvent what is happening there. 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. Interestingly enough, I sent the OP just before I went to a BayLISA talk about Apple's PKL. Since I tend to only use whatever comes out of the Debian repos (my only exceptions being Firefox and an emacs package the maintainers won't fix for bookworm), I'm unlikely to do more than look at it, But, between it and MDVL, I think I'm definitely going to try to make sure I don't configure myself into a corner. :-> Thanks for all of the commentary so far. Once I get something working, I will *try* to remember to follow up here with what I've managed to cobble together. Cheers! mrc PS: Actually, I used to share $HOME (and /usr) over PLIP, so, it is probably obvious that FS speed is not always a concern for me.
Re: Current best practices for system configuration management?
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
Re: Current best practices for system configuration management?
Mike Castle writes: For a while now, I've been using `equivs-build` for maintaining a hierarchy of metapackages to control what is installed on my various machines. Generally, I can do `apt install mrc-$(hostname -s)` and I'm golden. 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, [...] 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. [...] Hello, I can confirm from experience that Ansible can indeed scale down to as little as the one local machine that it is running from. It has a learning curve and at least to me it always felt a little clumsy to learn a YAML based scripting language for this purpose, but its a solid choice. Continuing the package-based approach is what I do because once some wrapper around the `debuild` commands was established, it became acceptably easy to use. I even maintain my “dotfiles” (not under $HOME but under /etc, but to a similar effect) this way: https://masysma.net/32/conf-cli.xhtml. With `config-package-dev` there are some tricks to even allow changing (config) files supplied by other packages. The disadvantage with the package-based approach is that it is heavily distribution-specific and also if you mess anything up, a core component of the OS (package management) can become broken - I luckily never broke it to the extent that recovery was impossible, but in the beginning ran a dedicated test VM to validate all package changes prior to installing them on my main system I have also heard good things about Nix and if I had to start again from scratch today, I'd probably invest time into learning that technology. Right now I am sufficiently satisfied with the package-based approach to not look into it yet. HTH Linux-Fan öö pgplLIRpEGPqu.pgp Description: PGP signature
Re: Current best practices for system configuration management?
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
Re: Current best practices for system configuration management?
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-
Current best practices for system configuration management?
For a while now, I've been using `equivs-build` for maintaining a hierarchy of metapackages to control what is installed on my various machines. Generally, I can do `apt install mrc-$(hostname -s)` and I'm golden. 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. 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. Cheers, mrc
Question about Configuration Management covered at kali.training
Hi there, My new book Configuration Management: Standard Requirements is out, get it here: https://www.dropbox.com/s/86hqr1454ovgdqw/CM_Configuration_Management.pdf?dl=0 My goal is to get in front of anyone who will benefit from it. - perhaps you will be able to help more people with a link or an article. I was searching for Configuration Management information and I came across kali.training, and had to reach out to you. My name is Gerard Blokdijk, I've been in many enterprise data center management and CxO roles over the past 25 years, and spoken to thousands of people at public events and at companies in 23 countries. And I'm an author. I have just published my new book called 'Configuration Management: Standard Requirements'. Because I feel this is of interest to you, and to establish mutual ground, I want to give you the book. Something straightforward as 'Configuration Management: Standard Requirements' is the Configuration Management guide I wish I had when I needed it; a tool to help develop a detailed vision of all areas impacted by a Configuration Management implementation, and a useful tool for scoring readiness and implementation quality. It highlights what's important now and in the future for the reader and delivers a Configuration Management roadmap to instantly understand and move forward in the right direction, based on verifiable data. 7 Sample Requirements: 1. Is an asset management process(es) in place to inventory and manage this new asset (investment) from a property management perspective, to provide Configuration Management support, and to monitor system performance? 2. If a customer complains that service levels are below those agreed in the sla, apparently due to a number of related hardware incidents, who is responsible for ensuring the cause is investigated? 3. Are physical configuration assessments conducted to determine the degree of agreement between the current physical configuration and the configuration depicted in the facility documentation? 4. What percentage of user PCs and servers are included in a centralized software inventory/CMDB (configuration management database); which is populated by a software tracking tool? 5. Have the cis and the exact version or revision that constitutes a particular baseline (documents, source code, problem reports and change documents) been identified? 6. How do you do keep current with a continuously changing codeline, and also make progress without being distracted by your environment changing out from under you? 7. Has the organization established a security configuration management program that is consistent with FISMA requirements, OMB policy, and applicable NIST guidelines? The book will be available at Amazon, Barnes and Noble and all major retailers later this month, the full info can be found at https://store.theartofservice.com/cm-configuration-management-standard-requirements/ right now. You can read and download the PDF version of the book instantly here: https://www.dropbox.com/s/86hqr1454ovgdqw/CM_Configuration_Management.pdf?dl=0 Where you can see this possible, I would appreciate it if you would consider linking to https://store.theartofservice.com/cm-configuration-management-standard-requirements/ - This will help more people with finding the book. To make it easy you can use the critical criteria above as input and the following text (or use any text you like): The Art of Service's Configuration Management Standard Requirements Excel Dashboard and accompanying eBook is for managers, advisors, consultants, specialists, professionals and anyone interested in Configuration Management assessment. https://store.theartofservice.com/cm-configuration-management-standard-requirements/ Thanks in advance and if I can assist you with anything else, or return the favor, please let me know. Gerard Blokdijk Connect with me here: https://www.linkedin.com/in/gerardblokdijk CEO The Art of Service https://theartofservice.com gerard.blokd...@theartofservice.com https://www.linkedin.com/in/gerardblokdijk/ The U.S. Department of Commerce, National Institute of Standards and Technology (NIST) has included our Cyber Security Self Assessment on their Framework Industry Resources list since our Self Assessment is deemed qualified, accurate and comprehensive as a Guidance that Incorporates the Framework: https://www.nist.gov/cyberframework/industry-resources Other recent posts: https://ctmfile.com/story/fraud-analytics-complete-self-assessment-guide-shows-how-to-tackle-fraud http://www.inboundlogistics.com/cms/article/summer-reading-guide-2017/ https://inc42.com/buzz/54-cryptocurrency-success-criteria/ http://www.myfrugalbusiness.com/2017/10/disciplined-entrepreneurship-success-criteria.html http://flarrio.com/artificial-intelligence-checklist/ http://blog.esker.com.au/customer-service-appreciation-week-how-are-you-doing/ https
configuration management
not sure how topical this here - as i'm not looking for anything debian specific. i'm looking at using some type of configuration management software. i have never used any of this software before, i just think i'm outgrowing svn and scp :) i've found this wiki: http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software and have been comparing them. i am familiar with perl and mysql. however, sense i don't think i would want to develop this software, it shouldn't matter. i do need something that supports linux, bsd (and it would be cool if i could have my two osx boxes on the system too - but don't care as much). i'd prefer the system have some sort of ajax, soap, xml, syslog, or snmp v3 output (in order of preference - can ya tell how i feel about snmp?). but, i suppose i can parse and spit out pretty much any output if need be. i'm not looking to pay for this (or i'd just shoot up to openview and call it a day). btw, if i could take lvm, zfs, and virtualbox snapshots with whatever software i use, that would be cool too :) comments? suggestions? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTikFT1z4y=eknftp1_ewp7l0syx...@mail.gmail.com
Re: configuration management
I have used cfengine2 and cfengine3, and I am currently learning puppet. These are roughly equivalent functionalities, with cfengine being the grandfather of all of them (circa 1993, iirc). One thing I have found is your programming preferences could help make the decision for you. cfengine is vaguely perl-like, while puppet is ruby-based. As I recall, bcfg2 is python-based. You can get all sorts of opinons on which is better and why around the internet. --b On Fri, May 6, 2011 at 7:56 PM, shawn wilson ag4ve...@gmail.com wrote: not sure how topical this here - as i'm not looking for anything debian specific. i'm looking at using some type of configuration management software. i have never used any of this software before, i just think i'm outgrowing svn and scp :) i've found this wiki: http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software and have been comparing them. i am familiar with perl and mysql. however, sense i don't think i would want to develop this software, it shouldn't matter. i do need something that supports linux, bsd (and it would be cool if i could have my two osx boxes on the system too - but don't care as much). i'd prefer the system have some sort of ajax, soap, xml, syslog, or snmp v3 output (in order of preference - can ya tell how i feel about snmp?). but, i suppose i can parse and spit out pretty much any output if need be. i'm not looking to pay for this (or i'd just shoot up to openview and call it a day). btw, if i could take lvm, zfs, and virtualbox snapshots with whatever software i use, that would be cool too :) comments? suggestions? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTikFT1z4y=eknftp1_ewp7l0syx...@mail.gmail.com
Re: configuration management
On 07/05/11 00:56, shawn wilson wrote:
i'd prefer the system have some sort of ajax, soap, xml, syslog, or
snmp v3 output (in order of preference - can ya tell how i feel about
snmp?). but, i suppose i can parse and spit out pretty much any output
if need be.
What information are you looking to get from the output of a config run ?
IMHO, if you are using configuration management software the process
should be kinda as follows:
Have a method of creating consistent base installs (for Debian, probably
preseed).
Create clean machine based on that.
Run configuration management tool.
Profit.
btw, if i could take lvm, zfs, and virtualbox snapshots with whatever
software i use, that would be cool too :)
Again, my opinion, but there should be no need to take snapshots of the
result of running any config management tool, as the canonical version
of your boxes can be created using said tool
comments? suggestions?
I'm mostly familiar with Puppet, and use it extensively. Something I've
found is that your first couple of attempts will probably not be ideal.
A large part of the config management puzzle is getting your
abstractions in the right place.
For example, it is fairly easy to copy /etc into file resources in
Puppet and push them to several machines. Ideally, there should be as
little machine specific configuration as possible.
Kinda like this:
httpd_config = {
'MPM' = 'prefork',
'StartServers' = '10',
'MinSpareServers' = '15',
'MaxSpareServers' = '25',
'ServerLimit' = '256',
'MaxClients' = '256',
'MaxRequestsPerChild' = '4000',
'Port' = '8000'
}
and using variables to put those values into config files and overriding
as appropriate rather than having multiple versions of files.
Hope that gives you a couple of pointers.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dc497ce.7080...@deathbycomputers.co.uk
Re: configuration management
thanks for the replies. replying to Karl's message so that it goes into the list archive. so, my thoughts so far: wikipedia needs updating on this front. cdist looks pretty simple - i think i could have it up for what i'm using in a matter of minutes. cfengine looks pretty old school and it probably does what it does very well. it seems to have the best documentation and is probably most widely used. puppet seems to have decent documentation as well and doesn't seem that hard to get started with (think i'll probably start with that). bcfg2. i just don't know what to think of this. might be cool, it just doesn't look mature or that it has a niche or anything... On Fri, May 6, 2011 at 8:51 PM, Karl Vogel vogelke+u...@pobox.com wrote: On Fri, 6 May 2011 19:56:01 -0400, shawn wilson ag4ve...@gmail.com said: S i'm looking at using some type of configuration management software. i S have never used any of this software before, i just think i'm outgrowing S svn and scp :) I'd start with the simplest thing that's also close to what you're already using, so you spend less time fixing the tool and more time using it. Try cdist. -- Karl Vogel I don't speak for the USAF or my company The nearest thing to eternal life we will ever see on this earth is a government program. --R. Reagan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=cyzmpuaejz7giqe1ejm9u7sr...@mail.gmail.com
looking for configuration management tools
I administer some 20 servers and it's a pain to keep something like the various postfix configurations up to par. What I'd love to do is use CVS, but it stores no permission/user information. There's cvs-conf, but it's not documented and thus crap. Do you guys know of better tools to manage a configuration across multiple servers? -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Keyserver problems? http://keyserver.kjsl.com/~jharris/keyserver.html Get my key here: http://people.debian.org/~madduck/gpg/330c4a75.asc pgp0.pgp Description: PGP signature
Re: looking for configuration management tools
also sprach martin f krafft [EMAIL PROTECTED] [2003.03.15.1956 +0100]: Do you guys know of better tools to manage a configuration across multiple servers? cfengine2? i even know the author. are there alternatives? -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Keyserver problems? http://keyserver.kjsl.com/~jharris/keyserver.html Get my key here: http://people.debian.org/~madduck/gpg/330c4a75.asc pgp0.pgp Description: PGP signature
Re: looking for configuration management tools
martin f krafft wrote: I administer some 20 servers and it's a pain to keep something like the various postfix configurations up to par. What I'd love to do is use CVS, but it stores no permission/user information. There's cvs-conf, but it's not documented and thus crap. As opposed to pointing to a particular tool, let me point you toward a methodology. This is _the_ paper on the subject. Give it a read and then start looking at tools. http://www.infrastructures.org/papers/bootstrap/bootstrap.html Check out the infrastructures archives for past discussions. Posting a note there would probably find a useful and well informed discussion. http://mailman.terraluna.org/pipermail/infrastructures/ Bob pgp0.pgp Description: PGP signature
Understanding debconf: The Debian configuration management system
The Philadelphia Area Debian Society (PADS) (http://www.CJFearnley.com/pads/) Presents Understanding debconf: The Debian configuration management system When: Wednesday 17 October 2001, 8:00 PM - 9:30 PM Presenter: Chris Fearnley, Chief Technology Officer, LinuxForce Inc. Where: 636 Pine St Apartment #3 Philadelphia, PA Abstract We will introduce debconf and explain its role in Debian configuration management. Social Dinner TBD. Please see the web site http://www.CJFearnley.com/pads/ or the PADS mailing list (http://lists.LinuxForce.net/mailman/listinfo/pads/) for discussion of a location of the social dinner that will probably precede the meeting. At this time the location has not been determined. -- Christopher J. Fearnley | AdminForce Remote, LLC [EMAIL PROTECTED] | President and CTO http://www.AdminForce.net | Design Science Revolutionary Dare to be Naïve -- Bucky Fuller
Re: Configuration management
I have been toying with the same idea (putting stuf like /etc) under CVS control, though I haven't gotten round to become serious about it yet. My idea towards handling individual machine specifics would be to use the branch system. If a certain file needed a specific change, branch off (on that file only) and do it. The trick would be to have a consistent tag naming scheme that would automate the process in the other direction. One could then run CVS through some apropriate scripts that would examine the tag structure and do the right thing. ---+-- Christian Lynbech | Ericsson Telebit A/S Fax: +45 8628 8186 | Fabrikvej 11, DK-8260 Viby J Phone: +45 8738 2228 | email: [EMAIL PROTECTED] --- URL: http://www.tbit.dk ---+-- Hit the philistines three times over the head with the Elisp reference manual. - [EMAIL PROTECTED] (Michael A. Petonic)
Re: Configuration management
On Wed, 8 Mar 2000, Christian Lynbech on satellite wrote: I have been toying with the same idea (putting stuf like /etc) under CVS control, though I haven't gotten round to become serious about it yet. My idea towards handling individual machine specifics would be to use the branch system. If a certain file needed a specific change, branch off (on that file only) and do it. The trick would be to have a consistent tag naming scheme that would automate the process in the other direction. One could then run CVS through some apropriate scripts that would examine the tag structure and do the right thing. I'm not sure this would be quite enough. Typically the configuration files differ only slightly from one another. What I would like is some way of having a way of seperating the local host configuration from the standard configuration. Some packages are already configured this way but most are not. Cfengine would be one way of addressing this but it essentially takes over control of the entire configuration process which I don't care for. -- Jean Pierre
Re: Configuration management
[I am not on this mailing list. Please cc: me in replies.] * CVS (the remote protocol) doesn't track file permissions, ownership and symbolic links. In ftp://ftp.pn.com/pub/bb/cvsmapfs you'll find a workaround: # Purpose: # # It would be extremely useful to store an entire UNIX under # cvs. However, the only thing cvs promises to restore at # checkout is the contents of files, not owners, groups, modes, # symlinks, or devices. Cvsmapfs records this extra information # so you can restore it after a checkout, and then deletes # non-files and non-dirs so cvs won't choke on them. It # restores empty directories that cvs 'optimized away'. It # deals transparently with funny characters in filenames, and # warns you when they might cause cvs or rcs to misbehave. It # puts hard links back, even when they aren't in the same # directory. A member of the League for Programming Freedom (LPF) http://lpf.ai.mit.edu --- Brian Bartholomew - [EMAIL PROTECTED] - www.wv.com - Working Version, Cambridge, MA
Re: Configuration management
On 28 Feb 2000, Olaf Meeuwissen wrote: However, I'm not really happy with this way of doing things. I'd like to hear about some other ways. I've toyed with the idea of using CVS, archiving /etc and making a local package. Slightly related, I'm also looking for ways to quickly clone a system. We're using CVS for just that purpose. Right now we're source controlling the full /etc directory for each machine. We've also explored just a little the possiblity of sharing configuration information for different machines using the module facility of cvs. Overall, I'm pleased with what we have so far. The big win is we can track all changes to our configuration, we can audit who changed what when, and roll back to known good configuration. The main limitation we've run into are: * CVS (the remote protocol) doesn't track file permissions, ownership and symbolic links. All of these are important for configuration files. * CVS component model is directory based. To share configuration across machines the configuration files for a particular package must be isolated in a separate directory. Many Debian packages are not organized like this. * Machine specific changes are hard to isolated. Debian packages make this somewhat difficult. Something like cfengine can handle this but it doesn't integrate well with CVS. Hope this helps. -- Jean Pierre
Configuration management
Hi all, Up to now, I've been managing my system's configuration in a rather ad hoc kind of fashion: configuration during installation, fine-tuning it with with the set-up/configuration utilities that come with a package (or as a separate package) and roughly document what I did in a normal ChangeLog file. However, I'm not really happy with this way of doing things. I'd like to hear about some other ways. I've toyed with the idea of using CVS, archiving /etc and making a local package. Slightly related, I'm also looking for ways to quickly clone a system. Your suggestions are most welcome. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development
