Sunday, October 26, 2014

Compiling Tor on CentOS 6.5

$ yum groupinstall "Development Tools"
$ yum install libevent-devel openssl-devel
$ ./configure
$ make
$ make install

That's it. I actually started writing this when I thought it would be more complicated.

It looks like the RPM for CentOS doesn't work with NTor (the new, faster) handshakes. There's some discussion on tor-relays@ about this here.

Tuesday, October 14, 2014

CrashPlan doesn't load on Ubuntu 14.04

These instructions from CrashPlan are spot on.

I installed webkit and added a line to run.conf as they described, and everything worked fine.

Saturday, June 7, 2014

Compiling mosh-chrome on 64-bit Ubuntu 14.04

mosh-chrome is great. For me, it addresses the last major feature that's keeping me from just using a light, cheap Chromebook as my day-to-day laptop as opposed to some beautiful/grotesque beast like a Thinkpad.

Anyway, these are my notes from compiling mosh-chrome on a relatively stock 64-bit (amd64) Ubuntu 14.04 machine:

  • Install the following packages: git subversion build-essential cmake autoconf libc6:i386 libstdc++6:i386 protobuf-compiler
    (Some of these are standard dev tools, some are 32-bit packages you won't get by default with a 64-bit dev toolchain, and there's one Google-specific tool thrown in there.)
  • pod2man gives an error when attempting to compile openssl. I wrote down a nasty workaround here last night. It's ugly but it worked for me.

That's it.

Compiling openssl 1.0.1g with Perl 5.18, the terrible way

[Edit: 2014-12-28: Newer versions of pod2man don't have this problem, apparently. The openssl issue has been closed, and this works for me now without the workaround below.]

It appears that openssl 1.0.1g doesn't compile with Perl 5.18 because the 5.18 of pod2man is stricter than previous versions, resulting in lots of errors like this:

cms.pod around line 457: Expected text after =item, not a number

There are patches ([1], [2], [3], plus the link above) that deal with this, but I couldn't find one that applied cleanly against openssl 1.0.1g.

In this particular case, I'm building openssl as a prerequisite for something else and won't be installing any manpages anywhere, so I actually don't care at all about building the documentation. So instead of actually fixing this, I just blanked out all the files:

$ echo "=pod" > ./../blank.pod
$ find . -name '*.pod' -exec 'cp' './../blank.pod' '{}' \;

This seems to be the simplest thing that works without modifying the build process at all or removing files, if one can't get any of the above patches to apply.

[Edited 2014-10-06 to simplify command for blanking pod files.]

Friday, April 25, 2014

Using a Custom Window Manager in Ubuntu 14.04

I just installed Ubuntu 12.04 on my Thinkpad X1 carbon (laptop). These are my notes about using a custom window manager via .xsession files; perhaps they'll be useful to someone else, too. (Notably, this is assuming you already know everything about configuring your WM and just want to know how to do it in the latest Ubuntu.)

I chose Ubuntu because the installation on a laptop has been painless for the last 4 years (10.04, 12.04, and 14.04 LTS).

To use a custom .xsession file, create a file /usr/share/xsessions/xsession.desktop, with the following contents:

[Desktop Entry]
Encoding=UTF-8
Name=Xsession
Comment=Run ~/.xsession
Exec=/etc/X11/Xsession

This will create an option on the login page (once you've chosen a user) called "Xsession". It relies on an ~/.xsession file being present, however.

Create a file ~/.xsession. The only thing it needs to do is exec your window manager. You can, optionally, put lines before that to set up your environment. (There are plenty of tutorials online for using xsession files in general.) What I appreciate about xsession files is that they let you keep a large part of your configuration separate from your window manager.

This is the xsession file I'm using for awesome:

/usr/bin/xscreensaver -nosplash &
/usr/bin/nm-applet &
caffeine >/dev/null 2>&1 &
blueman-applet >/dev/null 2>&1 &

exec /usr/bin/awesome

You can see it starts up a few applications (using &, so they don't block!), then exec's awesome.

Now, when you log in (Ubuntu's display manager is lightdm), choose "Xsession" and you're ready to rock.

Friday, March 14, 2014

Eclipse with android dev tools freezes on startup

I've just installed the eclipse+android dev tools bundle, x86_64, version 20131030.

I've noticed that, after a few sessions, eclipse will freeze when trying to load a workspace.

The workaround is to start eclipse with the -clean argument, which I found on this StackOverflow page:

$ eclipse -clean

That is all. I'm not investing any time learning eclipse in any detail at the moment, so I won't care why it works till it stops. This is so future-me doesn't forget what the option is called.

Saturday, December 28, 2013

Sending SMS alerts when the power goes out with apcupsd and Amazon SNS or Plivo

[Edited 2014-08-09 to add mention of Plivo (and pointer to sample script), and mention the NOLOGINDIR in the default Debian config.]

This post recounts how I set up SMS alerts to tell me when the power went out in my apartment. I set it up on a Debian testing box. It's very simple. (And you get to use the cloud, whatever that is!) Note that none of this will work if your ISP's networking gear is dead too! This probably won't protect you against a widespread mains outage, unless you're on DSL, or your ISP really cares.

I haven't tested it in a real power outage yet, and I haven't tested suitability of SNS for this kind of use-case. If you care a lot about this working, go read someone else's instructions.

Building blocks:

  • An APC uninterruptible power supply that powers to your server and any networking gear the server needs. (In my case: dumb switch, and firewall. The cable modem has its own battery, inexplicably.)
  • An Amazon Web Services account. We'll be using SNS. OR, a Plivo account. (Plivo is much simpler.)
  • A phone that can receive text messages. If you're using Amazon, it must be able to receive text messages from shortcodes. (That means no Google Voice if you're using Amazon. As of 2013-12-28 I confirmed that it cannot receive text messages from Amazon's shortcode, 30304.)
  • A linux server. It needs some software:
    • The AWS CLI, if you're going to use Amazon to send notifications; OR, the plivo python module, if you're going to use Plivo to send notifications.
    • apcupsd. Note the warnings on their page about UPS compatibility. I used a Back-UPS RS 1300G and it worked fine.

Plivo vs Amazon

Plivo is much simpler to set up. However, you must rent a dedicated phone number from them for $0.80/mo (as of Aug 2014), and there is no "subscriber" model like Amazon, which means you must send text messages to each recipient individually.

It depends on what you want. I only want to message myself (1 number) when something happens, and I use Google Voice -- so Plivo is a better fit for me.

Plivo Setup

(Skip if you're using Amazon.)

No detailed instructions, but it is not complicated: go to plivo.com and sign up for a phone number.

This is the script I wrote to send text messages -- it is just a simple modification of one of Plivo's examples. I put calls to this script in the event scripts in /etc/apcupsd/: plivo-sms.py.

Amazon SNS Setup

(Skip if you're using Plivo.)

Create a new topic in SNS. Note that it is uniquely identified by a string that Amazon calls an ARN. Add an SMS subscriber, and enter your phone number. Wait for the confirmation text message on your phone, and confirm. You may wish to also add an email subscriber.

Verify: Send a notification from the SNS console, by hitting the "Publish" button.

Amazon SNS Client Setup

(Skip if you're using Plivo.)

You'll have to be able to publish to SNS from the command-line. Set up a new user by going to the Security Credentials page. Create a new user. Note the credentials amazon has generated.

Add permissions to the new user so it may publish to the SNS topic you created before.

I gave my user "Publish" permissions to all my SNS ARNs, since I'm using SNS exclusively for this exercise. You can craft these permissions in the interface by clicking on your user -> Permissions tab -> Add User Policy -> Policy Generator. You can also select Custom Policy and paste in the following policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt138826832300",
      "Effect": "Allow",
      "Action": [
        "sns:Publish"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}
Install the Amazon command-line interface. Because we'll be calling aws from apcupsd, configure aws as the root user:
# aws configure

Enter the credentials you created before. I picked the region my SNS topic is in as my default region.

Verify: Test sending a notification from the command line with aws sns publish (substitute the ARN of your SNS topic for your_arn below):

# aws sns publish --topic-arn=your_arn --message="something happened on ${HOSTNAME}"

You should get a text message!

apcupsd Setup

Install apcupsd via your package manager. Configure it for your UPS by editing /etc/apcupsd/apcupsd.conf. Two notes for Debian, (1) comment out the line "#NOLOGINDIR /etc" unless you want apcupsd to prevent logins after a power failure, and (2) you must subsequently edit /etc/default/apcupsd to set ISCONFIGURED=yes and manually start the service.

Check that it can talk to your UPS by running apcaccess.

There are interesting configuration files in /etc/apcupsd -- they define what happens on various power events. The relevant one here is /etc/apcupsd/onbattery, which is run when the UPS switches to battery power. With apcupsd 3.14.10, the file looks like this (comments stripped out):

SYSADMIN=root
APCUPSD_MAIL="mail"

HOSTNAME=`hostname`
MSG="$HOSTNAME Power Failure !!!"

(
   echo "Subject: $MSG"
   echo " "
   echo "$MSG"
   echo " "
   /sbin/apcaccess status
) | $APCUPSD_MAIL -s "$MSG" $SYSADMIN
exit 0

I edited the file to add the bold text below (again, substitute the ARN of your SNS topic for your_arn):

SYSADMIN=root
APCUPSD_MAIL="mail"

HOSTNAME=`hostname`
MSG="$HOSTNAME Power Failure !!!"

(
   echo "Subject: $MSG"
   echo " "
   echo "$MSG"
   echo " "
   /sbin/apcaccess status
) | $APCUPSD_MAIL -s "$MSG" $SYSADMIN

# either amazon SNS script or plivo script follows:
aws sns publish --topic-arn=your_arn \
        --subject="${MSG}" \
        --message="${MSG}"
# or: /path/to/plivo-sms.py "${MSG}"
exit 0

I just use the subject line because text messages must be short. I figure the hostname will give plenty of context.

(If you've set up your mail daemon so mail can send messages to non-local addresses, you may wish to change the value of SYSADMIN to your email address as well. Note that doing that and adding your email address to the SNS topic will result in duplicate emails -- one verbose, one short.)

Restart the apcupsd service.

Verify: Pull the plug of your UPS out of the wall! You should get an anxious message from apcupsd.

Final Notes

Again, none of this will work if your ISP's networking gear is dead too! This probably won't protect you against a widespread power outage.

apcupsd is by default configured to shut down the machine when the UPS' battery has 5% or 3 minutes remaining.