On Sat, 21 Sep 2002, Jim Wildman wrote: > 1) monitor > 2) backups > 3) prestaged > 4) hire (viz. co-optinf jujitsu) > 5) different root > 6) Change password > 7) Firewall > 8) Complacency is your enemy.
hmmm ... I would add (it might be called part of 8, but lets make it express): 9) Study all the time -- subscribe at least to the security announcement mailing list of your vendor, or iet upstream, on every package you run. 10) Patch vendor releases updates -- it is not enough to know that the update which ate your system was fixed six months ago. 11) Design to meet Requirements -- including enough redundancy to meet SLA's, and fight for the advance spares and redundancy to do it right. I was at a major hospital yesterday, and needed a 4 G or bigger IDE drive -- __right now__ -- and there was not one in the 60 acre campus, I was told. ... 12) Document (maybe paper, maybe electronic, maybe only in the files themselves, which are on the backup media) to a degree that a 80 % restoration is less than a 24 hour clock hour task. 13) Drill -- yourself, and your staff -- Hand a red 3 x 5 card to a stranger and have them place it on anything in your lab. How do you work around the 'outage'? Extend the model with more cards at once, or maybe a deck of cards representing every item under your control. 14) Train -- yourself, and your staff -- Hand your disaster recovery notebook to a junior sysadmin, place a red card, stick your hands in your pocket and watch. Or maybe don't tell them about the notebook. <smile> Will they ask, or look for it, or make things worse? Anyone have any more? -- Russ Herrold ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.openprojects.net
