On Sun, 7 Oct 2001, Pekka Savola wrote:
> On Sun, 7 Oct 2001, Riku Meskanen wrote:
> > Does anybody know if there exist a project(s) or effort(s)
> > to create a proper centralized management system for Linux?
> >
> > None of current Linux (OSS) MGMT systems I've heard¹
> > or tried have not gone into the direction wich would
> > try to implement centralized installed software,
> > configurations and policies from database in MGMT station.
>
> We're managing about 30-40 servers and equal number of workstations,
> ranging from 5.2 to 7.2 beta, using cfengine (www.cfengine.org) and
> autoupdate (search freshmeat).
>
We have around same amount of servers kept up with autorpm
the cfengine pointer was good info thanks, I'll check what
it can do for us.
But, rather than just talking and thinking ourself
here where I happen to work now, I'm having broader
view... I have no difficulties understanding what's
the point behind the centralized remote software
administration tools that have appeared from Microsoft
(SMS, W2k AD w/ installation tools), Novell (ZEN), HP
(Ignite-UX), Lucent (CSL), etc.
They _all_ should pay back the time spent on installations,
upgrades etc on the setup effort quite easily, unless it
"costs an arm and the leg" to start with ;)
> Autoupdate keeps all the systems current RPM-wise of a local ftp
> repository, and cfengine can be used to synchronize configurations and
> perform basically anything you want in a central fashion.
>
> This has been in use for 2.5 years now. It has some limitations, but
> has proven to be very effective if one compares that "each system is an
> individual".
>
Duh, I know that. But when having the individual systems
without inheriting the packages, configurations and policies
we lose at least following:
- The systems will only kept up to date software
that was installed, it's darn much harder to add
or remove software afterwards to a group of systems.
For example: Think of scenario just with
either drag&drop/select/type to to class container
where you have hundred workstations in it, then
you kick one computer from the tool and it
will install the new package.
Right, now you ssh to it, modify the configuration
what you like and then notify with the tool
remotely the MGMT-station that you changed
the configuration and it will appear to the
management console where you select the config
file you just did. Then you just copy/link it
to whole class and kick whole class which then
propagates to each individual host in that class
to invoke installation and copying the config-
guration you just modified from the MGMT-station.
Beats 6-0 running ssh loops for "rpm -ivh ..."
to a bunch of systems. Ofcourse the system with
up2date, autorpm or autoupdate will be kept
upgraded when new packages appear to certain
location, but IMHO it's still a big difference.
- Installing and cloning new systems whould be a breeze.
- Having a consistent view from one place what is
installed and where. This would help on reporting,
creating plans for upgrades, checking inconsistencies
recovering possibly compromised or failed systems,
getting a software inventory installed would be childs
play.
- Centralized configuration file cvs history would be
a nice feature too compared to comparing differencies
with individual systems :)
:-) riku
--
[ This .signature intentionally left blank ]
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
