I docked myself at my Workstation and started downloading an ISO. Once finished, I burnt it and rebooted my Thinkpad. One of the great things about Ubuntu’s installation (which has existed for a while) is the Live CD – you get to boot into Ubuntu without having to install anything. It works well and is a great feature for new users who aren’t sure what they’re doing, or whether they want to risk installing Linux. What’s great is that the hardware issues of old are long gone: . Unforunately I found the boot-up process to be volatile: it was taking a long time and things didn’t look great. I eventually got into X and played around. Amazingly I had all my Thinkpad buttons working; suspend, hibernate (suspend-to-disk) and even the back & forward buttons for the browser. It worked flawlessly.

Naturally I decided to install as I was very impressed. So I fire up the installation procedure by clicking ‘Install’ on the Live CD’s desktop and go through the motions. Clicking ‘Forward’ after the username setup freezes, and my laptop performs a hard-shutdown…WTF?? I try again – the same thing happens. What’s going on? I decided to get an alternate ISO and try that. Thankfully it installed, but I was a little concerned that nothing was going to work…

After finally booting into X after my little ordeal, I decide to run `apt-get update && apt-get upgrade` in a shell. To my surprise, as soon as it starts upgrading packages (a Kernel upgrade) my shell gets spammed with “The system is going down for a reboot NOW!” and Ubuntu shuts down. Ouch. This isn’t good.

I’ve had overheating issues in the past, but this is beginning to worry me. Anything even remotely CPU intensive (scrolling the wireless network list, apt-get upgrade, etc etc) causes Ubuntu to force shutdown, and I’m left looking very cross at my X31.

Some googling produces thread after thread on the Ubuntu forums about this, but things seem to be getting ignored. There’s no issues, and people are talking about the exact same problems in Gutsy and Feisty – that’s three or more major releases ago. I’ve tried these things:

• Adding the following to /etc/rc.local:

  echo -n “90:80:60:75:70:65″ > /proc/acpi/thermal_zone/THM0/trip_points
  echo 2 > /proc/acpi/thermal_zone/THM0/polling_frequency

•  Appending these modules to /etc/modules:
  battery
  ac
  thermal
  processor
  acpi-cpufreq
  cpufreq-userspace

No luck. Furthermore, with each futile attempt, I get hard-rebooted or even worse: no init 0, just a hard shutdown. It’s frustrating and furthermore it is very likely that this is damaging my hardware. I’ve been monitoring `acpi -t` output, top and more but nothing’s helping. Even running /etc/init.d/gdm stop and trying the apt-get upgrade in a shell doesn’t help: same old hard shutdown.

I don’t know what to do. I’m a big fan of Ubuntu as it’s bringing Linux to the masses, but I can’t keep doing this to my poor old Thinkpad X31 – it won’t last much longer.

Anyone out there have any ideas?

Update: I’ve filed a bug report here

What I’m Running

Here’s a rundown of what sites I’m running and the software used.

• beplacid.net – Apache 2, Django (Python framework), MySQL (one instance)
• blog.beplacid.net – PHP 5, MySQL, WordPress
• readingcamra.org.uk – Apache Tomcat 6, Java 5, MySQL
• readingbeerfestival.org.uk – As above

Wget – the Swiss army knife of HTTP command line tools

Wget’s one of those tools you really take for granted. It’s versatile, reliable, simple and most importantly – it does its job very well. One of its nicest features is the –mirror option. This allows you to…mirror a given website. I initially thought of running multiple instances of wget at the same time. I started small at first: one instance running to mirror the entire site. I ran the following in a shell:

alex@prometheus:/tmp$ wget –mirror beplacid.net/

It’s simple: mirror beplacid.net. Watching the processes and CPU usage on the server, it became apparent that  this wasn’t going to do much. The CPU usage didn’t exceed 5% on its first core. I had to rethink. Then ab sprung to mind.

ab – Apache benchmarking tool

This is another useful tool. It’s simple to use and allows you to quickly and easily hit a given hostname with HTTP requests, all tailored to your specific needs. To do all this, however, you need to be running as root. A noble security measure.

I wanted to generate some traffic that would put the server under some strain, so I started with 50 requests and 5 at a time:

prometheus:/root$ ab -n 50 -c 5 beplacid.net/

Now things started to get fun. This peaked CPU usage to 94% on one core, the others were between 60 and 80. I was starting to see some real stats. I doubled things – 100 with 10 per request:

 prometheus:/root$ ab -n 100 -c 10 beplacid.net/

This was a little more representative of a heavy amount of traffic. Perhaps akin to slashdot or a reddit. Put simply, that’s 100 requests with 10 each sent each time. Still nothing major, so I went all out:

Concurrency Level:      10
Complete requests: 1000
Total transferred:      4856792 bytes
HTML transferred:       4687792 bytes
Requests per second:    4.99 [#/sec] (mean)
Time per request:       2002.453 [ms] (mean)
Time per request:       200.245 [ms] (mean, across all concurrent requests)
Transfer rate:          23.69 [Kbytes/sec] received

To summarise, the server took 1000 requests with an average of 5 per second, each returning just over 2 seconds. Not bad, considering what I’m running.

I’m pleased with my setup. It can take a punch and it’s still running. My next task is to hit both beplacid.net and the blog, with perhaps some traffic mirroring readingbeerfestival.org.uk too.

Fear not, fellow hacker – SSH over an HTTP proxy is here! Well actually, it’s been here a while. Ahem.

Before you do this, I must stress that you should check with your network’s usage policy before continuing. You may be breaking your networks rules, and I cannot & will not be held responsible for anything that arrises from using these instructions. You are on your own.

Installing Corkscrew

To quote its package details in Debian & Ubuntu repositories, Corkscrew “is a simple tool to tunnel TCP connections through an HTTP proxy supporting the CONNECT method. It reads stdin and writes to stdout during the connection, just like netcat“. Put simply, it’s a way of sending traffic that would normally go via alternate means (say, over port 22), through a proxy server that may block the original routes.

We’ll need corkscrew, or a similar TCP tunnel package, to send the info via the proxy. Fire up a shell and execute the following:

sudo apt-get install corkscrew

This will install corkscrew. Don’t worry, it doesn’t run as a daemon, but instead on a per-connection basis (that is, it reads from stdin), so it’s not going to hog many resources. Once that’s done, we’ll configure ssh to use corkscrew instead of a direct connection.

If your HTTP proxy uses authentication, then you’ll need to tell it about the username and password to use. This is where the concept of ‘auth-file’ comes into play. All you have to do is put your username & password, separated by a colon, into a textfile. Once you’ve done this, you just have to tell corkscrew where to find the auth-file. Create a file called .corkscrew-auth in your home directory and place your username and password in the following format:

username:password

Save the file and get ready for the next bit… :)

Configuring ‘ssh’ For Tunneling

Now we’ll tell ssh what to do when connecting to all or specific hosts. Open up ~/.ssh/config (that’s /home/yourusername/.ssh/config) in your favourite text editor (vim > *) and add the following lines:

Host *
ProxyCommand corkscrew proxyhostname proxyport %h %p /home/username/.corkscrew-auth

Note: replace proxyhostname and proxyport with the equivalents for your network.

Note: you won’t need to add the last section, ‘/home/username/.corkscrew-auth’, if your HTTP proxy doesn’t use authentication.

What we’ve just told ssh to do is for all hostnames (‘Host *’), use the following proxy command to route the connection. The text after ProxyCommand is all specific to your HTTP tunneling software, except %h and %p which are ssh config variables for the hostname and port respectively.

This should work out of the box. It did so for me. Test it out in a shell by doing the following:

ssh somehost.com

I think you’ll be pleasantly surprised…Any issues, please post below and I’ll be happy to help out.

Cheers for reading,

Placid

Introduction
This HowTo explains the installation and configuration of Apache 2.2.3, Tomcat 5.5.25 and the Apache Jakarta module — a connector/proxy for Apache & Tomcat — under Debian Etch. It is geared towards those who already have experience configuring Apache and Tomcat and are aware of the basic principles behind Apache modules.

Prerequisites
A working installation of Debian GNU/Linux that has an internet connection, or valid CD-ROM apt packages disc.

Step 1: Installing Apache
If you don’t already have Apache installed, you will need to run the following in a shell as root:

This will install Apache 2 and any relevant dependencies. Configuration files for Apache can be found under /etc/apache2, and host-specific configuration are found under /etc/apache2/sites-available/. This is where you should configure your individual Virtual Hosts, as opposed to placing the configuration in /etc/apache2/apache2.conf.

Step 2: Install mod_jk
Using apt, you need to install the Apache Jakarta module by executing the following in a shell as root:

The module may need enabling via ‘a2enmod jk’, but it is not necessary at this time. Go ahead and execute the following as root:

Running the above should return a message similar to ‘Module enabled, now run /etc/init.d/apache2 force-reload’. I do not recommend reloading Apache’s configuration until everything has been installed and setup. This will ensure Apache remains usable while you setup Tomcat in the next step.

Step 3: Download and Extract Apache Tomcat 5.5.25
There’s a reason I installed Tomcat manually: Debian’s Tomcat package is a mess. The default package splits, amongst others, the webapps and conf folders. Whilst the conf folder is situated in a respectable location (/etc/tomcat5), the webapps directory is symlink’d under /var/, which tends to cause problems with Apache->Tomcat configuration. Therfore, I have chosen to manually install Tomcat using the .tar.gz from tomcat.apache.org; as well as this being a recommendation from various people in the #tomcat channel on irc.freenode.net. In short, it’s a configuration and administration nightmare.

Download Apache Tomcat 5.5.25 from here: http://tomcat.apache.org/download-55.cgi (select a mirror) and extract it to one of the following locations (I used /usr/share/):

• /usr/local/
• /usr/share/

To do the above, execute these commands as root:

Now, let’s setup a user and group so we can provide safe permission control over the conf and webapps directories.

Step 4: Add a tomcat user and group

We’ve just created the tomcat user & group, so let’s apply the ownership permissions to the webapps directory:

This now means that any user who’s in the tomcat group can read, write and execute files under the webapps directory.

Note: if you use a specific user and group such as www-data for Apache ownership and execution, which is the default in Debian, you will need to add ‘tomcat’ to the www-data user’s groups:

The following is optional, as it sets the group permissions of the server.xml to writable by the tomcat group. This may not be what you want, so be careful!

Now that we’ve setup the most important directories, let’s make the tomcat startup and shutdown bash scripts executable, ready for starting it up:

Step 4: Create the workers.properties File
Create the following file, as root, under /etc/apache2 or a directory of your choice (/usr/share/tomcat-5.5.25/conf would also be fine), but make sure it’s readable by the tomcat user and/or group.

The ‘worker.list’ parameter defines the names for the ajp13 connector(s). This is what Apache talks to. You can specify a name of your choice, but make sure you remember it for later, and ensure you’ve changed all parameters beginning with ‘worker.default’ to the name you’ve set.

Step 5: Configure an Apache to Talk To Tomcat and add a Virtual Host
This step is the most important part. It assumes that you’re using virtual hosts for Apache (you may not be), so if that isn’t the case, just place the JkMount configuration lines in the Virtual Host section along with the config. below in your main apache file (/etc/apache2/apache2.conf).

For my virtual host, I created the following configuration file under /etc/apache2/sites-available:

The most important lines in the above quote are the following:

These two lines specify the URL paths that should be handed to mod_jk and thus Tomcat. The ‘default’ section of the line specifies the JK worker identifier. This must match the name you specified in the workers.properties file!

That’s the configuration done, let’s fire this baby up!

Step 5: Unleashing the Beast; Starting Apache & Tomcat
To ensure a clean start up, I recommend stopping Apache entirely, and then starting up Tomcat, then Apache. Do so by executing the following commands (as root, see the note blow otherwise)::

Note: if you want tomcat to run as a separate user but keep ownership as root, use jsvc and the -user flag to specify the user it should change to at startup.

Both Tomcat and Apache should startup without error, and you should now be able to connect to Apache and the Tomcat via the specified Virtual Host.