The latest posts in full-text for feed readers.
Nunmehr 11 Jahre fahre ich jeden Tag mit der Bahn
zur Arbeit
zur Arbeit,
angefangen 2008.
Da ich mir im Dezember wieder die Jahreskarte für die 4 Zonen
(MDV)
bis nach Leipzig gekauft habe, sind mir auch die alten Karten
wieder in die Hände gefallen.
Die Preissteigerungen sind schon erstaunlich, vor allem da sich
am Service nichts verbessert hat.
Jahr | Preis | Preis in Prozent | Tarifname |
---|---|---|---|
2008 | 1.135 € | 100% | MDV Jahreskarte |
2009 | 1.194 € | 105% | MDV Jahreskarte |
2010 | 1.256 € | 111% | MDV Jahreskarte |
2011 | 1.282 € | 113% | MDV Jahreskarte |
2012 | 1.320 € | 116% | MDV Jahreskarte |
2013 | 1.291 € | 114% | MDV ABO Light |
2014 | 1.340 € | 118% | MDV ABO Light |
2015 | 1.415 € | 125% | MDV ABO Light |
2016 | 1.463 € | 129% | MDV ABO Light |
2017 | 1.476 € | 130% | MDV ABO Light |
2018 | 1.481 € | 130% | MDV ABO Light |
2019 | 1.520 € | 134% | MDV ABO Light |
2020 | 1.555 € | 137% | MDV ABO Light |
2021 | 1.622 € | 143% | MDV ABO Light |
Seit 2013 gibt es verschiedene Tarife; ich habe den günstigsten gewählt und kann dadurch niemanden mehr mitnehmen. Bis 2012 ging das; deshalb auch die 30€ weniger im Vergleich zu 2012.
Published on 2011-01-02 in leben, netresearch
Dank des Abschiedgeschenks von netresearch durfte ich das von mir mitgebaute MyAIDA Bordportal auf der AIDAcara selbst ausführlich nutzen.
Das Portal funktionierte ganz gut, allerdings war die Seekarte nicht zu gebrauchen (hat kein Land angezeigt), und der Tagesplaner war nicht gepflegt. Der Kabinenreinigungsstatus im Profil hat sich auch nie geändert.
Hier sind ein paar Screenshots von Laptop und Handy:
Lustigerweise ist man auch bei der TYPO3 GmbH auf das Projekt aufmerksam geworden:
Letztendlich sind Agenturen auch unfassbar kreativ in den Anforderungen, die sie mit TYPO3 besetzen: Wenn man fragt, wie man auf die Idee kommt, das Mediacenter auf AIDA Kreuzfahrtschiffen mit TYPO3 umzusetzen, kommt als Antwort „Warum nicht, ist doch auch nur Content“. Und damit haben sie einfach Recht.
Published on 2016-11-05 in leben, netresearch
Bevor ich Ende letzten Jahres zu Mogic gewechselt bin leitete ich bei netresearch zwei Jahre lang die Umsetzung des Bordportals für die AIDAprima.
Das von Mitsubishi Heavy Industries für AIDA in Rostock neu gebaute Schiff hatte sich von ursprünglich Frühling 2015 auf Herbst 2015, und dann Frühling 2016 verzögert. Aus diesem Grund konnte ich die Portalsoftware leider nicht mehr selbst auf der Prima installieren.
Heute jedoch vermeldet netresearch, daß das Bordportal endlich live ist. Herzlichen Glückwunsch von mir dazu an das ganze Team!
Das Portal ist ein aufgebohrtes TYPO3, dessen Ausgabe an die an Bord befindlichen öffentlichen Terminals (hochkant angebrachte Touchscreens), Kabinenfernseher (gesteuert über Fernbedienung-mit-Gyroskop-als-Maus und Touchscreen für Tastatur auf der Rückseite) angepasst ist - und natürlich auch an Handy, Tablet und Laptop.
Auf den öffentlichen Touchscreen-Terminals läuft ein ge'app'ter Chrome im Vollbildmodus. Zur Authentifizierung im Portal wird die RFID-Bordkarte genutzt, die an einen kleinen Reader neben dem Bildschirm gehalten werden muss. Die Anbindung des Readers erfolgte über die chrome.serial API per JavaScript. Echt cooles Zeug!
Published on 2016-05-17 in netresearch, php
Am 15.10.2015 habe ich Netresearch nach 14 Jahren verlassen und bin zu Mogic gewechselt.
Mein jetzt Ex-Arbeitgeber schreibt dazu :
Schiff Ahoi und gute Reise!
Christian Weiske auf Abschiedstour
Nach 14 Jahren verlässt uns unser CTO, aber wir wollen ihn nicht so einfach ziehen lassen.
Christian Weiske war nicht nur irgendein Mitarbeiter. Besonders mit seinem technischen Know-How und seiner guten Vernetzung in einschlägigen Fachkreisen setzte er Maßstäbe, die Netresearch zu dem verhalfen, was es heute ist: eine erfolgreiche Agentur für Internet-Kommunikation mit hohem technischen Qualitätsstandard und einem besonderen Verständnis für individuelle Kundenwünsche.
Als Dankeschön für die jahrelange Zusammenarbeit schenken wir ihm und seiner Familie eine Kreuzfahrt mit der AIDA - AIDA Cruises ein Kunde, den Christian jahrelang begleitet hat. Wir wünschen ihm und seiner Familie eine tolle Zeit auf der AIDA und hoffen, dass er Netresearch in guter Erinnerung behält.
Das Netresearch-Team
Published on 2015-10-30 in job, netresearch, mogic
Dieser Artikel wurde ursprünglich im Blog meines Arbeitgebers veröffentlicht: Setup unserer Intranetsuchmaschine @ netresearch .
Während unserer täglichen Arbeit nutzen wir eine große Anzahl an Werkzeugen, in denen Informationen zu Projekten und Abläufen abgelegt werden.
Dazu gehören der Bugtracker JIRA, das Wiki, die Lesezeichenverwaltung, das interne Blog, unser zentrales LDAP-Adressbuch, der Git-Server, unser Pastebin, Logs der Chaträume und nicht zuletzt unser Projektnetzlaufwerk mit allen Dateien, die mit dem jeweiligen Projekt zu tun haben (Anforderungen, Designs, Schnittstellenbeschreibungen).
Zu viele Anlaufstellen, um die gesuchte Information manuell auf Anhieb zu finden. Aus diesem Grund begannen wir vor 2 Jahren mit dem Aufsetzen einer Intranetsuchmaschine. Ziel war es, alle Daten auf einmal durchsuchen zu können.
In diesem Blogartikel dokumentieren wir die getesteten Suchmaschinentools sowie die Konfiguration des jetzt eingesetzten regain.
Anfangs probierten wir Yacy aus. Yacy ist eigentlich eine verteilte Suchmaschine, bei denen je eine Maschine im Verbund für einen bestimmten Teil der zu durchsuchenden Daten zuständig ist, diese indiziert und bei der Suche Ergebnisse für diesen Teil der Daten zurückgibt.
Yacy kann allerdings auch im Einzelmodus ("Robinson Modus") betrieben werden, was wir bei uns so konfigurierten.
Mit der Zeit häuften sich aber die Probleme:
Nachdem die Such-VM mal wieder abgestürzt und nicht erreichbar war, wurde sie nach einem halben Jahr Testphase abgeschaltet und stattdessen regain ausprobiert.
Nach den ganzen Problem mit Yacy kommt jetzt regain zum Einsatz.
Trotz aller noch existierenden Probleme funktioniert die Suche zufriedenstellend über alle Werkzeuge hinweg.
Ein aus meiner Sicht großer Vorteil ist, dass regain über eine Konfigurationsdateien angepasst wird. Damit hat man alle Einstellungen im Blick und kann diese auch einfach ins Backup aufnehmen.
Der Suchcomputer kommt problemlos mit 768MiB RAM aus.
Indizierungs- und Suchkonfiguration sind voneinander getrennt, und man kann auch unterschiedliche Suchindizes anlegen, die unterschiedlich konfiguriert sind. Die Suche kann mehrere Indizes auf einmal durchsuchen.
Wir haben zwei Indexe, einen für das Projektlaufwerk und einen für den Rest.
Während der Einrichtung der Laufwerksindizierung musste der Index immer mal gelöscht werden, wobei aber nicht alle anderen Domains reindiziert werden sollten. Hier hilft die Trennung, weil man die Indexdateien einfach löschen kann.
Das Projektlaufwerk ist ziemlich groß; die Indexgröße beträg 1.1GiB. Der Rest sind knapp 400MiB Index. Falls mal etwas kaputt geht wurden die Dateien lieber getrennt, um die Wiederherstellung zu erleichtern.
Informationen zur Konfiguration findet man im Forum.
Die Konfigurationsdateien haben wir in /etc/regain/ abgelegt. Standardmäßig sucht regain im .jar-Verzeichnis nach der Konfiguration, aber das kann man mit dem CLI-Parameter -config/etc/regain/CrawlerConfiguration.xml ändern.
Reindizierung erfolgt einmal am Tag, nachdem alle Backups durchgelaufen sind und bevor die ersten Leute auf Arbeit kommen:
$ crontab -l -u regain 00 06 * * * cd /opt/regain/runtime/crawler/ && umask 0002 && java -jar regain-crawler.jar -logConfig /etc/regain/log4j-cron.properties -config /etc/regain/CrawlerConfiguration.xml 00 07 * * * cd /opt/regain/runtime/crawler/ && umask 0002 && java -Xmx128m -jar regain-crawler.jar -logConfig /etc/regain/log4j-cron.properties -config /etc/regain/CrawlerConfiguration-projekte.xml
Die Konfiguration des Crawlers haben wir in einigen wenigen Punkten angepasst:
Der Rest der Konfiguration haben wir im Ursprungszustand belassen.
http://adressbuch.nr/
http://blog.nr/
http://bookmarks.nr/
...
http://adressbuch.nr/
http://blog.nr/
http://bookmarks.nr/
...
http://blog.nr/tag/
http://blog.nr/wp-login.php
http://wiki.nr/api.php
http://wiki.nr/index.php
...
\.([^\.]*)$
^(.*)$
^http://([^/:]+)/
^http://xmpp.nr:5290/
]]>
In der Projektlaufwerkskonfiguration haben wir nur die Projektdateien eingestellt, den Suchindexspeicherort angepasst und die Vorschau deaktiviert (weil die > 20GiB zusätzlichen Speicherplatz bräuchte):
file:///mnt/projekte/
file:///mnt/projekte/
.*/Thumbs.db$
/var/regain/searchindex-projekte
false
.*
]]>
Die tägliche Reindizierung der 300.000 Dokumente dauert etwa 45 Minuten.
Die Konfiguration der Suche erfolgt in /etc/regain/SearchConfiguration.xml, was von regain auch nicht gemocht wird.
Damit regain die Datei liest, muss die .war-Datei nach /var/lib/jetty/webapps/regain/ entpackt und WEB-INF/web.xml angepasst werden:
searchConfigFile
../../../../../etc/regain/SearchConfiguration.xml
]]>
Als Applikationsserver nutzen wir Jetty, dessen Unix-Benutzer wir noch in die Gruppe regain aufnehmen mussten. Grund dafür ist, dass die Suche den neuen Index selbst aktiviert, wenn er fertig gecrawlt wurde. Das klappt nur, wenn sowohl der Crawler als auch die Suche dieselbe Gruppe haben.
In der Konfigurationsdatei haben wir ein Mapping der Projektlaufwerksdateien auf HTTP, sowie ein Mapping von HTTP auf HTTPS für sensible Daten.
Weiterhin sind dort die beiden Indizes definiert, die durchsucht werden sollen. Der Rest ist unverändert:
/var/regain/searchindex
/var/regain/searchindex-projekte
]]>
Zusätzlich haben wir noch den Domainfilter konfiguriert, und zwar in Dateien der entpackten regain.war: search_form.jsp, searchinput.jsp und advancedsearch.jsp bekommen:
Domain:
]]>
bzw.
Domain:
]]>
Auch mit regain haben wir noch unsere Probleme. Hier eine wahrscheinlich vollständige Liste:
Die Suchmaschine wird im Browser benutzt, und kann am Besten auf Daten verlinken, die über HTTP erreichbar sind. Viele unserer Tools haben allerdings eine Authentifizierung, oder sind gar nicht über HTTP erreichbar.
Als XMPP-Server verwenden wir prosody, der via mod_muc_log Logs schreiben und per mod_muc_log_http via HTTP verfügbar machen kann.
regain kann ganz einfach darauf angesetzt werden.
Für JIRA gibt es keine automatische Authentifizierung, deshalb exportieren wir alle Projekte und Fälle mit jira-export in statische HTML-Dateien. Diese können problemlos indiziert werden.
Die statischen Dateien können von der Suchmaschine über HTTP ohne Authentifizierung abgerufen werden, während alle anderen über HTTPS mit LDAP-Authentifizierung darauf zugreifen können. Das Mapping der URLs von HTTP auf HTTPS erfolgt in der Suchkonfiguration.
Ein Problem mit JIRA ist, dass man entweder viel zu viele Projekte angezeigt bekommt oder - wenn man die alten der Übersichtlichkeit halber deaktiviert - nicht mehr auf diese zugreifen kann.
Der statische Jira-Export soll allerdings alle Fälle und Projekte indizieren, weshalb wir einen eigenen "suche"-Benutzer angelegt haben, der nach Abschluss eines Projekts als einziger noch Zugriff auf das Projekt hat.
Damit wird man im täglichen Ablauf nicht von toten Projekten gestört, hat über die Suchmaschine aber immer noch Zugriff auf die Fälle.
Unser Adressbuch ist nur via LDAP erreichbar - ein Protokoll, das regain nicht versteht. Also haben wir einen LDAP-zu-HTML-Konverter gebaut, der jede Nacht den aktuellen Stand in HTML exportiert. Die 11.000 HTML-Dateien werden problemlos indiziert.
Normale Benutzer müssen sich im Wiki authentifizieren, die Suchmaschine nicht: Mit Hilfe der Extension IPAuth wird sie automatisch angemeldet.
Das Projektlaufwerk ist per CIFS auf der Suchmaschine gemountet und wird einfach von regain indiziert. Damit die Dateien in den Ergebnissen angeklickt werden können, werden sie zusätzlich noch über HTTPS freigegeben.
Die Verzeichniskonfiguration im Apache-VHost sieht so aus:
Options Indexes FollowSymLinks MultiViews
IndexOptions +FoldersFirst
IndexOptions +IgnoreCase
IndexOptions +IgnoreClient
IndexOptions +SuppressDescription
IndexOptions +SuppressHTMLPreamble
IndexOptions +VersionSort
IndexOptions +XHTML
AllowOverride None
Satisfy any
Deny from all
Allow from 127.0.0.1
AuthName "Windows-Benutzerdaten"
AuthType Basic
AuthBasicProvider ldap
AuthLDAPBindDN "readuser"
AuthLDAPBindPassword "readuser"
AuthLDAPURL "ldap://192.168.1.4/OU=Benutzer,OU=Netresearch,DC=netresearch,DC=nr?samAccountName?"
Require ldap-attribute memberOf="CN=Netresearch-Entwicklung,OU=Gruppen,OU=Netresearch,DC=netresearch,DC=nr"
Require ldap-attribute memberOf="CN=Netresearch - Marketing,OU=Gruppen,OU=Netresearch,DC=netresearch,DC=nr"
]]>
Das Mapping von lokalen Dateinamen auf die HTTP-Dateinamen erfolgt wieder in der Suchkonfiguration.
Das Aufsetzen der eigenen Suchmaschine hat zwar Zeit und Nerven gekostet, ist im täglichen Betrieb aber nicht mehr wegzudenken. regain erfüllt seine Aufgabe gut.
Die Möglichkeit, mit einer einzigen Suchanfrage alle betriebsinternen Daten zu durchsuchen, ist überwältigend.
Published on 2014-01-09 in netresearch, server, tools
At work we unfortunately switched to Google Apps for email, calendar and document storage - giving an us-american company access to our sensitive mails and contact data. Maybe one day they decide to disable our accounts and all data are lost, but our admins probably do backups and replacement servers will be setup instantly.</sigh>
When switching my email client - Claws Mail - to the new IMAP server (just changing the account settings), I got many errors in the network log, and moving mails did not work anymore:
WARNING: IMAP error on imap.googlemail.com: STATUS error
and
WARNING: IMAP error on imap.googlemail.com: UID COPY error
It turned out that I had to re-sync my folder tree - the errors vanished after that was done. Do that by right-clicking the account in the folder tree and select "rebuild folder tree".
Published on 2012-07-09 in mail, netresearch, network, tools
Gerade habe ich einen kleinen Vortrag beim Leipzig Semantic Web Tag über LESS gehalten.
LESS ist eine semantische Templateengine, mit der man Daten aus RDFa- und SPARQL-Endpoints in HTML umwandeln und damit auf seiner Website, Blog oder sonstwo anzeigen kann.
Hauptteil des Vortrags war eine Demonstration, die Folien sind hier runterzuladen.
Published on 2010-05-06 in conference, html, netresearch, php, semantic, sparql, web
At work, we use our own jabberd2 XMPP server instance to communicate with each other. Apart from one-to-one chats, we use the MUC plugin to get company-wide and project specific chat rooms.
The jabberd2 server directly reads user data from our mail server database (see XAMS patch, MySQL view for jabberd2 on the mail server DB). Our benefit in hosting our own jabber server is that we have absolute security by employing SSL connections that nobody can eavesdrop. Sensible data are only being sent over servers that we control.
One thing that did not work yet was file transfer. The idea is easy: Simply drop a file from your desktop of file manager onto the coworker in your XMPP roster (contact list) and the file is being sent to him. Sometimes it worked when both are in the internal network, but not always, and not with all clients. The solution here is either open ports in the company firewall or a file transfer proxy.
proxy65 is such a one; it is easy to setup and does what it says on the tin - even if the last release was nearly two years ago. Installation was easy:
After installation, you really should start proxy65 in debug mode:
twistd --nodaemon --logfile='-' proxy65 --secret=pass --proxyips=1.2.3.4 --rport=5347
When everything is fine and running, you should see a new XMPP service in the service list:
Now you may add that jabber ID ("proxy65" in our case") as file transfer proxy to your account settings. Please note that, although sometimes it looks like a FQDN like proxy.jabber.org, this is a Jabber ID! It took quite a while until I noticed that.
Published on 2010-05-02 in netresearch, network, tools, server, xmpp
Letzte Woche auf Arbeit: Jira geht wieder nicht. Also ssh auf die Kiste, top an und ... nichts. top liess sicht nicht starten, aber htop funktionierte. Irgendwann kam ich auf die Idee, das Datum ausgeben zu lassen:
jira:~# date Mon Mar 1 07:04:55 CET 2010 jira:~# date Mon Mar 1 07:04:55 CET 2010 jira:~# date Mon Mar 1 07:04:53 CET 2010 jira:~# date Mon Mar 1 07:04:53 CET 2010 jira:~# date Mon Mar 1 07:04:54 CET 2010 jira:~# date Mon Mar 1 07:04:55 CET 2010 jira:~# date Mon Mar 1 07:04:52 CET 2010 jira:~# date Mon Mar 1 07:04:53 CET 2010 jira:~# date Mon Mar 1 07:04:53 CET 2010 jira:~# date Mon Mar 1 07:04:54 CET 2010 jira:~# date Mon Mar 1 07:04:55 CET 2010 jira:~# date Mon Mar 1 07:04:52 CET 2010 jira:~#
Ja, hier hatte es Jira geschafft, aus der Java-VM heraus die komplette virtualisierte Maschine abzuschiessen - die bis zum harten Reset in dieser Zeitschleife gefangen war.
Fazit: Mit mantis ist das nie passiert.
Published on 2010-03-07 in bigsuck, linux, netresearch, offline, tools, server
Mein Brötchengeber netresearch sucht fähige PHP-Programmierer zur Festanstellung in Leipzig. Wer sich mit PHP tiefgründiger auskennt und keine Angst vor einem kleinen, netten Team hat bitte melden.
Published on 2008-02-07 in job, netresearch, php