Archive for the ‘Wien’ Category

h1

OpenStreetMaps auf Garmin nüvi 550

15. Mai 2009

Seit kurzem bin ich stolzer Besitzer eines nüvi 550 GPS von Garmin. Die Karten dafür kann man sich für teures Geld kaufen, gecrackte Versionen auch kostenlos (aber natürlich illegaler weise) downloaden oder auf die vom Projekt Open Street Map (OSM) zur Verfügung gestellten Karten zurück greifen. Der Vorteil von OpenStreetMap liegt auf der Hand: Die Kosten sind gering (man kann ja ab und zu was spenden) und Fehler im Kartenmaterial können sofort ausgebessert werden.

Die Installation der Karten von OSM auf dem GPS-Gerät erscheint zunächst einmal sehr kompliziert. Das liegt u.a. daran, dass OpenStreetMap die Basis für Karten in jeder Form und Größe und für verschiedenstee Zwecke und Geräte darstellt. Daher gibt es eine Vielzahl von Anleitungen und FAQs, durch die man sich erst einmal durcharbeiten muss, um die Spreu vom Weizen zu trennen. Für mich als Mac-Anwender und Besitzer eines aktuellen Gerätes von Garvin, reduzierten sich die nötigen Schritte auf das Folgende und solange ich keine Mountainbike-karte benötige, lässt sich alles mit Tools erledigen, die am Mac auch probemlos laufen. Ich hoffe mit diesem Artikel so manchem die mühsame Suche in diversen Wikis und Foren zu ersparen.

Vorbereitung

Um die nachfolgende Anleitung ausführen zu können, benötigt man einige Anwendungen. Von Garmin sollte man sich zumindest RoadTrip (auf Windows entspräche das dem Programm MapSource) und MapInstall herunterladen und installieren.

Zusätzlich wird das Programm Gmapi Builder benötigt. Download der graphischen Version http://berteun.nl/gmapibuilder/Gmapibuilder.dmg (aktueller Link siehe Kommentare). Benötigt wird Gmapi Builder um das für das Windows-Programm  MapSource vorbereitete Verzeichnis in ein für das Mac-Programm RoadTrip passendes gmapi-Paket zu verwandeln.

Schritt für Schritt

Download der vorbereiteten Kartenmaterials. Dieses besteht aus einer großen Anzahl von IMG-Dateien und einer TDB-Datei. Für Europa  sind diese  alle zusamengepackt in dieser Datei zu finden:
http://openstreetmap.teddynetz.de/latest/eu.tgz
(Falls man einen anderen Ausschnitt will: Ein Verzeichnis ähnlicher Dateien und alternativer Downloadmöglichkeiten ist hier zu finden.  http://wiki.openstreetmap.org/index.php/User:Computerteddy .  Interessant ist das z.B. wenn man nur Deutschland oder die ganze Welt auf seinem Garmin-GPS haben will.)

Die tgz-Datei wird von OS X nach dem Download sofort in eine tar-Datei umgewandelt, die dann wiederum mittels Doppelklick in ein Verzeichnis eu ausgepackt wird. Dort ist u.a. die besagte und für den nächsten Schritt benötigte tdb-Datei zu finden.

Start der zuvor Installierten Anwendung Gmapi Builder. In deren GUI ist dann der Pfad und Name der tdb-Datei anzugeben. Der Rest wird vom Programm i.A. richtig erkannt und ausgefüllt, so dass man nur noch auf Convert klicken muss.

Das so entstandene gmapi-Paket muss dann nur noch anklicken  und schon ist die Karte in Roadtripp zur Auswahl verfügbar.

Um sie dann auch noch am Garmin Device (bei mir das nüvi 550) zu haben, rufe man MapInstall auf. Dessen GUI ist selbsterklärend. Man bedenke aber, dass bei großen Karten die Übertragung mehrere Stunden in Anspruch nehmen kann. (Im Fall der Europakarte, auf der diese Anleitung beruht, sind es auch Stunden. Von der Installation der Weltkarte würde ich also Abstand nehmen.)

Was kann die OSM-Karte?

Die so installierte Karte ist ja nun sowohl in RoadTrip am Computer als auch am nüvi verfügbar. Die OSM-Karte ist sehr detailreich, genau und aktuell. Vor allem als Fußgänger und Radfahrer im urbanen Bereich (konkret habe ich bisher den 6. Bezirk in Wien genauer unter die Lupe genommen) freut man sich über Telefonzellen, Wasserstellen, Fusswege und Spielplätze. Das sind alles Details die auf den Garmin-Karten nicht zu finden sind. Auch war z.B. auf der Garmin-Karte ein Kino an der falschen Stelle, während die OSM-Karte hier viel genauer war. Öffentliche Verkehrsmittel sind teilweise erfasst.

Besser ausgestattet ist die Garmin-Karte was z.B. KfZ-Werkstätten betrifft aber auch Lokale und Gaststätten sind sehr viele erfasst  – leider nicht immer aktuell. Dafür fehlen die Öffis vollständig.

Der größte Vorteil der Garmin-Karte ist aber, dass man nach Adressen suchen kann und die Möglichkeit des Routings. Die wie oben importierte OSM-Karte kann das nicht (beim Import mit einem anderen Verfahren geht das aber sehr wohl, siehe unten). Was ich auf der OSM-Karte suchen kann, sind Points of Interest (POI). Das funktioniert ganz gut, wenn diese korrekt eingepflegt wurden. So findet z.B. die Suche nach „Trinkwasser“ alle jene Punkte, die im name-tag „Trinkwasser“ stehen haben. Nach anderen tags, wie z.B. jenem das auch für die Auswahl des Symbols verantwortlich ist  „amenity:drinking_water“ kann nicht gesucht werden. Das hat zur Folge, dass solche Punkte zwar auf der Kartenansicht im RoadTripp aufscheinen, aber mittels Suchfunktion nach „drinking_water“ nicht zu finden sind. Das tut vor allem dann weh, wenn solche Punkte von verschiedenen Personen erfasst wurden, die zwar alle konsequent das generische tag „amenity:drinking_water“ setzen, bei der Namensgebung aber die erlaubte Freiheit sich nehmen: Trinkwasser, Trinkbrunnen, Wasserstelle, Brunnen wären alles passende Inhalte für das name-tag. Am nüvi selbst, ist ein Suche nach dem POI „Trinkwasser“ gar nicht möglich. Sehr wohl aber werden Öffis, Polizei, u.ä. gefunden. Die dahinter stehende Logik ist mir noch nicht klar dürfte aber darin begründet sein, dass im Gegensatz zu dem Garmin-eigenen IMG-Format das OSM zugrundeliegende Namensschema beliebig erweiterbar ist.

Routing-fähige Karten aus OSM-Daten

Wer eine routuingfähige Karte möchte dem sei die auf OSM-Basis erstellte Karte der Mountainbiker empfohlen. In Wien habe ich diese kurz getestet und sie führt einen tatsächlich recht brav über Radwege und durch Einbahnstraßen – auch dann, wenn man kein Bergradl hat :-)

Info und Download hier http://openmtbmap.org/

Tipp: Auf meinem System konnte das mit dem Gmapi Builder erzeugte gmapi-Paket nicht richtig installiert und in Roadtrip nicht verwendet werden. Hier musste ich erstmals ein in einer VM installierten Windows-Rechner in Betrieb nehmen, das Material (tdb- und img-Dateien) nach MapSource (RoadTrip-Entsprechung auf Windows) importieren und dann mit dem Mac-Converter von Garmin in ein gmapi-Paket umwandeln. Dieses so erzeugte gmapi-Paket hat sich dann am Mac wiederum problemlos in Roadtrip einbinden und von dort auf das nüvi kopieren lassen.

Fazit

Für Autofahrten ist der City Navigator (bei mir die Version 2010) von Garmin, die ja auch kostenlos im nüvi mitgeliefert wird bis auf weiteres erste Wahl:  Tankstellen, KfZ-Werkstätten und Restaurants sind in großer Zahl erfasst. Für Fussgänger im urbanen Bereich sind Karten die aus den OSM-Datenbeständen erstellt wurden schon sehr brauchbar und eine wirklich ersntzunehmende Alternative, die heute schon in manchen Belangen den kommerziellen Garmin-Karten überlegen sind. Keine Erfahrung habe ich bisher wie die auf OSM basierenden Karten im ländliche Raum oder anderen Städten ausgestattet sind. Und eines habe ich mir auch schon hinter die Ohren geschrieben: Neben dem nüvi nehme ich immer noch Stadtplan, Kompass, Karten und andere Orientierungsutensielien mit, die keinen Akku brauchen, kein Betreibssystem haben, das sich mal eben so „aufhängt“ und auch dann noch Ihre Dienste tun wenn sie einem von weit oben auf den Boden fallen.

Advertisements
h1

SEO-Monitoring 3: Daten auswerten

27. Februar 2008

Wie in „SEO-Monitoring 2: Daten holen“ beschrieben, erhalten wir mit dem Skript get_google.pl jeden Tag ein neues Verzeichnis, in dem die Suchergebnisse als HTML-Files angelegt sind. Ein Vorteil des modularen Ansatzes (One task one tool) ist, dass es keineswegs nötig ist diese Verzeichnisstruktur mit dem Skript aufzubauen und zu befüllen. Genausogut kann man das manuell mit dem Browser machen, und die Seiten mit „Speichern als …“ als HTML-File ablegen. Das Skript get_google.pl macht ja nichts anderes, als einen „geskripteten“ Browser zur Verfügung zu stellen.

Results von get_google.pl (kleiner Ausschnitt)

In dem Bild oben sehen wir einen Ausschnitt aus dem Ergebnis von get_google.pl bei der Suche nach irgendwas in 1030 Wien um 9h05. Somit sind die Suchergebnisse für einen bestimmten Zeitpunkt und Begriff einmal vollständig archiviert, nur die Übersicht hat man so natürlich nicht … Daher ein weiteres Skript, das diese Verzeichnisse und alle Dateien systematisch durchsucht und daraus ein CSV-File (Kommaseperierte Datei) generiert. Dieses CSV-Ausgabefile soll z.B. aussehen wie folgt:

"Zeit[Epochenekunden]","Datum","Uhrzeit","Suchbegriff(e)","tad-position","ad-position","s-position","Anz. der Vorkommen in den S.E.",
"1204013102","2008-02-26","09h05","foo","0","1","11","2",
"1204013102","2008-02-26","09h05","bar","0","1","3","4",
"1204013102","2008-02-26","09h05","foo+bar","0","0","1","2",

So was sehen wir da oben nun: Zu dem Suchbegriff „foo“ wurde am 26. Februar um 9h05 eine bestimmte URL in den Google-Ergebnissen an der 11 Position angezeigt. In den Anzeigen (AdWords) war diese URL im rechten Block an 1. Stelle und im oberen Block gar nicht gelistet. In den ersten 100 Ergebnissen (ohne AdWords-Bereich), war diese URL 2 mal gelistet. Das alles entnehmen wir der ersten Zeile nach den Spaltenüberschriften (zweite Zeile im o.g. Ausschnitt).

Das bei Eingabe des Suchwortes „bar“ wird diese URL in den AdWords-Anzeigen oben nicht, auf der rechten Seite an erster Position und in den Suchergebnissen an 3. Stelle gelistet. Insgesamt ist diese URL 4 mal in den ersten 100 Ergebnissen zu finden. Das entnehmen wir der zweiten Zeile nach den Spaltenüberschriften (dritte Zeile im Beispiel oben).

Und nun die letzte Zeile: Hier wurde nach „foo bar“ gesucht. Die URL taucht in den Anzeigen gar nicht auf, dafür in den Suchergebnissen an erster Stelle und das zwei mal.

Dieses Beispiel ist übrigens fiktiv! Wenn jetzt wer verwundert innehält und frägt, was daran jetzt übersichtlich sein soll, sag ich – nur Geduld, denn eine CSV-Datei ist eine hervorragende Kandidatin für den Import in die unterschiedlichsten Anwendungen zur weiteren Verarbeitung.

Und damit zu dem Skript. Dieses benötig klarerweise einige Angaben: Nach welchen URLs in den Suchergebnissen gesucht werden soll; wo diese Suchergebnisse zu finden sind und wohin das CSV-File zu schreiben ist. Das meiste davon habe ich in dem Beispielskript fest kodiert – lediglich welches Unterverzeichnis in den Ergbnissen durchsucht werden soll wird beim Aufruf mitgegeben.

Damit das Skript ordentlich arbeiten kann, müssen beim Ablegen der Suchergebnisse als HTML-Files einige Konventionen eingehalten werden:

  • Das Basisverzeichnis für alle nun folgenden Verzeichnisse ist mit der Variable $basedir anzugeben. Es empfielt sich hier einen absoluten Pfad wie „/Users/Ingo/…./SEO-Monitor“ einzusetzen, wenn man das ganze mit einem Scheduler starten will.
  • In dem über die Variable $htmldir definierten Verzeichnis wird je befragtem Server ein eigenes Verzsichnis angelegt, z.B. http://www.google.ch. Je Tag ist ein eigenes Unterverzeichnis anzulegen im Format yyy-mm-dd.
  • Je Abfrage sind alle Ergebnisseiten zu benamsen wie folgt: Epochensekunden_Uhrzeit_Suchbegriffe_SSeite.html. Also z.B. sind die Ergebnisse 11-20 (zweite Seite) einer Suche nach „foo bar“ am 27 Februar 2008 um 15h55 auf google.at in dieser Datei abzulegen: /Users/Ingo/…/SEO-Monitor/google-results/www.google.at/2008-02-27/1204124118_15h55_foo+bar_S2.html

Aus dieser Datei bzw. ihrem Namen werden nun einige Informationen extrahiert: Die Zeit beispielsweise und die Seitennummer aber auch der Suchbegriff und der befragte Google-Server. Sehr wichtig ist die Kombination aus Zeit (Epochensekunden) und Suchbegriffen – diese definieren gemeinsam den Filegroupindex, legen also fest, welche Dateien zu einem bestimmten Suchbegriff und Zeitpunkt angelegt wurden. Alle Ergebnisse einer Filegroup werden dann in einer Zeile der ausgegeben CSV zusammengefasst!

Beispiel: Diese Dateien gehören zu ein und der selben Filegroup die den Namen „1204124118_foo+bar“ trägt:

1204124118_15h55_foo+bar_S1.html
1204124118_15h55_foo+bar_S2.html
….
1204124118_15h55_foo+bar_S100.html

Je wie oft nun die gesuchten URLs in den Suchergebnissen vorkommen, findet sich dann in einer Zeile des ausgegeben CSV-Files.

Das Skript durchsucht in seinem Hauptteil nun Token für Token jeder Datei. zunächst wird der Suchbegriff extrahiert. (Dieser ist zwar auch im Dateinamen zu finden, aber wir nehmen lieber den aus der Datei). Dann wird gesucht:

  • Auf Seite 1:
  • Anzeigen rechts, hier gibt es das Tag „<a id=an1, …“ – das ist praktisch, denn die Nummer gibt die Position wieder. Ablegen in einen Hash (%ad_pos) mit dem Filegroupindex als Schlüssel.
  • Anzeigen oben, hier gibt es das Tag „<a id=pa1, …“ – siehe oben. Ablegen in einen Hash (%tad_pos) mit dem Filegroupindex als Schlüssel.
  • Auch wenn es unwahrscheinlich ist, dass die selbe URL in den Anzeigen auf Seite 1 mehrfach vorkommt, so wird doch vom Skript sichergestellt, dass die jeweils beste Position erhalten bleibt.
  • Auf Seite 1 und allen folgenden Seiten
    • Die Tags der Suchergebnisse; wenn href und class=l, dann in diesem Tag nach den URLs suchen; das jeweils beste Position wird in einen Hash (%s_pos) mit dem Filegroupindex als Schlüssel abgelegt.

    Es werden also Anzeigen auf den Seiten 2-100 ignoriert – das entspricht aber dem normalen Userverhalten – wer schaut schon auf Seite 2 auf eine Anzeige?!

Sonst ist noch anzumerken, dass natürlich mehrere URLs gesucht werden können, z.B. apartments-wien.at und apartments-vienna.at – die jeweils beste Position wird in der Ausgabe angezeigt. Das ist sinnvoll, da so manche Organisation ja den selben Webauftritt unter verschiedenen URLs anbietet.

Am Ende des Skriptes wird dann ermittelt, welche Dateigruppen es gab – diese landen in einem Array namens @uFGIs (uniq FileGroupIndices). Dessen Elemente werden dann der Reihe nach in die Hashes %ad_pos usw. eingesetzt und so das CSV-File geschrieben.

That’s it. Zur Auswertung dieses CSVs dann wann anders.

P.S. Ja der Quellcode, den veröffentliche ich demnächst hier:

http://ingo.lantschner.name/Nagios.html

h1

SEO-Monitoring 2: Daten sammmeln

20. Februar 2008

Wie beschrieben, das Ziel ist über jene Schnittstelle, die auch der Benutzer einsetzt – also einen Webbrowser – zu erfassen, was Google bezüglich bestimmter Suchergebnisse anzeigt. Dies erledigt das Skript get_google.pl:

#!/usr/bin/perl -w
# get_google.pl -  query Google.at und speichere Ergebnis in eine Datei
# Rev. 0.6a # Copyright 2008 by Ingo Lantschner (ingo@boxbe.com)  # http://ingo.lantschner.name   # This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.   # You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.   use strict;
use LWP::UserAgent;
use URI::Escape ('uri_escape');
use Time::localtime;
my $debug =1;
my @search = (	"foo+bar",
		"foo",
		"bar",
		); ## Suchbegriff hier!
my $path_prefix = "./google-test";
my $heute = localtime;
my $epochensekunden = time();
my $browser = LWP::UserAgent->new;
$browser->agent("Mozilla Firefox");

# Verzeichnis anlegen ( ./<path_prefix>/JJJJ-MM-TT/)
chdir "/Users/ingo/Sites/seo/SEO-Monitoring/Versuch2"; # wegen Aufruf durch Apple-Skript
my $datum = sprintf("%04d-%02d-%02d", $heute->year+1900, $heute->mon+1, $heute->mday);
printf "$datumn" if $debug > 1;
my $path = $path_prefix . "/" . $datum;
print "$pathn" if $debug > 1;
if ( -d $path ) {
	printf "Info: Verzeichnis $path existiert schon.n" if $debug > 0;
} else {
	mkdir $path
	  or die "Fehler: Kann Verzeichnis $path nicht anlegen: $!";
}

foreach	(@search) {
	print "nSuchberiff: $_n" if $debug > 1;
	my $store = $path . "/" . "$epochensekunden" . "_" . $heute->hour . "h" . $heute->min . "_" . "$_";
	my $i = 0; # Zähler für Seiten
	while ( ++$i < 11 ) {
		my $file = $store . "_S$i.html"; # Seitennummer an Dateiname anhängen
		print "Dateiname: $filen" if $debug > 0;
		if ( $i == 1 ) { # Seite 1
			my $response = $browser->get(
		  		'http://www.google.at/search?hl=de&q=' .
				uri_escape($_) .
				'&btnG=Suche&meta=',
				':content_file' => $file,
			);
			die "Error: ", $response->status_line
			 unless $response->is_success;
		} else { # Seiten 2 bis ... (http://www.google.at/search?q=apartment+wien&hl=de&start=10&sa=N)
			my $start = ($i - 1) * 10; # Startzahl: 10, 20, ... 100
			print "Start: $startn" if $debug > 1;
			my $response = $browser->get(
		  		'http://www.google.at/search?q=' . uri_escape($_) . '&hl=de&start=' . $start . '&sa=N',
				':content_file' => $file,
			);
			die "Error: ", $response->status_line
			 unless $response->is_success;
			}

		my $wartezeit = 6; # Warten nächste Seite
		print "Wartezeit auf nächste Seite $i: $wartezeitn" if $debug > 1;
		sleep $wartezeit;
	}
	my $wartezeit = 8; # Warten nach Suchbegriffwechsel
	print "Wartezeit zum nächsten Suchbegriff: $wartezeitn" if $debug > 1;
	sleep $wartezeit;
}

Hinweis: Vor dem Einsatz dieses Scripts, ist die Erlaubnis dazu von Google einzuholen!

Als Ergebnis erhalten wir im Verzeichnis, das mit

my $path_prefix = "./google-test";

definiert wurde jeden Tag ein neues Unterverzeichnis, das dann mit den HTML-Files gefüllt wird: Jede Abfrage (also jeweils 10 Suchergebnisse) in einer Datei. Das ist dann zum Parsen zwar eine echte Herausforderung, dafür hat diese Methode den Vorteil, dass sie auf den Voreinstellungen für Google beruht und daher die „User-Experience“ der meisten Benutzer exakt wiedergibt. Klar wäre es verlockend gewesen, sofort 100 Ergebnisse im Google anzeigen zu lassen. Nur verändert Google das Ranking auch abhängig davon, wie viele Ergebnisse je Seite man anzeigen lässt. Daher diese etwas mühsamere Methode.

Ausgewertet (parsing der HTML-Files) wird mit einem anderen Modul – diese Trennung halte ich für wichtig, weil so jederzeit auf die historischen Daten noch einmal zurück gegriffen werden kann.

h1

SEO-Monitoring 1: Grundlagen

19. Februar 2008

Platzierung im Google systematisch beobachten – Professionelles Monitoring für Whitehat-SEOs

Die letzten Wochen habe ich mich damit beschäftigt, Webseiten in der wohl wichtigsten Suchmaschine auffiindbar zu machen. Zu den veschiedenen Techniken und was davon erlaubt und was unerwünscht ist, existieren jede Menge Artikel im Netz – ich gehe hier auf dieses Thema nicht weiter ein.

Was mir gefehlt hat, war eine Möglichkeit, die Fortschritte und Rückschläge meiner Arbeit systematisch protokoliert zu haben und sie so auswerten zu können.

Auf Grund meiner Kenntnisse in Nagios und Perl, war es naheliegend diese Werkzeuge einzusetzen. Bei der Frage, wie ich an die Ergebnisse der Suchmaschine herankomme entschied ich mich letztendlich für Abfragen mittels Perlskript und LWP. Die von Google angebotenen Schnittstelle Ajax ist mir zu riskant, denn ich will die Rohdaten so bekommen, wie sie ein Benutzer auch sieht, der die Suchbegriffe in Google eintippt. Übrigens: Google möchte nicht, dass seine Server automatisiert abgefragt werden, ohne dass man sich dazu vorher die Erlaubnis holt. Das sollte man bedenken und es ist sicher sinnvoll, bezüglich der Häufigkeit der Abfragen Maß zu halten und die sleep-Funktion einzusetzen.

Aufbau:

Das System besteht aus zwei Teilen:

1. get_google.pl speichert die Ergebnisse der Abfragen als HTML-Dateien auf Festplatte. Abgefragt werden die ersten 100 Ergebnisse um den Fortschritt bei der Optimierung verfolgen zu können.

2. parse_google.pl liesst diese Dateien aus, sucht die zu überwachenden URLs und erstellt eine CSV-Datei mit Zeit und der Platzierung dieser URL. Berücksichtigt werden sowohl die Anzeigen (falls jemand Google-Ads verwendet) und die Suchergebnisse.

3. Eine dritte Komponente sollte erlauben, Änderungen an den optimierten Seiten und Google-Add-Kampagnen mit Zeitstempel zu erfassen um diese dann in die aus 2.) erstellten Grafiken und Übersichten einblenden zu können.

Soviel für heute, Details folgen demnächst.

h1

Installation von Ubuntu Linux auf FuSi RX100 S2

9. September 2007

Im folgenden fasse ich einige Notizen zusammen, die ich mir vor ca. einem Jahr bei der Installation des Prototypen für einen „Linux Small Business Servers“ gemacht habe.

Grundlegendes

Der Linux Small Business Server basiert auf der Serverversion von Ubuntu (dzt. 6.06 LTS). Auf dem Server wird kein GUI installiert, also kein X, kein Windowmanager und schon gar kein Desktop. Dies hat einerseits Performancegründe aber vor allem Stabilitäts- und Sicherheitsgründe. Vgl. z.B. Linux Magazin 01/06, S 70, „Wo immer möglich empfiehlt es sich folglich, auf das X11-System für administrative und sicherheitsrelevante Aufgaben zu verzichten.“
Doku für Grundlegendes: Serverguide von Ubuntu https://help.ubuntu.com/ubuntu/serverguide/C/index.html

Proxy setzen

Wenn man innerhalb einer größeren Organisation arbeitet, ist damit zu rechnen, dass man nicht direkt auf das Internet zugreifen darf sondern über einen Proxy raus muss. Das ist bei der Installation von Debian-Derivaten insofern von Bedeutung, als während der Installation Pakete über das Netz aktualisiert werden. Ist der Proxy nicht korrekt eingetragen, so steht die Installation für ca. 10 Minuten. Administratoren mit schwachen Nerven, glauben dann, das System sein abgestürzt.

Der Proxy für den Download kann seit Ubuntu 6.06 während des Setups eingetragen werden. Hierbei wird jedoch nicht die Umgebungsvariable HTTP_PROXY gesetzt, sondern ein Eintrag in der /etc/apt/apt.conf vorgenommen. Um den Proxyserver bei zukünftigen Verbindungen wieder auszulassen, ist die Zeile hinten abzuschneiden. Sie lisst sich dann noch so:

Acquire::http;

Partitionierung

Allgemeine Empfehlung

Partitionierungstabelle

prim.   /       8GB
 prim    /swap   4GB
 prim.   /daten  restl. Plattenplatz

Partitionierung FuSi RX100 S2

Die in diesen Geräten gelieferten FakeRAID-Controller (aka „Software RAID“) sind zu nix zu gebrauchen. Daher besser ein Linux Software RAID aufsetzen.

BIOS-Einstellungen einer RX100 S2 für diese Konfiguration

  • SATA, Ubuntu kommt mit den SATA-Platten gut zurecht
  • RAID-Controller (Onboard) deaktivieren
  • Large Disk Mode auf Other
  • HD-Boot Auto/…???

Manche Optionen im BIOS sind gut versteckt, man muss über das Bildschirmende weiter nach unten blättern, um sie zu sehen!

Konfig im OS für Linux SW-RAID (u.a. auf FuSi RX 100)

RAID 1 (Spiegelung): siehe Software RAID 1 für Ubuntu Server →https://lanti.wordpress.com/2007/09/09/software-raid-1-fur-ubuntu-server/

Best Practices nach dem ersten Reboot

Einige Empfehlungen, was nach dem ersten Reboot noch konfiguriert werden könnte.

1. Sources konfigurieren
Aktiviert bleiben: „updates“, „major bugfixes“ und „security“

# vi /etc/apt/sources.list
deb http://at.archive.ubuntu.com/ubuntu breezy main restricted
deb http://at.archive.ubuntu.com/ubuntu breezy-updates main restricted
deb http://security.ubuntu.com/ubuntu breezy-security main restricted

Hinweis: deaktiviert wird die CD-ROM als Source für Updates!
2. Systemupdate

# apt-get update && apt-get upgrade

3. SSH-Server installieren

# apt-get install openssh-server

4. Ctrl-Alt-Del deaktivieren
In einer gemischten Windows-/Linuxumgebung kommt man leicht durcheinander. Um zu verhindern, dass durch irrtümlichen Affengriff auf die Tastatur des Linux Servers dieser einen Neustart durchführt, ist die entsprechende Zeile in der /etc/inittab auszukommentieren:

...
# What to do when CTRL-ALT-DEL is pressed.
#ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
...

5. vi als Standardeditor:
Die folgende Zeile in die Datei /root/.bash_profile einfügen:

export VISUAL=vim

6. Zeitsynchronisation:
Im Verzeichnis /etc/cron.hourly ein Script zeitsync anlegen, mit folgendem Inhalt:

#!/bin/sh
/usr/sbin/ntpdate -s -u time.xxx.at ntp.ubuntulinux.org

Links

Download von http://releases.ubuntu.com/ubuntu-server/6.06/.

h1

OpsMgr an Nagios …

9. August 2007

OpsMgr meldet an Nagios

System Center Operations Manager 2007 ist der von Microsoft vertriebene Systemmonitor. SCOM ist Nachfolger des MOM und seit kurzem verfügbar. Uns interessiert inwieweit dieser mit der bewährten Open Source Lösung Nagios interoperabel ist.

Na endlich, nach etlichen Irrwegen die wegen mangelnder Dokumentation des OpsMgr (Kurzname für den System Center Operations Manager oder SCOM2007) alle im Sande verliefen, haben wir nun einen gangbaren Weg gefunden, über den der OpsMgr dem Nagios den Zustand seiner Schäfchen signalisieren kann. Dazu wurde ein eigener SMTP-Handler entwickelt, der die vom OpsMgr versendeten Alert-Emails empfängt und an Nagios als Passivcheck übergibt.

SCOM(OpsMgr)-Nagios-Schnittstelle entwickelt in Zusammenarbeit mit der NTx BackOffice Consulting Group, 1010 Wien

h1

Die harte Tour zur sicheren Signatur – Teil 3: Ein Absturz und ein hilfreiches Update

8. August 2007

Kartenleser

Nachdem am iMac die sichere Signatur endlich geklappt hat, wollte ich das ganze bei einer Präsentation auf einem Macbook vorführen. Gut dass ich es vorher getestet habe – denn die Anwendung (der TrustDesk) stürzte reproduzierbar jedesmal ab. Doch auch diesmal hat sich der Support von ITSolution als kompetent und hilfreich erwiesen: Ein noch nicht öffentliches Update (tdb274.dmg) wurde mir testweise zur verfügung gestellt und das läuft am Macbook stabil. Und noch eine Verbesserung ist mir aufgefallen: Die in der im tdb274.dmg enthaltenen Version zeigt gegenüber der Version 2.7.0-Mac auch bei der Validierung signierter UTF-8 Klartextdateien die Umlaute als solche an.