[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19990625: next mcidasx terminal + security

>From: alan anderson <address@hidden>
>Organization: St. Cloud State
>Keywords: 199906252026.OAA25997 McIDAS Solaris x86


>We are bring up our next pc running solaris for intel.  Initial install
>went ok, but have a few glitches in getting it to work on the network.
>I think we had a similar problem with waldo, so am looking back in my
>email records.  Will check with you next week if it remains stuck.

OK, I'll be here.

>For the install of mcidasx, from what I see, we do not need perl or ntp, 
>but will need gcc and f2c which are part of the solaris package.

You should probably be running ntp so that the time on your system
stays correct.  In order to build McIDAS on the systems you would
need gcc/f2c, but since you have the binaries for x86 on waldo, you
really don't need to build again.  I see you having two options:

o setup the 'mcidas' account on the new PCs _exactly_ like it is on waldo
  so that you can simply copy the entire 'mcidas' directory tree to

o NFS mount the file system on waldo that has McIDAS binaries, ~mcidas/data
  and ~mcidas/help.  You could then use the NFS access to the binaries
  to share one instance of McIDAS-X on your network.

I believe that NFS access between x86 machines will be significantly better
than that between your OS/2 machines and x86 since all of the x86
machines should be using NFS3.  One of our theories as to why NFS loads
off of waldo are so slow is that waldo is using NFS3 and the OS/2 machines
are most likely using NFS2.

>Also, my campus system person noted that there have been several breakins
>by hackers to machines on our campus recently and asked "what are you guys
>doing about security?"

Good question.

>As you might guess, my department has not been doing
>anything about this.  I know there is a potential for very bad things to
>happen, but what should we be doing?

Your choice of x86 over Linux was a good one as far as security goes.
The other kinds of things you should be doing (actually, whoever does
the system administration stuff (which may be you)) are:

o keeping up on OS patches
o developing a program to change account passwords on a regular basis
o keeping the numbers of people that have root access limited (but
  you can trust us :-)

>Is there software available to provide protection?

The OS has a number of things already built in.  As to whether or not
you would want to install a firewall, I will have to defer to our
system administrator, Mike Schmidt.

>Is there a set of practices concerning how accounts are set up or files are

The OS basically forces you to choose passwords that are not simple to
crack.  Changing them on a regular basis can foil someone who learns
the access information covertly.

>We do not run email or other communication packages on our mcidas
>terminals, but some of them have browsers.

OK.  It is also a good idea to keep up on browser updates.

>The hostnames and logins on our unix machines are 
>private, but soon, at least some students and faculty will have their own

Yes, but the password file is encrypted.  This should slow down, at least,
a student would be hacker.

>What advice do you have about how to minimize our vulnerablility to this

I will have to ask Mike S. to respond to this one since he is the expert.


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.