Mit Twitter kann ich sehr leicht über meinen rbot publizieren, damit ich in der selben Frequenz auch soup.io verwende, was für spezielleren Content besser geeignet ist, muss es schon ebenfalls über den rbot funktionieren. Nach langem suchen stellte ich überrascht fest das das große Web 2.0 Projekt Soup.io keine API zum leichten publizieren(außerhalb des Browsers) besitzt. Da muss also erstmal eine art API gestrickt werden. Mit Hilfe von Mechanize baute ich die Browseranfragen nach und fasste es in einer kleinen Ruby Klasse zusammen. Es wird nicht jeder Content-Typ unterstützt aber für meine Zwecke reicht dies völlig aus. Dann noch schnell eine rbot-Plugin Klasse zum bedienen der eigenen “API” und fertig war die erste Version meines soupio-Plugins.
Hier eine Liste der möglichen Befehle(Argumente in eckigen Klammern sind Optional):

1
2
3
4
5
6
7
8
9
10
11

soup identify <username> <password> => Jeder Benutzer im Channel kann dem Bot seine 
Soup.io-Zugangsdaten im Query mitteilen.
 
soup login => Neuer Login falls die gespeicherte SessionId verloren 
oder ungültig wird. (Normalerweise nicht notwendig.)
 
soup link <url> [<title>]
soup image <url> [<description>]
soup text <text>
soup quote <source>: <quote>
soup video <youtube-url> [<description>]

Die SoupIoClass-Klasse kann übrigens auch außerhalb des Plugins, in jeder Ruby-Anwendung verwendet werden. Hier eine kleine Referenz, diesmal die optionalen Argumente in spitzen Klammern:

1
2
3
4
5
6

soup = SoupIoClass.new('[Username]', '[Password]'<, '[Domain]', '[Session-ID]'>)
soup.new_link '[URL]'<, '[Title]', '[Description]'>
soup.new_image '[URL]'<, '[Description]'>
soup.new_text '[Text]'<, '[Title]'>
soup.new_quote '[Quote]'<, '[Source]'>
soup.new_video '[Youtube-URL]'<, '[Description]'>

Die Domain und SessionId kann mit soup.sessid und soup.domain abgefragt werden. Die SessionId ist praktisch unbegrenzt lange haltbar, weshalb diese beiden Daten zwischengespeichert werden können um bei häufiger Nutzung der Klasse sich nicht ständig neu Anmelden zu müssen.

Die Version 0.1 ist bereits veröffentlicht, ich muss mich noch um die Validierung und Fehlerabfragen kümmern aber sonst sollte das Plugin schon funktionieren. Fehler bitte bei mir Melden.
Update: Version 0.2 veröffentlicht. (nur kleine Änderungen)
Update: Version 0.3 veröffentlicht. (Bugfix für eigene Domains)
Update: Version 0.4 veröffentlicht. (Änderungen an soup.io)

Ich wollte von unterwegs aus den Status meines Heimservers abrufen können. Dabei ging es mir vorallem um die Temperatur von CPU, Mainboard und den Festplatten. Der auf sixserv.org laufende rbot(im Freenode idled der in #sixserv) soll auf Kommando den Status anzeigen. Soweit so gut. Ein kleines Ruby-Skript das auf dem Server zuhause läuft erfasst die Temperaturen per “sensors” und “hddtemp”. Der xinetd-Daemon konfigurierte ich daraufhin so das auf einen Port das Skript gebunden wird. Es erwartet bevor es die Daten übermittelt ein Passwort, einfach zum zusätzlichen Schutz auch wenn das vielleicht gar nicht nötig ist. Jemand der einen Portscan durchführt könnte eben so informationen zum System gelangen, die Passwortabfrage verhindert dies.

Zunächst zu dem Ruby-Script(z.B. /opt/botinfo.rb):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#!/usr/bin/ruby
 
i = Kernel.gets
if i.chomp != 'DASGEHEIMEPASSWORT' then
	# puts 'Wrong Password'
	exit
end
 
puts `uptime`.lstrip
 
# HDD Temps:
matches = `cat /proc/partitions`.scan /([s|h]d[a-z])/
matches.uniq!
matches.each do |disk|
	print "#{disk}: #{`hddtemp -n /dev/#{disk}`.chomp}.0*C (#{$1}GB) "
end
puts 
 
systemp = `sensors`
 
temp1 = systemp.scan /CPU Temp:    \+([0-9]+)\.0.C/
temp2 = systemp.scan /M\/B Temp:    \+([0-9]+)\.0.C/
 
puts "System: #{temp2[0]}.0*C #{temp2[1]}.0*C | CPUs: #{temp1[0]}.0*C #{temp1[1]}.0*C"

Hier muss natürlich sensors und hddtemp installiert sein, aber dieses Script kann praktisch alles mögliche an Informationen sammeln und ausgeben.
Die Konfiguration von xinetd gestaltet sich sehr einfach, in dem Verzeichnis /etc/xinetd.d einfach eine neue Datei für das Script erstellen(z.B. “botinfo”):

1
2
3
4
5
6
7
8
9
10
11

service botinfo
{
    disable         = no
    port            = 8888
    socket_type     = stream
    protocol        = tcp
    wait            = no
    user            = apoc
    server          = /opt/botinfo.rb
    type            = unlisted
}

Den Port, User und den Skript Pfad entsprechend anpassen und xinetd neu starten. Mit netcat kann es man danach testen:

1
2
3
4
5

$ nc localhost 8888
DASGEHEIMEPASSWORT
18:40:35 up 3 days, 41 min,  4 users,  load average: 0.00, 0.02, 0.20
sda: 30.0*C (10GB) sdb: 29.0*C (10GB)
System: 39.0*C 38.0*C | CPUs: 37.0*C 36.0*C

Der Port muss ggf. vom Router geforwarded werden damit ein Entfernter Server darauf zugreifen kann. Auch ein dyndns ist hilfreich, sofern man über keine statische IP verfügt. Ein einfaches rbot-Plugin um diese Daten vom irc aus abzufragen sieht z.B. so aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

require 'socket'
 
class BotinfoPlugin < Plugin
  def help(plugin, topic="")
    'info => return system information'
  end
 
  def info(m, params)
    sock = TCPSocket.new('heimserver.dyndns.org', 8888)
    sock.puts('DASGEHEIMEPASSWORT')
    m.reply sock.recv(1024)
    sock.close
  end
end
plugin = BotinfoPlugin.new
plugin.map 'info'

Die Daten können ebenfalls von einem PHP-Script aus abgefragt werden. Keines Beispiel:

1
2
3
4
5
6
7
8
9

<?php
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_connect($socket, "heimserver.dyndns.org", "8888");
 
$pass = "DASGEHEIMEPASSWORT\n\n";
socket_write($socket, $pass, strlen($pass));
 
echo socket_read($socket, 2048);
?>

Vielleicht findet das ja irgendjemand interessant

Ich setze schon lange den grandiosen IRC-Bot “rbot” ein. Ein überaus vielseitiger und einfach zu erweiternder Bot, der dazu auch noch in meiner Lieblings Script-Sprache Ruby geschrieben ist. Vielleicht komme ich dazu einige meiner Plugins, die ich für ihn geschrieben habe, hier zu Veröffentlichen.

Eines der Features von rbot welches ich erst kürzlich entdeckt habe und was absolut genial ist, ist das Rbot Remote Interface. Per Default hört der Bot nämlich auf Port 7268(127.0.0.1) und stellt dort ein DRb(Distributed Ruby) Interface zur Verfügung. Dieses erlaubt es von Außen den Bot zu steuern und beispielsweise Funktionen eines Plugins auszuführen. RbotRemote kann z.B. dazu genutzt werden bei neuen SVN-Commits im RSS Plugin das Updaten eines Commit-Feeds zu starten. Denkbar ist dies natürlich auch für neue Blog-Posts innerhalb von WordPress etc.

Da DRb logischerweise nur für Ruby zur Verfügung steht muss bspw. eine PHP-Webapplikation ein Ruby-Skript starten welches die gewünschte Aktionen am rbot auslöst. Hier als Beispiel-Skript wird eine Nachricht an #sixserv(btw: im Freenode) gesendet:

#!/usr/bin/ruby
 
require 'drb'
 
rbot = DRbObject.new_with_uri("druby://localhost:7268")
id = rbot.delegate(nil, "remote login owner [Owner/Auth Passwort]")[:return]
rbot.delegate(id, "dispatch say #sixserv Hallo Welt!")

In /bin/rbot-remote gibt es ein ähnliches, etwas komplexeres Beispiel welches die Eingaben von stdin erwartet.

Eine weitere Möglichkeit ist wie schon erwähnt eine Methode eines Plugins zu starten. Hier ein ganz einfaches rbot-(Remote)Plugin:

class SimplePlugin < Plugin
  include RemotePlugin
  def sayfoo(m, params)
    @bot.say '#sixserv', 'foo'
    if params.has_key?(:bar) then
      @bot.say '#sixserv', params[:bar]
    end
  end
end
 
plugin = SimplePlugin.new
plugin.remote_map 'sayfoo'
plugin.remote_map 'sayfoo :bar'

Wird die Methode extern aufgerufen kann man natürlich kein m.reply verwenden, wenn die Nachricht im Channel landen soll, ich habe das hier ganz einfach gelöst indem ich den Channel fest eingebunden habe. Hier noch das Skript welches sayfoo mit Parameter aufruft:

#!/usr/bin/ruby
 
require 'drb'
 
rbot = DRbObject.new_with_uri("druby://localhost:7268")
id = rbot.delegate(nil, "remote login owner [Owner/Auth Passwort]")[:return]
rbot.delegate(id, "sayfoo bar")

Update: Das Plugin auf remote_map geändert, thanks for the hint tango!