>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
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.