sanity's questions

I tried following the instructions described here: https://help.ubuntu.com/community/EOLUpgrades/Jaunty

However, this gives me the following error:

root@hawk:~# do-release-upgrade 
Checking for a new ubuntu release
Done Upgrade tool signature
Done Upgrade tool
Done downloading            
extracting 'lucid.tar.gz'
authenticate 'lucid.tar.gz' against 'lucid.tar.gz.gpg' 
tar: Removing leading `/' from member names

Reading cache

Checking package manager

Can not upgrade 

An upgrade from 'jaunty' to 'lucid' is not supported with this tool. 

root@hawk:~#

How can I do this safely?

Here is the relevant part of my config:

<VirtualHost *:80>
  ProxyPreserveHost On
  ServerName mydomain.com
  ProxyPass / http://127.0.0.1:9000/
  ProxyPassReverse / http://127.0.0.1:9000/
  <Location "/">
    Order allow,deny
    Allow from all
  </Location>
</VirtualHost>

When I visit http://mydomain.com/ it appears to proxy as it should, however if I visit http://mydomain.com/subdir I get a

This page appears to be broken

This isn't what I want as I want all requests to http://mydomain.com/ and its subdirectories to be proxied. There is no corresponding error in the error.log.

What am I doing wrong here?

I have an Ubuntu server called crow:

$ hostname
crow

But when I try to ping it (from itself), I get unknown host:

$ ping crow
ping: unknown host crow

This is despite explicitly adding crow to /etc/hosts:

$ sudo cat /etc/hosts
127.0.0.1       localhost crow

What am I doing wrong?

Additional info in response to comments:

The hosts line of /etc/nsswitch.conf looks like this:

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

My Ubuntu 9.04 server on Slicehost is periodically freezing, and not responding to ssh or console access. I believe it is some kind of resource starvation or swap death issue.

This has been happening every few days, and I need to figure out what is causing it. Can anyone recommend the simplest way to do this?

Someone recommended "sar", and I've installed it, but its not clear to me whether it can pinpoint a specific troublesome process, or whether it is running frequently enough to catch the likely culprit.

I'm a recent convert from bash to zsh (which I'm using "oh my zsh" with), but one thing annoys me:

When I hit the tab key, the first autocompletion is filled out automatically, and you need to cycle through the completions by hitting tab repeatedly.

This differs from bash, where you are just shown a list of the completions. If all completions have the same prefix, then this prefix is filled out. You can select the one you want by continuing to type.

I find the latter preferable since it is faster to type, than to select a completion by hitting tab repeatedly.

Is there any way to make zsh completion act more like bash in this regard?

Does anyone know the approximate time required to retrieve and modify a kilobyte of data for various types of storage media in a typical modern server?

Specifically:

• RAM
• Hard disk
• SSD

This would be a random access, not sequential.

I'm more interested in the orders of magnitude than the specific actual numbers (since I don't know the actual hardware my software will be running on).

We have a Redhat Enterprise server (not set up by us, but we have no reason to assume its not a stock installation) that is restarting every few weeks for no apparent reason whatsoever. On previous occasions there was nothing in the log file which suggested it just died without warning.

We just discovered that the server has been down since Saturday, and the logs seem to indicate an orderly shutdown:

Dec 19 14:23:38 SKUNK1 shutdown: shutting down for system halt

The problem is that we have no idea why it shutdown, and are pretty sure that it wasn't anyone doing it deliberately.

Can anyone suggest why this might be occurring, and how we can diagnose it?

I have a directory full of files.

I want to initially pass each of those files through a command, and send the output to another file in a different directory as follows:

cat dir1/sourcefile | process.py > dir2/destfile

the name of "destfile" is unimportant, it can be any filename.

Easy enough, however - new files are being added to dir1 all the time, and existing files are occasionally being modified.

How can I write a bash script (or another type of script) that will keep an eye on dir1, and whenever a new file is added or modified, process it or re-process it into dir2?

I need to use a command like the following:

$ cat large.input.file | process.py > large.output.file

The problem is, as this is won't the hard disk have a hard time jumping between reading the input file and writing the output file?

Is there a way to tell bash to use a large memory buffer when doing this kind of pipe?

Is there a way, in a single command, to establish a ssh connection from my computer A, through computer B, to computer C, such that I have access to the shell on computer C?

A wrinkle (which seems to rule out simply forwarding the ssh connection using the -L option) is that I have the password to the account on computer B, and the account on computer B is authorized to connect to the account on computer C, but I do not have the password to the account on computer C.

I have a Java application where scalability is primarily limited by RAM, that I would like to run on one or more servers in a datacenter. Where should I be looking for server hardware that can accommodate 100GB - 512GB or more of RAM? I'm not an expert in such matters so I really don't know where to start.

Is this getting into supercomputer territory (6 figures or more), or could I obtain such a server for low 5-digit dollars?

A few notes based on some questions below:

• Yes I have tried hard to think of ways to remove this scalability requirement, and no its not really an option. The application fundamentally requires very fast random access to very large amounts of data, storing in a hard disk (via a database perhaps) won't cut it.
• I'm pretty sure the JVM can, at least in theory, scale up that far. I regularly run my code with 10GB allocated to the Sun 1.6 JVM without noticeable problems.