20001211: LDM File times (cont.)

>From: Erick Lorenz <address@hidden>
>Organization: UC Davis
>Keywords: 200012082136.eB8La8o05400 ldm-mcidas pnga2area

Erick,

re: what do you mean by 'dated'

>I mean the time stamp that you see when I run "ld -l"
>It doesn't matter whether I am logged in as ldm or root.  If I create a new
>file it is 7 hours off the time that I get with the "date" command.

OK.

>For example if date gives a date/time Dec 11 11:09 and then I touch a file
>and list it, it shows a date of Dec 11 19:09

The first thing we can suggest is that you make sure that you are not
using aliases for commands and not commands themselves.  For instance,
do you get the same thing when you run '/bin/date' and '/bin/ls -l'.

re: is TZ defined in the 'ldm' session

>I tried both env and echo $TZ in the ldm account and got nothing

OK.  It just struck me (given your comment below) that this is most
likely a Linux "thing".  I ran into problems on my machine at home
when trying to get the system to use UTC (GMT) time.  The weirdness
you are reporting seems to indicate that you are having the same sort
of a problem.  And, for reference, I never figured out my problem, so
I resorted to defining TZ in my environment to force things to work
the way I wanted.

>In any case I have taken ATM20 off the network because of other evidence
>that it has been compromised and am planning to do a reinstall of Linux.
>Is there any reason why I can't go to Red Hat 7.0 and still run ldm and
>McIDAS?

RedHat 7.0 Linux brought some new changes to the table.  For one thing,
the setup for inetd has totally changed since there is no longer an
inetd in 7.0!  The FSF developers have replaced inetd with xinetd and
inetd.conf with xinetd.conf and xinetd.d (a directory).

In order to configure your system for the LDM (which we have not tested
on 7.0 yet) and McIDAS, you will have to do more things "by hand".

Speaking from the McIDAS side, instead of simply running mcinet7.7.sh
to install the remote ADDE server, you will have to create two files in
/etc/xinetd.d: mcserv and mccompress.  The contents of those files are
basically:

%cd /etc/xinetd.d
%ls -alt mcserv
-rw-r--r--    1 root     root          327 Nov  8 14:36 mcserv
%cat mcserv

# mcservsh (port 500)
service mcserv
{
        log_type        = SYSLOG authpriv debug
        flags           = REUSE
        socket_type     = stream
        protocol        = tcp
        wait            = no
        port            = 500
        user            = mcadde
        server          = /home/mcidas/bin/mcservsh
        server_args     = -H /home/mcidas
        log_on_success  += USERID HOST DURATION
        log_on_failure  += USERID HOST RECORD
}

%ls -alt mcserv
-rw-r--r--    1 root     root          327 Nov  8 14:36 mccompress
%cat mccompress

# mccompress (port 503)
service mccompress
{
        log_type        = SYSLOG authpriv debug
        flags           = REUSE
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = mcadde
        port            = 503
        server          = /home/mcidas/bin/mcservsh
        server_args     = -H /home/mcidas
        log_on_success  += USERID HOST DURATION
        log_on_failure  += USERID HOST
}

The other thing is that the signal one uses to tell xinetd to reread
its configuration files is -USR1, not -HUP like it is for inetd!

On a positive note, xinetd has a lot of configuration capabilities.
This is also a little bit of a drawback since you have to be familiar
with those configuration options in order to accomplish your goals.

>Thanks
>Erick

Tom

>From address@hidden Mon Dec 11 15:41:31 2000
>Subject: Re: 20001211: LDM File times (cont.)

>There is no alias but when I did "ls -l /bin", three files including ls
>and ps showed up with funny dates (older by two years than the rest)
>and funny UIDs and GIDs.  These were only numbers and they were no
>number that I had ever assigned nor were they in my /etc/passwd file.
>More evidence of a break-in.

re: inetd changes

>Then it looks like I would have to a full reinstall of LDM and McIDAS rather
>than back them up and then slip them back in.