© solstizia, 123RF

Die Webanwendung Huginn holt Informationen und Daten von Webseiten, bereitet diese auf und verschickt sie gebündelt per E-Mail an einen Nutzer. Zudem führt sie bei bestimmten Ereignissen automatisch vorgegebene Aktionen aus. Die kleine IFTTT-Alternative einzurichten erfordert aber einige Handarbeit.

“Auf Twitter gab es gestern ungewöhnlich viele Beiträge zur Netzneutralität, der in der Nacht veröffentlichte neue XKCD-Comic beschäftigt sich mit Drohnen und das Wetter wird heute regnerisch.” Die etwas wirr klingende kurze Zusammenfassung stammt von Huginn [1]. Die Webanwendung beobachtet kontinuierlich mehrere vom Anwender vorgegebene Websites und Internetdienste. Aus den dort veröffentlichten Informationen erstellt sie eine Zusammenfassung, die sie dem Benutzer per E-Mail an den Frühstückstisch sendet.

In seinem Bericht verweist Huginn unter anderem auf eine hohe Regenwahrscheinlichkeit für den eigenen Wohnort oder schlägt Alarm, wenn es auf Twitter viele Beiträge zu einem Begriff wie Netzneutralität gibt. Ähnlich wie der Internetdienst IFTTT [2] löst Huginn bei bestimmten Events automatisch Aktionen aus. Etwa wenn sich der Text auf einer News-Seite ändert oder der Onlineshop das begehrte Notebook im Preis senkt. Auch bei IoT-Projekten macht es sich nützlich. Die Nutzer bedienen es bis auf wenige Ausnahmen per Webinterface.

Anspruchsvoll

Huginn steht unter der MIT-Lizenz und läuft auf dem Server des Anwenders. Der sollte mindestens über 2 GByte RAM und einen Dualcore-Prozessor verfügen. Wer Huginn auf einem schwachen Rechner wie dem Raspberry Pi betreiben möchte, sollte den Tatendrang der Software über die Konfiguration zügeln. Die dazu nötigen Umbauten erklärt ein Eintrag im Huginn-Wiki [3].

Die Software basiert auf Ruby on Rails [4] und setzt folglich eine installierte Ruby-Umgebung voraus, wobei sie die Referenzimplementierung in der Version 2.2 oder 2.3 braucht. Mit den alternativen Ruby-Implementierungen J-Ruby und Rubinius kann sie hingegen nichts anfangen.

Huginns gesammelte Daten landen in einer MySQL- oder PostgreSQL-Datenbank. Das Webinterface liefert Nginx [5] aus. Auch mit dem Apache-Server soll es aber problemlos kooperieren [6]. Einen reibungslosen Betrieb garantieren die Entwickler nur unter Debian 7 und 8 sowie Ubuntu 14.04 und 16.04. Prinzipiell gelingt die Installation auch auf anderen Linux-Distributionen sowie unter OS X und Free BSD.

docker run -it -p 3000:3000 huginn/huginn

docker run -it -p 3000:3000 -v /home/huginn/mysql-data:/var/lib/mysql huginn/huginn

Das Installieren von Huginn erfordert etwas Arbeit. Unter Ubuntu 16.04 existiert zudem eine fiese Stolperfalle: Huginn verlangt nach Runit. Das schlummert zwar in den Repositories, setzt aber Upstart als Initsystem voraus, das Canonical durch Systemd ersetzt hat. Daher meldet Ubuntu 16.04 beim Installieren von Runit einen Fehler.

Wer dennoch Ubuntu 16.04 einsetzen möchte, übersetzt Runit daher selbst oder ignoriert die entsprechende Fehlermeldung. Im Test lief Runit dennoch fehlerfrei. Huginn streikt übrigens auch unter dem aktuellen Ubuntu 17.04. Dort stürzt das Tool Foreman beim Erstellen der Initskripte reproduzierbar ab. Reibungslos lief Huginn am Ende nur unter Ubuntu 14.04 und Debian 8 (Jessie).

Paketdienst

Debian-Nutzer melden sich zunächst als Benutzer »root« an und holen das Kommandozeilentool »sudo« nach, das es gleich erlaubt, einige Befehle unter einem anderen Nutzerkonto auszuführen:

su root
apt install sudo

In jedem Fall brauchen sie einen Texteditor, im Folgenden Nano. Mit den Befehlen aus Listing 1 holen sie alle benötigten Abhängigkeiten nach.

01 sudo apt update
02 sudo apt upgrade
03 sudo apt install runit build-essential git zlib1g-dev libyaml-dev libssl-dev libgdbm-dev libreadline-dev libncurses5-dev libffi-dev curl openssh-server checkinstall libxml2-dev libxslt-dev libcurl4-openssl-dev libicu-dev logrotate python-docutils pkg-config cmake nodejs graphviz

Huginn setzt neben Ruby noch die Hilfsprogramme Bundler, Rake und Foreman voraus. Unter Ubuntu 16.04 spielt der folgende Befehl die Bande ein:

sudo apt install ruby2.3 ruby-bundler ruby-foreman ruby2.3-dev rake

Debian 8 und Ubuntu 14.04 bieten in ihren Repositories nur Ruby 2.1 beziehungsweise 2.0 an. Die User übersetzen hier Ruby und seine geforderten Hilfstools aus dem Quellcode, was die Befehle aus Listing 2 erledigen. Der Schritt bürdet ihnen aber auch die Verantwortung auf, Ruby aktualisieren zu müssen. Die Befehle aus Listing 2 erstellen ein temporäres Verzeichnis, holen den Quellcode des zu Redaktionsschluss aktuellen Ruby 2.3.4, übersetzen ihn und installieren die Ruby-Umgebung. Der letzte Befehl holt noch Rake, Bundler und Foreman.

01 mkdir /tmp/ruby && cd /tmp/ruby
02 curl -L --progress http://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.4.tar.bz2 | tar xj
03 cd ruby-2.3.4
04 ./configure --disable-install-rdoc
05 make -j`nproc`
06 sudo make install
07 sudo gem install rake bundler foreman --no-ri --no-rdoc

Huginn unterstützt keine Versionsverwaltungen wie RVM, Rbenv oder Chruby. Wer sie dennoch verwendet, muss im Betrieb mit schwer zu identifizierenden Problemen rechnen.

Huginn besteht aus der erwähnten Weboberfläche sowie einem zugehörigen Hintergrunddienst, der die Informationen abholt. Über

sudo adduser --disabled-login --gecos  'Huginn' huginn

erzeugt der Admin zur Sicherheit ein Konto für einen Benutzer »huginn«.

Lagerhalle

Die nächste fehlende Zutat ist die Datenbank. MySQL holt der folgende Befehl auf den Rechner:

sudo apt install -y mysql-server mysql-client libmysqlclient-dev

MySQL kennt einen allmächtigen Datenbankbenutzer namens »root«, der alle Stellschrauben der Datenbank verändern kann. Während der Installation von MySQL sollte sich der Installateur für diesen Benutzer ein möglichst gutes Passwort ausdenken und es zweimal nacheinander eintippen. Sind die MySQL-Pakete eingespielt, setzt er diesen Befehl ab:

sudo mysql_secure_installation

Das dabei startende Skript sichert nach ein paar Rückfragen die Datenbank etwas ab. Nach der Eingabe des Passworts für den MySQL-Benutzer »root«, verneint der Anwender die erste Frage nach der Passwortänderung mit »n«. Alle anderen Fragen bestätigt er hingegen mit »y«. Ist das Skript fertig, muss er Huginn den Zugriff auf MySQL gestatten. Das geschieht über den Kommandozeilen-Client von MySQL, den folgender Befehl weckt:

mysql -u root -p

Die Anmeldung erfolgt wieder mit dem Passwort des MySQL-Benutzers »root«. Am Prompt setzt er jetzt die Befehle aus Listing 3 ab. Sie erstellen in MySQL für Huginn ein Benutzerkonto, wählen Inno DB als Storage-Engine und erlauben Huginn den Zugriff auf eine Datenbank namens »huginn_production«. Das geheim im ersten Befehl ersetzt der User durch ein eigenes, möglichst schwer zu erratendes Passwort. Ob MySQL das neue Benutzerkonto korrekt erstellt hat, überprüft der folgende Befehl:

sudo -u huginn -H mysql -u huginn -p -D  huginn_production

Wer das Passwort des Benutzers Huginn eintippt (hier geheim), sollte nun die Fehlermeldung »ERROR 1049« (Unknown Database) sehen. Andernfalls ist das Anlegen des Nutzers schiefgelaufen.

01 CREATE USER 'huginn'@'localhost' IDENTIFIED BY 'geheim';
02 SET default_storage_engine=INNODB;
03 GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, LOCK TABLES ON `huginn_production`.* TO 'huginn'@'localhost';
04 exit

Huginn holen

Läuft die Datenbank, holt sich der Betreiber mit folgenden Befehlen als Benutzer »huginn« den Quellcode der Software in das entsprechende Homeverzeichnis:

cd /home/huginn
sudo -u huginn -H git clone https://github. com/cantino/huginn.git -b master huginn

Die Huginn-Entwickler veröffentlichen keine stabilen Versionen, sondern stellen auf Github stets nur den aktuellen Quellcode bereit (im so genannten Master Branch). Der obige zweite Befehl lädt daher automatisch immer die aktuelle Huginn-Version herunter.

01 cd huginn
02 sudo -u huginn -H cp .env.example .env
03 sudo -u huginn -H cp config/unicorn.rb.example config/unicorn.rb
04 sudo -u huginn mkdir -p log tmp/pids tmp/sockets
05 sudo chown -R huginn log/ tmp/
06 sudo chmod -R u+rwX,go-w log/ tmp/
07 sudo chmod -R u+rwX,go-w log/
08 sudo chmod -R u+rwX tmp/
09 sudo -u huginn -H chmod o-rwx .env

Gleich zwei mitgelieferte Beispiel-Konfigurationsdateien vereinfachen das Einrichten. Es genügt, wenn der Admin sie einfach an die passende Stelle kopiert, die dazu nötigen Befehle zeigt Listing 4. Sie legen zugleich noch einige von Huginn benötigte Unterverzeichnisse an – unter anderem für die Logs – und justieren dann die Zugriffsrechte. Der Befehl

sudo -u huginn -H bundle install  --deployment --without development test

spielt abschließend alle von Huginn benötigten Zusatzpakete für Ruby ein (die so genannten Gems).

Stelldichein

Ist die Installationsorgie abgefeiert, geht es an die Konfiguration von Huginn. Dazu ermittelt der Nutzer zunächst die Versionsnummer von MySQL via »mysql –version«. Im Hinterkopf merkt er sich, ob die angezeigte Nummer größer oder gleich 5.5.3 ist. Als Nächstes ruft er »sudo -u huginn -H rake secret« auf. Dieser Befehl liefert am Ende eine lange kryptische Zeichenkette, die er in die Zwischenablage kopiert oder abschreibt. Jetzt öffnet er als Benutzer »huginn« die Konfigurationsdatei ».env« in einem Texteditor:

sudo -u huginn -H nano .env

Am Anfang der Datei tauscht er zunächst »REPLACE_ME_NOW!« gegen die Ausgabe von »sudo -u huginn -H rake secret« aus. Im Abschnitt »Database Setup« ersetzt er zudem die Zeile

DATABASE_NAME=huginn_development

durch:

DATABASE_NAME=huginn_production

Des Weiteren tauscht der Huginn-Betreiber noch »DATABASE_USERNAME=root« durch »DATABASE_USERNAME=huginn«. Rechts neben »DATABASE_PASSWORD=« hinterlegt er zwischen Hochkommata das Passwort, mit dem sich der Benutzer Huginn bei MySQL anmeldet. Im Beispiel heißt es geheim.

Sofern die verwendete MySQL-Version mindestens in der Versionsnummer 5.5.3 vorliegt, ersetzt er noch

DATABASE_ENCODING=utf8

durch:

DATABASE_ENCODING=utf8mb4

Das Ergebnis sollte wie in Abbildung 1 aussehen. Im unteren Bereich der Konfigurationsdatei entfernt er das vorangestellte Hash-Symbol »#« in der Zeile »# RAILS_ENV=production«.

Abbildung 1: Mit diesen Einstellungen erhält Huginn Zugriff auf die Datenbank »huginn_production«.

Damit Huginn eine E-Mail verschicken kann, muss der User die Zugangsdaten für einen SMTP-Server hinterlegen. Dazu sucht er im unteren Teil der Konfigurationsdateien den Abschnitt »Email Configuration«. Dort deponiert er hinter »SMTP_SERVER=« den Domainnamen eines SMTP-Servers, der Port steht hinter »SMTP_PORT=«.

Braucht er zum Anmelden am SMTP-Server einen Benutzernamen und ein Passwort, trägt er das passende Duo hinter »SMTP_USER_NAME=« und »SMTP_PASSWORD=« ein. Gegebenenfalls passt er die Authentifizierungsmethode hinter »SMTP_AUTHENTICATION=« und die Verschlüsselung hinter »SMTP_ENABLE_STARTTLS_AUTO=« an. Die Kommentare über den Einstellungen liefern weitere Hilfen. Abschließend hinterlegt er hinter »EMAIL_FROM_ADRESS=« noch die Absenderadresse.

In Nano speichert die Tastenkombination [Strg][O] die Änderungen, [Strg][X] bringt den Nutzer zur Kommandozeile zurück. Dort richtet er im nächsten Schritt die Datenbank mit den Befehlen aus Listing 5 ein. Der erste legt die Datenbank an, der zweite bringt sie auf den aktuellen Stand. Damit er sich gleich in der Weboberfläche bei Huginn anmelden kann, richtet schließlich der dritte Befehl einen Benutzer namens »admin« mit dem Passwort »supergeheim« ein. Der letzte Befehl aus Listing 5 bereitet alle von der Weboberfläche benötigten Dateien vor, darunter Javascript-Code.

01 sudo -u huginn -H bundle exec rake db:create RAILS_ENV=production
02 sudo -u huginn -H bundle exec rake db:migrate RAILS_ENV=production
03 sudo -u huginn -H bundle exec rake db:seed RAILS_ENV=production SEED_USERNAME=admin SEED_PASSWORD=supergeheim
04 sudo -u huginn -H bundle exec rake assets:precompile RAILS_ENV=production

Sollte der erste Befehl eine Fehlermeldung ausspucken oder das Passwort des MySQL-Benutzers »root« verlangen, stimmen in der Konfigurationsdatei ».env« die Zugangsdaten nicht. Der Admin sollte dann kontrollieren, ob hinter »DATABASE_PASSWORD=« das korrekte Passwort in Hochkommata steht (und nicht in Anführungszeichen).

Initskripte

Im nächsten Schritt muss der Admin ein paar Initskripte erzeugen. Dazu knöpft er sich zunächst mit »sudo -u huginn -H nano Procfile« die Konfigurationsdatei »Procfile« vor. In ihr setzt er ganz oben vor die folgenden beiden Zeilen jeweils ein Hash-Zeichen »#«:

web: bundle exec rails server -p ${PORT-3000} -b ${IP-0.0.0.0}
jobs: bundle exec rails runner bin/threaded.rb

Umgekehrt entfernt er im unteren Abschnitt »PRODUCTION« die Hash-Zeichen vor den beiden Zeilen:

# web: bundle exec unicorn -c config/ unicorn.rb
# jobs: bundle exec rails runner bin/threaded.rb

Nach dem Speichern der Datei lässt er die Skripte erstellen, richtet Logrotate ein und prüft, ob Huginn läuft:

sudo bundle exec rake production:export
sudo cp deployment/logrotate/huginn /etc/logrotate.d/huginn
sudo bundle exec rake production:status

Will er nachträglich eine der Huginn-Konfigurationsdateien ».env«, »unicorn.rb« oder »Procfile« ändern, muss er die Initskripte via »sudo bundle exec rake production:export« neu erzeugen.

Nginx liefert die Weboberfläche aus. Immerhin liegen Huginn bereits ein paar fertige Konfigurationsdateien bei, die der Betreiber dem Webserver nur unterschieben muss. Damit reduziert sich die Installation auf drei Befehle aus Listing 6. Ist Huginn die einzige von Nginx ausgelieferte Website, deaktiviert der vierte Befehl die Standard-Nginx-Seite.

01 sudo apt install nginx
02 sudo cp deployment/nginx/huginn /etc/nginx/sites-available/huginn
03 sudo ln -s /etc/nginx/sites-available/huginn /etc/nginx/sites-enabled/huginn
04 sudo rm /etc/nginx/sites-enabled/default

Eine kleine Einstellung in der Konfigurationsdatei von Nginx fehlt doch noch:

sudo nano /etc/nginx/sites-available/huginn

Dort ersetzt der Admin den Platzhalter »YOUR_SERVER_FQDN« durch den Domainnamen des Rechners, auf dem Huginn läuft. Im Zweifelsfall oder auf einem Testsystem ist das meist »localhost«. In jedem Fall sollte er darauf achten, dass ein Semikolon die Zeile abschließt. Nach dem Speichern prüft »sudo nginx -t« die Konfigurationsdatei auf Tippfehler. Sofern alles stimmt, startet er Nginx über »sudo service nginx restart« neu.

Klickibunti

Das schließt die Installation endlich ab. Huginn und Nginx starten künftig automatisch mit dem System. Um Huginn zu steuern, ruft der Admin es im Browser auf. Läuft es auf demselben System, tippt er »localhost« in die URL-Leiste und sollte in jedem Fall die Seite aus Abbildung 2 sehen. Die Anmeldung erfolgt hinter »Login« mit dem Benutzernamen »admin« und dem Passwort »supergeheim«. In der Benutzeroberfläche sollte der Anwender zunächst unter »Account | Account« das Passwort ändern und eine korrekte E-Mail-Adresse hinterlegen. An diese verschickt Huginn später auch die Zusammenfassung.

Abbildung 2: Wenn die Installation von Huginn geklappt hat, erscheint diese Seite.

Agenten sammeln und verarbeiten in Huginn die Daten der Websites. Der User verwaltet sie über den Menüpunkt »Agents« (Abbildung 3). Der Agent »XKCD Source« etwa schaut regelmäßig nach, ob es einen neuen XKCD-Comic gibt, während der »Afternoon-Digest«-Agent jeden Abend eine E-Mail an den Anwender verschickt. Die Pfeile in der ersten Spalte zeigen an, ob der Agent Daten abholt (Pfeil nach links) oder Daten herausgibt (Pfeil nach rechts). Bei einem Doppelpfeil nimmt der Agent nicht nur Daten entgegen, sondern gibt auch welche aus.

Abbildung 3: Nach dem Installieren hält Huginn bereits sieben Beispielagenten parat.

Die Spalte »Schedule« verrät, wann der Agent tätig wird. Wichtig ist zudem die Spalte »Working?«: Nur bei einem grünen »Yes« ist der Agent überhaupt aktiv. Manuell starten lässt er sich über das Menü hinter »Actions« via »Run«.

Holt ein Agent Daten ab, erzeugt er ein Event. Dabei handelt es sich in der Regel um die eingesammelten Rohdaten – im Beispiel unter anderem den Titel und die Beschreibung des aktuellen XKCD-Comics. Sämtliche Events listet der gleichnamige Menüpunkt auf (Abbildung 4). Die Liste ist anfangs leer, zeigt später aber via »Show« den Inhalt des jeweiligen Events und somit die eingesammelten Informationen an.

Abbildung 4: Jeder Agent erzeugt ein oder mehrere Ereignisse, das macht die Liste mitunter etwas lang.

Die Events dienen anderen Agenten als Datenquelle. So konvertiert der »Comic Formatter«, der unter anderem die Überschrift des Comics in HTML-Tags verpackt, die von »XKCD Source« abgeholten Informationen. Da er auf die Ereignisse von »XKCD Source« wartet, verarbeitet er die gelieferten Daten automatisch. Reagiert er einmal nicht auf ein Ereignis, verschickt der Anwender in der Liste unter »Events« ein Ereignis via »Re-emit« erneut. Welcher Agent seine Daten an welchen Kollegen weiterreicht, verrät das Diagramm hinter »Agents | View Diagramm« (Abbildung 5).

Abbildung 5: Der Agent »XKCD Source« gibt die Beschreibung des XKCD-Comics an den »Comic Formatter« weiter, der den Text hübsch formatiert an den E-Mail-Agenten »Afternoon Digest« übergibt.

Weil bei sehr vielen Agenten mitunter die Übersicht leidet, gruppiert Huginn sie. Die Gruppen bezeichnet Huginn als Scenarios. So versammelt Huginn alle Agenten, die Twitter anzapfen, in einem Scenario namens »Twitter«, während die Agenten im zweiten Scenario »Wetter« Wetterdaten aufbereiten. Der Anwender entscheidet frei, wie viele Szenarios er einrichtet und wie er die Agenten darauf verteilt. Die vorhandenen Szenarios listet der Menüpunkt »Scenarios« auf. Von Hause aus bringt Huginn ein Standardszenario namens »default-scenario« mit. Ein Klick auf ein Szenario zeigt die enthaltenen Agenten an, »New Scenario« legt ein neues an. Wer die Szenarios als zu kompliziert empfindet, ignoriert sie einfach.

Kollegen für 007

Einen neuen Agenten erstellen Anwender über »Agents | New Agent«. Unter »Type« entscheiden sie, welche Daten der Agent abholen oder weiterverarbeiten soll. Neben spezialisierten Agenten, die zum Beispiel auf Twitter zugreifen, gibt es auch allgemein einsetzbare Agenten. So schneidet etwa der »Website Agent« einen Text aus einer beliebigen Internetseite heraus, während der »Rss-Feed«-Agent einen Newsfeed anzapft. Den passenden Typ für eine gewünschte Aktion zu finden, ist nicht ganz einfach, da Huginn die Liste nicht alphabetisch sortiert. Über das Eingabefeld sucht der User nach dem Namen oder der Tätigkeit des anvisierten Dienstes.

Nach der Auswahl eines Typs erscheint im grauen Kasten eine Beschreibung des Agenten (Abbildung 6). Auf der linken Seite erhält der im entsprechenden Feld zunächst einen Namen. »Schedule« legt fest, wann oder in welchen Intervallen der Agent seine Arbeit verrichtet. Die erzeugten Ereignisse merkt sich Huginn für immer. Erzeugt der Agent viele Ereignisse, kann das schnell den verfügbaren Plattenplatz auslasten. Daher löscht der Agent ältere Ereignisse bei Bedarf wieder. Wann dies geschieht, bestimmt die Einstellung unter »Keep events«. Die dort vorgegebene Zeit sollte der Admin nicht zu kurz wählen, da nur so die anderen Agenten eine Chance erhalten, die Ereignisse weiterzuverarbeiten.

Abbildung 6: Hier entsteht ein Agent, der den RSS-Feed von Linux-Magazin Online anzapft.

Übernimmt der Agent die Daten eines Kollegen, gibt der Admin diesen als Datenquelle unter »Sources« an. Analog gehören unter »Receiver« jene Kollegen, denen der Agent Daten übergibt.

Um einen Agenten auszuwählen, klickt er in einen freien Bereich des Eingabefeldes und wählt einen passenden. Die Liste bietet ausschließlich bereits existierende Agenten an. Wer sie um weitere Agenten als Quelle oder Empfänger ergänzen möchte, klickt erneut in einen leeren Bereich des Eingabefelds. Über das X neben seinem Namen entfernt der Admin einen Agenten. Nach dem gleichen Prinzip wählt er unter »Scenarios« das gewünschte Szenario – im Zweifel einfach nur »default-scenario«.

Die Einstellungen unter »Options« hängen vom jeweiligen Agenten ab. Zapft dieser beispielsweise einen RSS-Feed an, gehört in das Feld »url« die Internetadresse des Feeds. Um eine Einstellung zu ändern, klickt der Nutzer einfach auf ihren Wert. Die Bedeutung der einzelnen Einstellungen erläutert der Text im grauen Kasten auf der rechten Seite. Dort finden sich mitunter noch weitere Einstellungen, die über die in »Options« hinausgehen. In diesem Fall fügt der Huginn-Betreiber dort über das kleine Plus-Symbol eine neue Einstellung hinzu. »Dry Run« prüft schließlich, ob der Agent wie gewünscht funktioniert.

Abbildung 7: Wer hinter »Agents« den Namen eines Agenten anklickt, erhält einen Überblick über all seine Einstellungen und die erzeugten Events.

Das erzeugte Ereignis erscheint in einem neuen Fenster. In ihm sammelt das Register »Log« eventuell auftretende Fehler. Passt alles, legt ein Klick auf »Save« den Agenten endgültig an. Geht trotz Trockenlauf etwas schief, arbeitet der Admin nach, indem er nachträglich »Agents« auswählt (Abbildung 7) und in der Zeile des Agenten unter »Actions« den Punkt »Edit Agent« wählt.

Durchreiche

Nicht nur die vom RSS-Agenten erzeugten Ereignisse enthalten meist unformatierte Rohdaten. Sie aufzuarbeiten verspricht der »Event Formatting Agent«. Der muss aber zunächst lernen, wie die Ereignisse des anderen Agenten aussehen, die er aufhübschen soll. Das gelingt in der Liste hinter »Events« und über den beschriebenen »Dry Run«. Den letzten stößt der experimentierfreudige Admin über »Agents« mit einem Klick auf den »Actions«-Button jederzeit erneut an. Der »Rss Agent« produziert zum Beispiel für jede Meldung im RSS-Feed ein Ereignis wie das aus Listing 7.

01 [...]
02 {
03         [...]
04         "url": "https://www.linux-magazin.de/NEWS/Gartner-Weltweite-Serververkaeufe-sinken",
05         "links": [
06         {
07                 "href": "https://www.linux-magazin.de/NEWS/Gartner-Weltweite-Serververkaeufe-sinken"
08         }
09         ],
10         "title": "Gartner: Weltweite Serververkäufe sinken",
11         "content": "        <p>\n\tLaut Gartner wurden im ersten Quartal 2017 weltweit wieder weniger Server verkauft als im Vorjahr. Gegen den Trend konnten zwei chinesische Hersteller die Zahl ihrer verkauften Einheiten deutlich steigern.    <\/p>",
12         [...]
13 }
14 [...]

Mit diesem Wissen im Hinterkopf bastelt sich der Admin einen neuen »Event Formatting Agent«. Als »Source« dient im Beispiel der RSS-Feed-Agent. Die Informationen aus dem RSS-Feed sollen dann formatiert in der allabendlichen E-Mail auftauchen.

Als »Receiver« wäre damit der »Afternoon Digest«-Agent genau der Richtige. Der Event Formatting Agent gibt später den in den »Options« neben »message« hinterlegten Text aus. In diesen Text baut der Admin die Informationen aus dem Event über Platzhalter ein. Der letzte heißt dabei so, wie im Event die entsprechende Information, wobei er diesen Namen noch in doppelt geschweiften Klammern einrahmen muss.

Im Beispiel würde der Agent den Platzhalter »{{title}}« gegen den Text »Gartner: Weltweite Serververkäufe sinken« eintauschen. Hinterlegt der Admin also neben »message« den Text »Linux-Magazin meldet: {{title}}.«, so enthält die allabendlich verschickte E-Mail den Text »Linux-Magazin meldet: Gartner: Weltweite Serververkäufe sinken«.

Nach dem erfolgreichen Anlegen des Agenten sollte der Admin anschließend noch sicherstellen, dass der »Rss-Feed«-Agent seine Daten exklusiv an den Event Formatting Agent liefert. Sind mehrere Agenten miteinander verknüpft, dauert es eine Weile, bis Huginn sie aktiviert hat. Standardmäßig leitet die Software die Events im Minutentakt weiter.

Nach dem gleichen Prinzip richtet der Admin beliebige weitere Agenten ein und verkettet diese miteinander. Als nützlich erweist sich dabei vor allem der so genannte Trigger-Agent. Dieser führt eine frei wählbare Aktion aus, sobald ein vom Benutzer vorgegebenes Ereignis eintritt. Neben dem Morning und Afternoon Digest gibt es zudem noch einige weitere interessante Receiver. Zum Beispiel startet der Shell Command Agent einen Kommandozeilenbefehl, während der Twitter Publish Agent bei Bedarf einen Tweet absetzt.

Einige Agenten funktionieren allerdings nur, wenn der Admin zuvor die begleitende Konfigurationsdatei ».env« anpasst. Dazu zählen beispielsweise alle Twitter-Agenten: Um sie in Betrieb zu nehmen, muss er zunächst bei Twitter eine neue App anmelden. Die dann erhaltenen Zugangsdaten gehören in die Datei ».env« hinter »TWITTER_OAUTH_KEY=« und »TWITTER_OAUTH_SECRET=«. Wer Ruby beherrscht, kann übrigens die vorhandenen Agenten um eigene, maßgeschneiderte ergänzen [9].

Fazit

Für das Installieren und Einrichten von Huginn sollte der Nutzer Zeit einplanen. Die “Dokumentation” ist ein recht lückenhaftes und teilweise veraltetes Wiki [10]. Läuft die Software aber, aggregiert sie zuverlässig Informationen und stößt Aktionen an. Obendrein bleiben die Daten auf dem eigenen Server.