[Thread Prev][Thread Next][Index]

Re: More on access control for LAS

HI Jennifer,

Any ideas as to why the script doesn't work when run outside of LAS as nobody? That's the key to solving this problem; I don't think that changing Apache config files will help (unless you have Apache run with a user id that works outside of LAS).

Jennifer Adams wrote:

Hi, Joe --
Our apache configuration was also set up so the server userid
would be nobody.nobody. We tried what you suggested, and ran the
GrADS script outside of LAS as nobody and it didn't work. Nobody was
getting nowhere. We tried changing the apache userid to be www.www (which
is how it's set up on another web server running here), added www
to the /etc/passwd and /etc/group file and hoped for the best, but the
results were the same. So we're still stuck. Perhaps you could send me a
copy of your httpd.conf file and we'll try it with that on our system?

--Jennifer, hoping for a reproducible problem...

On Thu, 12 Jul 2001, Joe Sirott wrote:

> Hi Jennifer,

> I can't reproduce this problem on my Linux LAS/GrADS server, so my guess
is that the Apache server process doesn't have access to the directory
where the GrADS file is stored.

Have you tried running GrADS outside LAS using the user and group of
Apache server process (on my Redhat system, for instance, that is

> "Jennifer M. Adams" wrote:
> > Dear Experts,
> >
> > My GrADS-enabled version of LAS is working (thanks, Joe!)
> > and I am getting ready to serve up some real-time forecast
> > data in GRIB format. Here's the thing: if the data set I'm
> > serving is not located underneath the $LASROOT directory,
> > then the LAS's execution of GrADS can't see the file and I
> > can't open it, even for read-only purposes. If I execute
> > GrADS outside the LAS and run the very same script that the
> > LAS tried to run, it works just fine. When I copied the data
> > set so it would be underneath $LASROOT, then the LAS worked
> > perfectly.
> >
> > It smells like an apache configuration problem, and I found
> > a brief exchange on a similar issue in the email archives.
> > Steve Cousins referred to the Directory Tag in the
> > httpd.conf file, and although his solution was for
> > *restricting* access to certain data directories, I think
> > the implementation is probably similar. Here's what we've
> > added, where /var/homes/wxdata/dodsdata is the top directory
> > where the GRIB data is located:
> >
> > <Directory "/var/homes/wxdata/dodsdata">
> >    Options Indexes Includes FollowSymLinks
> > </Directory>
> >
> > Unfortunately, this change made no difference to the LAS,
> > even after re-configuring and shift-reloading. I'd like the
> > LAS to access this directory and anything underneath it. The
> > data files there are all readable by everyone (i.e.,
> > -rw-rw-r--) Can anyone tell me what would be the right way
> > to configure it?
> >
> > Respectfully submitted,
> > Jennifer
> >
> > --
> > ----------------------------------------
> > Jennifer Miletta Adams
> > Center for Ocean-Land-Atmosphere Studies
> > 4041 Powder Mill Road, Suite 302
> > Calverton, MD 20705-3106
> > Phone: (301)902-1278 or (301)595-7000
> > Fax:   (301)595-9793
> > Email: jma@cola.iges.org
> --
> Joe Sirott

Joe Sirott
[Thread Prev][Thread Next][Index]

Dept of Commerce / NOAA / OAR / PMEL / TMAP
Contact Us | Privacy Policy | Disclaimer | Accessibility Statement