Schlagwort-Archive: Hochschule

Jetzt wird’s ernst!

Der Tag der Abreise rückt näher: Am Donnerstag fliegen wir nach Tokio und unsere Weltreise geht los. Wir sind leicht nervös.

Die beste Nachbarin der Welt wird sich während unserer Abwesenheit um unsere Meerschweinchen (Ein stetiger Quell der Freude!) kümmern und hat jetzt schon für uns Streu und Heu eingekauft.

Derweil war Andreas in Kiel, mit unserem Freund Florian, der an der dortigen Fachhochschule Lehrbeauftragter ist, im Computermuseum und fand es echt gut!

Die Reisevorbereitungen sind in vollem Gange und inzwischen ist schon vieles vorausgeplant. Kanada hat sich als ausgesprochen teuer erwiesen. Für Neuseeland sieht es momentan so aus, dass wir wohl auf der Nordinsel bleiben, da es auf Südinsel zu dieser Jahreszeit kalt und verregnet sein wird und außerdem der Coastal Pacific nicht fährt.

Im Datenbanken-Teil sind wir bei der Umsetzung vom Entity-Relationship-Modell ins relationale Modell, also in Tabellen, angelangt. Das ist in diesem Blogeintrag von Andreas erklärt. Kurz gefasst: Aus Entitätstypen werden Tabellen, die Attribute werden zu Spalten. Für jede Tabellen sollte es einen Identifier geben, einen Primärschlüssel. Wenn sich kein Attribut dafür anbietet, nimmt man einen künstlichen Schlüssel, den man vom DBMS generieren lässt. 1:N-Beziehungen können mit einer zusätzlichen Spalte, einem Fremdschlüssel, in der Tabelle auf der N-Seite umgesetzt werden.

Für die Spalten muss man Datentypen festlegen. Wichtige Datentypen in SQL sind:

INTEGER – Ganzzahlen
NUMERIC(n,m), DECIMAL(n,m) – Dezimalzahlen mit Längenangabe (Stellen insgesamt, Nachkommastellen)
FLOAT(n), DOUBLE, REAL – Gleitkommazahlen (ist oftmals keine gute Idee, mehr dazu später)
CHARACTER(n), VARCHAR(n) – Zeichenketten (mit Längenangabe)
DATE, TIME, DATETIME, TIMESTAMP – Datum und Uhrzeit
CLOB, BLOB – große Texte, große Daten
BOOLEAN – wahr/falsch

Und hier ist, was Anke während der Aufnahme als Übung mit MySQL gemacht hat:

mysql> create database todo;
Query OK, 1 row affected (0,43 sec)


mysql> use todo;
Database changed

mysql> create table Person (IdentifierPerson integer primary key auto_increment, Name varchar(20) not null, Nachname varchar(30) not null);
Query OK, 0 rows affected (0,44 sec)

mysql> create table Todoeintrag (IdentifierTodoeintrag integer primary key auto_increment, Text varchar(200) not null, Prioritaet integer, Faelligkeitsdatum date, IdentifierPerson integer not null, Foreign key (IdentifierPerson) references Person(IdentifierPerson));
Query OK, 0 rows affected (0,09 sec)

mysql> insert into Person values (null, "Andreas", "Hess");
Query OK, 1 row affected (0,12 sec)


mysql> select * from Person;
+------------------+---------+----------+
| IdentifierPerson | Name    | Nachname |
+------------------+---------+----------+
|                1 | Andreas | Hess     |
+------------------+---------+----------+
1 row in set (0,03 sec)

mysql> insert into Todoeintrag values (null, "Handgepäck packen", 10, "2019-04-10", 1);
Query OK, 1 row affected (0,04 sec)


mysql> select * from Todoeintrag;
+-----------------------+--------------------+------------+-------------------+------------------+
| IdentifierTodoeintrag | Text               | Prioritaet | Faelligkeitsdatum | IdentifierPerson |
+-----------------------+--------------------+------------+-------------------+------------------+
|                     1 | Handgepäck packen  |         10 | 2019-04-10        |                1 |
+-----------------------+--------------------+------------+-------------------+------------------+
1 row in set (0,00 sec)


mysql> insert into Todoeintrag values (null, "Handgepäck packen", 10, "2019-04-10", 5);
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`todo`.`todoeintrag`, CONSTRAINT `todoeintrag_ibfk_1` FOREIGN KEY (`IdentifierPerson`) REFERENCES `person` (`identifierperson`))

Dienstreisen

Anke und Andreas berichten von Dienstreisen nach Dublin und Leipzig. Andreas ist dabei viel mit Straßenbahnen gefahren. Da kommen bestimmt noch ein paar Bilder davon ins Blog.

Auch was die Reisevorbereitungen angeht hat sich einiges getan. Anke hat ein System eingeführt, das für jeden Wochentag eine kleine Tasche vorsieht. Die Bildungsreise nach Japan wurde abgesagt, wir organisieren jetzt selbst. Anke will die Haseninsel in der Nähe von Hiroshima besuchen.

Im Datenbanken-Teil erklärt Andreas das Entity-Relationship-Modell. Da hat er auch schon mal was drüber gebloggt. Wer also ein Entity-Relationship-Diagramm auch mal sehen will, sollte sich diesen Artikel mal zu Gemüte führen. Das E/R-Diagramm, über das Andreas in dieser Folge spricht, hat er auch gebloggt. Seine Vorlesungsfolien darüber sind dort auch verlinkt. Der Artikel von damals gibt auch für die nächste Episode noch was her, anschließend muss Andreas wohl im Blog nachlegen.

Ansonsten fährt Andreas niemals in den Straßen von Tokio. Er arbeitet nämlich für die badische Regierung. In seiner Position wäre das also wenig ratsam. 😉

Checklisten

Unsere Weltreise wirft ihre Schatten voraus: Anke berichtet von der Vorbesprechung zur Bildungsreise nach Japan, zu der außer uns wohl nur Lehrerinnen fahren. Reiseleiter Chris hat uns eine Checkliste und viele nützliche Tipps gegeben. Andreas‘ Cousin Rudi und seine Frau Olivia sind gerade in Neuseeland und bloggen von dort. Da werden sicher auch viele interessante Sachen für uns dabei sein.

Für unsere Reise ist noch ganz schön viel zu planen und die To-Do-Liste soll natürlich mit einer Datenbank umgesetzt werden. Andreas erklärt Anke, dass ein relationales Datenbank-Management-System Daten in Tabellen speichert und was DML, DDL und SQL bedeuten. Anke wundert sich, dass es relationale Datenbanken erst seit 1970 gibt.

Zu dem, was Andreas heute über Datenbanken erzählt hat, hat er vor anderthalb Jahren schon mal was gebloggt.

Intro und Outro sind wie immer von der großartigen Band Revolte Tanzbein, denen wir nochmals danken, dass wir „Panama“ dafür benutzen dürfen. Unser Dank geht auch an unseren Freund David Göbel, der unser Logo gestaltet hat.

Statt Outtakes gibt es diesmal ein kurzes Zitat aus dem Hörbuch „Der Aufstieg und Fall des D.O.D.O.“ von Neal Stephenson und Nicole Galland. Wir hoffen, dass Euer Verhältnis zu Datenbanken anders ist als das der Romanfiguren und Ihr uns viel Feedback (und positive Bewertungen) gebt.

Trailer

Wir stellen uns und unseren neuen Podcast vor.

Wir wollen auf eine Weltreise gehen und Japan, Neuseeland, Australien und Kanada besuchen.

Unser Plan ist, dass wir nicht nur über unsere Erlebnisse berichten, sondern auch über Datenbanken sprechen.

Unser Dank geht an die großartige Band Revolte Tanzbein dafür, dass wir Ihren Song „Panama“ als Intro benutzen dürfen sowie an unseren Freund David Göbel, der unser Logo gestaltet hat.

Cyberbull

Wenn Ihr mal ne spannende Serie schauen wollt, schaut Euch Designated Survivor an, aber bitte nur die erste Staffel.

Wenn Ihr ne schlechte Serie schauen wollt, schaut Euch auch Designated Survivor an, aber diesmal die zweite Staffel.

Diese Serie bekommt von mir nicht nur die Auszeichnung für das größtmögliche Qualitätsgefälle, sondern auch den Preis für den größten jemals gemessenen Bullshit in Szenen mit Computerbezug.

Dass Bildschirminhalte nicht so eine große Rolle spielen, so lange es irgendwie kompliziert und doch cool aussieht, ist nichts neues. Auch dass mittels Magie aus einem Satellitenbild eine hoch aufgelöste Frontalaufnahme eines Verdächtigen entsteht, ist im Fernsehen schon lange Standard. Dass dieses Bild dann „Pixel für Pixel“ mit den Datenbanken abgeglichen wird, ist schon eine Spezialität. Einen einzelnen weißen, schwarzen oder bunten Punkt in einer Datenbank zu suchen, das bringt sicher viel. Aber egal, das geht vielleicht noch als unglückliche Formulierung durch.

Anekdoten aus Designated Survivor

Ein wenig später freut sich der IT-Crack Chuck, dass er die Firewall des Laptops eines Verdächtigen überwunden hat. Da staunt der Laie und der Fachmann wundert sich. Warum hat sich Chuck die Mühe gemacht, die Firewall, die den Rechner vor unbefugtem Zugriff aus dem Netzwerk schützen soll, zu überwinden, wenn das Gerät direkt vor ihm auf dem Tisch steht?

Aber vielleicht ist es auch nur des Wortwitzes wegen: Der Laptop geht wenige Augenblicke später in Flammen auf, weil der böse Besitzer „den Akku gehackt“ hat. Vielleicht hätte das FBI doch lieber einen IT-Forensiker anstellen sollen, der sich mit sowas auskennt.

Eher ein Schmankerl für Kenner war dann noch, dass der selbe Chuck Erkenntnisse über eine Auktion von Alan-Turing-Memorabilia gewinnt, bei der unter anderem eine Turing-Maschine versteigert wurde. Da wurde der Käufer wohl betrogen, handelt es sich bei einer Turing-Maschine doch um ein mathematisches Konstrukt, ein rein theoretisches Gebilde, nicht um ein physisch existierendes Gerät.

Warum ärgert mich das?

Eigentlich finde ich sowas ja ganz amüsant, besonders weil es gerade in dieser Serie so unglaublich übertrieben absurd ist, wenn man sich auch nur ein bisschen mit der Materie auskennt.

Doch das Problem ist, dass sich so beim Zuschauer ein falsches Bild von Computertechnik, von Sicherheitslücken und von Angriffen auf IT-Systeme verfestigt. Wenn etwas nur oft genug im Fernsehen gezeigt wird, und wenn es auch in einer Action-Serie ist, besteht leider die Gefahr, dass es irgendwann jemand für bare Münze nimmt.

Anstatt sich von solchem Cyber-Zauber beeindrucken zu lassen, sollten sich Computernutzer (d.h. wir alle!) lieber auch mal mit echter IT-Sicherheit befassen. Wer sich auch nur ansatzweise von dem Bild inspirieren lässt, das in dieser TV-Serie vermittelt wird, schwebt in Gefahr, die realen und alltäglichen Bedrohungsszenarien zu ignorieren.

Die letzte Konsequenz davon sieht man auch in dem aktuellen Fall von „Doxing„, bei dem personenbezogene Daten von etwa 1000 Menschen, darunter viele Politiker, veröffentlicht wurden. Mehr Kompetenz im Umgang mit IT-Systemen ist notwendig, um die Ursachen zu verstehen und solche Vorfälle in Zukunft zu vermeiden. Nimmt man dagegen zu viel von dem Mumpitz zu sich, wie er in Designated Survivor und anderen Action-Serien vorkommt, dann kommen leider so kompetenzbefreite Ideen wie die des „Hack-Back“ auf den Tisch, statt generell die (defensive) IT-Sicherheit zu stärken. Letzteres könnte natürlich als Nebeneffekt dazu führen, dass der Bundestrojaner dann nicht mehr läuft. Ob man das deshalb nicht will?

Die Realität ist spannender!

Dass die Realität sehr viel spannender ist als Cyber-Bullshit, sieht man übrigens jedes Jahr beim Chaos Communication Congress. Dieses Jahr wurde da unter anderem gezeigt, wie man über Fax in Firmennetze einbrechen kann, es wurde die biometrische Identifikation mit Venenerkennung durch eine Attrappe überwunden und es wurde gezeigt, wie man Geldautomaten um ihren Inhalt erleichtern kann.

Man sich übrigens durchaus an der Realität orientieren und trotzdem daraus eine spannende Serie stricken! Mein Schlusswort ist deshalb: Wenn Ihr mal ne spannende Serie mit mehr Cyber, aber weniger Bullshit sehen wollt, dann schaut Euch Mr. Robot an!

Nutch und Solr einrichten

Wer selber Suchmaschinenbetreiber werden und dem Großen G Konkurrenz machen will, kann das mit dem Webcrawler Nutch und dem Suchserver Solr tun. Leider ist das Tutorial von Nutch nicht ganz so deutlich, enthält ein paar unnötig komplizierte Sachen und zudem in einer nicht ganz logischen Reihenfolge.

Das hier gezeigte Vorgehen wurde mit Ubuntu 16.04 getestet, sollte aber genau so mit anderen Linuxen oder macOS funktionieren.

Unter Windows laufen die Nutch-Skripte nicht. Da das eigentliche Nutch selbst aber genau wie Solr in Java implementiert ist, ließe sich das mit Cygwin lösen. Die Frage ist nur, ob man das auch will…

Für die Beispiele wird davon ausgegangen, dass sich Nutch im Verzeichnis „apache-nutch-1.14“ und Solr im Verzeichnis „solr-6.6.3“ jeweils direkt unterhalb des Home-Verzeichnisses befinden.

Wer möchte, kann das Nutch-Tutorial parallel öffnen. Ich orientiere mich hier am Stand des Tutorials vom Mai 2018 und weise jeweils auf Stellen im Tutorial hin.

1. Voraussetzungen: Java und Solr

Siehe Abschnitt Requirements im Tutorial.

Nutch 1.14 setzt Java voraus. Von mir wurde Nutch mit Java 1.8 getestet.

Ant ist nicht nötig, wenn Nutch als Binary geladen und nicht selbst kompiliert werden soll.

Damit Nutch die gecrawlten Webseiten direkt zum Indexieren an Solr weiterreichen kann, muss die passende Solr-Version laufen. Nutch 1.14 läuft mit Solr 6.6

Die Installation von Solr ist denkbar einfach, es ist lediglich ein Archiv herunterzuladen und zu entpacken.

(Im Tutorial wird Solr erst später erwähnt, es ist meiner Ansicht nach aber empfehlenswert, schon an dieser Stelle Solr zum Laufen zu bringen und zu testen.)

2. Nutch herunterladen

Siehe Option 1 im Abschnitt Install Nutch im Tutorial.

Die Installation von Nutch läuft erst mal fast genau so: Downloaden von http://nutch.apache.org/ und in ein Verzeichnis nach Wahl entpacken.

Siehe nun Verify your Nutch installation im Tutorial.

Aus dem Nutch-Verzeichnis heraus sollte jetzt ein „bin/nutch“ schon funktionieren und Nutch sollte zumindest mal ein Lebenszeichen von sich geben.

Wenn Nutch wie oben angegeben ins Verzeichnis „apache-nutch-1.14“ entpackt wurde, sind folgende Befehle einzugeben:

cd apache-nutch-1.14/
bin/nutch

Es sollte eine Meldung erscheinen, die die möglichen Nutch-Kommandos auflistet.

Achtung: An der /etc/hosts herumzufummeln, wie es im Tutorial steht, sollte im allgemeinen nicht notwendig sein!

3. JAVA_HOME setzen

Wir sind immer noch bei Verify your Nutch installation im Tutorial.

Möglicherweise ist die Umgebungsvariable JAVA_HOME nicht gesetzt. Ob das so ist, erfährt man durch Eingabe von

echo $JAVA_HOME

Wenn nichts ausgegeben wird, war JAVA_HOME nicht gesetzt. Dann ist unter Ubuntu (oder Debian) folgendes zu tun:

export JAVA_HOME=$(readlink -f /usr/bin/java | sed "s:bin/java::")

Damit beim nächsten Neustart des Terminals die JAVA_HOME gleich gesetzt ist, empfiehlt es sich, diese Zeile ans Ende der .bashrc im Home-Verzeichnis anzufügen:

cd

echo 'export JAVA_HOME=$(readlink -f /usr/bin/java | sed "s:bin/java::")' >> .bashrc

Unter macOS setzt man die JAVA_HOME wie folgt auf den korrekten Wert (Achtung, die Angabe im Nutch-Tutorial stimmt für neuere macOS-Versionen nicht!):

export JAVA_HOME=$(/usr/libexec/java_home)

Bei macOS würde man die JAVA_HOME wohl eher in der .profile setzen:

cd

echo 'export JAVA_HOME=$(/usr/libexec/java_home)' >> .profile

4. Crawler-Properties

Wir sind im Tutorial nun bei Customize your crawl properties.

Der Crawler meldet sich bei den Web-Server, die gecrawlt werden, mit seinem Namen. Es ist aber standardmäßig nichts voreingestellt. Ohne dass wir hier etwas konfigurieren, verweigert Nutch seinen Dienst.

In die Datei apache-nutch-1.14/conf/nutch-site.xml muss folgendes rein (der fette Teil ist neu):

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>

<!-- Put site-specific property overrides in this file. -->

<configuration>
<property>
<name>http.agent.name</name>
<value>Der Test Nutch Spider</value>
</property>
</configuration>

Statt „Der Test Nutch Spider“ sollte man natürlich selber irgendeinen Namen wählen.

5. Solr konfigurieren

Wir überspringen einiges im Tutorial und gehen nun direkt zu Setup Solr for search.

Im Tutorial wird als zu Nutch 1.14 zugehörig die Version Solr 6.6.0 angegeben. Im Test funktionierte es aber auch mit 6.6.3. Mit Solr 7 dagegen könnte es Probleme geben.

Die von Nutch gecrawlten Webseiten sollen in einen eigenen Solr-Core. Zum Setup des Schemas für diesen Core nehmen wir die Standard-Beispielkonfiguration von Solr und kombinieren sie mit einer schema.xml, die von Nutch geliefert wird.

Die Schritte im einzelnen:

1. Das Configset basic_configs kopieren und neu nutch nennen.

Update!

Das Configset heißt a Solr 7 „_default“ und nicht mehr „basic_configs“. Wenn Ihr bei den Befehlen unten das entsprechend ersetzt, funktioniert die Anleitung auch noch mit Nutch 1.16 und Solr 7.

2. Die managed_schema im Configset nutch löschen.

3. Die schema.xml von Nutch ins neue Configset nutch kopieren.

Noch ein Update!

Im Nutch-Tutorial ist im Abschnitt „Setup Solr for search“ eine alternative schema.xml verlinkt, am besten die „most recent schema.xml“ verwenden und die im Configset „nutch“ ersetzen.

4. Solr starten

5. Einen neuen Core unter Verwendung des soeben erstellen Configsets einrichten.

Die Befehle dazu:

cd
cd solr-6.6.3/
cd server/solr/configsets/

cp -r basic_configs nutch

cd nutch/conf

rm managed-schema

cd

cp apache-nutch-1.14/conf/schema.xml solr-6.6.3/server/solr/configsets/nutch/conf/

cd solr-6.6.3/

bin/solr start

bin/solr create -c nutch -d server/solr/configsets/nutch/conf/

6. Nutch klar machen zum Crawlen

Wir springen nun im Tutorial zurück zu „Create a URL seed list„.

Wenn man das Web crawlen will, muss man irgendwo anfangen. Diese Startseiten kommen in die Seed List.

Den Teil des Tutorials, wie man an eine schöne Seed List kommt, in dem man z.B. eine Liste von Webseiten von dmoz herunterlädt, ignorieren wir hier mal, wir machen das von Hand und setzen unsere Lieblingswebseite als Startpunkt.

Die Schritte im einzelnen:

1. Unterhalb von apache-nutch-1.14 ein Verzeichnis urls anlegen

2. Darin eine Datei seed.txt anlegen und da drin einfach eine Liste von URLs eintragen.

Konkret:

cd

cd apache-nutch-1.14/

mkdir urls

cd urls

echo 'http://hs-furtwangen.de/' > seed.txt

Jedenfalls sollte man das so machen, wenn die Webseite der Hochschule Furtwangen die Lieblingswebseite ist.

Den Regex-URL-Filter (siehe Tutorial) lassen wir so er ist. Wir müssten den ändern, wenn wir z.B. nur die Unterseiten einer Homepage crawlen und indexieren wollen, ohne externe Links zu verfolgen.

Den ganzen Abschnitt „Using Individual Commands“ überspringen wir mal getrost. Die Befehle, die dort stehen, sind zwar schön, wenn man mal sehen will, was im einzelnen passiert, aber zu kompliziert.

7. Crawl starten!

Wir gehen im Tutorial direkt zu Using the crawl script.

Den Aufruf des Crawl-Skripts ist im Tutorial erklärt, aber wir können selber das Skript von einem eigenen Skript aus starten, das direkt schon die gewünschten Parameter enthält. 🙂

Ich gehe hier davon aus, dass, wie hier im Beispiel, der Solr-Server auf dem selben Rechner läuft, der Core nutch heißt und die Seed-Liste dort liegt, wo wir sie in Schritt 4 gerade angelegt haben. Außerdem sind hier jetzt mal 50 Iterationen eingestellt. Das ist viel! Man kann den Crawl-Vorgang aber ruhig zwischendurch abbrechen.

cd

cd apache-nutch-1.14/

echo 'bin/crawl -i -D solr.server.url=http://localhost:8983/solr/nutch -s urls crawl 50' >> crawl.sh

chmod +x crawl.sh

./crawl.sh

8. Die Ergebnisse begutachten

Schon während der Crawl läuft, können wir in der Admin-Oberfläche von Solr den Index abfragen. Spätestens jetzt empfiehlt es sich, sich mit dem Schema des neuen Cores vertraut zu machen, um anschließend ein schönes Frontend programmieren zu können.

Viel Spaß!