When trying to sort my cthub XML file recently I found out that my code from the post on sorting the role listing had stopped working.
Turns out that there was an error introduced into the format of this file when upgrading from Contribute 3.11.
As you are no doubt aware, when at least one admin upgrades to Contribute 4 or Contribute CS3 (aka 4.1) all the admins have to since there are upgrades made to the XML files that control the site. Well it appears that this upgrade makes the cthub file non-valid XML.
Take a look at this file and look for the tag font_use_css inside the group_list_item child node of the group_list node. In a copy of the cthub file that was upgraded you will find that this standalone tag is missing the appropriate closing slash. If you compare this against a copy of the cthub file from before the upgrade, assuming you made a backup, you will find that the tag is properly closed.
Since this file is the master file with all of the role information for the site, I wonder if this XML error is causing unknown instability in the system somewhere.
While this is an easy fix, I will be posting some code that you can run to fix this, since editing a file like this by hand can be a real pain.
When you setup a website to be managed by Contribute, the name that shows up in the client for the connection description is generated from the text of the title tag of the index page of the website.
For setups where you are only managing a single site, this may not matter, but if you have a system where you use a development server and a production server, you may want the connection string to depict which server the user is editing and publishing to.
In order to change the text of the description you have to alter some text in a few files on the CPS management server.
In the installation directory of CPS, there is a database directory. This is the location of the files that are specific to the individual websites that are being managed.
The files in each site being managed are in a directory that is “numbered”, the number relates to the numerical order in which they were set up. If you remove a particular site, the numbers are not reused.
In each of the site directories there is a file named: connection_key.stc
This file, in XML format, contains a localinfo tag. The attribute sitename is the text that shows up in the Contribute client on the start page.
Once this is updated and a user logs into the Contribute server, the client connections are updated.
While this may be enough on it’s own to effect the change desired, the original name is still referenced in the cthub file for each individual site. I changed the name in both locations for completeness.
At VSU, we are implementing the Adobe (formerly Macromedia) Contribute Publishing Server and CMS.
This is a two-piece system that involves a client-side component (Contribute) and a server-side component (CPS).
We are running this on a Linux server, so we needed an easy way to start the service up should a system reboot occur.
Now Macromedia included a very simple shell script that made a call the included OEM Jrun binary to start the server. The only problem is that it had no facility to plugin to the chkconfig tool that can be used to manage services in the various runlevels.
So I wrote a very simple one:
#!/bin/bash # # CPS Startup script for the Macromedia Contribute Publishing Server # # chkconfig: 2345 80 20 # description: The CPS is the backend to manage the Macromedia Contribute CMS. # processname: jrun -nohup -start contribute-wps # pidfile: none noticed # Source function library. . /etc/rc.d/init.d/functions jrun=${JRUN-/usr/Macromedia_CPS/jrun4/bin/jrun} prog=CPS lockfile=${LOCKFILE-/var/lock/subsys/macromedia_cps} RETVAL=0 start() { echo -n $"Starting $prog: " $jrun -nohup -start contribute-wps RETVAL=$? echo [ $RETVAL = 0 ] && touch ${lockfile} return $RETVAL } stop() { echo -n $"Stopping $prog: " $jrun -stop contribute-wps RETVAL=$? echo [ $RETVAL = 0 ] && rm -f ${lockfile} } # See how we were called. case "$1" in start) start ;; stop) stop ;; status) $jrun status ;; restart) stop start ;; *) echo $"Usage: $prog {start|stop|restart|status|}" exit 1 esac exit $RETVAL
Note that the lockfile referenced was an invention on my part, since the standard startup of jrun included with CPS doesn’t appear to create either a standard lockfile or pidfile.
After creating the file in /etc/init.d directory, you will need to run the following command: chkconfig --add CPS
This will add your new script to the service list maintained for use with chkconfig. At this point all the standard chkconfig commands can be used to manage this.
For more on chkconfig check out the chkconfig online man page at LinuxCommand .
In the process of troubleshooting the LDAP user problems I was experiencing I found that by default the logging of info and debug messages is turned off by default for the OEM jrun install that is part of Contribute Publishing Server 3.11.
In order to enable these logging levels you have to edit the sevrer configuration xml file. This file should be located in the configuration directory of your jrun4 server’s WEB-INF folder.
The name of the file is: ckm.xml
Open this file in your favorite editor and look for the following section:
/usr/Macromedia_CPS/logs/out.log /usr/Macromedia_CPS/logs/err.log true true true
By default the logger is only set to show error messages. This section also shows the location of the error logs and the output logs.
Note, that enabling this you will get larger log files, since this will log all connections to the LDAP server by the Contribute client(s) that you have installed. You may find it necessary to open the admin console and set a max log file size to control this.
One of the annoyances I have found with the Contribute Client is that in the Administration interface section, when adding a user, the menu of roles is not sorted for you. The list that appears when you reassign a user or when you create a new role, is sorted for you.
Each time that a new role is added, the client updates the hub file, adding the new role to the end of the list.
In investigating this I found that the hub file is just an XML file. This file is stored in the root _mm folder of the website that you are managing. Note that this file is connection specific, so if you are managing multiple websites, the location of this control file will vary. And if you are managing a large deployment by having multiple sites with a single directory structure, you will have a different _mm folder and hub file for each site, even though they are physically on the same server they are treated differently by the logic of the software.