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

20010309: McIDAS: Locked file (LOCAL.NAM) (cont.)

>From: Erick Lorenz <address@hidden>
>Organization: UC Davis
>Keywords: 200103090125.f291PqL26988 McIDAS-X LWPATH.NAM

Erick,

re: LOCAL.NAM should not be locked by a McIDAS session

>But one does read LOCAL.NAM from within a McIDAS session if one enters:
>       
>       REDIRECT REST LOCAL.NAM

Yes, but that only opens the file for reading.

re: machine running Linux
>You are right.  This is a Linux box running Red Hat 6.2.
>
>I seldom if ever use vi as an editor.  However I tried it on LOCAL.NAM
>just now and I was able to add a comment line.  After trying this I
>still couldn't make any changes with emacs.

Hmm... sounds like an emacs thing.  I just checked with one of our
emacs gurus, and he said that emacs keeps a database of files that
are being edited by other emacs invocations.  You can, however, steal
the lock.  In your previous message, a line was telling us this,
but we didn't know enough to interpret it correctly:

.../mcidas/data/LOCAL.NAM locked by mcidas@localh... (pid 12208): (s, q, p, ?)?

The 's' in the sequence 's, q, p, ?' means to steal the lock.  The '?' in
the same list will explain the list options to you.

So, what you want to do is steal the lock and edit the file.  After exiting
the lock should be gone.

>I cannot find any *.swp file anywhere in the ~mcidas file system.

OK, this is a 'vi' thing.

>At the moment ATM20 is not mounting any remote disks.  ~mcidas resides
>on /home which is a local disk.
>
>I tried rebooting.  The problem persisted.  I did copy LOCAL.NAM to
>LOCAL.NAM.TEMP and I was able to edit that so maybe I can instruct
>users to restore from a different file.

Yup.  The emacs database is persistent.

>The machine _was_ hacked some time ago.  I cleaned off the disk that
>contains / and /usr and reinstalled Linux from scratch.  Then I got
>McIDAS and LDM running from the original files which resided on the
>/home disk.  The hack was running from a hidden directory in /etc
>called troia (as in troy).

This turns out to be an emacs thing, not a hacked into thing.

>For what its worth I have ATM20 more tightly secured with wrappers.  No
>machine should be able to access any network utility except the student
>workstations that run McIDAS and the upstream LDM providers (and my
>desktop).  I also have more strict limits on what a remote mount of a
>local disk can do.

OK.

>I can't say that I have tried to edit any file in the mcidas since
>getting it up and running.

Some emacs edit session must have been running at some time and then
was aborted before the lock entry in its database could be updated.

>Any ideas that you have will be appreciated.  I think I have a usable
>McIDAS for the next few weeks.  The current class uses it for just one
>project that involves canned data.  I was trying to modify LOCAL.NAM so
>that students could easily redirect to the site of this data when I
>found this problem.

You should be good to go after stealing the lock.

>After this project is done perhaps it time to reinstall with 7.7

Yup.

>Do you get the impression that McIDAS systems running on Linux are
>being hacked into more frequently than other flavors of Unix?

I get the impression that Linux systems get hacked into more than
other Unix systems.  I don't think that McIDAS has anything to do with
this.

Talk to you later...

Tom