OpenCms Administration Guide

Environments

Please see Environments

Logging in to OpenCms

• Use Putty on remoteadmin.pan.intuit.com
• Login using a normal user account.
• Once you are logged in, run 'sudo bash' - and re-enter your password. You should get a root shell.
• Change directories to /data/jboss/server/default/deploy/opencms.war/WEB-INF - most things you'll want to do are within striking distance of this directory.

Log Files

Of course, the magic command under Linux for watching log files is:

 bash> tail -f <log file location>

This will allow you to watch the bottom of the log file as it is appended to in real time.

OpenCms exposes two log files of particular interest:

• /data/jboss/startup.log : This is the JBoss startup/runtime output. You won't see a particularly large amount of OpenCms details in here, but you will see all the server level errors. I liberally observe this file at initial startup, and then will switch to the next one once the OpenCms application has started its initialization.
• /data/jboss/server/default/deploy/opencms.war/WEB-INF/logs/opencms.log : This is the main OpenCms log file; any log output from the code will end up in here, including those from our very verbose modules.
  • One particular note: and per the settings of log4j in use by Alkacon 7.0.4 default the files are kept short. Hence, if you leave a tail on this log file, at some point you'll notice it will start progressing; this is because the log files have been rotated under your tail, leaving tail with a dead file i/o pipe and you with no more data. Just Control-C, and then run the tail again and you'll get the updates.

Another possibility on most Linux systems is to use:

 bash> tail -F <log file location>

This will follow not the the file descriptor, but the file name. If the log file gets rotated, tail will re-open the original file name, thus leaving you with a working log display, without doing anything.

Restarting JBoss

• All of these steps can be coded into the startup script, but at this time we've selected not to.
• Make certain you are the root user on the system prior to any of these steps.
• Make certain you are in the WEB-INF directory.
• Find out the process id of the running jboss instance:

bash> ps wwwaux | grep java

• Now, run one concatenated command to kill & restart & jump in to the log file. If any part of this does not work (which it should every time), the next part of the command will not run. Make sure to replace <pid> with the Process Id you found in the last step:

bash> kill -9 <pid> && rm /data/jboss/startup.log && mv web.xml.org web.xml && /etc/rc.d/init.d/jboss start && tail -f /data/jboss/startup.log

• Here's about what you should be doing & what you'll see...

Deployment of OpenCms from one machine to another

• Copy /data/jboss to the new machine
  • It's not a bad measure to change ownership of the OpenCms application directory to apache recursively:

 bash> chown -R apache:apache /data/jboss/server/default/deploy/opencms.war

• Remove any existing java installed.
• Copy /usr/java to the new machine, make certain typing 'java' alone works, otherwise you may need to remap/create the java symlink.
• Copy /etc/rc.d/init.d/jboss in to place. Update the ip addresses within this document to the new machine's ip.
  • The ip address is used to remap requests from port 80 (which is open from CORP to IE) to 8080 (where jboss actually attaches)
• Start up JBoss. Watch the log file at /data/jboss/startup.log, and then at WEB-INF/logs/opencms.log - watch for any exceptions that may represent an issue in what you deployed.

Files We've Changed At Times

• WEB-INF/config/opencms-workplace.xml: To remove the properties option from the right click menu, we commented out the references to this item within the workplace configuration.
• WEB-INF/config/opencms.properties: This is the essential core configuration for OpenCms, and includes the database connection information.
• A couple of the other files in config have been edited to support OCEE installation, but those changes are generic per an OCEE installation.
• WEB-INF/web.xml: We added in the necessary bindings for our webservices (Search, Import, DocumentRetrieval) in to web.xml following normal J2EE standards.
• Remember, these are parred down linux environments, you aren't likely to find an editor other then 'vi', so read up on your 'vi' commands.

Refresh the PTC

1. Schedule this work with our partners so as to avoid causing an issue for their development (ex: A/C uses PTC OpenCms for QA).
2. Make certain CMS2 & CMS3 are in sync with CMS1 in production.
   1. Remember, the configurations for the modules need not be in sync, but the code base should be.
3. Work with your DBA to copy over Production OpenCms DB -> PTC OpenCms DB.
4. Record the working configurations for our modules within PTC. This will include any settings for sync with filesystems or GSA's.
5. Kill PTC OpenCms Services.
6. Log in to CMS2. Tarball the /data/jboss/server/default/deploy/opencms.war directory en total.
7. Move this large tarball, likely through the remoteadmin machine, to the PTC server(s).
8. Log in to the PTC server(s). Move the current webapp en total to a backup location:

    $ mkdir /jboss/backup/<date>/
    $ mv /data/jboss/server/default/deploy/opencms.war /jboss/backup/<date>/

1. Decompress the production app tarball, place it back in /data/jboss/server/default/deploy, and set rights:

    $ chown -R apache:apache /data/jboss/server/default/deploy/opencms.war

1. You'll need to move the settings from opencms.properties in your archived PTC copy that pertain to db connectivity in to opencms.properties that came with the prod build. This will be server location, username, and user password.
2. Turn on jboss services, watch carefully for processing of the moved application file in /data/jboss/startup.log. If all steps have executed properly, you should find no issues at startup, otherwise the issues should provide insight in to what's going on.
3. Log in to OpenCms, navigate to Administration->Module Management. Update the module configurations in preprod to match prior state.
4. If startup was slow, you may have an issue with the db connectivity desired by the workflow module. This can be obviated by removing these modules (we aren't using them right now in prod or preprod anyhow) - these are the first three 'bearingpoint' modules. If you don't want to do that, follow the install directions in the bearingpoint documentation to see where the db connectivity for their goods are separately configured, and update it as appropriate.

Mounting a samba share for OpenCms

Each NT machine that we look to synchronize with via the push channel needs to be

1. configured through the webservice/publication module
2. have network connectivity from the OpenCms instance
3. needs to have a writeable OpenCms share
4. needs to have a Samba mount on the OpenCms instance to the NT share.

Although we opened up a lot of network connectivity to provide options at each tier, generally PTC servers alone can sync to PTC NT machines, and likewise for IE (although we have set up qbkscms2.ie.intuit.com as a pre-prod OpenCms that in fact lives in the IE area so we could testbed GSA sync events!)

Here's how to affect the OpenCms samba mount:

mount -t cifs //qbksweb6.ie.intuit.com/OpenCms /mnt/support6 -o user=avocado,uid=apache,gid=apache,directio

Surprisingly, if you forget the uid,gid params you'll get java.io errors instead of synchronization. Feel free to use a non-admin account in the future provided it still has r/w access to the share.

To see what mounts have been set up on a machine, use:

df -h

umount can be used to umount a share. You'll need to do this to reset the share's utilized password.

1. umount the share. Verify with df -h
2. change the nt password on the nt server.
3. mount the share. Provide the password again.

You can also test r/w on the NT machine with this combination of commands to validate sync should be good:

$ cd /mnt/supportN/
$ echo "bob" > bob
$ ls bob
$ cat bob
$ rm bob

Validate that you could see and read the file you created prior to deleting it.