On Sun, 7 Oct 2001, Riku Meskanen wrote: > 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.
We used autorpm before, but it is way too inflexible and unmaintained to be used anymore. Autoupdate can solve dependencies (also circular), kernel upgrades w/ lilo.conf modifications and a lot of interesting stuff. > 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. As noted, the tricks here are just a top of an iceberg. It would be nice to be able to keep all the relevant configs local to the systems centrally managed so that in a case of e.g. emergency, you could just "re-create" the O/S from scratch with proper IP, host, networking etc. settings. > > 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. This is no problem; with autorpm and now autoupdate, we have used 'install' directory in addition to 'updates'; every rpm appearing to 'install' is automatically installed in the system. This way one can trivially install new packages on all the systems. > - Installing and cloning new systems whould be a breeze. Installing is no problem with kickstart and/or customized install trees. > - 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. This is one thing that should be focused more on. E.g. quite often if you haven't personally installed and administrated a box and are about to e.g. upgrade it, you often don't know if there are some local issues to consider (e.g. sendmail rpm was removed, replaced with something else, etcetc.). This is a matter of documentation, and cannot (much) be helped, but automation and using _self-documenting_ tools like CVS might be a key here. > - Centralized configuration file cvs history would be > a nice feature too compared to comparing differencies > with individual systems :) Our global configs (distributed through cfengine) are stored in CVS. Keeping the most important local configs in cvs would also be interesting, but that might be too difficult a task to do properly. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
