Capistrano is a tool for automating tasks via SSH on remote servers. It has many uses, I (and many others) use it to deploy their (rails) applications. The best I can tell there is no built in way to deploy a branch from your source code control system. There are a couple ways of accomplishing this. I chose passing in the branch as a parameter to the Capistrano command:
cap --set-before branch=testbranch deploy
A client site still uses cvs, the ever trusty version control system. After what seemed a run of the mill merge I noticed this:
C lib/jt400_3_3.jar
cvs update: move away lib/jt400_3_3.jar; it is in the wayVery peculiar. That file hadn’t changed on the branch. I googled around and an explanation started to come together.
First, from the always excellent Roedy Green’s Java & Internet Glossary on Mindprod:
CVS is disturbed by the appearance of repository files it did not put there. Your best bet is simply to delete the entire directory containing the offending file by hand, and re checkout or reupdate the directory to build the necessary entries. Then you can add the files safely.
Then, I found this mailing list post:
This means the file that CVS wants to checkout exists on the local machine but CVS never created the file in the past. This it isn’t CVS’s file and it complains rather than blindly overwriting.
The solution everywhere was the same: just blow away the directory and check it out again. Worked for me. Now I need to puzzle out how it happened in the first place…
I’m not sure if something isn’t set up correctly of if this is just a fact of life with rails but the sessions it creates never seem to go away. I think before rails 1.1 the sessions where stored in /tmp and now they are stored in the apps directory along with everything else so they is probably no internal mechanism to delete them. I only noticed because after about a month of an certain app running the disk on the machine started to fill up. After digging a little I found 50K ruby_sess.* files hanging out in the rails session directory.
Anyway it was easy enough to clean up the stale ruby_sess files by going into the rails webapp/session directory and then running the following command:
find -type f -name "ruby_sess*" -exec rm -f {} \\;
I’m not sure why the app is creating sessions but it isn’t something that stores state so I didn’t have to worry about killing active sessions here. If you do need to worry about that you will probably want to toss a time on the find command.
After looking a little more I found a post about this that has a ruby way of cleaning up the sessions.
I think by now most sysadmin types know about rrdtool and the nice graphs it makes. I recently wanted to create some graphs by hand using PHP so I turned to the php-rrdtool extension. I found that it takes a little work to get it to compile but that could be because I’m not constantly recompiling PHP and just don’t know better. You can get this module as an rpm for fedora (php-rrdtool) but I like to compile php by hand so I couldn’t use it. I’m going to assume that you know how to compile PHP normally with whatever other items you want to include and that you have the rrdtool development libraries installed or have compiled and installed rrdtool from source.
Go to the contrib directory on the rrdtool distribution site:
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/pub/contrib/
There are a number of files in this directory that mention rrd. You want the one named: php_rrdtool.tgz
At a customer site, the test and production linux servers for some intranet applications were slowly running out of disk space. The apps themselves were running fine, it was the logfiles generated by the apps that were the issue; logging that came in useful just in case something went wrong, but quickly aged. In one particular case, a catalina.out file was several years old and was 11 gigabytes; 90% of it wasn’t really relevant any longer.
The solution to the problem of wrangling logfiles is probably already installed on your server: it’s logrotate. Chances are logrotate is already configured in your system crontab as a daily task, and chances are it is configured to obey any configuration files found in the /etc/logrotate.d directory. If you find that directory, you are probably good to go.