headers
John Jasen | 27 Apr 22:25

Puppet: a few questions and issues


As a brief summary, $work had a puppet module call the underlying OS
package manager. The package manager (apt) apparently failed, reporting
a non-zero exit status to puppet, which seems to have aborted the rest
of the puppet run. The systems were left in a half-provisioned state,
which escaped our monitoring system for a few days.

In looking at the matter, we were not quickly able to come up with a way
to detect failed puppet runs. Mining syslog may be an option, but see
the point about that further in. Is there an acceptable external way
(say through nagios) to determine if the last puppet run succeeded or
failed?

Second, it seems that puppetd -t and puppetd -t --noop both log the same
to syslog and also update the state.yaml file. Is there a way to
differentiate --noop or test runs from syslog? Is there a way to make it
not update the state file? If not, should there be? :)

Thanks in advance.

--

-- 
-- John E. Jasen (jjasen@...)
-- "Deserve Victory." -- Terry Goodkind, Naked Empire
Permalink | Reply | 4 comments |
headers
John P. Rouillard | 25 Feb 21:42
Favicon

Config management and asset tracking on tickets


Hi all:

Here is my senario:

  ticketing system with an asset tracker

  tickets should include info on which hosts (asset) were modified
    for a given ticket so when problems occur I can search for a
    host and see all the recent changes on the host.

does anybody do anything like this? If so, does your CM system supply
you with the asset information or do you add it manually?

In a CM managed environment, do we need a different/enhanced idea of
an asset (e.g. an asset is a service rather than a host) to make
troubleshooting problems easier?

Any quips, comments, evasions, questions or answers welcome.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
Permalink | Reply | 9 comments |
headers
John P. Rouillard | 28 Jul 05:28
Favicon

Has the config mgmt workshop at LISA been scheduled?

Hi all:

Has anybody scheduled a configuration management workshop
for LISA 2009?

I ask because it has been placed on Sundays in the past and I am
teaching a full day course that Sunday, so I was hoping to influence
the day on which the workshop is held (i.e. pretty please don't
schedule it on Sunday 8-)).

Thanks.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
Permalink | Reply | 2 comments |
headers
James Youngman | 11 Apr 21:06
Picon
Gravatar

GNU CSSC 1.2.0 is released

I'm pleased to announce the release of GNU CSSC, version
1.2.0.

This is a stable release and follows the previous stable release
1.0.1.  Stable releases of CSSC are available from ftp.gnu.org.

CSSC ("Compatibly Stupid Source Control") is the GNU
project's replacement for the traditional Unix SCCS suite.
It aims for full compatibility, including precise nuances of
behaviour, support for all command-line options, and in most
cases bug-for-bug compatibility.  CSSC comes with an
extensive automated test suite.

If you are currently using SCCS to do version control of
software, you should be able to just drop in CSSC, even for
example if you have a large number of shell scripts which
are layered on top of SCCS and depend on it.  This should
allow you to develop on and for the GNU/Linux platform if
your source code exists only in an SCCS repository.  CSSC
also allows you to migrate to a more modern version control
system (such as CVS or git).

There is a mailing list for users of the CSSC suite.  To
join it, please send email to <cssc-users-request <at> gnu.org>
or visit the URL
http://lists.gnu.org/mailman/listinfo/cssc-users.

For more information about CSSC, please see
http://www.gnu.org/software/cssc/.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Jenkins | 5 Mar 16:27
Picon
Gravatar

Suggestion: config-mgmt sponsorship of an annual CM survey

Summary: I've recently been talking with owners/developers of a few of
the different configuration management systems, and I would like to
suggest that this group work together to build an annual survey that
can then be advertised and used across the different communities, with
the input process for the survey being open, and the results being
open as well.

Background: I've noticed that many of the CM developers are doing
surveys within their own communities; however, many of the questions
are actually applicable across all CM communities.  Since there are
overlapping (competing, even) surveys, it's not realistic to have the
survey being done by ABC go out to the XYZ community, even though much
of the data would be usefully shared across the larger CM community.

Proposal: whomever is interested form a group to work on a generic
survey to be distributed annually that CM product owners could opt-in
to use in their communities.  The CM product owners who opt-in could
still do their own product-specific surveys within their own
communities, of course, to help with their own prioritize directions
for their products, but the generic survey would be cross-product,
with resulting data available to everyone.

Do people think that's a good idea, and who is interested in
participating in helping construct the survey?

Thanks,
Steven Jenkins
End Point Corporation
http://www.endpoint.com/
(Continue reading)

Permalink | Reply | 0 comments |
headers
John P. Rouillard | 16 Jan 23:50
Favicon

DACS - YACCMS version 2.0 released


Hi Folks:

Well the much promised version 2.0 of the 'Config' computer
configuration management system renamed DACS is finally released.

The home page is:

  http://www.cs.umb.edu/~rouilj/DACS

This page includes the manula in pdf and html forms as well as a tar
bundle with a starter DACS master tree.

A quick blurb from the home page:

DACS, the Distribution and Configuration System, is a tool for
maintaining system configuration on multiple computers. It is similar
to other CCM (computer configuration management) tools such as bcfg2,
lcfg, puppet and the well known cfengine. However, it has some unique
features, it integrates:

    * a host "database"
    * a version control system
    * an optional file generation system
    * a file distribution and remote command execution mechanism

The other systems I looked at in 2005 had minimal (or absent) support
for the key things I wanted in a configuration system:

    * a database of information about systems that can be queried
(Continue reading)

Permalink | Reply | 0 comments |
headers
John P. Rouillard | 2 Dec 05:09
Favicon

Looking for editors for DACS CCM documentation

Hi all:

During the last LISA conference I had a few people ask me about the
availiability of the next generation of the Config CCM (computer
configuration mangement) tool called DACS.

I have taken this week off from work to get a running start on getting
the documentation and release done and I am looking for some
editors/reviewers for the documentation.

I have one prior DACS user who is looking at deploying it at another
job. I would like at least one reviewer who is using/has used a CCM system,
bcfg2, puppet, cfengine etc doesn't matter. Also I would like a
reviewer who hasn't deployed or used a CCM and is considering it.

I am afraid I can't provide anything except mention in the document
(unless you would rather I omit your name 8-)).

I am looking for a release by 1 Jan, so the editing and comments would
have to be done by then.

I have the following sections at the moment:

  Intro
  Database
  Version Control System
  Build system
  Distribution
  Examples/Case Studies
  Advanced topics
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Anderson | 6 Oct 09:24
Picon
Picon

Re: Configuration files


On 4 Oct 2008, at 20:00, Narayan Desai <desai@...> wrote:

>   Paul> I think this is going in the right direction, but I still  
> think that
>   Paul> dealing with "files" as opaque objects is misleading - a  
> "file" is
>   Paul> rather an arbitrary unit - it is just a convenient way of  
> bundling
>   Paul> together some information - which may, or may not be  
> conceptually
>   Paul> related in configuration terms.
>
> I disagree. While I certainly agree that configuration files are a
> historical artifact, as opposed to some sort of platonic ideal, there
> are some really useful properties that configuration file-based
> statistics have that have not yet (to my knowledge) been implemented
> with a parameter-based statistics mechanisms (for lack of a better  
> term).
>
> Like it or not, configuration files are a unique formulation; this  
> means
> that a given change (or state) can be represented in a unique
> fashion.

You are picking a completely arbitrary level by talking about files. Why
not talk about bits on the disk if you want to use this argument -  
the same
is true there, and that actually makes a much better starting point  
if you
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Anderson | 3 Oct 13:48
Picon
Picon

Re: Config-mgmt Digest, Vol 32, Issue 2


On 2 Oct 2008, at 20:00, John Rouillard <rouilj@...> wrote:

> I am not claiming that a file is the ultimate end all, but it does
> provide a level of granularity that can be measured.

I guess I'm just not sure what you are measuring by doing this  
though ...
It doesn't really relate to the effort required to make the change,  
or the potential
disruption, or .... (anything useful?)

>> Who cares how
>> many low-level operations (file replacements, file edits, database
>> inserts, process restarts) the configuration management system needs
>> to perform?
>
> Well the goal is to get a configuration change deployed. If you are
> waiting for an hour for the CM system to run through it's file
> generation, update, restart to impose a configuration then it is a big
> deal as it contributes to waiting time which is a type of waste under
> a LEAN framework.

Um. I'm still don't get this. Isn't it like saying that you are going  
to write
raw machine code because you can't be bothered to wait for the
compiler .. .. ? Usually, having it correct is more important than fast.

> Then you may have to do it a couple of times if you didn't get the
> config right the first time. Right now depending on how well the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Anderson | 1 Oct 08:42
Picon
Picon

Re: Config-mgmt Digest, Vol 31, Issue 6


On 30 Sep 2008, at 20:00, Lamont Granquist <lamont@...>  
wrote:

> if you want to measure a useful statistic, measure the complexity  
> of the configuration state when it comes to deltas between boxes.
> as an example:
>
> if you have 30,000 servers with the same sshd_config file that is  
> highly compressible information and is a very low amount of state.
>
> if you have 30,000 servers with the same sshd_config file except  
> one group of boxes which have a different sshd_config file then  
> that is only slightly less compressible, but it roughly doubles the  
> compressed state (considering the sshd_config files to be opaque).
>
> if you have 30,000 servers with most having the same sshd_config  
> file except you've got 10 unique groups but those groups all share  
> the same slightly different sshd_config file, then that is even  
> less compressible.
>
> if you have 30,000 servers and have a standarized default, but 10  
> different groups have 10 differently unique sshd_config files then  
> you've degraded your compressibility even more.
>
> if you have 30,000 servers and have 10 different sshd_configs, but  
> have 6,000 different groups of servers and have no sane default and  
> each server group gets one of the 10 different config files, then  
> you've got a huge amount of config state (equivalent to 6,000  
> individual servers with each server having one of 10 different
(Continue reading)

Permalink | Reply | 8 comments |
headers
Paul Anderson | 29 Sep 09:30
Picon
Picon

Useful stats from a CM system (John Rouillard)


On 28 Sep 2008, at 20:00, John Rouillard <rouilj@...> wrote:

>> I'd be interested in a very simple
>> classification of the reasons - eg. software upgrade, hardware
>> upgrade, configuration bug fix, etc. etc.
>
> Interesting idea. Do you have an exhaustive list of categories
> that you would like to see?

No - I had these "starters", but I thought we'd need to try it out  
for real
and add new ones when people came to make a change that didn't fit
any of the existing categories. I'd *really* like to see some figures on
this, but you need the buy-in from the people actually making the
changes to make this worthwhile ....

>  The
> amount of work the user has to do is reduced by 1/(multiplier) since
> the user touches one file rather than say the 10 files that really
> have to be updated.

Yes. Again, its not just the amount of work though - its the improved  
chance
of getting it consistent and correct ....

>> (*) "How do you tell whether your config management system is making
>> things better?". It would be very interesting to do some kind of
>> formal study on this
>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane