<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
</div>He sure was.  And it doesn't get much simpler than editing a config<br>
file.<br>
<div class="Ih2E3d"><br>
> Installing one package does actually work 99.99% of the time. It<br>
> seems a bit hackish but requires very few dependencies that wouldn't<br>
> already exist anyway (rpm).<br>
<br>
</div>Neither does config file editing, and it has the added advantage of<br>
not being even "a bit" hackish.<br>
<div class="Ih2E3d"><br>
> Besides none of this matters anyway - that's the way it's done on<br>
> the Redhat based distros so either we can get our panties in a twist<br>
> or work with it.<br>
<br>
</div><br>
<div class="Ih2E3d"><br>
Michael<br>
</div></blockquote></div><br>I do think there's a place for configuration management like cfengine but I also think there's the <br>best simplest way requiring fewer dependencies for all other times. It's like when you're writing  <br>
a shell script, do you make it bourne compatible or do you bring in BASH and make everyone <br>require it, do you use cut or do you bring in awk immediately etc... The more complex way will<br>give you more power and control but require more of the executer.<br>
<br>Managing the OS version for the package database in a package means you're not requiring the<br>OS to have any additional software during the course of setting the OS version that it didn't already have. <br>This lowest common denominator way doesn't fit all solutions. If you have a lot of near identical servers<br>
in a controlled environment it's always better to use something like cfengine to manage configuration files. <br>What we need to keep in mind is that not all configurations are typical server environments.  <br><br>In my case I have a bunch of machines (growing by about 5 a week) all over the world inside networks and companies<br>
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<br>and sftp connection through a firewall in a DMZ. <br>The machines are built by people who don't understand Linux and operated by Airplane technicians and engineers that <br>
have very little Linux knowledge as well as movie houses and others that have zero knowledge. In my case<br>the simplest solution with the smallest dependency footprint works best. <br><br>None of this really matters though because we're only relating it to how Smart works and how the variables should <br>
be set in the config files. Yum uses the centos-release file for OS version and I think you said uname to set $ARCH.<br>Either we mimic this method for Redhatish distros and then mimic the way APT does it for debianish distroes etc., we <br>
use a package everywhere (redhat/debian) to actually keep the channels config itself or we use something like CFengine to manage it. <br><br>The last one is out if you want to consider initial installation no matter how good it is for managing already installed servers. <br>
I <b>think</b> we agree on that.<br><br>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 <br>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<br>
if it's good form to tie repository/mirror information to smart releases since one is program code and the other describes outside variables<br>that could change and/or go away.. I think that's just a matter of my opinion though. <br>
<br>Ok, so let's assume we just include the repos (including hard coded version and arch numbers) in the smart package for each distro. <br>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<br>
stored in the config file automatically or do we have to tell it to suck them in?<br>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<br>
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.<br><br>If in fact it does consult those files on startup and will add or change any repository information then we can manage all repos<br>
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<br>time. <br><br>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<br>
and we should manage static repos with a config file or cfengine or whatever. <br><br>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<br>
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.<br>
<br>Grant<br><br><br>