[ome-users] Apache2/Mod_Perl Troubles with OME Install

[Ilya Goldberg]

On Jun 28, 2006, at 2:21 PM, Guenter Resch wrote:
>
>> It does appear that your Apache2/mod_perl1.99 combo is
>> working on Debian, which is good news, but lets make sure it gets all
>> the way through before celebrating.
>
> ... I just logged into OME and as far as I can judge, everything looks
> fine ... is there anything specific that I can do to test if
> mod_perl1.99 is working fine for me?

There are a lot of tests that are done during installation which is  
why the install fails so frequently.  Generally, if it survives  
installation, it'll pretty much survive anything.  It tests that  
Apache can load + execute a script through the mod_perl interface,  
but this is not an exhaustive test obviously.  That being said, we  
haven't seen a case where this test passes, yet mod_perl remains a  
problem.

At the end of installation, the whole XML import/meta-data definition/ 
DB schema expansion system is taken for a spin as the installer loads  
up OME's microscopy ontology (Semantic Type Declarations, in  
OMEish).  This is also a pretty extensive test because all of the  
interfaces are exercised (upload and download to the image server  
OMEIS, the XML processing facilities, manipulation of the DB schema,  
etc).
The only thing that's not extensively exercised during installation  
is the Web UI and the image importers.
A lot of the Web UI goes through the same set of code because it uses  
HTML templates to determine content and layout, so seeing any of it  
work generally means that it all works.
The code in CVS-HEAD currently has a couple of subtle bugs with the  
way that images are imported (which are fixed in the  
IMPORT_CLEANUP_2006-06-27 testing branch - the last thing before  
2.6.0 release).  These don't result in actual errors - some of the  
images (STK, specifically) are just not stitched together from  
multiple files the way they should be.

So after install, click around the Web UI, and try importing some of  
the images here:
http://www.openmicroscopy.org/TestImages/

The last possible problem is permission settings on OME user's data  
directories.  In order to import a file using the Web UI, the apache  
user has to have read access to the directory you're importing from  
and the files inside of it.  To help with this, the installer creates  
an ome group, and adds apache to it.  If you change the group  
ownership of the files/directories you want OME to access to the ome  
group, things should generally work out pretty well.  I'm saying it  
this way because managing permissions on a unix system (or any  
system) can be a thing onto itself.

Generally, in deployment we use a mounted NFS share which contains  
folders for the different users.  We set up the share to give read- 
only access to the OME server.  Since we're using LDAP, we set up a  
group in LDAP which owns the whole share, then added apache, ome, and  
any ome admin users to this group locally.  The share is such that  
people can mount it on their desktops as well (mostly Windows), and  
drop files into it (which immediately appear in the Web UI for them  
to import).  Other things we do with this share is only let files  
live on there for a few days - OME takes over management of the  
files, so there is no point in keeping them if /OME/OMEIS is backed  
up regularly.  Other people have apparently set up (or are setting  
up) watch folders to import files automatically (using the ome import  
command).

-Ilya


>
> Thanks,
>
> 	Guenter
>