Smart config file parsing

[Grant McWilliams]

>
>
> He sure was.  And it doesn't get much simpler than editing a config
> file.
>
> > Installing one package does actually work 99.99% of the time. It
> > seems a bit hackish but requires very few dependencies that wouldn't
> > already exist anyway (rpm).
>
> Neither does config file editing, and it has the added advantage of
> not being even "a bit" hackish.
>
> > Besides none of this matters anyway - that's the way it's done on
> > the Redhat based distros so either we can get our panties in a twist
> > or work with it.
>
>
>
> Michael
>

I do think there's a place for configuration management like cfengine but I
also think there's the
best simplest way requiring fewer dependencies for all other times. It's
like when you're writing
a shell script, do you make it bourne compatible or do you bring in BASH and
make everyone
require it, do you use cut or do you bring in awk immediately etc... The
more complex way will
give you more power and control but require more of the executer.

Managing the OS version for the package database in a package means you're
not requiring the
OS to have any additional software during the course of setting the OS
version that it didn't already have.
This lowest common denominator way doesn't fit all solutions. If you have a
lot of near identical servers
in a controlled environment it's always better to use something like
cfengine to manage configuration files.
What we need to keep in mind is that not all configurations are typical
server environments.

In my case I have a bunch of machines (growing by about 5 a week) all over
the world inside networks and companies
that I don't control. There's no ability to push anything so I have to rely
on the machines accessing an rpm repo across
and sftp connection through a firewall in a DMZ.
The machines are built by people who don't understand Linux and operated by
Airplane technicians and engineers that
have very little Linux knowledge as well as movie houses and others that
have zero knowledge. In my case
the simplest solution with the smallest dependency footprint works best.

None of this really matters though because we're only relating it to how
Smart works and how the variables should
be set in the config files. Yum uses the centos-release file for OS version
and I think you said uname to set $ARCH.
Either we mimic this method for Redhatish distros and then mimic the way APT
does it for debianish distroes etc., we
use a package everywhere (redhat/debian) to actually keep the channels
config itself or we use something like CFengine to manage it.

The last one is out if you want to consider initial installation no matter
how good it is for managing already installed servers.
I *think* we agree on that.

I have no problem setting the initial repositories in the smartpm rpm as
long as that rpm is updated if any repository does not use
a symlink to reference the most current version. That's the only time the
repos rpm would have to be updated. However, I don't know
if it's good form to tie repository/mirror information to smart releases
since one is program code and the other describes outside variables
that could change and/or go away.. I think that's just a matter of my
opinion though.

Ok, so let's assume we just include the repos (including hard coded version
and arch numbers) in the smart package for each distro.
The Smart rpm with updated repo information is updated so Smart updates
itself and as a result the repo file. Will smart notice the new repositories
stored in the config file automatically or do we have to tell it to suck
them in?
When I first started using Smart it didn't reliably notice differences
between what was in /etc/smart/channels and what it stored in it's internal
binary config whereas on initial install it always picked them up so I've
scripted a remove-channel/get new channels,mirrors file/suck in new
channels/mirrors.

If in fact it does consult those files on startup and will add or change any
repository information then we can manage all repos
with a package with all values hard coded. I don't know if it does this out
of interest in speed but I haven't tested that behavior in a really long
time.

So I guess what I'm wondering is how do you folks think this should be
managed. Maybe Michaels right and we don't need variables in the config
and we should manage static repos with a config file or cfengine or
whatever.

Ideas please. I'm going to ask the Yum/Redhat folks what their idea behind
the variables are too because I'd like to know. Maybe they've got something
in mind that we don't know about. I've been around Redhat long enough to
know that generally a lot of thought goes into their products (except for
the lvm gui!) but this may be something they inherited and since it works
don't have any reason to change it. I don't know.

Grant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.labix.org/pipermail/smart-labix.org/attachments/20080616/a6dc9cdf/attachment-0003.htm>