Hi All, Merry Xmas and Happy New Year!
Thanks to everybody who shared their experience regarding the strategy
for operational system updates. Here is the summary of responses - it
seems that majority of people replied are quite cautious in this matter,
and are not in a hurry to update the OS on spectrometers (although try to
apply security patches). Installing a firewall is popular option. Making
good backup of the old working system is important. As the approaches vary
a bit, I've decided to paste all original replies one after another in the
end of this message. Thanks to the contributing authors once again.
Answering the question - the program which was affected by the OS update
(which I mentioned in the original posting) was NOT Xwinnmr or any other
program controlling spectrometer.
Best regards,
Alex
Original message:
===================================================
I've got philosophic question after one of the programs stopped working for
unknown reasons (bug, obviously) following operational system update :(
Does anybody use any particular strategy to avoid potential problems with
incompatibility of existing programs, especially those running
spectrometers (like Xwinnmr, etc., which are not updated as often as OS)
and new updates of operational system (e.g., for minor updates from
IRIX6.5.N to 6.5.N+1, or major updates from 6.N to 6.N+1)? If you do update
OS, you are risking to introduce incompatibilities or introduce new bugs
into otherwise perfectly running system (and then wait for couple of weeks
until the bug will be found and fixed). If you do not update OS, you risk
to compromise security. Personally I would rather keep the working system
as it is while it works, and update only as last resort, but may be I'm
paranoid?
Any suggestions on this issue? I wonder if it is possible to keep up with
security improvements, but without many changes in the system.
===================================================
Responces:
There used to be, and probably still is, a table on the Bruker website
listing compatibility between Irix versions and XwinNMR versions.
I'm running Irix 6.5.14 with XwinNMR 2.6 with no problems on 6 computers.
Perhaps the choice should be not upgrade the OS if you need to run a really
old version of XwinNMR, but to consider separating the system from the
internet and have a purely local nmr network. Not ideal, but it would keep
running. What OS/Xwin version conflict have you found?
I still run our spectrometers on IRIX. In principle, I start with updates of
OS and/ or xwinnmr on one of our processing workstations (IRIX as well as
windows) and see how the users go. Only if there are no problems for about
two to three months, and if there are no other problems reported (eg, Bruker
webpage etc) I start to update things on the O2s that control the
spectrometers.
I try to update the OS and xwinnmr simultaneously if possible. I usually
wait for a few months after the new versions have been released to see if
others report about problems. So far, I never run into serious problems.
For what it's worth, our stratgey is determined by a combination of
laziness and fear. We
(a) keep all our machines behind a firewall (now pretty cheap), to
minimise security issues and do away with one driver for frequent OS
software changes;
(b) keep old OS versions until there's a definite need for change
(either we or the applications software need facilities offered by newer
versions); and
(c) first install new OS versions on an external disk for testing -
disks are very cheap compared to the time that can be wasted overwriting a
working system with a kamikaze OS version.
This is an important issue indeed. One of our spectrometers got
compromised and we realized that, the only
thing to do is to re-install the entire OS and start from there. This is a
situation, where, we cannot avoid re-installing the OS. But, I am not going
to upgrade the OS. I feel it is better to keep the OS as recommended by the
manufacturer, Varian in my case, and keep applying the patches. The
consensus in my circles is, to wait for some feedback about new OS and NMR
software releases, especially from the manufacturer, and then try it out.
Especially, if a particular machine is doing, 'production runs', it is
better to go slow at it.
I became convinced a long time ago that spectrometer hosts should
NOT be accessible from the Internet. The risks outweigh the benefits. In
that case you only need to patch/upgrade to add functionality. Any
computer on the Internet has to be set up with security in mind,
monitored, and patched promptly--and you will still have problems.
When I upgraded last I also wiped the disk clean and backed up
everything of any worth. If I encounter the incompatibility problem I
make sure I have the prior installation disks ready, so that I can just
reinstall the old system. (I don't have the luxury of waiting with only
one instrument, which is used 12+ hours/day.) If I have to reinstall
the old system, at least the disk is clean and I don't have any
conflicts. With the age of my system the next upgrade will be to
Linux or Windows on a PC. The Indys are too old to deal with the
larger operating systems. Mine is running into clock errors as well.
Needless to say, my Indy saw its last upgrade nearly 2 years ago
and I'll be upgrading soon. The next upgrade will also include a
firewall.
My motto--Sacrifice the firewall-Keep the instrument running!
We have Suns running the spectrometers. In general I plan to install all
the latest patches each time we do a fill. This is basic security. And yes
I was once hacked when I failed to patch. I do not update the OS until
something dramatic happens. Sometimes you have a problem and you know that
the place to start is by reinstalling the OS and the spectrometer software.
Then I go for the latest stable version of the OS that the vendor supports
which will run on that particular computer.
For SGIs since the updates to the OS generally fix all the current security
issues I make a point of regularly updating the OS. The 6.5.N releases
should not change the OS in fundamental ways. They serve many of the same
functions of the Sun patch sets. We have never seen any of our processing
software quit after such an upgrade. SGI has recently changed their policy
about access to software maintenance updates. This should be a concern for
anyone who does not have a service contract.
All is takes is having a system hacked to make one paranoid.
Bruker states that it will no longer support ParaVision and Xwinnmr on the
SGI platform, for me that means no more OS upgrades besides security
updates. Do I like it NO! But perhaps the Lunix (sp.) will be a cheeper
proposition in the long run. But it should be clear that one should NOT run
an OS that post dates Bruker Ware.
I just answered this for myself. I opted to update the OS. In my case, I
had been hacked and was starting to see some problems which may or may not
have been related, so I had to do a clean install before asking help on
spectrometer problems. As long as I was going to suffer learning a lot of
unix, I opted to do the clean install of the newest (supported) system so
that my hard-earned knowledge would be current longer; so the spectrometer
company would be more interested in any incompatibilities I found; and so
more security loopholes would be closed.
Given the price of disks, however, you can have it both ways. You want to
buy new disks every 5 years or so anyway. ("mean time until failure"; 5
year old disks are only 4 Gb). I started with a blank disk for my clean
install; you could just as well copy the old system and data onto the new
disk, and update the OS on that. The original disk can be restored into the
computer and booted from in about 10 minutes. We did this several times
during re-installation week when the users' work ground to a halt.
What is very valuable is to keep a detailed record of everything you had to
do to get the spectrometer running properly again: All of the critical
spectrometer configuration and standard parameter files; needed tweaks of
the OS after the by-the-book installation. The first attempt at
installation took me a week, overdriving my brain with all the IQ I could
muster. The second time was a charm - an afternoon's work, relaxing down in
the double-digit brain loads, using the cookbook recipe I wrote the first time.
I'll be posting that recipe as soon as I finish the TCP wrapper
installation. (Sorry it's for Solaris 8 on a Sparc running a Varian Inova. )
Our response is to restrict access to the critical spectrometer host
computers (via a firewall). Lower use spectrometers are first tested with
any updates before propagation throughout the facility. Only data stations
are accessible to the outside, and these are constantly updated for security patches.
A simple, cheap solution is to only plug the spectrometer host computer into
the network when you need to transfer data. Leave it off the network all
the rest of the time and you don't have to worry. Burning CDs is so cheap
and easy now there is little reason to have network access to these few
machines.
--
Dr. Alexander P. Golovanov
Biological Magnetic Resonance Centre
Department of Biomolecular Sciences
University of Manchester Institute of Science & Technology (UMIST)
P.O.Box 88,
Manchester M60 1QD
Tel. No: ++44 (0) 161 200 5813 Office
++44 (0) 161 200 5812 NMR room
Fax. No: ++44 (0) 161 236 0409
e-mail a.golovanov_at_umist.ac.uk
Received on Thu Dec 19 2002 - 11:09:56 MST