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

20011229: McIDAS7.8-04 reinstall on SuSE

>From: James Frysinger <address@hidden>
>Organization: College of Charleston
>Keywords: 200111061842.fA6Igt112242 LDM binary install

Jim,

re: how to setup use of static f2c library

>Gee, I don't remember doing that part before on the previous build. Did
>it this time, as well as the rest of your suggestions and it worked
>like a champ! BTW, the next time you modify that web page, I suggest
>that you add the explicit steps above for the sake of nubs such as I.

The instructions I included were cut and pasted from the Notes and Warning
page.

>That was most helpful. Otherwise, I could only think of what I had
>learned about INCLUDE statements in C programs when I read "link
>against".

OK.

re: switch to use of g77 combined with gcc

>Yep! I did and it did.

re: setup environment definitions for build use in .cshrc

>I did the bash version of all that (as well as the rest of the stuff
>that was supposed to go into .cshrc. I can send it to you if you're
>interested.

Sure.

>(Do you accept attachments?)

Yes.

>Have to admit that it sent me
>back to the books, but I learned something so the trip was worthwhile.

OK.

>Incidently, the LDM instructions seem to make a csh environment sound
>mandatory. I did that on my previous build, but wonder why LDM cannot
>run in a bash environment. Is it because of the scripts in the LDM
>package? Or could LDM be bash'd?

It is mostly historic, but it makes life easier following existing
instructions if the default shell for 'ldm' is the C shell.

re: after a 'make clobber' run 'make all'

>Took 20.5 min this time. Of course, it's a slightly larger package.

Yes, but the majority of the increase in size is due to larger map
database files.

>Doing g77 instead of gcc may have made a difference, too.

My own timing tests on RH 7.1 show that the gcc/g77 builds take almost
exactly the same amount of time that gcc/f2c/mcfc builds do.

>I see from
>the 'info g77' file that the g77 front end does some extra stuff.

g77 basically is a front end to gcc. But, then again, so is the f2c
and mcfc combination.

>I got as far as testing the installation with 'mcidasx'
>(satisfactorily) and the install script (satisfactorily, too).

Sounds good.

>Got
>stuck on the mcadde server. The shell script modified /etc/services
>(adding that one line) and modified inetd.conf by adding two lines at
>the end:
>
>   mcserv  stream  tcp     nowait  mcadde  /home/mcidas/bin/mcservsh       
>mcservsh -H /home/mcadde
>       
>   mccompress      stream  tcp     nowait  mcadde  /home/mcidas/bin/mcservsh  
>     mcservsh -H /home/mcadde

These look correct.

>but then I get (below shows output of repeated attempt):
>
>   metric:/home/mcidas # sh ./mcinet7.8.sh install mcadde
>   mcinet7.8: /etc/services: mcserv already set up
>   mcinet7.8: /etc/services: mccompress already set up
>   mcinet7.8: /etc/inetd.conf: mcserv already set up
>   mcinet7.8: /etc/inetd.conf: mccompress already set up
>   mcinet7.8: telling inetd to reread its configuration
>   mcinet7.8: waiting for inetd to reread its configuration
>   mcinet7.8: WARNING: inetd not listening
>   Try running the script again in a few minutes.
>   mcinet7.8: WARNING: inetd not listening on compress port
>   Try running the script again in a few minutes.

What is happening here is that a HUP signal is sent to inetd.  Apparently,
inetd wasn't paying attention.  You can always send the HUP as 'root'.
As a last resort, rebooting should do the job.

>I've got a pretty tight security program running now that I didn't
>before and the directions warned that some services might require
>tweaking on permissions. I'll have to take a look at that after I take
>a break here. One thing that is different is that I had inetd _not_ set
>to start and run normally, so I had to change that because my first
>attempt to do this shell script said inetd wasn't running! Well, golly,
>if it's going to get fussy....  Anyway, I started inetd (and set it for
>automatic start on boot) and that allowed the shell script to modify it
>---- but with the results above.

It could be that the warning you are getting above is a red herring.

>>From address@hidden Sat Dec 29 17:38:37 2001

>I checked permissions on inetd and don't see a permissions problem. Unless I 
>missed an suid somewhere, that should work, I would think. I have:
>
>-rw-r--r--    1 root     root         5436 Dec 29 14:54 /etc/inetd.conf
>-r-xr-xr-x    1 root     root        22708 Sep 20 00:13 /usr/sbin/inetd

The permissions on /usr/sbin/inetd are -rwxr-xr-x on my RH system.

>By the way, the program I spoke of in my last message uses permissions.foo 
>files (foo=easy, secure, paranoid) with chkstat.

This is a new one for me.

>Thought that I had found the problem when I checked /etc/services. The notes 
>warn linux users about isakmp on port 500 and I found that there is now a 
>program called intrinsa that gets posted on 503. I commented it out as well. 

Very good.

>now the pertinent parts of my /etc/services read
>
>ldm             388/tcp unidata         # Unidata LDM
>ldm             388/udp unidata         # Unidata LDM
>....
># Commented out isakmp on port 500 for support of mcidas
>#       at bottom of file.
>#isakmp          500/tcp                        # isakmp
>#isakmp          500/udp                        # isakmp
>....
># Commented out intrinsa on port 503 for support of mcidas
>#       at bottom of file.
>#intrinsa        503/tcp                        # Intrinsa
>#intrinsa        503/udp                        # Intrinsa
>....[added at bottom of file by shell script]
>mcserv          500/tcp      # McIDAS ADDE port
>mccompress      503/tcp      # McIDAS ADDE compression port

Looks good

>Again, doing 'ps -e | grep inetd' shows inetd running:
>
>6797 ?        00:00:00 inetd
>(and no xinetd in sight).

OK.  I don't like the look of '00:00:00', however.

>Still no joy in Mudville. I get the same output as before from running that 
>shell script to install mcadde.

Again, the message might well be ignorable.  If you send a HUP to the inetd
process as 'root' it may be sufficient.  One last comment, however: you
only need to do this setup if you are going to serve data local to your
machine to external machines.  You do not have to do the setup if you
are simply going to use your machine to access remote machines.

Tom

>From address@hidden Sat Dec 29 22:36:39 2001

I did it. The inetd is working (apparently!) and I finished the set up of 
ADDE and McIDAS to the point of doing 'mcidas config' as user 'jim'. Then I 
popped up a display or two just to see if it would work. Got a nice GE4KIR 
display with T & P contours and the fronts. (I roger what you're saying about 
my not really needing ADDE here, but I might end up migrating 'weather' to a 
linux box someday and the practice was good for me.)

That's enough for tonight. I'm a tired puppy and I'm going to bed. I'll check 
out your new bells and whistles tomorrow.

Thanks again, Tom. Let's all have a happy New Year, eh?

Jim