Der SUB meiner Frau ist nur “leicht” größer. Aber hier ist meiner. Aktuell hab ich also auf dem Nachttisch: “Spring 2.5” (schon etwas älter), “Lync Server 2010 Unleashed” und “Forefront TMG 2010 – Das Handbuch”.
Zum einen wollte ich mich damit in das Thema Spring etwas einlesen. Zum anderen muss ich die anderen beiden Bücher mal näher studieren für die Firma. Mit dem Buch zu Lync will ich mich weiter einarbeiten in das Thema Lync und mit Forefront entdecke ich komplettes Neuland.
Irgendwann kommt der Zeitpunkt da ist einem die Suche seines 
Programmes über die Datenbank zu langsam oder gewisse Features sind nur schwer über die Datenbank zu realisieren oder die Suche skaliert einfach zu schlecht. Gründe gibt es viele sich mal umzuschauen nach Alternativen. Aber was gibt es da? Eine Lösung könnte Apache Solr sein.
Apache Solr ist eine Enterprise Plattform für Suchen. Solr baut auf dem Apache Lucene Projekt auf und bietet Features wie Highlighting, Faceting, Clustering, Volltextsuche, REST-Schnittstelle und andere tolle Sachen die man auch von Google her kennt.
In diesem Artikel möchte ich euch bei den ersten Schritten mit Apache Solr unterstützen. Vielleicht gibt es zu dem Thema in Zukunft auch noch weitere Artikel.
Also, was haben wir vor. Ich möchte eine Multicore-Installation von Solr mit Tomcat zeigen. Dazu muss man wissen, dass man mit Solr nicht nur eine “Datenbank” zum dursuchen haben kann sondern mehrere parallel(Multicore) und das auch mit unterschiedlichen Konfigurationen. Aber dazu später mehr.
OK. Was brauchen wir?! Apache Solr und Apache Tomcat. Beides können wir als tar.gz herunterladen:
http://tomcat.apache.org/
http://lucene.apache.org/solr/
Weiterhin benötigt ihr Java. Das heißt, ihr solltet euch entweder Java herunterladen oder über eure Distribution installieren.
Kommen wir zu unserem Arbeitsbereich. Hierfür nutze ich den Ordner /www/solr bei mir. Ihr könnt auch irgend ein Ordner eurer Wahl nehmen. In diesem Ordner entpackt ihr dann das Solr.tar.gz und das Tomcat.tar.gz. Danach benennt ihr noch das Solar Verzeichnis direkt in “solr” und das Tomcat Verzeichnis direkt in “tomcat” um. Fertig wäre Step 1.
Und weiter geht es mit Step 2. Jetzt legen wir den Ordner “solr-multicore” in /www/solr an. Danach kopieren wir alles aus solr/examples/multicore nach /www/solr/solr-multicore:
cp -a /www/solr/solr/examples/multicore/* /www/solr/solr-multicore/
Im Step 3 kümmern wir uns endlich um Tomcat. Wir müssen Tomcat zum einen mitteilen wo er unsere Multicore Installation findet und zum anderen müssen wir Solr im Tomcat veröffentlichen. Wir öffnen also tomcat/conf/catalina.properties und fügen folgende Zeile hinzu:
solr.solr.home=/www/solr/solr-multicore
Jetzt legen wir noch einen Benutzer für die Verwaltung von Tomcat an. Dazu öffnen wir tomcat/conf/tomcat-users.xml und legen die Datei so an:
<?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="manager-gui"/> <user username="admin" password="admin" roles="manager-gui"/> </tomcat-users>
Jetzt sind wir auf der Zielgeraden. Wir müssen jetzt noch Solr im Tomcat veröffentlichen. Dazu kopieren wir die WAR-Datei aus Solr in das Tomcat webapps Verzeichnis.
cp /www/solr/solr/dist/apache-solr-3.3.0.war /www/solr/tomcat/webapps/solr.war
Jetzt brauchen wir nur noch Tomcat starten. Dazu gehen wir in das Verzeichnis tomcat/bin und führen startup.sh aus. Nach dem starten öffnen wir unseren Browser und öffnen folgender URL:
http://localhost:8080/solr/
Damit sollten wir einen Überblick über alle konfigurierten Cores in Solr sehen und können jetzt anfangen mit Solr zu spielen. Dazu kommen wir aber in einem neuen Artikel. Zum Schluss noch kurz erwähnt. In solr-multicore/solr.xml könnt ihr weitere Cores konfigurieren und in jedem Core Ordner gibt es einen conf Ordner mit einer schema.xml über welche ihr den Core konfigurieren könnt. Dazu dann aber mehr in einem neuen Artikel.
Mein Kollege holt das Wasser aus dem Boot:
Wenn man nicht gerade den NSM von Juniper einsetzt sollte man sich selber Gedanken machen wie man Backups seiner Netscreen Geräte macht.
Was bleibt einem neben manuellem einloggen auf der Netscreen und das ziehen der Konfiguration noch übrig? Ja. SCP! Damit man automatisch eine Konfiguration von einer Netscreen kopieren kann muss man erstmal SSH und SCP aktivieren. Das machen wir mit:
set ssh version v2 set ssh enable set scp enable
Danach müssen wir noch auf dem entsprechenden Interface über das wir zugreifen möchten SSH aktivieren. Das machen wir mit:
set interface ethernet0 manage ssh
Jetzt würde ich empfehlen, dass wir einen read-only Benutzer anlegen. Das können wir wie folgt machen:
set admin user "backup" password backuppass privilege "read-only"
Was fehlt noch für einen Passwortfreien Login über SSH? Ja, ein PublicKey. Einen PublicKey könnt ihr unter Linux wie folgt anlegen:
ssh-keygen -t dsa
Jetzt müsst ihr aus der angelegten id_dsa.pub den PublicKey kopieren und setzt jetzt folgenden Befehl auf der Netscreen ab:
set ssh pka-dsa user-name backup key AAAAB3NzaC1kc3MAAACBAIQ9SkpRIz/TcrdyPkVdbty...
Damit könnt ihr euch ab sofort ohne Passwort mit diesem User und dem PublicKey einloggen.
Jetzt kommen wir zur eigentlichen Aufgabenstellung. Das Backup! Das ist dann jetzt auch ganz leicht gemacht mit:
scp backup@netscreenip:ns_sys_config netscreen.cfg
Der Befehl muss jetzt nur noch über ein Cronjob gestartet werden und schon habt ihr eurer automatisches Netscreen Backup!
Neulich bei uns in der Firma…
Da wollte schon vor einiger Zeit jemand bei uns einen Trend setzen.
Mal eben schnell das Service Pack1 von Windows Server 2008 R2 eingespielt und nix geht mehr in Sachen XenApp. Das heißt die Anmeldung macht Probleme. Sehr komisch alles. Vor allem hab ich schon an mir selbst gezweifelt. Aber nach einem kurzen Blick in die Citrix Foren gab es auch schon die Lösung. Ein kleiner Hotfix. Einfach einspielen und alles wird gut.
http://support.citrix.com/article/CTX125388
Bitte auch dringend die Release-Informationen durchlesen! Nicht das ihr sonst Probleme mit dem Lizenzserver bekommt.
Mit XenApp 6 hat sich ja einiges geändert. Ganz neu ist ja jetzt, dass einiges über Richtlinien zu konfigurieren geht. So auch wie im Titel beschrieben die Server-Neustarts.
Aber wer jetzt denkt, dass geht ja einfach von der Hand… Dem sei gesagt: es gibt auch einige Stolpersteine wie ich feststellen durfte.
Ziel war es, dass ich Server in der Nacht um 4 Einmal Durchbooten lassen möchte. Dafür habe ich eine eigene Richtlinie im Bereich Computer angelegt.
Dann habe ich die, wie ich denke, entsprechenden Regeln aktiviert und konfiguriert. Doch leider musste ich nächsten Tag feststellen, dass das so nicht funktioniert hat. Ich hab dann die nächsten Tage nochmal hier und da die Regeln geändert. Ohne Erfolg. Dann war ich in den Citrix Foren mal unterwegs und hab zu dem Thema auch einiges gefunden. Da musste ich dann auch leider folgendes lesen. Die Neustart-Richtlinien greifen erst ab der Enterprise Edition von XenApp. Dies war aber in meinem Fall gegeben. Das heißt daran konnte es nicht liegen.
Ich habe dann meine Richtlinien mit einigen Tutorials verglichen und bin dann über die Regel Neustartbeginn gestolpert. Hier hatte ich immer Standard Wert aktiviert. Dies hab ich dann mal auf den 01.01.2011 geändert. Und siehe da. In der nächsten Nacht wurde der Reboot gemacht.
Fazit deshalb. Produkt Edition prüfen und hier meine Regeln als Beispiel:
Da sitzt man morgens alleine im Büro und denkt sich man macht mal eben das neueste Update für die Netscreen und dann sowas.
Wie sonst zur sicherheit erstmal Backup machen. Nebenbei die Firmware von der Website geladen. Dann entpackt und über das Webinterface eingespielt. Nach kurzem warten der Reboot. Dann
*warten*
*warten*
*warten*
Ok. Das dauert jetzt eindeutig zu lange! Serielles Kabel gezügt und fix angeschlossen. Totenstille auf der Leitung… Mist… Fix vom Strom genommen und wieder ran.
Ah… Da ist sie wieder. Fährt hoch und lädt… Und mit mal CRC Error. Und nu???
Beim booten gibt es einen Loader. Fix angeschaut. Mist… Kein TFTP Server zur Hand. Dann über umwege aus dem Netz fix einen heruntergeladen. Danach konnte ich dann per TFTP das Image nochmal neu einspielen.
Hapu! Das hat geklappt. Die Kiste startet. Aber… Nur die Default Konfiguration. Ein Lächeln für ein Backup 😉 Zum Glück wie immer vorher gemacht *yeah*
Nach 45 Minuten war das Thema durch und ich konnte mir endlich meinen Morgen-Kaffee holen.
Natürlich ist das nicht die Regel. Und das letzte Fehlgeschlagene Update ist schon ein paar Jahre her. Trotzdem bleibt ein ungutes Gefühl. Gerade wenn man Updates auf Geräten einspielen will wo man nicht vor Ort ist.
Wir schreiben das Jahr 2011. Es ist März. Ein Mann. Ein Nagel. Eine Wand. Das Loch und schon hängt er. So einfach kann es im leben sein.
Wer mich also jetzt im Büro besuchen bekommt kann sich auch gleich diesen tollen Kalender angucken.
Heute gibt es mal den Blick aus dem Büro in Richtung Osten. Zu sehen ist neben dem üblichen Hamburg Grau in Grau die Industrielandschaft der City-Süd.
Written by