DIENST Installation Documentation

Last Revision Date: August 22, 1996


DIENST Installation FAQ's

These are some of the common questions that crop up while installing Dienst. If your question is not addressed here or in other installation documentation, please direct it to help@ncstrl.org.

  1. I am a Standard Dienst site, and I have created some sub-naming authorites. Do I have to register these sub-naming authorities with NCSTRL?

  2. Will Dienst/NCSTRL work with my Apache server?

  3. What should I check first if the installation didn't work? (The Perl Path!)

  4. I have problems with getting LibMgt/db_build to run?

  5. I have problems with cgi-bin/imagemap that comes with NCSA 1.5.1 or later?


I am a Standard Dienst site, and I have created some sub-naming authorites. Do I have to register these sub-naming authorities with NCSTRL?

All sites register with NCSTRL and receive a naming authority (ex: ncstrl.greatstate_cs. Each naming authority site has the right to create sub-naming authorities (ex: ncstrl.greatstate_cs.robots, ncstrl.greatstate_cs.ai). At this time, however, Dienst software design requires that each sub-naming authority be treated as an individual site. You must register each of them with us, and they will be listed separately on our list of sites.

7/17/96 - Dienst-4.1.3


Will Dienst/NCSTRL work with my Apache server?

NO, the Apache server has an acknowledged bug (acknowledged by them!) in the way they process encoded slash characters in a URL for a Script. A URL like /cgi-bin/test-cgi/foo/bar%2fbaz should invoke test-cgi with PATH_INFO set of /foo/bar/baz (at least it does with the NCSA server). Apache gives an Error message.

Unfortunately this is a problem completely out of our control, and we can think of no work around. So, until Apache fixes this, Dienst and Apache are incompatible.

8/15/96 - Dienst-4.1.4


Check the Perl version first if the installation didn't work?

The most common problem (and hardest to remember to check) is with Perl - either with the version of Perl (or Perl5), the way Perl has been installed, or the bang lines in our Dienst code files being incorrectly updated during autoconf. Here are a few tips.

The command "perl -v" (for perl, version 4) should result in something like:

This is perl, version 4.0

$RCSfile: faq_install.html,v $$Revision: 1.4 $$Date: 1996/08/22 20:34:15 $
Patch level: 36

The lowest patch level of Perl(V4) that Dienst works with is 36.

The command "perl5 -v" should result in something like:

 		This is perl, version 5.001
 		Unofficial patchlevel 1m.
If it doesn't list a patch level, it may be a very old (very buggy) version.

If the bang lines are not updating properly, add the following line to the top of Config/install.config (WARNING: Do NOT add it as the last line of the file - there is another bug it would trip over)

<perl_path>your.path.to.perl</perl_path>
and rerun autoconfig.pl.

8/15/96 - Dienst-4*


I have problems getting LibMgt/db_build to run?

Two common problems: The first arises from ghostscript version variations between the gs_init.ps that we ship with Dienst (in LibMgt directory) and the "public" version that you are probable running. The second problem occurs if your processes path does not include the pbm library directory.

  • ghostscript version variations

    Error Message from running db_build:

    [GMT day and date ERROR:: ncstrl.dienst.server]: Building inline from
    postscript.
    gs: Interpreter revision (333) does not match gs_init.ps revision (261).
    

    Here's a fix that has worked for ghostview version(3.3.3). You can try it and see if it works for you. If it doesn't, send us e-mail, and we will take another look.

    There is that one-line diff from the public gs_init.ps, and the one that is in our LibMgt dir:

    diff /usr/local/gnu/ghostscript-2.6.1.2/lib/ghostscript/gs_init.ps gs_init.ps
    
    < currentdict /SAFER known   /SAFER exch def
    ---
    > currentdict /SAFER known   {SAFER 1 eq} {true} ifelse /SAFER exch def
    
    1. save <dienst>/LibMgt/gs_init.ps to another file
    2. copy your site's installed version of gs_init.ps to the LibMgt dir
    3. edit the above line appropriately
    4. run db_build and see if it works with the new version of gs

  • Set the environment variable "$PATH" to allow access to the pbm library

    Error message looks something like this:

    [GMT day and date] ERROR:: ncstrl.dienst.server:test Can't make composite from
    inline because got error running (/usr/local/pbm/giftopnm /----/dienst/DocumentR
    oot/ncstrl.nrad.diglib/test1/inline/0001.gif | /usr/local/pbm/pnmmargin -black
    1 | /usr/local/pbm/pnmscale -xsize 85 -ysize 110 | /usr/local/pbm/ppmquant
    -quiet 16  >/----/dienst/temp/ncstrl.nrad.diglib:test1/thumb_1.pnm) 1> /dev/
    null 2>/dev/null.
    
    SOLUTION: The pbm library is defined as a variable in Config/config_constants.pl. This library must also be accessible from the path of the account that runs db_build, esp. when building composite formats.

    8/15/96 - Dienst-4.1.4


  • I have problems with the cgi-bin/imagemap that comes with NCSA 1.5.1 or later?

    This is a problem that crops up with newer versions of the cgi script imagemap. When the user clicks on the thumbnail sketch, the browser returns an error message like:
    Couldn't open configuration file:[really/long/filepath/]/Composite/0001.map 
    

    NCSA (v1.5.1) is currently shipping a version of imagemap(v1.9a) that always interprets the path of the imagemap map file relative to DocumentRoot as defined in the httpd configuration file. So the "really/long/filepath/" contains both the value of the httpd server's DocumentRoot in addition to the full pathname of the map file. Currently Dienst passes a full pathname (not relative) for this map file. We are in contact with NCSA, but until there is some resolution on their part or ours, here is a work around:

    1. Start with two peice of information: a) the httpd server's value for DocumentRoot and b) Dienst's value for the root of the document database.
    2. Change directory to httpd server's DocumentRoot.
    3. Create a symbolic link to the Dienst's document database root.

    Now things should work.

    8/15/96 - Dienst-4.1.4


    Return to Dienst's Document Menu


    DIENST Installation Documentation