My new box has arrived, and I've started building it up with the next LTS version of Ubuntu (not actually due for release till April). I've installed with hcmc admin logon only, added gnome-shell, and started adding applications. I'll keep hacking at this till 12.04 seems pretty stable, and then switch from my old machine by moving HDs to the new one. In the meantime, there's a lot of testing to do.
Working with RVDB in Belgium, I've been helping to investigate problems building and running the eXist WAR distro (trunk) on Windows. It appears to be the case that the WAR distro does not run correctly on Windows unless an additional stax jar file is added (this jar was recently removed from trunk, as it was thought to be unnecessary). We have now clarified and confirmed the symptoms and solution, and RVDB wil make a detailed bug report. We don't run eXist under Windows ourselves, but 70% of eXist downloads came from Windows users over the last few years, so it's important that the upcoming new version work well on Windows.
Not as easy as you'd think. There are a couple of easy ways to find out who's logged in to a linux machine: 'users' and 'who'. But I've discovered that when a user has been authenticated via ldap they don't show up when 'users' and 'who' are called. This MAY be a result of my configuration of the machine, but until that is determined, the only I've found of doing this is a bit convoluted. Run this one-liner when logged in to a remote machine:
me=`whoami`;today=`date +"%a %b %d"`;last|sort -r|grep "$today"|grep -v "$me"|grep -v reboot|cut -d " " -f1
me=`whoami` -> we want to able to exclude ourselves from the output.
today=`date +"%a %b %d"` -> we need the current date, without the time
last -> the actual command we need to find users logged in with ldap
sort -r -> last outputs oldest last, this reverses the order
grep $today -> cleans up our output to only show stuff from today
grep -v "$me" -> exclude me from output
grep -v reboot -> exclude the last reboot command
cut -d " " -f1 -> get the first field of the output (this is the login name of the ldap user)
All of that and all you *really* get is the last logged in user. They may or may not actually be logged in right now.
I'll have to look in to my ldap config a bit more closely. There must be a way of including ldap auth'd users in the output from 'users' or 'who'.
NOTE: a simpler, possibly just-as-useful, method is to run this
last | grep 'still logged in' | grep 'tty' | cut -d " " -f 1
which returns the logged user running on a local display.
This is a collection of bits and pieces we have painfully learned over the years regarding the setup of Tomcat proxied through Apache, enabling the reliable use of UTF-8 encoding in form submissions etc.
To make sure Tomcat starts with UTF-8 instead of the default, I put a script in [tomcat]/bin called utf8startup.sh:
#!/bin/bash ./startup.sh dFile.encoding="UTF-8"
If another script is starting Tomcat, that script must ensure that the process is launched with the
dFile.encoding="UTF-8" flag on the command line.
Add the correct parameter (URIEncoding="UTF-8") in conf/server.xml:
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" />
If Tomcat is proxied through Apache using the AJP connector, Tomcat's conf/server.xml file may need to be tweaked to add a URIEncoding="UTF-8" parameter for that:
<!-- Define an AJP 1.3 Connector on port 8019 --> <Connector port="8019" protocol="AJP/1.3" redirectPort="8081" />
<!-- Define an AJP 1.3 Connector on port 8019 --> <Connector port="8019" protocol="AJP/1.3" redirectPort="8081" URIEncoding="UTF-8" />
This needs to be added to the Apache configuration:
JkOptions +ForwardURICompatUnparsedThis does not relate specifically to UTF-8 encoding, but it's collected here for completeness:
Tomcat 7 handles default "welcome files" differently from 6. If you look in Tomcat's
conf/web.xml, you'll see this:
<welcome-file-list> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> <welcome-file>index.jsp</welcome-file> </welcome-file-list>
Obviously, there's no handler for an empty directory root; Tomcat 7, when presented with a directory root, goes to this list to see what to pass to the webapp. Absent a matching item, Tomcat 6 would simply pass the directory root through to the webapp, but Tomcat 7 doesn't; it always chooses the first item and passes that through. If your application isn't expecting it, the result will be an error. Assuming your application (Cocoon or eXist) is set up to handle everything it might get, then the best option is to comment out all the
<welcome-file> elements; if this is done, then Tomcat seems to hand off all processing to the webapp.
Incidentally, you have to restart Tomcat between changes to web.xml to cause them to have an effect (according to the web).
Other configuration changes may need to be made in eXist and/or Cocoon (if used), and these are detailed elsewhere on the blog. These changes relate specifically to Tomcat.
To turn on directory indexing, add this to your .htaccess file:
The additional setting for fancy indexing doesn't seem to work on our servers:
Authentication through LDAP stopped working for all our PHP sites, so after RE figured out the problem (pointing at the wrong LDAP server in Mustard) we had to make changes to all the .htaccess files.
I encountered this bug on teiJenkins, and after reading around a bit, followed the advice there to work around it:
sudo mv /etc/init/ureadahead.conf /etc/init/ureadahead.conf.disable sudo shutdown -r now
It seemed to solve the problem. We should do df -h every now and then to check for a recurrence.
We've had two permgenspace problems in the last two days on pear. A bit of research turned up a stack overflow answer that suggests the use of -XX:+CMSClassUnloadingEnabled in the java options.
I also found this (old) page which outlines things quite succinctly. To sum up:
-Xms and -Xmx should be set to the same number because "making these settings the same value prevents the JVM from frequently re-sizing the heap as it grows, something that can trigger frequent garbage collections and can degrade performance."
Only adjust permgensize if your other settings still produce permgenspace errors.
Another, more recent page goes in to more detail. It too argues that "it is recommended that the initial and maximum values for heap size be set to the same value. This is often referred to as a fully committed heap and this will instruct the JVM to create a heap that is initially at its maximum size and prevent several full garbage collections from occurring as the heap expands to its maximum size."
When we get the old-db-server-cum-new-tomcat-server ready we'll try this setup out:
Oracle 1.6 JVM, latest Tomcat (right now that's 7.0.25) and use the recommendations from tomcatexpert.com. We then plan to stress test the new setup with jMeter (jmeter.apache.org).
Chard is being re-purposed as a tomcat-legacy/tomcat-bleeding-edge machine called grape.hcmc.uvic.ca
Sysadmin is removing the IP name chard, so anyone using chard in a connection string will suddenly have failures - but of course no-one is using chard in a connection string because they aren't supposed to...
This blog is the location for all work involving software and hardware maintenance, updates, installs, etc., both routine and urgent, in the server room, the labs and the R&D rooms.
|<< <||Current||> >>|