On Sun, 29 Nov 1998, Juergen Braukmann wrote:
Eric Lee Green wrote:
A little more attention to enterprise-scale features, and I'd unhesitantly recommend it for large-scale deployments. Here's some things that need to be considered for enterprise-scale deployments: 1) Routine maintenance tasks need to be distributable across the network without editing script files. Red Hat's /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly are such a means of doing this. I can use "rdist" or equivalent and zap out
is this a problem?? you *can* alter / create entries in /etc/crontab
Across 1,000 machines, each of which may also have local crontab alterations? As you state, it is not a problem of individual deployments. However, for enterprise-wide deployments, it *IS* a problem. All Red Hat did was add a script that'll execute all the scripts in a directory, add this to /etc/crontab, and voila. Now I can send out something to happen on a daily basis (e.g., I have a particular application where I want the application's password to change on a daily basis, due to security reasons) without bothering the contents of any file on the system. It's like Sys V Init. It allows you to do for cron-scheduled tasks what Sys V Init does for startup tasks -- i.e., change the configuration without messing with any other part of the configuration.
3) An effort must be made to segregate configuration and user information from the rest of the system so that a coherent backup strategy can be formulated. For example, under Red Hat Linux I know that if I back up /etc, /usr/local, and /home I can restore my entire system configuration by reinstalling the system, reinstalling my applications such as applix, then restoring the contents of those
As far as I remember, a few things were changed due to "standardisation", like the move from /etc/init.d to /sbin/init.d. So,
I read the LHS different from what SuSE reads it. No matter. /sbin/init.d can live in /sbin, but the configuration information (the links to the individual scripts in /sbin/init.d) needs to live under the /etc directory because /etc is where the LHS says configuration info needs to live. Same thing with the link to the "X" server. That is *CONFIGURATION* information, buster -- and belongs under /etc. When I save and restore /etc, I want *ALL* of my configuration info to be saved and restored, not just the particular configuration info that happens to live under /etc. Again, this is not much of an issue under individual deployments... but for large-scale deployments it is DEFINITELY an issue, because it allows me to have a reasonable backup policy. For example, I developed an automated backup system that backed up /database and /home daily, /etc weekly and /usr/local monthly from all the Linux servers on my WAN to a centralized backup server that had a 40gb DLT on it. This happened at 1am in the morning, every night, as a scheduled task. There is *NO WAY* that I could backup the ENTIRE contents of these servers on a regular basis, even this little bit, being transmitted as a compressed tarball, takes up the entire bandwidth of the WAN for several hours. Not to mention that even a 40gb DLT has a finite capacity! A machine went down, we re-installed Linux on it, we re-installed the database software and /etc and /usr/local and /home and /database, and the machine was back up and running. *THAT* is the kind of reassurance I need -- that I can restore a machine from scratch and know that I'm not going to be bit by some kind of configuration information living somewhere else on the system that I did not have backed up over the WAN. And no, we can *NOT* depend on branch sites performing regular backups! (They were supposed to, but they never did, and unfortunately there's nothing that the IT department can do to force them to do so).
if we are talking about that, we have to keep in mind that there are standards set in unix world that should be reached (by all unices).
I don't care about standards. I care about getting the job done. Standards are supposed to help in that. If parts of a standard hinder that, then it is the standard that is wrong, not me.
Lest you think these are just minor quibbles: they are *NOT* minor quibbles when you are trying to maintain 250 systems scattered across a 10,000 square mile area in less than 2 hours a day of available time. I have managed enterprise-scale deployments. "minor" things like this swiftly become major when the number of systems involved passes 100. Many of these features were added to Red Hat 4.0 as the result of feedback from people like me, people who were managing
yes, that's true. try that with the "other" OS. ;-)
You're joking, right? :-).
asks for feedback from others who are involved or who have been involved in the past with corporate-wide deployments of Linux, because I know that you can probably come up with some stuff that'll blow Red Hat in the weeds there. But it won't happen without someone making it their
should this *realy* be a prime goal??
Blowing Red Hat into the weeds should not be a prime goal. Improving the product should be. Enterprise-scale managability issues need to be addressed no matter what other Linux distributions do. I mention Red Hat merely because this is one area where they have done their homework (as you would suspect, given that Red Hat's technical lead is an old system administrator, not a hacker). -- Eric Lee Green eric@linux-hw.com <A HREF="http://www.linux-hw.com/~eric"><A HREF="http://www.linux-hw.com/~eric</A">http://www.linux-hw.com/~eric</A</A>> "Linux represents a best-of-breed UNIX, that is trusted in mission critical applications..." -- internal Microsoft memo - To get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e