Install software in unsupported Ubuntu versions with apt-get

When an Ubuntu version goes unsupported its repositories get moved to an archive server. If you don’t update the repo origins you’ll get some errors like those:

Err http://archive.ubuntu.com quantal/main i386 Packages
  404  Not Found [IP: 91.189.91.14 80]
Err http://archive.ubuntu.com quantal/restricted i386 Packages
  404  Not Found [IP: 91.189.91.14 80]
Err http://archive.ubuntu.com quantal/universe i386 Packages
  404  Not Found [IP: 91.189.91.14 80]
Err http://archive.ubuntu.com quantal/multiverse i386 Packages
  404  Not Found [IP: 91.189.91.14 80]
Err http://archive.ubuntu.com quantal-updates/main i386 Packages
  404  Not Found [IP: 91.189.91.14 80]
Err http://archive.ubuntu.com quantal-updates/restricted i386 Packages
  404  Not Found [IP: 91.189.91.14 80]
Err http://archive.ubuntu.com quantal-updates/universe i386 Packages
  404  Not Found [IP: 91.189.91.14 80]
Err http://archive.ubuntu.com quantal-updates/multiverse i386 Packages
  404  Not Found [IP: 91.189.91.14 80]
Err http://archive.ubuntu.com quantal-security/main i386 Packages
  404  Not Found [IP: 91.189.91.14 80]
Err http://archive.ubuntu.com quantal-security/restricted i386 Packages
  404  Not Found [IP: 91.189.91.14 80]
Err http://archive.ubuntu.com quantal-security/universe i386 Packages
  404  Not Found [IP: 91.189.91.14 80]
Err http://archive.ubuntu.com quantal-security/multiverse i386 Packages
  404  Not Found [IP: 91.189.91.14 80]

The key to solve this is changing the repo urls from archive.ubuntu.com and security.ubuntu.com to old-releases.ubuntu.com:

sudo sed -i -e 's/archive.ubuntu.com\|security.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list

Then update:

sudo apt-get update

apt-get-404

Ref: http://askubuntu.com/questions/91815/how-to-install-software-or-upgrade-from-old-unsupported-release

Load testing a web site with Siege

Siege is an HTTP load testing and benchmarking utility. It helps you test you server and web developments in high load situations. Quoted from it’s home page:

Siege is an http load testing and benchmarking utility. It was designed to let web developers measure their code under duress, to see how it will stand up to load on the internet. Siege supports basic authentication, cookies, HTTP and HTTPS protocols. It lets its user hit a web server with a configurable number of simulated web browsers. Those browsers place the server “under siege.”

Servers

To install it in Ubuntu just use the repositories:

sudo apt-get install siege

In Mac OS X using MacPorts:

sudo port install siege

And using brew:

sudo brew install siege

If you don’t use either of them you’ll have to download and compile the source code. It’s as easy as running those commands that will install the binary files in /usr/local/bin folder:

curl -O http://download.joedog.org/siege/siege-latest.tar.gz
tar xzvpf siege-latest.tar.gz
cd `ls -1d */ | grep siege- | sort -r | head -1`
./configure
make
sudo make install

Note: That “strange” cd command moves you into the folders extracted from siege-latest.tar.gz. As it could have any version number we get the list of all folders starting with siege-, then sort in reverse order and get the first one.

Use siege.config to create a .siegerc file in your home folder with the default configuration:

$ siege.config
New configuration template added to /Users/user/.siegerc
Run siege -C to view the current settings in that file

Then you can list it’s options using the -C parameter of siege:

$ siege -C
CURRENT  SIEGE  CONFIGURATION
Mozilla/5.0 (apple-x86_64-darwin13.3.0) Siege/3.0.6
Edit the resource file to change the settings.
----------------------------------------------
version:                        3.0.6
verbose:                        true
quiet:                          false
debug:                          false
protocol:                       HTTP/1.1
get method:                     HEAD
connection:                     close
concurrent users:               15
time to run:                    n/a
repetitions:                    n/a
socket timeout:                 30
accept-encoding:                gzip
delay:                          1 sec
internet simulation:            false
benchmark mode:                 false
failures until abort:           1024
named URL:                      none
URLs file:                      /usr/local/etc/urls.txt
logging:                        true
log file:                       /usr/local/var/siege.log
resource file:                  /Users/user/.siegerc
timestamped output:             false
comma separated output:         false
allow redirects:                true
allow zero byte data:           true
allow chunked encoding:         true
upload unique files:            true

Now that siege is installed you can start testing a web site:

siege -c5 -d5 -r1 -v http://www.test.com

In this example I used:

  • -c5 to define the number of concurrent users
  • -d5 to define the delay between each user request
  • -r1 to define number of repetitions

The result of the command is something like this:

** SIEGE 3.0.6
** Preparing 5 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200   0.14 secs:    7706 bytes ==> GET  /
HTTP/1.1 200   0.16 secs:    7706 bytes ==> GET  /
HTTP/1.1 200   0.11 secs:    7706 bytes ==> GET  /
HTTP/1.1 200   0.11 secs:    7706 bytes ==> GET  /
HTTP/1.1 200   0.11 secs:    7706 bytes ==> GET  /
done.

Transactions:		           5 hits
Availability:		      100.00 %
Elapsed time:		        4.12 secs
Data transferred:	        0.04 MB
Response time:		        0.13 secs
Transaction rate:	        1.21 trans/sec
Throughput:		        0.01 MB/sec
Concurrency:		        0.15
Successful transactions:           5
Failed transactions:	           0
Longest transaction:	        0.16
Shortest transaction:	        0.11

But this command only tests one URL in your server, the one you give as parameter. To make a more real world test you can use the logparse Perl script to create your own urls.txt file. This program collects URLs from Apache style access logs and populates a urls.txt file to use it later with siege. The parameters needed are the web site you want to generate the URLs for and an access_log file from the Apache server:

perl logparse -h http://test.com -f /opt/local/apache2/logs/test.com-access_log

Once you have the urls.txt file you can use it in siege with the -f option:

siege -c5 -d5 -r1 -f=urls.txt -v http://www.test.com

Ref: http://www.joedog.org/siege-home/

Fix “No such file or directory: httpd: could not open error log file /…/${APACHE_LOG_DIR}/site.log”

If you get an error like this in the Apache2 error log:

No such file or directory: httpd: could not open error log file /.../${APACHE_LOG_DIR}/site.log

apache_logo

You can fix it by just adding the path of your Apache2 log folder in the envvars file. If you use Mac Ports it’s located in /opt/local/apache2/bin/envvars:

export APACHE_LOG_DIR=/opt/local/apache2/logs

If you don’t know where envvars is just find it with this command:

find / -name "envvars"

Once added just restart the Apache2 server.

Disable blank console in Ubuntu

Edit /etc/default/grub and add consoleblank=0 in the GRUB_CMDLINE_LINUX_DEFAULT option:

GRUB_CMDLINE_LINUX_DEFAULT="consoleblank=0"

grub

Then update grub and reboot.

sudo update-grub
sudo shutdown -r now

Run Solr as a service in Ubuntu

I’ve been doing some tests with Nutch and Solr these days. One thing I didn’t like was that when you run Solr all the info messages output to the standard output in the command line.

solr

I rather use it as a service so after a little search I found this solution from Terrance A. Snyder. I’ve just tweaked a little bit to get the output and error logs to different files and I’m still using the example folder.

#!/bin/sh -e
# SOLR auto-start
#
# description: auto-starts solr engine
# processname: solr
# pidfile: /var/run/solr.pid

NAME="solr"
PIDFILE="/var/run/solr.pid"
LOG_FILE="/var/log/solr-output.log"
ERROR_FILE="/var/log/solr-error.log"
SOLR_DIR="/opt/solr-4.10.0/example"
JAVA_OPTIONS="-Xmx1024m -DSTOP.PORT=8079 -DSTOP.KEY=stopkey -jar start.jar"
JAVA="/usr/bin/java"

start() {
  echo -n "Starting $NAME... "
  if [ -f $PIDFILE ]; then
    echo "is already running!"
  else
    cd $SOLR_DIR
    $JAVA $JAVA_OPTIONS 1> $LOG_FILE 2> $ERROR_FILE &
    sleep 2
    echo `ps -ef | grep -v grep | grep java | awk '{print $2}'` > $PIDFILE
    echo "(Done)"
  fi
  return 0
}

stop() {
  echo -n "Stopping $NAME... "
  if [ -f $PIDFILE ]; then
    cd $SOLR_DIR
    $JAVA $JAVA_OPTIONS --stop
    sleep 2
    rm $PIDFILE
    echo "(Done)"
  else
    echo "can not stop, it is not running!"
  fi
  return 0
}

case "$1" in
  start)
    start
  ;;
  stop)
    stop
  ;;
  restart)
    stop
    sleep 5
    start
  ;;
  *)
    echo "Usage: $0 (start | stop | restart)"
    exit 1
  ;;
esac

Save this as /etc/init.d/solr, give it execution permissions (sudo chmod +x /etc/init.d/solr) and then you are ready to start and stop it as usual.

sudo /etc/init.d/solr start
sudo /etc/init.d/solr stop

You can also configure it to start with the system:

sudo update-rc.d solr defaults

And remove it:

sudo update-rc.d solr remove

Ref: http://blog.shutupandcode.net/?p=463