Webseite horizontal zentrieren

Dezember 22nd, 2010

Viele meiner neueren Webseiten enthalten ein großes Hintergrundbild, vor dem positionierte Divs exakt eingefügt werden müssen.

Trotzdem soll die Webseite – egal mit welchem Browser oder Auflösung/Fenstergröße – horizontal immer mittig ausgerichtet sein.

Das funktioniert mit einem Div, das den gesamten Code (natürlich innerhalb von <body>) umschliesst und das relativ positioniert sein muß:

.back
{
position: relative;
top: 0px;
left: 0px;
width: 1242px; /* Hintergrundbildbreite */
height: auto;
margin-left: auto;
margin-right: auto;
text-align: left; /* fuer IE 6 */
}

Den BODY ändern wir für den IE 6 noch wie folgt:

BODY
{
background-color: #FDFCE8; /*benötigte Hintergrundfarbe */
text-align: center; /* fuer den IE 6 */
}

Jetzt können die zu positionierenden Divs absolut positioniert werden, denn sie sollen Childs von .back sein, z.B. für das Hintergrundbild jetzt:

.hintergrund
{
position: absolute;
top: 0px;
left: 0px;
width: 1242px;
height: auto;
}

und so fort.

Der HTML Code ist dann z.B. so:


<body>
<div class=”back”>
<div class=”hintergrund”><img src=”hintergrund.jpg” width=”1242″ height=”768″></div>
… hier kommen alle anderen zu positionierenden Inhalte hinein
</div>

Ich habe das an allen mir zugänglichen Browsern unter Windows, Mac und Linux ausprobiert (inklusive dem IE 6 unter Windows) und es funktioniert einwandfrei.

Mails von stillgelegten Mailserver holen

September 30th, 2010

Vor einigen Monaten habe ich meine Mail umgestellt. Statt vom eigenen Mailserver hole ich sie seither über einen Google-Account. Dazu war auch die Änderung von Nameserver-Einträgen nötig.

Es dauert sehr lange, so habe ich festgestellt, bis alle Mails den neuen Weg gehen. Immer noch tröpfeln einige auf den alten Mailserver auf den ich lediglich ssh-Zugang habe. Mit dem uralten Linux-Programm mail können wichtige Irrläufer weitergeleitet werden. Das geht so:

Das Kommando “mail” öffnet eine Liste aller vorhandenen Mails (mit Nummern davor) und führt in einen interaktiven Modus. Findet sich eine Mail, die an eine alternative Adresse weiterzuleiten ist, dann merkt man sich deren Nummer.

Mit “m ponnath@andere-adresse.de” startet man die Erstellung einer Mail, füllt das Subject aus etc.

Dann kann man mit “~m NachrNr.” die weiterzuleitende Mail einfügen (mit ~M auch die Header).

Und schließlich sendet man sie dann durch Eingabe eines Punktes in die nächste Zeile (und Return) ab.

So einfach – aber bis ich das heraus hatte, oh, oh.

Teiltransparente divs

Februar 25th, 2010

Seit CSS3 gibt es die opacity-Definitionen, mit deren Hilfe man einen Milchglaseffekt erzeugen kann: durch den so definierten Bereich kann man dann – mehr oder weniger transparent – den Hintergrund scheinen sehen.

Wendet man das auf einen div-Container an, dann ergeben sich so interessante gestalterische Effekte. Allerdings tritt dabei das Problem auf, daß daß nicht nur der Hintergrund des divs durchscheinend wird, sondern auch alle darin enthaltenen Inhalte (Texte, Bilder, etc.). Das ist oft nicht so beabsichtigt.

Im Netz finden sich mehrere Lösungsansätze, z.B.
Dirk Jesse Transparente Hintergründe mit CSS (crossbrowser) – High Resolution Weblog
<http://www.highresolution.info/weblog/entry/transparente_hintergruende_mit_css/>
setzt auf ein zusätzliches div.

Eric Eggert yatil!: Cross-Browser rgba()
<http://yatil.de/Weblog/cross-browser-rgba> opfert die
Rückwärtskompatibilität und setzt auf rgba

Oder man arbeitet mit einem teiltransparenten PNG.

Die beiden Ansätze funktionierten bei mir nicht, jedenfalls nicht mit dem aktuellen IExplorer 8.0.6001… Ich vermute, das lag an etwas seltsamen
Zeilen:
-ms-filter:”progid:DXImageTransform.Microsoft.Alpha(Opacity=50)”;
bzw.
filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#4CFFFFFF,endColorstr=#4CFFFFFF);

Und auch die Sache mit dem teiltransparenten PNG habe ich erstmal beiseite gelassen.

Stattdessen konnte ich das Problem dadurch lösen, daß ich einfachzwei divs definiert habe, exakt an der gleichen Position und mit gleicher Größe.

Das erste div hat diese Eigenschaften:

.opakbox {

background-color: White;
/* fuer IE */
filter: alpha(opacity=60);
/* Standard CSS3 */
opacity: 0.6;
}

Das ist das teiltransparente div. Es muß genau unter dem nächsten liegen – notfalls mit Festlegungen in der z-Ebene. Bei mir wird es einfach vor den
anderen aufgerufen.

Das zweite div unterscheidet sich von diesem lediglich durch das Weglassen der opacity-Definitionen und es enthält sicherheitshalber noch die Festlegung der
Hintergrundfarbe auf transparent:

.transbox{

background-color: transparent;
}

Mir scheint das die sauberste Lösung zu sein. Bisher habe ich sie auf folgenden Browsern ausprobiert: MsIE 7.0.5730 und 8.0.6001, Firefox 3.6,
Opera 9.10, Safari 4.0.4, Google Chrome 4.0.249 unter Windows XP, Safari 4.0.4 unter Mac, Iceape 1.0.9 und Konqueror 3.5.9 unter Linux. Letzterer
beherrscht offenbar die opacity-Definitionen nicht und stellt den Hintergrund weiss dar. Da hilft auch die angeblich dafür funktionierende Anweisung
-khtml-opacity: 0.6;
nicht. Weitere (und ältere) Browser werde ich ausprobieren, wenn die Seite über das Internet erreichbar ist.

Eine harte Nuss: Typo3 Website spiegeln

November 11th, 2008

Das hatte ich mir einfacher vorgestellt! Eine Typo3-Website, die online ist, sollte auf einem anderen Computer gespiegelt werden.

Ein Grund dafür war, daß mir immer etwas unwohl war bei dem Gedanken daran, wie schwer oder wie einfach es wohl wäre, nach Störungen aus einem Backup die Website wiederherzustellen. Mir kam es sicherer vor, die gleiche Webpräsenz auf meinem lokalen Computer vorrätig zu haben.

Ein weiterer Grund war, daß ich immer etwas Scheu hatte, einige Dinge direkt auf dem Originalrechner auszuprobieren. Mir erschien es sicherer, für Experimente zunächt nur das lokale Spiegelbild zu verwenden.

Im Prinzip geht das ganze eigentlich ganz einfach: Der lokale Rechner  arbeitet – wie der Server im Web – unter Debian Linux etch, verwendet die gleiche Version von Apache2, PHP und MySQL. Mittels mysqldump sollte die Datenbank auf dem Server im Web gespeichert und dann auf dem lokalen Rechner wieder hergestellt werden. Außerdem waren die entsprechenden Verzeichnisse 1:1 auf den lokalen Rechner zu übertragen.

Gesagt, getan. Die Arbeit wurde dadurch erleichtert, daß ich auf dem Quellrechner auch Administratorrechte habe. Andererseits wollte ich so wenig wie möglich den laufenden Betrieb des Webservers und seine Sicherheitskonfiguration stören.

Das erste Problem hatte seine Ursache darin, daß es aus Sicherheitsgründen nicht möglich ist, sich direkt als Root in den Quellserver einzuloggen. Zunächst war das noch nicht als Problem erkennbar, denn sobald ich per ssh als normaler User eingeloggt war, konnte ich per su ganz schnell Root werden.

Ich habe dann per

mysqlshow -u root -p -h localhost

und Eingabe des Passworts schnell den Namen der gewünschten Datenbank festgestellt. Dann konnte ich die nötigen Verzeichnisse in einen dem normalen User zugänglichen temporären Bereich kopieren.

Danach hatte ich vor, einfach per scp alles auf meinen lokalen Rechner zu schieben – da kam dann das Problem zutage: Ein scp vom Quellrechner aus war nicht möglich, denn der Zielrechner verfügt zum einen nicht über eine feste IP-Adresse und liegt zum anderen hinter einer Firewall in einem lokalen Netzwerk- wie hätte ich also den Zielrechner bezeichnen sollen? Ein scp aber vom Zielrechner aus war ebenfalls nicht möglich, denn dazu hätte ich mich auf dem Quellrechner im scp-Befehl als root einloggen müssen- und das ist wie oben schon gesagt nicht möglich. Vermutlich hätte es für gewiefte Linuxer doch irgendeinen Dreh gegeben,so gut bin ich aber in Linux nicht und mußte daher einen anderen, leider etwas komplexeren Weg gehen, der das Kopieren der Verzeichnisse als normaler User möglich macht.

Mein Weg war es,  alle betroffenen Verzeichnisse und Dateien auf dem Quellrechner zum Eigentum des Users und seiner Gruppe  zu machen. Das war ohne weiteres möglich, weil ich ja mit einer Kopie in einem temporären Userverzeichnis arbeitete. Danach konnte ich dann per scp als normaler User die kompletten Verzeichnisse auf den Zielrechner schieben. Der Haken an dieser Lösung ist es leider, daß danach alle Eigentumsverhältnisse und Rechte wieder auf den Ursprungswert gestellt werden müssen, was etwas Geduld erfordert hat.

Nachdem auf diese Weise gewissermassen das Bett vorbereitet war, konnte ich nun auf dem Quellrechner (als Root) den Datenbank-Dump erstellen:

mysqldump -u root -p –opt –databases Datenbankname > backup.sql

Das ging gottlob sehr schnell und hat den laufenden Zugriff auf die Typo3-Website sicher kaum behindert. Nach kopieren in den temporären User-Ordner und ändern der Eigentümerschaft war auch diese Datei schliesslich auf dem lokalen Rechner gelandet.

Zum Wiederherstellen der Datenbank habe ich dann eingegeben:

mysql -u root -p Datenbankname < backup.sql

Das Ergebnis war die Fehlermeldung

ERROR 1049 (42000): Unknown database ‘Datenbankname’

Da wurde dann klar, daß zunächst einmal per mysql auf dem Zielrechner die Datenbank namens Datenbankname angelegt werden musste! Das war lösbar nach ein wenig MySQL-Lektüre und danach liess sich auch der obige mysql-Befehl  zum Füllen der erzeugten Datenbank ohne Fehlermeldung ausführen.

Bei einem versuchten Start der Benutzeroberfläche der jetzt kopierten Typo3-Website auf dem lokalen Rechner kam es allerdings wieder zu Fehlern. Der Grund lag darin, daß sich Passworte und Nutzernamen auf dem Quell- und dem Zielrechner unterschieden. Um auch dieses Hindernis noch auszuräumen ist es nötig die Datei localconf.php zu editieren und die entsprechenden Zeilen, die sich damit befassen zu verändern.

Außerdem habe ich mir eine Sache nicht so genau gemerkt: Beim versuchten Start der Typo3-Konfigurationsseite wird ein neues Passwort verlangt, welches auf der gleichen Seite unten dann in verschlüsselter Form zu sehen ist. Dieses verschlüsselte Passwort muß dann ebenfalls in die entsprechende Zeit der Datei localconf.php eingetragen werden.

PDF aus InDesign-Datei ergibt weisse Kästen um Objekte mit Schlagschatten

April 23rd, 2008

Eine InDesign-Kundendatei ergab bei der Umwandlung in ein PDF-X3-Format weissliche Kästen um Objekte (Schrift und Grafik) mit Schlagschatten, die in der Überdrucken-Vorschau allerdings verschwunden waren.

Eine genauere Überprüfung der InDesign-Datei ergab, daß unterschiedliche Farbsysteme eingesetzt waren: Der Hintergrund war als HKS-Farbe angegeben, zwei Bilder lagen im RGB-Format vor, der Rest bestand aus CMYK-Daten. Erst nach der Umwandlung der Hintergrundfarbe in eine CMYK-Farbe war die sich ergebende PDF-X3-Datei frei von den weisslichen Kästen.

Fazit: Am besten sollten alle eingesetzten Farben als CMYK-Farben vorhanden sein. Eine Mischung von Farbsystemen führt leicht zu Problemen. Sollte es mal aus irgendwelchen Gründen unumgänglich sein, HKS-Farben einzusetzen, dann muß der Druckerei mitgeteilt werden, daß auf der RIP-Maschine die Option Überdrucken eingeschaltet sein muß.

Einschränkung: Möglicherweise gibt es für PDF-X4-Dateien andere Regeln.

AWSTATS: Alte Log-Dateien nachträglich einbinden

September 1st, 2007

Es ist mir passiert, daß ich erst nach der Einrichtung von awstats für einige Server festgestellt habe, daß mir einige ältere Log-Dateien fehlten. Der Wunsch des Kunden war es aber, auch diese in der Log-Auswertung sehen zu können. Gottlob waren die fraglichen Server erst vor kurzem eingerichtet worden, sodaß sich nur diese Log-Dateien in /var/log/apache2 fanden (Beispiel):

access-server1.log (das aktuelle Log)
access-server1.log.1
access-server1.log.2.gz (ab hier komprimiert)

access-server1.log.6.gz

Natürlich läßt sich das Problem bei größeren Mengen alter Log-Dateien mit einem eleganten Skript besser lösen, weil ich aber nicht so firm in der Erstellung von Skripten bin, habe ich einfach schnell alles von Hand gemacht. Und so läßt sich das Problem lösen:

1. Kopien der alten Log-Dateien in ein temporäres Verzeichnis

2. Entzippen dieser Dateien mit gunzip

3. Auskommentieren der entsprechenden Zeilen im Cronjob (bei mir in /etc/cron.d/awstats), damit nicht unversehens der cronjob dazwischen funkt.

4. Löschen der bisher schon vorhandenen Statistik-Dateien von awstats. Sie finden sich bei mir in /var/lib/awstats und heißen z.B. awstats062007.server1.txt (für den Statistik-File für Juni 2007 des Servers, dessen Konfigurationsdatei awstats.server1.conf heißt).

5. In chronologischer Reihenfolge wende ich dann awstats.pl an, z.B.:

/usr/lib/cgi-bin/awstats.pl – config=server1 -LogFile=”/var/log/apache2/tmp/access-server1.log.6″ -update

/usr/lib/cgi-bin/awstats.pl – config=server1 -LogFile=”/var/log/apache2/tmp/access-server1.log.2″ -update

6. Dann muß ich das noch für die beiden ursprünglich nicht komprimierten Dateien ausführen:

/usr/lib/cgi-bin/awstats.pl – config=server1 -LogFile=”/var/log/apache2/access-server1.log.1″ -update

und

usr/lib/cgi-bin/awstats.pl – config=server1 -update

7. Und zu guter letzt in cron.d die Auskommentierung noch wegnehmen, damit wieder regelmäßige Upadtes automatisch erfolgen können.

Und schon sind die Statistik-Angaben wieder aktuell und um die alten Log-Dateien ergänzt.

Natürlich sollte zum Abschluß das temporäre Verzeichnis noch geleert und gelöscht werden.

AWSTATS für mehrere Server verwenden

September 1st, 2007

Es ist einfacher als ich dachte, awstats für mehrere – in diesem Fall virtuelle – Server einzurichten:

1. In der Apache-Konfiguration sollte zunächst dafür gesorgt werden, daß jeder virtuelle Server eine eigene Logdatei verwendet (z.B. access-server1.log).

2. Jetzt nimmt man einfach die vorhandene awstats.conf und kopiert sie in eine neue Konfigurationsdatei namens awstats.server1.conf.

3. In diesen conf-File ist nun noch der Name des Servers einzutragen (z.B. www.server1.de) und der Name (und der Pfad) zur dazu gehörigen Log-Datei (also z.B. /var/log/apache2/access-server1.log).

4. Jetzt muß ich noch awstats für server1 anwerfen. Bei mir
/usr/lib/awstats/awstats.pl -config=server1 -update

5. Und in die crontab den dazu gehörigen Eintrag einbauen (bei mir ist das in /etc/cron.d/awstats )

6. Der Aufruf über das Web lautet dann z.B. so: http://www.server1.de/cgi-bin/awstats.pl?config=server1

Das funktioniert natürlich bei beliebig vielen virtuellen Servern.

AWStats installieren und konfigurieren unter Debian Sarge

November 9th, 2006

Auf dem Server eines Kunden sollte ein OpenSource Statistik-Tool eingerichtet werden. Die Wahl fiel auf AWStats, weil es von allen mir bekannten Tools dieser Art die am besten aufbereiteten Informationen aus den Logs zieht und auch die Präsentation sehr übersichtlich und vor allem in deutscher Sprache arbeitet.

Der erste Teil der Installation geschieht auf die übliche Debian-Art mittels:

aptitude update
aptitude install awstats

Dabei werden die nötigen Programme, Konfigurationsdateien etc. gleich automatisch erzeugt und an die richtigen Stellen gepackt. Unter anderem entstehen:
/usr/lib/cgi-bin/awstats.pl, /etc/awstats/awstats.conf und das Verzeichnis /var/lib/awstats/
Außerdem wird in /etc/cron.d ein Cronjob erzeugt, der ebenfalls awstats heisst.

Jetzt ist es spätestens an der Zeit , sich einige Parameter zur auszuwertenden Log-Datei anzusehen. Ich verwende Apache2 als Server, weshalb die Logdatei /var/log/apache2/access.log heisst. Und auch die Art der Logdatei ist wichtig: Bei mir ist es “combined”. Das kann in den Konfigurationsdateien des Servers festgestellt werden. Und von Bedeutung ist auch noch der Name der Website, die beobachtet wird, also z.B. www.beispiel.de .
Es folgen nun einige Einstellungen in der Konfigurationsdatei /etc/awstats/awstats.conf . Also Öffnen dieser Datei mit einem Editor und Festlegen dieser Werte:
LogFile erhält als Wert den Pfad zur Logdatei: /var/log/apache2/access.log
LogType bekommt (weil es sich um ein Web-Log handelt) den Wert: W
LogFormat enthält eine Schlüsselzahl für die Art des Logs. “Combined” wird durch die Zahl 1 bezeichnet.
SiteDomain soll den vollen Namen der Website enthalten, hier also www.beispiel.de
HostAliases kann weitere Bezeichnungen der Domain auflisten: z.B. localhost 127.0.0.1 etc.

Die Konfigurationsdatei ist gut dokumentiert und mit Beispielen versehen. Einfach mal durchblättern und eventuell weitere Parameter verändern – und dann speichern der Datei.

Jetzt ist AWStats schon funktionsfähig. Es muß aber zunächst einmal der erste Auswertungslauf vollzogen werden, damit die Daten aus der vorhandenen Logdatei verarbeitet werden. Das geschieht von der Kommandozeile aus mittels:

perl awstats.pl -config=www.beispiel.de -update

Das kann eine Weile dauern – je nach Größe der aktuellen Logdatei – und endet dann mit einem kleinen Statusreport.

Wenn wir jetzt zum ersten Mal das Ergebnis sehen wollen, dann geht das am besten mit einem Webbrowser. Diese Adresse wird aufgerufen:

http://www.beispiel.de/cgi-bin/awstats.pl?config=www.beispiel.de

Voila: AWStats funktioniert und bringt einen detaillierten Bericht über viele interessante Aspekte des Zugriffs auf unsere Website.

Nachtrag: die Angabe config=www.beispiel.de führt dazu, daß awstats nach einer Konfigurationsdatei namens awstats.www.beispiel.de.conf sucht. Wird solch eine Datei nicht gefunden, dann nimmt awstats automatisch die Default-Konfiguartionsdatei dafür, die awstats.conf heißt.
Ein Wermutstropfen ist leicht zu beheben: Es werden keine Icons angezeigt! Das läßt sich schnell ändern durch einen Symlink. Dazu schreiben wir in das Wurzelverzeichnis unserer Website (meist ist das /var/www/) eine Symlink namens awstats-icon, der auf das Verzeichnis /usr/share/awstats/icon weist. Und schon sind die Icons nach einem Reload der Seite sichtbar.

Damit nun das Log auch automatisch alle 10 Minuten ausgewertet wird, hat Debian bei der Installation schon eine Cron-Datei erzeugt: /etc/cron.d/awstats . Das Problem dabei ist aber, daß sich zeigt, daß dieser Job zwar regelmäßig angestossen wird, sich aber keine Ergebnisse der Cron-Läufe in der Statistik zeigen. Die Ursache dafür liegt in den Rechten, die Apache2 den Log-Dateien gibt: Sie gehören root und der Gruppe adm, sollen aber von www-data gelesen werden. Die Lese-Schreibrechte lauten aber auf 640, was das Lesen nicht erlaubt.

Um sie lesbar zu machen, sollte dafür 644 verwendet werden. Dazu öffnet man am einfachsten mit einem Editor die Datei /etc/logrotate.d/apache2 und ersetzt in der 8.Zeile die Zahl 640 durch 644. Jetzt speichern – und von nun an wird tatsächlich alle 10 Minuten die Statistik ergänzt um die neuen Werte aus dem Log.

Es gibt noch eine ganze Reihe weiterer Aspekte von AWStats, die zu bearbeiten wären:

1. Es kann sein, daß sich die Log-Rotation und der Einsatz des Cronjobs so überschneiden, daß ein paar Log-Einträge verloren gehen. Um das zu verhindern, muß im Ablauf der Log-Rotation noch ein Aufruf von awstats erfolgen als sog. prerotate.

2. Man kann mittels AWStats auch mehrere Websites getrennt voneinander beobachten.

3. Sicherheitsfragen: Wie kann der Zugriff auf die Statistik am effizientesten beschränkt werden.