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

20000802: McIDAS-X ADDE installation at Western Michigan (cont.)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20000802: McIDAS-X ADDE installation at Western Michigan (cont.)
  • Date: Wed, 02 Aug 2000 15:01:00 -0600
>From: "John D. Tucker" <address@hidden>
>Organization: Western Michigan
>Keywords: 200007181435.e6IEZAT22632 McIDAS-X -XCD ADDE install

John,

>Leonard is out of town until next week.

OK.

>If I understand your posting correctly, you are looking for access to the
>"mcadde" account (which apparently to this time has not yet been used).

Right.  If the accounts had been setup in the way I requested, the
mcadde account would not allow logins, and its HOME directory would
be the same as the user 'mcidas'.  For some reason, this was not done.

>I will change the password and call (leaving a message if you are not
>available) with the new password.  WMU policy does not allow e-mailing
>passwords.

I got your phone mail and was able to login as 'mcadde'.  Getting a
remote ADDE server has progressed a little, but I am once again running
into a disk quota problem on s418:

~/workdata> cp ../data/LOCAL.NAM LWPATH.NAM
cp: LWPATH.NAM: Disc quota exceeded

Apparently, the raise in the quota that allowed me to build and install
McIDAS has been lowered.  Without being able to configure things in the
McIDAS account (i.e., create new files/directories/etc.) I can not
finish until the quotas are once again raised for 'mcidas'.
Furthermore, the ADDE installation will not work if the quotas are
lowered so that no new files can be made.

Another problem is that it appears that there is some sort of a rule
at W Mich that users in the same group can not access each other's
directories.  I say this since:

mcadde, mcidas, and ldm are supposedly in the same group:

~> id mcidas
uid=5453(mcidas) gid=646(ldm)
~> id mcadde
uid=7319(mcadde) gid=646(ldm)
~> id ldm
uid=3081(ldm) gid=646(ldm)

From the mcadde login an ls of ~mcidas will get a premission denied:

~> whoami
mcadde
~> ls ~mcidas
/home7/ldm/mcidas: Permission denied

and the same is true from the mcidas login of ~mcadde:

~/workdata> whoami
mcidas
~/workdata> ls ~mcadde
/home7/ldm/mcadde: Permission denied

This becomes important in the operation of the LDM as user 'ldm' since
it will need to access and maniuplate files in the mcidas account.

Can anything be done about this situation?

Tom