509. Very briefly: Send remote commands via the dropbox folder

This is probably fairly obvious to most people.

I've got a reverse ssh tunnel set up so that I can access my work computer from home. However, for the past few days I've had the connection get stuffed up on a regular basis (it doesn't get dropped, but the connection gets refused), and it frustrates me a little bit.

While a proper ssh connection is unbeatable, I would at least be able to copy files back and forth via dropbox if I only had a way of sending commands to my work computer.

And an obvious way of doing that would be to use a cronjob and a tiny bit of bash scripting. So here we go:
While we don't have to (we could just have an empty script file instead) I like the idea of testing for the presence of a specific file in the Dropbox folder, and if it exists, execute it.

Let's call the file that tests for it runremote.sh, and put it in our home folder (~/). I personally suspect that making sure that execution output and error messages get properly logged is a good thing if you're going to fly blind like this, hence the 1> and 2>

runremote.sh

if [ -e ~/Dropbox/runme.sh ]; then
    sh ~/Dropbox/runme.sh 1>> ~/Dropbox/runme.log 2>> ~/Dropbox/runme.error &
fi

Then when you want something executed, put a file called runme.sh in ~/Dropbox:

pwd
echo 'Is it working?'
cp ~/testfile.text ~/Dropbox
date

Note that any command in runme.sh is going to be run in the ~/ folder -- not in ~/Dropbox.

And set the runremote.sh file to be executed e.g. every five minutes through cron:

crontab -e

*/5 * * * * sh ~/runremote.sh

Again, you don't need to have it test for the presence of a file, but I just instinctively like the idea.

Anyway, any command you put in ~/Dropbox/runme.sh should be executed and logged within five minutes from being synced.

You CAN use sudo (echo mypassword| sudo -S ls /root )as well by providing your password in the script file, but this is obviously not terribly safe.

508. Very, very briefly: why apt-get purge exists (anecdote)

Sometimes my brain and I fall out, and we refuse to communicate. Yesterday was a day like that.

Having put my TV computer back together again (see post), I realised that I hadn't installed conky or guake on it. So I did. Having edited my default conky.conf (a bit like the one in this post) to change eth0 to eth1, I was wondering why my wireless card wasn't showing up in the ifconfig -a output. lspci showed that I had a broadcom chip, so I installed broadcom-sta-dkms. Nothing much happened, so I rebooted. And...no network card whatsoever recognised (including the ethernet one).

Face palm. I don't have a wireless pci/pci-e card on that computer. I should know -- I had just rebuilt it...

Oh well. apt-get autoremove broadcom-sta-dkms. Nothing. Reboot. Still no eth card -- also, the eth card was obviously the broadcom one (broadcom 4401). But why wasn't it working? I had uninstalled the broadcom package after all.

A bit of googling suggested loading b44 so modprobe b44 it was. Still nothing. Then a thought hit me -- ls /etc/modprobe.d/*blacklist*

And yes -- the broadcom package had installed a broadcom-wl-blacklist.conf file in /etc/modprobe.d -- and b44 was blacklisted. At this point I could either edited the file and comment out b44, delete the file entirely or purge the package and everything would be back to normal. So I did.

So remember: just because you uninstall a package (apt-get autoremove) doesn't mean that you've restore your system to the state it was before you installed the package. To at least have a chance of restoring it you need to purge your package so that settings files are removed too (apt-get purge).

507. (re)assembling a Dell C521 -- pictures

I finally got around to getting a new (well, refurbished) power supply for my old Dell C521. While the PSU worked fine, on trying to shut down the computer before it booted linux I managed to get the power button stuck. As it turns out, it's not that easy to access things on the front panel on this particular model...

So I took everything apart. EVERYTHING. Except for removing the front panel, ironically. If this post has a lesson for anyone else it's that you shouldn't be afraid to attack (gently) your desktop with a screwdriver. Computers ain't magic.

Anyway, here are some pictures from me reassembling it. For most people it will probably be more useful to look at these pictures in reverse.

Empty case. The arrow indicates where the screws for the panel go. I forget to attach them the first time I reassembled the case...

The plastic bits go to the lights on the front panel

The arrow indicates the front button thingy which I had to attack (gently) with a screw driver to get the power button to release.

The power button. Not sure why I took a picture of it, but there you go.

Front panel screws.

The (very dusty) fan swings out in the direction shown by the arrow. Because of this, you must remove the mobo before removing the fan, which you need to remove in order to remove the front panel. Not a very good design.

The mobo gets stuck in the fabric, so you might need to poke it with a narrow plastic pen or something like that in order to get it to release when removing it. Lift up this side and then slide out the mobo when dismantling.

Another odd design feature -- the heatsink must (more or less) be removed in order to reach the front panel. Also, the CPU is in dire need of a clean and some thermal paste.

The heatsink is now attached -- the plastic bit funnels the airflow from the fan at the front across the heat sink.

The PSU is now in place, but not connected

The P1 main power connector

ATX12V (labelled p2 here) in place

The HDD in place

The CD/DVD ROM in place

PCI and PCI-E in place (and nvidia graphics card and a DTV 1000S tv card)

And it's back in one piece.