Normalerweise sind die Artikel hier ja ziemlich umfangreich, was ja auch gut ist schließlich geht das Sixserv Blog ja schon sehr ins technische Detail. Doch diesmal wird es eher kurz, ich möchte eine kleine Logger Klasse vorstellen die ich in Ruby geschrieben habe und seither häufiger benutze.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

class Logger
  def self.init
    @logfile = LOG_FILE
    @buffer = [] # logging lines for buffering
  end
 
  def self.<< msg
    msg = format msg
 
    # append message to buffer
    @buffer << msg
 
    # flush the buffer if possible
    self.flush
  end
 
  def self.flush
    return if @buffer.empty?
 
    # try to lock the file for writing
    log = File.new(@logfile, 'a+')
 
    if log.flock(File::LOCK_EX | File::LOCK_NB) == false
      # Logfile is locked
      puts "Logfile is locked!"
      log.close
      return false
    end
 
    # ==> not locked, write buffer to logfile
    while @buffer.length > 0
      log.puts @buffer.shift
    end
 
    log.flock(File::LOCK_UN)
    log.close
  end
 
  private
  def self.format msg
    time = Time.now.strftime '%H:%M:%S - %d.%m.%Y'
    "[#{time}] #{msg}"
  end
end

Nichts großes also, es gibt z.B. keine Log-Level usw. Außerdem kann man sich, wenn man etwas mehr Features braucht, auch eine Logging Bibliothek aus dem Gems bedienen. Die Anwendung ist ganz einfach:

1
2
3
4
5
6
7
8

require '/pfad/zu/logger.rb'
Logger.init
# das kann man dann überall im Code verteilen:
Logger << "Irgendeine Nachricht!"
# hat man eine große Anwendung mit vielen Prozessen/Threads
# kann man auch an strategischen Stellen ein
Logger.flush
# einbauen :)

Hier noch eine kleine Erweiterung die einen Log-Server implementiert. Er öffnet einen TCP Port, jeder der sich verbindet(z.B. per Telnet/Netcat) kann daraufhin die Log-Nachrichten mitlesen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73

class Logger
  def self.init
    ...
    @port = LOG_PORT
    @query = []
    @query_mutex = nil
    @running = false
    @server = nil
  end
 
  def self.start_server
    @query_mutex = Mutex.new
    puts "Start logging console @ #{LOG_HOST}:#{LOG_PORT}"
 
    @server = TCPServer.new(LOG_HOST, LOG_PORT)
    clients = []
    @running = true
    Thread.start do
      client = []
      while @running do
        begin
          client = @server.accept_nonblock
          clients << client if client != nil
        rescue
        end
 
        begin
          message = nil
          @query_mutex.synchronize { message = @query.pop }
          if message != nil
            clients.each do |client|
                begin
                    client.puts message
                rescue
                    clients.delete client
                end 
            end
          end
        end while not @query.empty?
        sleep LOG_SERVER_INTERVAL
      end
      clients.each { |client| client.close }
      @server.close
      @server = nil
    end
  end
 
  def self.destroy
    @running = false
    @fs.close
 
    # wait until server closed
    true while @server != nil
  end
 
  def self.<< msg
    if @query_mutex != nil
      @query_mutex.synchronize do
        @query << format(msg)
      end
    end
    puts ">>> #{msg}"
  end  
 
  def self.flush
    # just wait until everything is sent/written
    if @query.length > 0
      true while @query.length != 0
    end
  end
 
  ...
end

So das wars schon, ich hoffe das ich das mit dem Mutex richtig gemacht habe und das hier überhaupt notwendig war, ich habe auf dem Gebiet nicht viel Erfahrung und würde mich über einen entsprechenden Kommentar freuen.
// I’m not sure I used the Mutex in this example correctly, I would appreciate a comment about this.

Praktisch jede Interaktion mit einer Website oder Webapplikation kann gescriptet, d.h. automatisiert werden. Das Abgrasen von Webseiten nach bestimmten Informationen wird auch als Scraping bezeichnet(für die nicht menschlichen Besucher dieser Seite sei das erwähnt *g*) Scripte können einem eine ganze Menge Arbeit abnehmen und sogar Dinge tun, die manuell unmöglich wären. Ich beschäftige mich mit dem Thema schon seit einer ganzen Weile und möchte hier nun die von mir favorisierte Methode dafür vorstellen, die Bibliothek Mechanize für die Scriptsprache Ruby.

Mechanize hat seinen Ursprung in Perl, mittlerweile gibt es jedoch auch Implementierungen der API für Python und eben Ruby. Für PHP gibt es mit Snoopy ein ähnliches Projekt, wenn es auch bei weitem nicht so fortgeschritten ist. Mechanize bietet die Möglichkeit mit einfachen Methoden eine art Webbrowser zu simulieren. Alle Beispiele wurden mit Mechanize Version 0.9.2 und Ruby 1.8.7 getestet.

Installation / Initialisierung

Mechanize kann mit Gems(ähnlich CPAN oder PEAR) installiert werden(# gem install mechanize --remote), einige Distributionen bieten aber auch eigene Pakete an. Ein Ruby-Script kann daraufhin Mechanize inkludieren und ein Objekt erstellen:

require 'rubygems' # ist unter Umständen notwendig
require 'mechanize'
agent = WWW::Mechanize.new

Jetzt ist Mechanize einsatzbereit, die folgenden Beispiele bauen darauf auf. Außerdem können mit dem agent nun noch grundlegende Einstellungen vorgenommen werden:

agent.set_proxy('localhost', '8000')
agent.user_agent = 'Individueller User-Agent'
agent.user_agent_alias = 'Linux Mozilla'

Die Einstellung ‘user_agent_alias‘ wählt einen User-Agent String aus dem folgenden Satz von Beispielen aus: Windows IE 6, Windows IE 7, Windows Mozilla, Mac Safari, Mac FireFox, Mac Mozilla, Linux Mozilla, Linux Konqueror, iPhone und Mechanize. Die Timing Einstellungen können ebenfalls sehr wichtig sein:

agent.open_timeout = 3 # setzt timeouts
agent.read_timeout = 4
agent.keep_alive = false # default ist true

Hier folgen nun einige Beispiele, vielleicht werde ich mit der Zeit auch noch ein paar ergänzen, falls jemand Vorschläge hat, immer her damit. Ich habe auf http://apoc.sixserv.org/requestinfo ein kleines Skript am laufen das nützliche Informationen zum HTTP-Request liefert, das kann zum Experimentieren mit Mechanize sehr nützlich sein. Einige Beispiele findet man auch in den GUIDE und EXAMPLES Dateien des Mechanize Pakets.

#01 – Manuelle Get Requests

url = 'http://apoc.sixserv.org/requestinfo/'
page = agent.get url # einfacher get request
# parameter können auch als Hash mitgeliefert werden:
page = agent.get(url, {"name" => "value", "key" => "val"})

#02 – Manuelle Post Requests

url = 'http://apoc.sixserv.org/requestinfo/'
page = agent.post(url, {"name" => "value", "key" => "val"})

In diesem Fall werden die Post-Daten manuell erzeugt, häufig ist es jedoch besser das eigentliche Formular zu verwenden. z.B. ein Login oder Suchformular:

#03 – Post Requests(/Submits) aus Formular erzeugen

page = agent.get 'https://twitter.com/login'
login_form = page.form_with(:action => 'https://twitter.com/sessions')
login_form['session[username_or_email]'] = '[Username]'
login_form['session[password]'] = '[Password]'
page = agent.submit login_form

Dieses kleine Beispiel loggt sich bei Twitter ein.

#04 – Navigation über Links und der History

page = agent.get 'http://www.heise.de/'
page = agent.click(page.link_with(:text => /Telepolis/))
page = agent.click(page.link_with(:href => /artikel/))
agent.back
agent.back
puts page.body

#05 – Exceptions

Wird z.B. eine nicht vorhandene Seite aufgerufen, wirft Mechanize eine Exception, diese sollte Abgefangen werden da das Skript sonst an dieser Stelle abbricht.

begin
  page = agent.get 'http://apoc.sixserv.org/diese/seite/gibt/es/nicht/'
rescue WWW::Mechanize::ResponseCodeError
  puts "ResponseCodeError - Code: #{$!}"
end

#06 – Referer

Mechanize benutzt seine Navigations-History auch zum senden eines passenden Referers, diesen kann man allerdings auch manuell bestimmen, hier für GET und POST Requests:

page = agent.get(:url => 'http://apoc.sixserv.org/requestinfo/',
:referer => 'http://google.com/this/is/a/custom/referer')
puts page.body

#07 – Headers / HEAD / Redirect

Der Request Header kann manuell erweitert werden, bspw. den “X-Requested-With” so zu setzen um einen Ajax-Aufruf zu simulieren. Es gibt leider keine wirklich gute Möglichkeit eigene Header zu setzen, das ganze wurde in den vergangenen Versionen oft geändert, die folgende Methode funktioniert mit älteren Versionen von Mechanize nicht.

agent.pre_connect_hooks << lambda do |params|
  params[:request]['X-Requested-With'] = 'XMLHttpRequest'
end

Dies ist übrigens auch die einzig wirklich einfache Möglichkeit manuell Cookies zu setzen/ zu übertragen. Die andere Seite, also das Abfragen des Response-Headers ist trivial, hier wird z.B. per HEAD-Request die Server und evtl. der PHP-Version abgefragt:

page = agent.head 'http://sixserv.org'
server_version = page.header['server']
puts "Server: #{server_version}"
if page.header.key? 'x-powered-by'
  php_version = page.header['x-powered-by']
  puts "X-Powered-By: #{php_version}"
end

Will man einen HTTP-Redirect(302) abfragen, muss man zunächst das automatische Weiterleiten im Mechanize deaktivieren, dann kann man den Zielort abfragen ohne das Ziel zu besuchen. (Nützlich z.B. wenn man auf einen Datei-Download weitergeleitet wird)

agent.redirect_ok = false
page = agent.get 'http://www.sixserv.org/' # leitet auf http://sixserv.org weiter
puts page.header['location']

#08 – Threads

Will man ein Script etwas beschleunigen kann man mit Threads arbeiten um mehrere Inhalte gleichzeitig abzufragen. Das folgende Grundgerüst für z.B. Foren mit vielen Seiten, bearbeitet 10 Seiten gleichzeitig und kann so ein Skript erheblich beschleunigen. In diesem Fall würde man allerdings wahrscheinlich eher nicht Mechanize einsetzen sondern eine Low-Level API fürs Netzwerk-Zugriff, das wäre deutlich effektiver ich will nur das Prinzip deutlich machen.

$threads = 0
last_page = 200
max_threads = 10
for page in 1..last_page
  Thread.new(page) do |page|
    $threads += 1
    puts " [*] Create new Thread for scanning Page ##{page}"
 
    page = $agent.get "http://example.com/datalist.php?page=#{page}"
 
    # process / save received data
 
    puts " [*] Destroy Thread"
    $threads -= 1
  end
  while $threads > max_threads
  end
  puts " [*] Next Page"
end

#09 – Parsing / XPath

Hat man eine Seite empfangen und will bestimmte Inhalte herausfiltern gibt es mehrere Möglichkeiten, meistens werden mehr oder weniger umfangreiche Reguläre Ausdrücke zum parsen verwendet:

page = agent.get 'http://example.com/'
page.body.match /< h3>([^<]+)< \/h3>/
puts "Überschrift 3: #{$1}"

Wesentlich stabiler sind jedoch XPath Ausdrücke die sich direkt auf die Struktur eines XML-Dokuments beziehen. Werden nur Kleinigkeiten am HTML-Code geändert sind RegEx’s häuft aufgeschmissen und müssen mühsam angepasst werden, XPath ausdrücke dagegen funktionieren häufig auch dann noch. Eine Einführung gibt es z.B. auf w3schools.com oder der offizielle Standard der W3C. Allerdings geht das alles auch sehr einfach mit entsprechenden Werkzeugen, so gibt es z.B. eine Menge Firefox-Addons(nützlich ist z.B. der XPath Checker) die einem, zu markierten Elementen einer Seite einen passenden XPath Ausdruck anzeigt oder umgekehrt, wenn auch die nur einfachen Ausdrücke gelegentlich Nachbearbeitung erfordern.

Firebug kann einem zu beliebigen Elementen einer Seite einen passenden XPath(Rot unterstrichen) anzeigen.

Der von Mechanize verwendete HTML-Parser Nokogiri(鋸) ist sehr robust und kann auch “kaputtes” HTML parsen, was XPath zu einem auserordentlich mächtigen Werkzeug macht, um jede beliebige Information aus noch so komplexen Seiten zu extrahieren.

Mit Firebug: Ein beliebiges Element auf einer Seite markieren und im Kontextmenü, “Inspect Element” aufrufen. In der oberen Zeile von Firebug(siehe Screenshot) kann im Kontextmenü mit “Copy XPath” der XPath geholt werden. Im Beispiel wird der XPath zum Comic-Strip auf XKCD angezeigt: /html/body/div/div[2]/div/div[2]/div/div/img In Mechanize kann so der IMG-Tag extrahiert werden:

page = agent.get 'http://xkcd.com/'
img = page.search '/html/body/div/div[2]/div/div[2]/div/div/img'
puts img
# Ausgabe: < img src="http://imgs.xkcd.com/comics/designated_drivers.png" title="Calling a cab means cutting into beer money." alt="Designated Drivers" >

Das wars damit vorerst. Anmerkungen oder Fragen zu den Beispielen oder Ideen für weitere, bitte in den Kommentaren hinterlassen.

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!