MythBox: Connection to mythtv host 127.0.0.1 failed

The system setup:
MythTV backend running on a separate machine (e.g. 192.168.1.4)
XBMC MythBox plugin running on a separate computer (e.g. 192.168.1.5)

This error occurs during MythBox setup, stating the following after MySQL credentials are entered: Connection to mythtv host 127.0.0.1 failed: (10061..

This can be a plain MySQL error, but it can also be an error where the MySQL connection is successful but MythBox is referred back to 127.0.0.1 when it tries to connect (by settings on the mythtv backend system).

Checklist:
– Ensure that the MySQL user can connect remotely. To test this from another computer:

$ mysql -h 192.168.1.4 -u mythtv -p

If not working, check MySQL permissions for the mythtv user (make sure the host field for the user is ‘%’) and look at my.cnf (find the file with `locate my.cnf`).

From the mythtv backend:
$ mysql -u root -p
mysql> use mysql;
mysql> select * from user where user = 'mythtv';

* If MySQL is working, ensure that the MythTV backend is setup properly.

Summary:
Run mythtv-setup
Go General -> IP Address
Set both IP addresses to the external IP of the machine you are connecting to from XBMC (setting only Local Backend to an external address did not work).

References: http://wiki.xbmc.org/?title=MythTV#Setup_in_MythTV

KDE 4: Turning off desktop switch via scroll wheel

There seems to be an kerfuffle with the layout of KDE settings. The option for this is not in the main ‘System Settings,’ but in another area entirely, named ‘Desktop Settings,’ which can be found by going to:

(From the desktop)

Right click -> Desktop Settings -> Mouse Actions

Click the minus sign by Middle-Scroll to delete it. Then click Apply.

Enabling webGL with Fedora 16

In Fedora 16, detection of WebGL fails for some reason (I haven’t looked into this too throughly).

What worked for me was to visit (in Google Chrome):

chrome://flags

I then enabled “Override software rendering list” and clicked the restart button at the bottom left.

WebGL worked without a hitch (i’m using a Sapphire ATI 6850 graphics card if it matters).

Increasing the size of a LUKS cryptfs partition

Warning: This guide assumes that the partition you’re expanding into is adjacent to a pool of free space. Things get a bit trickier if that isn’t the case (re-arranging your partitions is probably necessary).

The system that I performed this on: Fedora 16 KDE install, on a 120GB SSD installation (migrated from an 80GB SSD using Acronis True Image). Fedora doesn’t set encryption up via LVM in the installer, seemingly opting for a plain vanilla container.

Step 0: Boot into a live CD environment. I used a Fedora 16 KDE respin CD which had all these tools. Open a console (in KDE this was `konsole`).

Step 1: Blow away the partition itself. You’ll need to do this with `fdisk`. Make a new partition, with the cluster of free space included. Select Linux for type when prompted (usually 82 OR 83). Write changes to disk.

Step 2: Open your crypted filesystem:

# Replace /dev/sda2 with your own filesystem

# cryptsetup luksOpen /dev/sda2 root 

Step 3: Expand the crypted FS

# cryptsetup resize root

# e2fsck -f /dev/mapper/root

# resize2fs -p /dev/mapper/root

Step 4: Safety hat

# cryptsetup luksClose root

# sync; sync; reboot

Increasing the size of a LUKS cryptfs partition

Warning: This guide assumes that the partition you’re expanding into is adjacent to a pool of free space. Things get a bit trickier if that isn’t the case (re-arranging your partitions is probably necessary).

The system that I performed this on: Fedora 16 KDE install, on a 120GB SSD installation (migrated from an 80GB SSD using Acronis True Image). Fedora doesn’t set encryption up via LVM in the installer, seemingly opting for a plain vanilla container.

Step 0: Boot into a live CD environment. I used a Fedora 16 KDE respin CD which had all these tools. Open a console (in KDE this was `konsole`).

Step 1: Blow away the partition itself. You’ll need to do this with `fdisk`. Make a new partition, with the cluster of free space included. Select Linux for type when prompted (usually 82 OR 83). Write changes to disk.

Step 2: Open your crypted filesystem:

<code>

# Replace /dev/sda2 with your own filesystem

# cryptsetup luksOpen /dev/sda2 root 

</code>

Step 3: Expand the crypted FS

<code>

# cryptsetup resize root

# e2fsck -f /dev/mapper/root

# resize2fs -p /dev/mapper/root

</code>

Step 4: Safety hat

<code>

# cryptsetup luksClose root

# sync; sync; reboot

</code>

A plan against planning

I was most recently part of an organized gaming match among thirty-two players. Two days before, a meeting was called to carefully lay out which directions groups would go, and how everything would be built, stacked, and executed. Almost down to dotting the little ‘i’.

As you, the reader would know, this plan went completely out the window as soon as virtual feet hit the virtual pavement. My team ‘won’, but the only plan that followed was common sense among people who knew what to do.

Weddings and other big events work in similar ways with similar dynamics. Plans only serve to answer questions of how things should be done if one does not know how.

These are things that happen in the course of execution like where the groom and bride should stand, or where the place settings on the table should go.

It is only by natural circumstance that the groom doesn’t completely run in circles while walking down the isle (although I presume that some have).

Plans are in essence part-way of being a hindrance. Nothing ever really goes to plan, and some things should never be planned (unless they are so obscure of an idea that they should be — such as building blueprints for instance).

The best that one can do with a plan of any sort is to control chaos. Almost always however, it is better to just allow people to train people to react, in a boolean logic sort of way.

A nice example of this is in a concert. A concert is a collection of people working all at once to play out a common piece of music. It is a very refined form of chaos. Players are given sheet music, and told what to play, how to play it, and when to play it by a conductor.

A concert is a great form of how planning should work; the players are (usually) not told how their breathing should work, and what the best position for their fingers are. Quite simply, they know all the little things, and how to adjust their actions to fit in with the big picture.

This type of training falls out of the scope of any general plan, but these people are simply better known as folks that can ‘do it on the spot’, either because they have prior training, or instinctively know how something should be done properly.

People who can adapt and adjust quickly to align themselves with the plan (“play some sheet music”, “defeat the other team”) are the ones that make any plan successful. Those who try to plan excessively instead of allowing people to adapt on the spot risk diluting the original plan (the more important message).

The more important thing is that it risks alienating the people in the plan, who may feel that they know how to, for instance, hold a football while catching a pass. The prime message of the plan is lost.

Thus a complicated plan is never a solution to a complicated problem. Practice helps greatly, but is no substitute for having people around with great sense of what they already need to do, and how to react when the time is right.

If you can’t find people that can adapt, it is probably better to just train them, or toss them, but it should never be okay to treat them as programmable robots. It is both a waste of your time, and theirs.

Team Fortress 2 Demo: Unknown command “demopauseafterinit”

Sometimes this error can pop up due to a corrupt file, or changes in the TF2 version. If you know that isn’t the case (the TF2 version is the same, etc), it is possible that the Demo Editor is causing problems.

Delete the .vdm files in the same folder as your demo. You’ll lose your edits, but the video will be playable again.

Including one package in a yum repository

Yum can be surprisingly simple and frustrating at once. To add only one package from a repository you can do the following.

In the yum configuration file for the repository (normally this is /etc/yum.repos.d/$repository.repo).

[rpm_repository_something]
includepkgs=vlc

You can also glob to include all packages of that type, such as:

includepkgs=vlc*

Save the file, and search/install new packages. Yum will only see packages of “vlc” and nothing else.

If you are looking to do the opposite, the keyword is `exclude`. To exclude all rpms from a repository for instance:

exclude=*

Don’t add both exclude and includepkgs together without careful consideration.

Pushing forward

With the Arduino movement fully underway and unlikely to lose steam, there is something to be said about how the world was before it.

Revolutionary ideas take things that were once hard and distill them into safe, guided, and easy experiences.

Some of the more experienced scoff at projects like Arduino because at the core, they eat into hard knowledge bought with time. A computer scientist might be a bit miffed if tomorrow they would be somewhat replaced by clever self-optimizing algorithms (pending the submission of a million dollar proof, of course).

Before Arduino, building an AVR breakout board from a knowledge base of zero would have required knowing even beginning electronics lingo (by asking such inane questions like: “what is ground?”) to finally making the selection of AVR over PIC, ARM, FPGAs and otherwise.

A beginner doesn’t really need to understand the innate difference between a crystal and a resonator (the crystal has better quality), or why one is needed in the first place (its used as a sort of heartbeat for microchips).

This is often why hard problems remain hard, and why few people tackle them. Smart (and rich) people remove irrelevancies like these.

Good projects that change the world have this embedded in them as a core value (distilling hard problems) and have become wildly successful because they pander to the masses, and not exclusively to the experts.

Ubuntu for instance, became synonymous with “Linux” on several forums because it was a great entry-level distribution.

Ruby on Rails for quite some time has been the de-facto web framework, and arguably ushered in MVC as a mainstream way of doing web development. Its framework and “opinionated” way of doing things made web development less boilerplate and more manageable.

Knocking down barriers is something that can be done with nearly all that is hard in every field: Mathematics, Biology, Teaching, and Engineering.

While brain ‘trusts’ are nice and elite, drawing many smart people to a field and having them stay is more valuable to society as a whole.

Here is to the next framework, or hard problem solver that makes a massive splashdown on a problem once ruled solely by experts. Things can only get more interesting as people figure out how to craftily exploit making hard things easy. Because problems only get more interesting.

opsview and notifications

To send a notification to an external party in opsview (3.13.1) there are a few things to do:

1. Attach keywords in the host configuration to that particular host (unique no, spaces, special characters, underscores are okay).
2. Setup a new role (with the NOTIFYSOME permission, which is vaguely documented) + check off the ‘all’ box in the keywords permission section.
3. Add a contact with an e-mail address.
4. Add a notification profile attached to that e-mail address, with specific keywords to notify on checked off.
5. In the keywords section, click to flag all services with the specified keyword (otherwise no notifications will appear).

For the lazies (which means pretty much every systems administrator out there) there is, (thankfully) a *full* REST API with JSON built into opsview (unlike some of the other Nagios derivatives). More on that later hopefully.