Re: [xwiki-devs] [VOTE] Upgrade officeimporter to use JODConverter 3.0-beta-2 release and add support for auto-starting oo server

Hi Devs, Jodconverter 3.0-beta-2 version has been released: http://groups.google.com/group/jodconverter/browse_thread/thread/8b73b26b70… One of the most important fix for us is the first point mentioned there: "OOo is now started with -nofirststartwizard by default. This avoids the frequent problem of OOo refusing to work on a new machine because it's expecting somebody to accept its license dialogue even in -headless mode" Without this fix currently we have to copy an already initialized ooprofile directory to the destination server and point to it from xwiki.properties file. This is a pain.

From a security standpoint, it would be nice to have "separation of

Installation notes for Fedora 10 Strange bugs can occur if the incorrect or incomplete openoffice install is selected, or if this particular build of openoffice is run with a different Java JVM than the GNU GCJ which "yum" loads as a dependency of OpenOffice. After numerous troubles with the OpenOffice server using the default Sun JDK used to run Tomcat and Xwiki, I set the JVM used by OpenOffice back to "GCJ" and things began working reliably and quickly. Therefore these instructions assume you've done "yum groupinstall 'Office/Productivity'" and "yum install openoffice.org-headless" and have the entailed Java dependencies installed: 'java-1.5.0-gcj' , 'sinjdoc', 'java_cup', 'lucene', 'saxon', 'jdom', 'xalan-j2', … See here<http://jira.xwiki.org/jira/browse/XAOFFICE-5?focusedCommentId=35043… details. The OpenOffice server currently must run as same user running the Java Web Container. For example, if user 'tomcat' runs the Tomcat server, then the same user must be used to start the OpenOffice server. However since 'tomcat' is not a login account, the OpenOffice server setup requires a first interactive run of the application via the "console" or remote X server. This allows it to write configuration files used when it is launched as a server. First, we create a new account 'OOo' to run the Open Office server interactively for its first run: ROOT-MYHOST-105-~> useradd --user-group --password MYPASSWORD OOo ROOT-MYHOST-106-~> cp -rp .ssh ~OOo ## optional copy existing user's SSH credentials, for remote login ROOT-MYHOST-107-~> chown -R OOo ~OOo/.ssh ## optional change ownership so SSH works Log in to this account "OOo/MYPASSWORD" via console or via "ssh -Y OOO@MYHOST". Run OpenOffice launch program 'ooffice' once either from the SSH session or from a console menu or terminal. From the menu-bar, select "Tools->Options..." and from the "Options" dialog, open the "Openoffice.org" hierarchy and select "Java." In "Java options" be sure "Use a java runtime environment" checkbox is selected, and that the "Free Software Foundation 1.5.0" (/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre) java is selected. Then click Ok to submit the "Options" dialog. Finally, select "File->Exit" from menu-bar and openoffice should save this configuration for future use by the OpenOffice server. Now that OpenOffice is setup for interactive use, we now need to change it over to a "server" setup. This is done by changing permissions on the ~OOo home-directory so that 'tomcat' can write the directory. Since we're no longer going to login on the "OOo" account, first thing we do is disable it: chsh -s /sbin/nologin OOo ## you may also want to !! away the associated password in /etc/shadow Openoffice uses two directories to persist "user" files in ~OOo; 'ooserver-start' also writes log files into ~OOo. Therefore we set permissions for the affected directories: ROOT-MYHOST-112-~> chown -R tomcat.tomcat ~OOo/.openoffice.org ROOT-MYHOST-113-~> chown -R tomcat.tomcat ~OOo/.fontconfig ROOT-MYHOST-125-~> chown tomcat.tomcat ~OOo The server invocation is: sudo -u tomcat /usr/local/bin/ooserver-start Sudo <http://fedorasolved.org/post-install-solutions/sudo> is used to run the script /usr/local/bin/ooserver-start as user 'tomcat': #!/bin/bash export OO_SERVER="/usr/bin/ooffice" export OO_FLAGS="-nofirststartwizard" export OO_ACCEPT="socket,host=127.0.0.1,port=8100;urp;" export OO_LOG="OOSERV.log" export USER="OOo" export LOGNAME="$USER" export HOME="/home/$USER" unset DISPLAY #### Prevent OO from running interactive; force failure on missing openoffice.org-headless echo DISPLAY="$DISPLAY" #### for details, see http://www.artofsolving.com/node/12 echo Cleaning up in $HOME cd $HOME killall soffice.bin killall soffice.bin ### second kill's error message means the first one succeeded rm -f .openoffice.org/3/.lock ### Lockfile left from previous ^C'd invocation rm -f OOSERV-LOG.bak mv -f $OO_LOG OOSERV-LOG.bak ### Backup previous logfile echo Starting $OO_SERVER -- see $OO_LOG for details exec $OO_SERVER -headless -accept="$OO_ACCEPT" $OO_FLAGS < /dev/null > $OO_LOG 2>&1 & The running Openoffice server leaves a socket for communications in /tmp by default (perhaps this is the reason why the OpenOffice server must be the same user as the java webserver??): srwxr-xr-x 1 tomcat tomcat 0 2009-01-27 17:57 /tmp/OSL_PIPE_91_SingleOfficeIPC_cabcdef0123456789abcd= To automate startup of the OpenOffice server on boot, consider using the SysV init runlevel system<http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s… a script like /etc/init.d/openoffice<http://little.bluethings.net/2008/05/30/automating-document-conversion-in-linux-using-jodconverterooo/> .

IMHO, it would be a significant improvement if the OpenOffice server could run as a different user than the one which runs the web-container, such as 'tomcat' on fedora 10. The entire reason you want to run tomcat as a lower-privilege user is specifically to give it a "container" to run in, in which it has less chance of accidentally overwriting some other part of the system configuration, such as the port-80 webserver's configuration. By the "principle of least privilege" we want Java/Web-Container stuff running as a low-priv user (100<499) that can only bind nonprivileged ports. That's why tomcat runs on port 8080 or 8000 and you use Apache httpd and mod_jk etc to provide a "secure" front for Java that sysadmins have approved for use on privileged ports like port 80. Also, by the principle of least priviledge and reduction of overlapping concerns, low privilege users such as 'tomcat' should only be able to write to a very specific part of the filesystem. Likewise a different user, e.g. 'ooserv' in the example above, should be the only user able to write in /home/ooserv and be the user running the OpenOffice server. If someone "hacks" via the OpenOffice server importer, at best they'll be able to get it to write some data into /home/ooserv, but it will not be able to change which web-apps are deployed on your server. The latter could potentially happen, in theory, because the OpenOffice server is running as same user as the Java web conainer. There's no reason for this either. The openoffice server should be able to accept connections from any other process on the system given that it is listening on localhost, per the "socket,host=127.0.0.1,port=8100;urp;" setting.