Bhaskar, I very much appreciate this advice. As a nacent system administrator, I have many issues I still need to get covered.
I am running RH9. How do you have the UPS trigger a shutdown on the server? I know that the devices come with windows drivers and USB connections, but I don't know if there are linux drivers. Thanks again Kevin P.S. I don't keep most of the messages posted this list. But I almost always keep Bhaskar's -- and I usually come back to them at least once or twice in the future. Thanks again, Bhaskar! --- "K.S. Bhaskar" <[EMAIL PROTECTED]> wrote: > Kevin, Rusty, et al -- > > Although VistA on GT.M on Linux on CoLinux on > Windows is likely to be a > perfectly good demonstration environment, it is not > supported for > production or even safe for situations where you > need to ensure data > integrity (like production). Please do not use it > in production. > > The only officially supported Linux distribution for > GT.M is RHEL 3. It > is safe to put GT.M in production on just about any > contemporary release > of any major Linux distribution. Anything else is > potluck and I must > strongly urge against it. Let me give a medical > analogy. > > A doctor getting treated by another doctor is > officially supported. A > doctor treating himself or his loved ones is not > officially supported, > but safe as long as he can keep himself objective. > Uncle Fred offering > you his prescription migraine pill when you have a > headache that won't > go away is potluck. > > For a database to have integrity in the face of a > system crash, the > behavior of the underlying IO subsystem needs to be > (a) known and (b) > predictable. When GT.M says "commit this data to > non-volatile storage, > now" and hears back from the operating system that > it is committed, in > the event of a system crash, when recovering, GT.M > needs to be sure that > committed data was indeed committed. When layering > one operating system > on top of another, this assurance does not exist. > This is just one > example of the need to have known and predictable > underlying system > behavior. > > A demonstration environment needs to be operational > for a small period > of time when everything underneath is operating > correctly. Worst case, > for a demonstration environment is a failed > demonstration and you > recover by starting over. Production environments > do not have this > luxury, and must be much more rigorous. [By way of > background, I came > to GT.M by way of a career in electronics test and > measurement - in > fact, every time you step on a 757 or 767, you are > putting your life in > my hands, because I was the software architect of a > instrument used to > test and troubleshoot their radio altimeter. I > bring a "belt & > suspenders" approach to engineering and I find > myself annoyed by things > like operating systems that need frequent > rebooting.] > > In this context, officially supported means that > Fidelity has a server > grade system (as opposed to something you might buy > in Staples, Wal-mart > or Best Buy) in house running RHEL 3, and we run the > GT.M regression > test suite on it for every production release of > GT.M. A contemporary > release of a major distribution (Debian > Stable/Testing, SuSE, Mandrake, > Fedora, etc.) on server grade hardware is safe > because the core > components that GT.M relies on is very small, and to > the best of our > knowledge is both common across contemporary > releases of major > distributions, as well as being well tested. > Potluck is, well, potluck. > > Note that this extends to hardware. Use server > grade hardware (it > doesn't have to be a big name brand like IBM, HP or > Dell - you can > certainly use reputable off-brands like Penguin > Computing). In > production, USB flash drives are not acceptable; > even USB or PCMCIA hard > drives are not. Use server-grade IDE or SCSI hard > drives from reputable > manufacturers, not consumer grade disk drives in a > RAID 5, RAID 0+1 or > RAID 1+0 configuration. If you plan to push > performance, disk > controllers that have battery-backed nonvolatile > "write back" cache, > with Linux drivers that support this functionality > can help; RAID 0+1 > and RAID 1+0 will perform better than RAID 5. > > NFS or SMB (Samba) mounted file systems, as well as > NTFS and FAT file > systems (on Linux) are potluck for production. Use > ext3, reiserfs, jfs > or xfs. [Ext3 is officially supported; reiserfs is > faster and very safe > - I personally use reiserfs in preference to ext3; > jfs and xfs are > believed safe.] > > More notes for production: > > Get a UPS, and connect it to your computer > system so that when > the power fails you can script an automated > and orderly > shutdown. > > Run a server with the minimum set of > packages that you need for > production. Tuxracer is cool, but do you > really want that on > your production EHR system? Every unwanted > package is one more > potential vulnerability, and one more piece > of software that > will be periodically patched and updated. > > Go through the procedures for all routine > operations (e.g., > backup) as well as all the forseeable but > unscheduled > eventualities (e.g., power failure, > forgotten password). Create > a "run-book", and have it handy near the > computer console. When > things go bump in the night, your sleep > deprived brain is more > likely to be able to correctly follow a > documented series of > steps than correctly plan a course of > action. > > Last but not least, buy support contracts - > from your hardware > vendor, for your operating system (you can > purchase support for > all major Linux distributions - Crawford > Rainwater may want to > comment here), for GT.M, and, if you are not > supporting VistA > yourself, then for VistA. > > Someone like Jim Self who has run a large production > installation may > wish to expand on (or disagree with) this advice. > > -- Bhaskar > > *************************************************************************** > This electronic mail transmission contains > confidential and/or privileged information intended > only for the person(s) named. > Any use, distribution, copying or disclosure by > another person is strictly prohibited. > *************************************************************************** > > NOTE: Ce courriel est destine exclusivement au(x) > destinataire(s) mentionne(s) ci-dessus et peut > contenir de l'information privilegiee, > confidentielle et/ou dispensee de divulgation aux > termes des lois applicables. Si vous avez recu ce > message par erreur, ou s'il ne vous est pas destine, > veuillez le mentionner immediatement a l'expediteur > et effacer ce courriel. > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the hype. > Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id396&op=click > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === message truncated === __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
