Thursday, December 20, 2012

Tomcat catalina.out rotation and truncation

Tomcat rotates catalina.out in a way that it logs for the current date everything in its own file ( catalina.yyyy-MM-DD.log ) but it also keeps the whole log without truncation in catalina.out. Most of the traces going to catalina.out can be avoided removing the Console Handler from the below line in conf/logging.properties:
.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
The reality is that still catalina.out will grow if any library not using logging decides to send its output to the stdout, for example (probably not the best example for production as you won't run a debugger there, will you?):
Listening for transport dt_socket at address: 8000
This might not a big deal after all in terms of file size but we will agree it is easier to read from the same file when monitoring your logs rather than having to inspect a different log every day. It makes sense IMO to go to rotated logs only for historical reasons.

I believe that setting a file size you are comfortable with and making sure any time the catalina.out goes beyond that size is truncated makes the most sense. However that is not easy to be achieved from outside tomcat itself.

Truncating catalina.out from the stop command in catalina.sh makes the most sense out of the very different ways you can stop catalina.out from growing. That means right before the stop section ends (before the else for configtest) we can resolve this issue just adding:
...
  if [ "`stat -c %s $CATALINA_OUT`" -gt "$CATALINA_OUT_MAX_SIZE" ]; then
    cp /dev/null "$CATALINA_OUT"
  fi
elif [ "$1" = "configtest" ] ; then
...
Of course you need to configure the value for $CATALINA_OUT_MAX_SIZE in setenv.sh.

Please understand that catalina.out will stop growing once the log file is greater than CATALINA_OUT_MAX_SIZE *AND* the stop command is used. This might mean you can have eventually a file bigger than the expected CATALINA_OUT_MAX_SIZE but hopefully it will not go out of control as it is the case when you do not take proper measures.

Wednesday, December 19, 2012

Ubuntu 12.04 Unity Launcher How To

Every time I have to come back to Ubuntu Desktop there is some major change I need to adapt to. I will make no comparisons with other Desktop OS but instead will keep here some notes I found useful for Ubuntu 12.04.
  1. You run applications by searching for them via "Dash Board", the top icon from the Launcher (the by-default left bar)
  2. You can add a shortcut in the Launcher to a particular application: Run the app, right click on its icon from the Launcher and select "Lock to Launcher"
  3. The bar can autohide if you use the "Appearance" app, "Behavior" option
  4. The Launcher is buggy at least in 12.04 so it might disappear, freeze, God knows what else. You just need to be able to connect to the console and run the below (which will restart the box and try to rebuild all compiz related settings)
    $ mv ~/.config/compiz-1 ~/.config/compiz-1.BACKUP
    $ shutdown -r now
    

Tuesday, December 18, 2012

DevOps and VDI configuration - Ubuntu Desktop POB recipes

We have presented before how to install remotely in any Ubuntu desktop Talend Open Studio IDE. The same can be done of course with any other package and I have just released the simple recipes that helped me installing not only Talend but Eclipse and iReport as well.

Here is you would use it to install Eclipse Juno from a CIFS mounting point in your network:
common/ubuntu-desktop/eclipse-gui-install.sh //fileServer/path/to/Eclipse/gzip/distro/file /mnt/Eclipse WIN_DOMAIN `logname` `logname` eclipse-jee-juno-SR1-linux-gtk-x86_64.tar.gz eclipse-jee-juno-SR1-linux-gtk-x86_64


Automating the Desktop is usually ignored but the time you save is simply to big not to bring my attention to it. Agility after all is to be applied to all areas of your development lifecycle. How can you possibly claim you are agile if you do not automate?

Having Desktop golden images for the Virtual Desktop Infrastructure (VDI) is as important for a software shop as having recipes for server configuration, management and maintenance. From Plain Old Bash scripts you can build a huge collection of recipes that can take care of your whole Infrastructure and development. With a tool like Remoto-IT you can deploy those on demand in new virtual or physical boxes.

Only when your Devs are agile AND your Ops are agile, you can claim you have DevOps in your workplace.

Mountain Lion OSX slow SMB / CIFS / Windows network share access

Mountain Lion OSX slow SMB / CIFS / Windows network share access?
$ sudo bash
# if [ -f /etc/smb.conf ]; then mv /etc/smb.conf /etc/smb.conf.bak; fi
# echo "[default]" > /etc/smb.conf
# echo "notify_off=yes" >> /etc/smb.conf

Multi line comments in bash

Friday, December 14, 2012

Security: Stop Tomcat info disclosure

Not that I believe obscuring information of your running backend services will stop any smart hacker from figuring out what version you are running. In fact are hackers still doing that manually? I would expect them to have automated tools that would simply try to attack using a reverse historical vulnerability list for example.

In any case it is "recommended" to obscure tomcat version number and here is a recipe to do exactly that. We cannot afford patching dozens of tomcat servers following steps and while any configuration and management tool could help we prefer Plain Old Bash (POB) recipes run from Remoto-IT. So we just include a recipe line like:
common/tomcat/tomcat-remove-server-info-from-catalina-jar.sh /opt/tomcat

Tuesday, December 11, 2012

couchdb Unknown SSL protocol error in connection

After hardening a couchdb server I found the below:
$ curl -v -X GET https://localhost:6984
* About to connect() to localhost port 6984 (#0)
*   Trying 127.0.0.1... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to localhost:6984 
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to localhost:6984 
But I have done this several times before and it did work so I knew it should be a problem with certificates. How to debug what is going on? From erlang traces we could barely see any other clue than the fact there was a crash after loading the key so running a local server using the certificate and key should be the next step to later test if from that server (default port is 4433) we get a better curl reponse so:
$ openssl s_server -key couchdb.pem -cert couchdb.cert.pem -www
Enter pass phrase for couchdb.sample.com.pem
And that was the issue, the key needed a password. This can be either configured or removed from the key so it works without a password. No need to say which one is more secure.

Running tomcat remotely

Let us say you want to restart tomcat remotely. Any of the below commands would work when issued directly in the server:
$ service tomcat start
$ /etc/init.d/tomcat start
Unfortunately they will not work if you try something like:
$ ssh -t remoteserver sudo /etc/init.d/tomcat start
That is what ultimately happens when you try to restart tomcat from a POB recipe using Remoto-IT as well.

Solution

The tomcat/bin/startup.sh script needs to be modified to use the nohup command like:
$ vi /opt/tomcat/bin/startup.sh 
...
exec nohup "$PRGDIR"/"$EXECUTABLE" start "$@"
The reason for this issue is that when the command is run remotely the logout signal causes the tomcat process to be killed as it depends on a terminal session that is to be closed. The command nohup allows the process to be detached from its parent (terminal), basically the process becomes a daemon.

Monday, December 03, 2012

Mount a VirtualBox shared folder in Ubuntu guest

VirtualBox "presents" to the Linux operating systems a device named after the shared name you selected from "Devices|Shared Folders" VM menu option. In order to use that as a directory in Ubuntu or any Linux system you need to follow the same steps you would follow to mount any device. Let us say you picked as a name "reports" to mount some reports folder in our host:
  1. Create a directory to be used as the destination of the mounting point:
    sudo mkdir -p /mnt/reports
    
  2. Mount the device using the proper file system type (-t)
    sudo mount -t vboxsf -o uid=`logname`,gid=`logname` report /mnt/reports
    
Look how I mounted after /mnt. That is for the purpose of organization, you should not be mounting in any path (even though it is perfectly valid). You better know from one single place how many mounted paths you have.

Finally look at the use of `logname` invocation to make sure the VBOX folder gets mounted in a directory where the username of the current logged in user has enough permissions.

Followers