Sun T2000 Niagara Noodling. Part 5

Part 4 is here.

Now to install some of the "must haves", starting with Python...Mentally switch from apt-get-think to pkgadd-think. Find good stuff on the Solaris freeware site (watch out for the 5 dependancies that Python has. You will need those packages too).

How to download the packages in one fell swoop? wget? Nope. Not installed. Bummer. Life is so much harder without wget.

Downloaded wget via another machine and sftp'ed it to the T2000.

Then wget gets all the packages which pckgadd installs just fine.

Next up, Apache. Remember the 1 million or so HTML pages I mentioned? They are now sitting on the T2000 waiting to be served up.

I'm looking forward to comparing performance with an old warhorse Sun Ultra that we currently use as a test server for those 1 million HTML pages.

Congrats to Bill and family

Laoise de hOra.

Just for grins : plotting daily blog hit counts

Using Google Adsense, I can get a CSV file giving me a daily breakdown of hits (to page level) on this blog.

I get this graph when I sort them by hit count:



Am I the only one who is amused by the fact that Pareto's Principle, when applied outside the field of economics, is sometimes called Bradford's Law. A law that was hatched mulling the exponentially diminishing returns of extending a library search?

Sun T2000 Niagara Noodling. Part 4.

Part 3 was here.

Turns out we left the machine room a wee bit early. ssh and telnet could both see the T2000 but we would kicked off every time we tried to log on.

Root is not allowed log on over telnet/ssh which makes a lot of sense. However, we've got quite used to Unix systems (debian, Ubuntu) creating a non-root user as part of the install. Back into the machine room to do that.

Now we can hopefully move on to the software side of things. I have a website of about 1 million static HTML pages I want to try. I also have about 300,000 OpenOffice documents I want to uptranslate to a custom XML schema. I also have a mission critical, carrier grade wireless portal that I'd like to try out on it.

More on these items anon.

Sun T2000 Niagara Noodling. Part 3.

Second part was here.

Getting the T2000 racked up was straighforward. The arms have neat clips instead of the ususal screws to lock the machine in place (i.e. stop it sliding out). Press the clips and slide out, then slide back and it locks in place. Much nicer to use than the thumbscrew approach.

Power connected, network, console cable to laptop running Windows Hyperterminal.
Press the power button (tiny - you need a pen, it even says this on the installation instructions! 'needed - one screwdriver, antistatic strap (supplied) and one ballpoint pen').

And then...Lights flash...all amber...Not good.

Turns out we were trying to fly on one power supply connection. No can do. It will not power on without the second PSU plugged into mains as well. We don't
have any redundant power (the T2000 obviously expects a better class of
machine room!), so we plugged it into a spare socket, and off it went.

The fans make a goodly amount of noise but not appreciably different from other servers in the server room (mostly Dell and HP boxes).

Following the text-based installation was straightforward up until the point where it wanted to know what name service to use. NIS+, DNS, LDAP and NONE. The machine is not yet in our DNS and it wasn't happy about the DNS choice. We chose NONE and are hoping we won't live to regret that later.

Then came root password and a reboot. Time to get out of the machine room.

Sun T2000 Niagara Noodling. Part 2.

T2000_1
Originally uploaded by PropylonSean.

First part was here.

Its all very neat and tidy under the hood. Swappable drive bays to the front.Two swappable power units to the back. RAM all lined up like so many Terra Cotta Warriors.

"Where all the CPUs?", has a new answer in these multi-core days as the CPU count diverges from the CPU chip count. Ours is a 4 CPU unit but an untrained eye cannot tell too easily by just looking at the motherboard setup.

The red cable snaking through the middle is the SATA cable and is responsible - so the hardware people tell me - for moving data at unspeakable speeds to/from the hard disks.

Programming a Picasso

"It is in this area - the algorithm - that I think Picasso would have had great fun if the circumstances of his life had been different. The reason being, I cannot think of a medium more pregnant with possibilities, more laden with powerful and beautiful abstractions, than algorithm design." - Programming a Picasso

OpenOffice Conference 2006, Lyon, France

Open Office 2006 is in Lyon, France. The Call for papers has been issued.

An *Ubuntu Home Network #5(Last)

The final step was to arrange for TinyProxy and DansGuard to run whenever the machine boots.

I added a local.start shell-script in /etc and added it to /etc/inittab, to run them (TinyProxy first) on boot.

Thats it.

Its not finished yet. I have yet to allocate a fixed IP address to the proxy and I've yet to look into avoiding any bypassing of the proxy from the EduBuntu machines.

I have to stop now though because there is a queue of people behind me to want to have a go at this broadband internet thing Daddy is so chuffed about.

An *Ubuntu Home Network #4

By default, DansGuard listens for requests on port 8080 which is fine by me. I did not need to change the configuration of DansGuard at all.

Its import to run TinyProxy *first*.

With the two running, I was able to point to port 8080 as my proxy and lo! it all worked.

Note: For reasons I don't fathom, the speed problems I was witnessing with TinyProxy just went away. If anything, adding DansGuard would add an extra layer and thus exacerbate rather than amerliorate latencies right? Not so.

I've filed that one under problems-that-disappeared-in-a-disconforting-way.

An *Ubuntu Home Network #3

I installed TinyProxy first. Its configuration file lives in /etc/tinyproxy called tinyproxy.conf.

I set it up to run as root with group root and to listen on port 3128. (The overall setup is that Firefox will use 8080 as a proxy address. DansGuard will sit on port 8080 and forward requests to TinyProxy on 3128. DansGuard will then run the rule over what it gets back from TinyProxy before deciding to allow/disallow the content to be forwarded to Firefox).

You can (and should) test the TinyProxy bit independently of adding DansGuard. It runs as a daemon by default. Use tail -f on /var/log/tinyproxy.log to watch what is going on.

Note: TinyProxy seemed to significantly slow down browsing for me. I was expecting some sort of hit but not a hit of the size I was experiencing.

I was on the cusp of the verge of the edge of the decision not to bother with the whole setup at all. Why bother if it was going to make browsing porky slow?

Luckily, I was dead tired at the time and decided just to proceed and see what would happen...

An *Ubuntu Home Network #2

I made a couple of false starts w.r.t. Dansguardian. Not seeing it in the default package repositories, I elected to compile from source. A comedy of errors ensued. I grabbed a not-completely-up-to-date tarball which doesn't compile with GCC 4. I ended up taking a long detour down a scenic but avoidable C/C++ compilation lore sideroad...

To cut a long story short, add the "community maintained" repositories to your Synaptics Package Manager and download the packages of Dansguard and TinyProxy that it provides.

Dansguard relies on an underlying proxy to do the actual fetching of stuff. Any proxy will do but Squid and TinyProxy are the most mentioned in the Googlesphere.

I elected to use TinyProxy as it is small and resource-lean. The machine I'm setting this up on would not win any prizes for speed or capacity...