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

20001211: LDM File times (cont.)

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


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.


>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

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

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



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

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.