Category Archives: Idno

Posted on
by

So, the other week I told you about the improvements to my access logging tool, which will now keep a user by user track of account activity.

This tool also makes a call to a GeoIP lookup hook, but until now remained unanswered. So, I wrote a quick tool that implements this GeoIP lookup hook using PHP’s built in geoip functions.

Once installed and configured (and the appropriate GeoIP database set up), this plugin will respond to any geoip/lookup event requests by looking up ['ip' => '....'] and returning the a country.

If installed along side LoginSyslog, you should start seeing the country listed along side the IP address!

» Visit the project on Github...

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!

Posted on
by

Every page on a Known site can potentially be an API endpoint, which means that pretty much everything you can do with the interface, you can write a script or client to connect to.

As things are still being built out there are no libraries, or indeed detailed instructions, out there yet (although you might want to look at some of my sample code) so I’ve been fielding a bunch of questions from folk.

Overview

At its simplest level, all pages on a Known site are API endpoints.

When you post a status update, the form you fill in POSTs the form fields to the API endpoint /status/edit. So, if you were to write a client to do this, you’d send the same variables to the same endpoint, but you’ll also have to do a couple of extra things as well.

Authentication

In order to access restricted content, or to post to your stream, you will need to authenticate yourself. There is currently only one built in way to do this, however Known supports extensible authentication methods, so it is of course possible to hook in other methods.

For example, if you don’t want to use the built signed HTTP request method, you could use an OAuth2 server.

  • Get your API Key: from your Tools and Apps page.
  • Generate a signature: You need to generate a base64 encoded HMAC, which is a SHA256 digest of the path of the api (i.e. if you’re using “`https://yoursite.com/status/edit“`, your path should be “`/status/edit“`) using your API key as the key.

    From the shell:

    HMAC=$(echo -n "/status/edit" | openssl dgst -binary -sha256 -hmac '***APIKEY***' |  base64 -w0)

    In PHP:

    base64_encode(hash_hmac('sha256', "/status/edit", $api_key', true));
  • Sign your HTTP requests by sending the following HTTP headers: 
    X-KNOWN-USERNAME: 
X-KNOWN-SIGNATURE:
  • Tell Known you want the API to return a machine understandable response by sending the following header: 
    Accept: application/json

Some points to remember…

  • Remember to follow forwards: Known makes use of forwards, for example when creating a post, you’ll be forwarded to the completed object. So, you need to tell cURL (if that’s what you’re using) to follow forwards CURLOPT_FOLLOWLOCATION
  • Create a cookie jar: In order to preserve your session, and to avoid getting 403 errors after a successful post, you’ll need to store your cookies. Again, if you’re using cURL you can do this by passing the CURLOPT_COOKIEJAR option.

Hope this helps!