20010201: IDD backup feed site assignments

>From: Leigh Orf <address@hidden>
>Organization: UNCA
>Keywords: 200102010314.f113ERX17446 IDD

Leigh,

re: getting a backup site
>Yeah, I already get that impression from monitoring the traffic on the
>mailing lists. I've emailed the two folks who are serving stuff to us.
>I'd like to have a backup connection. Is there any logic in picking who
>to ask for access? Should I go by geography?

Backup sites _are_ assigned by the UPC as we need to keep a good handle
on the IDD topology.  I am CCing this note to Jeff Weber for followup
on IDD backup site assignment.  Sorry for the confusion.

re: MCDATA for users
>Indeed it is. And for local users it's ~/mcidas/data... that ok?

Yes, that is correct.

re: transition should be easy
>Good. I vaguely remember building the LDM and the ldm-mcidas stuff on
>linux with no problem a while ago, but I never got it running (was just
>testing to see if I would run into any snags).

OK.  There are binaries available for both packages, so you don't even
have to go through the pain of a build.

re: NFS implementation on Linux - still waiting for a good one -
>I know. In fact, what prompted me to do this finally was suddenly,
>without warning, my system log on storm2 (the Linux NFS server) was
>filling up with the following messages regarding file locking:
>
>Feb  1 13:56:32 storm2 rpc.statd[384]: STAT_FAIL to storm2.atms.unca.edu for S
> M_MON of 152.18.35.163
>Feb  1 08:56:32 storm2 kernel: lockd: cannot monitor 152.18.35.163
>Feb  1 13:56:32 storm2 rpc.statd[384]: gethostbyname error for storm2.atms.unc
> a.edu
>
>This would repeat and repeat... note also the time shift, I don't get
>that. Maybe it's a UTC/localtime thing, I don't know.

Wow!  I have never seen this one.

>Anyway, I restarted, rebooted, did all sorts of things to no avail.  It
>seems for every file access (vortex writing via NFS to storm2) I'd get a
>bunch of those. I did a web search which came up empty. What is strange
>is that it just started without any warning after running fine. Maybe
>there is a file somewhere that needs to be deleted.

Are you running xntp?

>Anyway, by having storm2 ingest mcidas data it will make the NFS problem
>a moot point, and I've been meaning to do this anyway.

Sounds like a good plan.

re: update of Fkey menu to provide ADDE access to GINI imagery
>Neat. People seem to like the MCGUI interface better than the F-key
>interface in my experience.

I do too.  But like I said, MCGUI needs a _total_ rewrite to be really 
useful.

>Having both interfaces confuses some. But I
>have them both up for those who are used to using F-keys.

OK.  I understand the two interfaces being confusing.  By the way, the
way that I use both interfaces is:

o start McIDAS with 'mcidas config'
o select MCGUI
o start the Fkey menu from the Misc dropdown menu in MCGUI

re: security with ADDE
>|   o TCP wrappers on the ports that ADDE uses
>|   o turning on McIDAS accounting of ADDE use
>
>I might add
>    o via firewall rules

Yes, I did leave out firewalls

>One neat feature of the 2.4 kernel is iptables, which is much easier
>to use than ipchains. I could just limit access on a per-host basis,
>much like tcp_wrappers.

Since I am no Linux guru, I will rely on your experience here.

>I do like your second option though, assuming
>it's "secure".

It is secure.  The good thing about McIDAS is that one can't go through
the ADDE interface and get to the system.  The main reason for this is
that almost 100% of ADDE from a remote host is read only.  The little
bit that is not is taken care of by assiduous assignment of write
permissions to image data files.

>I've been hacked a couple times and err on the side of paranoia.

Gotcha!

>Hope your meeting was exciting ;)

Yea, sure :-(

Tom