sixserv blog

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.

Tagged: Development, logging, Ruby, snippets

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. Read the rest of this entry »

Tagged: Development, mechanize, Networking, Ruby

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)

Tagged: bot, Development, irc, plugin, RBot, Ruby, soup.io, web2.0

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

Tagged: hddtemp, irc, Linux, Networking, PHP, plugin, RBot, Ruby, sensors, xinetd

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!

Tagged: bot, drb, irc, plugin, RBot, Ruby