I just learned the hard way that you can't run multiple Eucalyptus cloud controllers on the same network.

I'd assumed that as long as each cloud had a different private address pool and physically separate cluster networks that it would work.

After about a day, the primary cloud starts detecting the secondary cloud and things went a bit haywire. The primary cloud controller crashed but left the instances still running.

Rebooting things didn't get much better either - the nodes just didn't work right. Not quite sure what the deal was but nodes would show available, but all instances would just stick at "starting" and never fully reach a running state. Checking "euca_conf --show-nodes" resulted in no instances showing associated with any nodes.

I had to power down the new test cloud and de-register it's cluster controller from the primary cloud (which magically registered itself) and a reboot or two later was able to get my primary cloud back up and running.

To clarify - I wasn't trying to run multiple clusters, but wanted a completely separate cloud with it's own clusters. For future reference: do it on a separate subnet.

When you talk about desktop security there's a lot that can be discussed: user permissions, firewalls, etc. Here's a little step that gets overlooked quite a bit, but can go a long way to preventing a direct attack against your destkops.

In Ubuntu Desktop, you can deploy custom Gnome settings that override the defaults by dropping an XML file at:
/etc/gconf/gconf.xml.mandatory/%gconf-tree.xml

I use Puppet to deploy these settings to all of my Linux desktops. If you're from the Windows world, this is like using group policy, but with much more granular control.

Here's a sample of a few things you should change:

I've often stated that Linux is no harder to use than Windows for the average Joe. I think now I've proved my point.

We've been slowly converting desktops in our organization to Linux for the past year and a half. About 2 months ago, I switched over four more desktops in our production area.

The employees don't get a choice in the matter - we just do it. We provide zero training in Linux. We simply have a network PXE install that automatically installs the software they need for work and places the icon for it on their desktop named in such a way that they would recognize it. One day they have Windows, the next day they come into work and Linux is there with a note on their keyboard telling them they've been switched.

We use Ubuntu 10.04 LTS with Gnome, and allow the default environment to have the menu bar at the top of the screen. I do automatically push out a change to the desktops that places the window close button back on the right side of the screen for their first login so they aren't completely confused.

Now to the point...

I just walked through the production area and noticed that those four desktops now had custom wallpapers, screensavers and in one case even had the menu bar at the bottom of the desktop.

When your database applications start to reach multiple terabytes (that's really big for you novices, really small for fortune 500) it becomes harder to get the database performance out of a traditional database without laying out some serious cash.

We do exceptionally well with the distributed appliance model we built on top of MySQL, but as we continue to grow I'm always keeping an ear to the ground listening for the next big train.

Enter NoSQL

NoSQL is a concept more than a database. In fact it has nothing to do with the database that is actually named "nosql" which really is a relational database. The concept with NoSQL databases is that they are not your traditional database, instead storing things in key / hash pairs. Many of them are built around Apache Lucene, a text search engine.

Continuing my "avoid the console" series, I'm going to cover remotely managing partitions on a Linux server. Yes, this will involve a bit of console, but this will set you on a path to using GUI tools on your servers without having to install a complete windowing environment. Installing a complete desktop-like environment is a waste of resources for most servers, so keeping things to a minimum helps to streamline and allow your servers to do more things with less hardware.

A lot of new Linux users don't realize it, but a Linux desktop has both a "server" and a "client" for drawing things on the screen. This allows you to separate the program's interface from the machine it's running on and display it remotely.

The most powerful way to remotely manage Linux servers is using the SSH (Secure SHell.) It's like a DOS prompt for your server that you can use securely and remotely. The beauty is that if set up properly, it can tunnel a windowed program through that connection to display on your local desktop. Just don't get confused as to what is running where.

For the average joe computer user, if you ask them to "open a console" on their computer they'll stare at you dumbly. For the uninitiated the "console" is the Linux equivalent (loosly) of the "command prompt" or "dos prompt".

So, I just don't understand why it is that a lot of Linux sites and magazines (yes, I'm talking to you, Linux Journal!) insist on forcing the console on everyone for tasks that are just as easy to do without it. Yes, it's nice to know how, and there certainly needs to be a way to find out more about the console, but I firmly believe the console should be reserved for power users and not try to force it on everyone.

Don't get me wrong - I'm not really dissing on Linux Journal. It's a great magazine and it's really targeted more towards the power users like me who will use the console on a daily basis even if you show us a GUI (Graphical User Interface - something everyone has been using since before 1995) that is 10x faster for most people. It's just that the Linux Journal articles recently got me thinking about Linux broadscale desktop adoption.

Perspective

Anyone else see anything wrong with this screenshot?

Yeah, weird, huh? For some reason it was reporting my disk usage as a NEGATIVE number. I've never seen that before. I found it because ZoneMinder had stopped recording for some reason - it thought I was out of hard disk space when in actuality there's very little drive used. A quick reboot fixed the problem. Lucky for me there's nothing important on this box - it's simply for zoneminder and watching Hulu or streaming my MythTV recordings to my bedroom. I think this happened after our power spike and outage the other day. This particular PC isn't on a UPS.

Well, it seems they still haven't made any progress at making the Compiz graphics effects work on a multi-GPU setup, but you can run two X screens each using two monitors and keep the Compiz effects. If you want to grab and drag windows across all four monitors, you lose the cool graphics effects.

Here's what it might look like though using four monitors of three different sizes using xinerama without Compiz on Ubuntu Lucid 10.04 with two nVidia cards, each driving two monitors:

I decided it was time to place a PXE boot install image on my network for installing Ubuntu 10.04 Lucid desktops. For the most part everything went as expected (see this post) but during the install I got an error that "restricted/binary-amd64/Packages was corrupt".

It turns out there are no restricted packages on the alternate installer image, and the lack of an empty "Packages" file at "/dists/lucid/restricted/binary-amd64" where the networked install image is located was causing it to bomb.

Simply doing

touch Packages

in that shared directory within the install image seems to have fixed the issue. For some reason the fact that the Packages.gz ungzips into a zero byte file was throwing it, but having an already existing zero byte file seemed to fix it.

You've heard of community developed software. What about community developed advertising?