Category Archives: Technology

Posted on
by

The other week I wrote about a plugin I made that lets you syndicate content from a Known site to an IRC channel.

Since folk using other platforms expressed an interest, I thought I’d quickly write down how to do it for the other indieweb folk out there.

Getting started

Writing content to an IRC channel is actually pretty straightforward, I’ll get onto the specifics of what you need to do in a moment, but your first step is to collect necessary information.

At the very least you’ll need:

  • Server details: Server (e.g. irc.freenode.net), Port (e.g 6667, or better, 6697 for TLS)
  • The channel you want to post to (e.g. #indiewebcamp)
  • The nickname to use (and password if your nick is protected by nickserv)

Collect that information (or hard code it if it’s just for you), you’ll need it later.

Making a post

Posting some content to the channel after this is fairly straightforward. Obviously, if you want to persist on the channel you’ll need to start thinking about implementing a proper bot, but a single posting doesn’t need to get into that.

The basic protocol is:

  • Connect to the server on the given port, and I strongly suggest you use TLS.
  • Greet the server by sending the following: 
    USER *username* *username* bla :*username*\r\n
NICK *username*

    All the *username* bits in the first line are actually meant to be your username, fullname and nickname. For brevity, because I wasn’t writing a full client, I just used the same thing.

  • Wait for response from server. At this point the server will spit back some information about the server, and may ask you some questions. You *should* parse that intelligently, but I couldn’t be bothered, so I just wait a few seconds.
  • If you need to send a password to the nickserv, do so now: 
    PRIVMSG NickServ :IDENTIFY *username* *password*

    Wait for response (or a few seconds) as before.

  • Join your channel: 
    JOIN #channel

    and wait for response.

  • Post your message: 
    PRIVMSG *#channel* :*your message*

    and wait…

  • Quit: 
    QUIT

    and close your connection.

If you want to experiment with this before you start coding, you can connect and do the whole exchange by hand via telnet/telnet-ssl, e.g:

marcus@dushka:~$ telnet-ssl irc.freenode.net 6697
USER example example bla :example
NICK example

.... server response ....

PRIVMSG NickServ :IDENTIFY example somesecretpass

....

JOIN #indiewebcamp

....

PRIVMSG #indiewebcamp :Hello folks!

....

QUIT

Some gotchas

All in all, posting to an IRC channel is pretty straightforward, however there are a few things that can trip you up.

  • Don’t be too fast: The main issue is that if you just open the connection and splurt your commands, you likely won’t get anywhere. The server will respond, and will expect you to listen to what it says. As I said above, the best thing is to read and process this response intelligently, but you can of get away with just waiting a few seconds… obviously YMMV.
  • Nickname collisions: The above code doesn’t handle a situation where the nickname is already active on the network. I sidestep this issue by using a different username than my regular IRC handle for my syndication user, and to use nickserv to guard it. If you don’t want to take that approach you’re going to need to do something else, like parse the server response to detect the problem and present alternate nicks.

Happy syndicating!

Posted on
by

On the Indiewebcamp wiki, there’s a page discussing HTTPS, the support for which is strongly recommended. As I’ve mentioned previously, at this stage all non-encrypted communication forms (including traditional port 80 HTTP) should be considered deprecated and dangerous.

Indieweb compatible sites are encouraged to get a higher level as possible, and thanks to some prodding, I’ve finally moved both this blog and my feed over to HTTPS only, with HSTS and forward secrecy.

This got me thinking, perhaps it would be worth adding a “Level 7” (or perhaps Level 6.5) to this, and to suggest that Indieweb sites should also be made available as .onion hidden services on Tor?

Pros

  • Anonymity. Would go a large way towards protecting communication metadata (who know’s whom), which is a goal we should move towards in a world of endemic selector based surveillance.
  • Encryption. Traffic within the tor network is end to end encrypted, and there is some discussion of whether this renders HTTPS unnecessary.

Cons

  • Tor has nothing to do with HTTPS, although it is encrypted. However, the HTTPS levels page seemed a good place to put the suggestion.
  • Could be seen as endorsing one service. Tor is Free software and is pretty much the only game in town when it comes to anonymity networks, but does that constitute a silo? Probably not, but is a point for discussion.
  • No certificates for .onion. There are currently no certificate providers available for .onion domains. But, this may not be a problem.

Anyway, just mooting this as a point for discussion.

Posted on
by

I’ve previously documented how I’ve previously used Known to track system events generated by various pieces of hardware and various processes within my (and my client) infrastructure.

Like many, I use a UPS to keep my servers from uncontrolled shutdowns, and potential data loss, during the thankfully rare (but still more common than I’d like) power outages.

Both my UPS’ are made by APC, and are monitored by a small demon called apcupsd. This demon monitors the UPS and will report on its status, from obvious things like “lost power” and “power returned”, but also potentially more important things like “battery needs replacing”.

While some events do trigger an email, other messages are written to the console using the wall command, so are less useful on headless systems. Thankfully, modifying the script is fairly straightforward.

Setting up your script

First, set your script as you did for nagios. Create an account from within your Known install, and then grab its API key, then put it in a wrapping script.

#!/bin/bash

PATH=/path/to/BashKnown:"${PATH}"

status.sh https://my.status.server apc *YOURAPICODE* >/dev/null

exit 0

I need to Pee

The next step is to modify /etc/apccontrol to call your wrapper script.

I wanted to maintain the existing ‘post to wall’ functionality as well as posting to my status page. To do this, you need to replace the definition for WALL at the top of the script, and split the pipe between two executables.

To do this you need a command called pee, which is the pipe version of tee, and is available in the moreutils package on debian based systems. So, apt-get install moreutils.

Change:

WALL=wall

To:

WALL="pee 'wall' '/path/to/wrapperscript.sh'"

Testing

To test, you can run apccontrol directly, although obviously you should be careful which command you run, as some commands fire other scripts.

I tested by firing:

./apccontrol commfailure

Happy hacking!