Peter Urban wrote: > Hello Robert. We just went through an install on Ubuntu 7.04. For the > most part, the instructions here were helpful - > http://wiki.dspace.org/index.php/Installing_DSpace_on_Ubuntu_6.06_(LTS). > As for setting Tomcat to user dspace, I believe this is done by > editing the /etc/default/tomcat5.5 and setting the line: > > TOMCAT5_USER=dspace Thanks very much for this hint! I am sorry not to recognise this page earlier. I just followed the installation instructions in the distribution package (file:///opt/dspace-1.4.2-source/docs/install.html). But the Wiki-page make things much more clear. The source of the main misunderstanding is the sentence "Note that DSpace will need to run as the same user as Tomcat, so you might want to install and run Tomcat as a user called 'dspace'." So I tried to install Tomcat and started it as user 'dspace' from the command line. This lead to further adventures with 'chmod', 'chown' and modifiing the start script /etc/init.d/tomcat5.5. As far as I see the difference between the Ubuntu 6.06 and 7.04 are only some version numbers. Unfortunately I still have no luck with my installation (see below). But if I succeed I will add the Ubuntu 7.04 installation to the Wiki.
Christian Voelker schrieb: > Hello, > > Am 30.10.2007 um 10:48 schrieb Robert Roggenbuck: > >> Missing packages... this can well be. Because I did not installed the >> Ubuntu package tomcat5.5 with all it's dependencies. Instead I >> downloded the apache-tomcat-5.5.25.tar.gz from Apache >> (http://tomcat.apache.org/download-55.cgi). The reason was that DSpace >> needs to run Tomcat as user dspace. > [snip] > The reason why to use the distribution packages is that > you chose the distribution to get support for upgrading > your system during production. You loose the most valua- > ble aspect of the distribution if you depart from this. Yes. But I saw no other way. [snip] > > It is much more important to understand what the unix > user actually needs access to. First, the database user > dspace is separate from the unix user dspace. As the > database user dspace is only used for the database > dspace, the name makes sense. The database itself runs > under another unix user 'postgres' btw. Then, the unix > user under which tomcat runs will write into your dspace > directory. It is obvious with the assetstore subdirectory, > but is also true e.g. with the history subdirectory and > others. Once running, you will see by file-dates which > are written during operation. The short solution is that > you run your ant tasks under the unix user which is > tomcat-55 in your case. For consistency, I would make > it a habit, but it is actually required only during the > fresh-install. You really mean I should say $sudo -u tomcat55 ant fresh_install instead of $sudo -u dspace ant fresh_install ? > Subsequent ant updates can be run under > your user as long as you are allowed to put stuff into > the webapps. Your .war files get unpacked by tomcat, > so the resulting subdirectory under webapps will be > owned by tomcat-55 again. If this is true, the Wiki page should be corrected at this point. There it is said to execute $sudo chown dspace /var/lib/tomcat5/webapps/*.war This makes no sense if the change of ownership is gone after the unpacking of the *.war files. But if I understand it right the setting of 'TOMCAT5_USER=dspace' in /etc/default/tomcat5.5 prevent this change... > You should check this to > get a better understanding of what is actually > happening. I will do it, but again I am stopped during 'ant fresh_install'. After removing my 'manual' Tomcat installation, I installed via Synaptic the packages named in the Wiki instruction (I only selected newer versions). Everything worked fine until 'fresh_install': Buildfile: build.xml compile: [mkdir] Created dir: /opt/dspace-1.4.2-source/build/classes [javac] Compiling 233 source files to /opt/dspace-1.4.2-source/build/classes [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. install_code: [jar] Building jar: /opt/dspace/lib/dspace.jar build_wars: [copy] Copying 1 file to /opt/dspace-1.4.2-source/build [mkdir] Created dir: /opt/dspace-1.4.2-source/build/jsp [copy] Copying 220 files to /opt/dspace-1.4.2-source/build/jsp [copy] Copying 1 file to /opt/dspace-1.4.2-source/build/classes [war] Building war: /opt/dspace-1.4.2-source/build/dspace.war [copy] Copying 1 file to /opt/dspace-1.4.2-source/build [war] Building war: /opt/dspace-1.4.2-source/build/dspace-oai.war init_configs: setup_database: [java] 2007-10-31 16:46:06,811 INFO org.dspace.storage.rdbms.InitializeDatabase @ Initializing Database load_registries: BUILD FAILED /opt/dspace-1.4.2-source/build.xml:333: Java returned: 1 Total time: 14 seconds As far as I see, according to the line 333 in build.xml, it fails on looking up the class org.dspace.administer.RegistryLoader . Is there a connection to the warnings in the beginning, the notes from javac? Could it be that my CLASSPATH setting is wrong? I remember my first installation attempts where I got warnings using the path settings used for Tomcat (/usr/share/tomcat5.5/common/lib/jsp-api.jar and /usr/share/tomcat5.5/common/lib/servlet-api.jar). After unsetting the CLASSPATH the warnings vanished. Now I got warnings without CLASSPATH and I set it now to /var/lib/tomcat5.5/webapps . Is this may be wrong or not enough? Best regards Robert ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
