Neues in der Kategorie linux server

Im Gegensatz zur Novemberinstallation läuft seit etwa einem Monat bei mir Google's mod-pagespeed im "produktiven" Einsatz. Es sind keine Auffälligkeiten zu erkennen. Alles stabil!

Zur Funktion, das heißt "Schnelligkeitszuwachs des Apachen", kann ich leider wenig Aussagen machen. Aber trotzdem eine winzige Neuentdeckung:

Beim heutigen Update des Paketes...

$ wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.deb
$ sudo dpkg -i mod-pagespeed-*.deb
Vorbereiten zum Ersetzen von mod-pagespeed-beta 0.9.15.3-r404 (durch mod-pagespeed-beta_current_i386.deb) ...
Entpacke Ersatz für mod-pagespeed-beta ...
Richte mod-pagespeed-beta ein (0.9.16.3-r534) ...

... ist nur eines aufgefallen:

Die Installation des .deb-Paketes erzeugt ein Paket-Quelleneintrag in der Datei

/etc/apt/sources.list.d/mod-pagespeed.list
_______________________________________________________________
### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out this entry, but any other modifications may be lost.
deb http://dl.google.com/linux/mod-pagespeed/deb/ stable main
_______________________________________________________________

Vielen Dank Google, dass ihr Euer Programm auf meinen Server so "very convenient" aktuell halten möchtet. Ich hätte doch lieber gern einen Hinweis bei der Installation bekommen.

Nun gut sei es drum. Nun weiß ich es ja.
Die Pakete sind anscheinend auch noch nicht in der Quelle hinterlegt, heißt ja auch "stable". Ansonsten hätte das heutige Update ja keinen "Versiönchen"-Sprung angezeigt.


Na dann vielen Dank an die fleißigen Programmierer. Einer mehr testet mal das pagespeed-beta....
...ich weiß bisher nur noch nicht, ob es was bringt (und wie ich es vernunftbegabt testen kann)!

Update:

Heute sendete mir der apticron-Dienst meines Servers folgende Mail:

apticron report [Wed, 16 Mar 2011 23:48:18 +0100]
========================================================================

apticron has detected that some packages need upgrading on:

        www.tobis-home.de
        [ 123.456.7.8 ]

The following packages are currently pending an upgrade:

        mod-pagespeed-beta 0.9.16.9-r576

========================================================================

Damit ist klar, dass die Paketquelle vom mod-pagespeed "stable" auch für die Betaversion funktioniert.

Mit der Einwilligung zum Update: $ sudo apt-get dist-upgrade
ist nun die aktuelle Version installiert. Bisher gibt es keine Probleme damit!


Update2:

apticron report [Mon, 16 May 2011 23:48:21 +0200]
========================================================================

apticron has detected that some packages need upgrading on:

        www.tobis-home.de
        [ 123.456.7.8 ]

The following packages are currently pending an upgrade:

        mod-pagespeed-beta 0.9.17.6-r698

========================================================================


auch installiert!

Update3

apticron report [Thu, 19 May 2011 23:48:21 +0200]
========================================================================

apticron has detected that some packages need upgrading on:

        www.tobis-home.de
        [ 123.456.7.8 ]

The following packages are currently pending an upgrade:

        mod-pagespeed-beta 0.9.17.7-r716

========================================================================

läuft jetzt!
Heute hat Google den Webserver-Mod mod_pagespeed als Open Source freigegeben. Das musste ich gleich mal ausprobieren. Da mein Upload für den Webserver nicht allzu üppig ist, wäre das ja eine super Alternative.

Herunterladen+Installieren:

ich habe das heute freigegebene fertig kompilierte Paket installiert, das hier zu finden ist:

http://code.google.com/intl/de-DE/speed/page-speed/download.html

Terminaleingaben wie folgt: (# = Kommentare, $ = Terminal-Eingabezeilen, alles andere = Terminal-Ausgaben)

$ wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.deb
$ sudo dpkg -i mod-pagespeed*.deb

Entpacke mod-pagespeed-beta (aus mod-pagespeed-beta_current_i386.deb) ...
Richte mod-pagespeed-beta ein (0.9.0.0-r128) ...
Enabling module pagespeed.
Run '/etc/init.d/apache2 restart' to activate new configuration!

$ sudo apt-get -f install
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Status-Informationen einlesen... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

$ sudo /etc/init.d/apache2 restart
 * Restarting web server apache2
 ... waiting

--> so, nun isses fertig!

Konfigurieren:

In der Datei /etc/apache2/mods-available/pagespeed.conf  kann man noch Einiges konfigurieren. Mich hat hier lediglich der Zugriff auf die Statistiken interessiert. Sonst habe ich die Voreinstellungen belassen.

Ich habe den letzten Abschnitt angepasst, der wie folgt aussieht:

   <Location /mod_pagespeed_statistics>
        Order allow,deny
        # You may insert other "Allow from" lines to add hosts you want to
        # allow to look at generated statistics.  Another possibility is
        # to comment out the "Order" and "Allow" options from the config
        # file, to allow any client that can reach your server to examine
        # statistics.  This might be appropriate in an experimental setup or
        # if the Apache server is protected by a reverse proxy that will
        # filter URLs in some fashion.
        #Allow from localhost
        Allow from 192.168.1.0/24
        SetHandler mod_pagespeed_statistics
    </Location>

Die fett markierte Zeile hat meinem Desktop-Rechner Zugriff auf die mod_pagespeed-Statistiken des Servers verschafft. Mit der Eingabe http://[meine-domain oder Server-IP]/mod_pagespeed_statistics  im Browser konnte ich mir die Aktivitäten anschauen. Das sah so aus:

resource_fetches: 0
total_page_load_ms: 0
page_load_count: 0
cache_extensions: 0
not_cacheable: 0
css_file_count_reduction: 0
css_filter_files_minified: 0
css_filter_minified_bytes_saved: 0
css_filter_parse_failures: 0
css_elements: 0
image_inline: 0
image_rewrite_saved_bytes: 0
image_rewrites: 0
javascript_blocks_minified: 0
javascript_bytes_saved: 0
javascript_minification_failures: 0
javascript_total_blocks: 0
url_trims: 0
url_trim_saved_bytes: 0
resource_404_count: 0
slurp_404_count: 0
serf_fetch_request_count: 0
serf_fetch_bytes_count: 0
serf_fetch_time_duration_ms: 0
serf_fetch_cancel_count: 0

Nach einigem Rumklicken auf den Webseiten zählten die Zahlen fleißig immer höher. Das Verzeichnis /var/mod_pagespeed wurde mit vielen zwischengespeicherten Dateien gefüllt. Alles toll schnell?

Nicht so ganz: Mein indianischer Webserver hat da den einen oder anderen, großen oder auch kleinen Hänger gezeigt. Es fing mit kurzen Verzögerungen an, auch Reload-Versuche mit F5-gedrücke ohne Erfolg.

Insgesamt lief das mod bei mir etwas mehr als 4 Stunden (ab 15 Uhr) ohne mein Dazutun. Danach habe ich viel rumprobiert und auch den Server genutzt. Die Aktivitäten sind natürlich in die Höhe geschnellt. Ich habe den Apachen ab 21 Uhr auch hin und wieder neu gestartet, deshalb die Einbrüche. Anhand der folgenden Munin-Plots kann man den Einfluss des pagespeed-mods deutlich erkennen.

Der helle Bereich zeigt den Zeitraum, in dem mod_pagespeed aktiv war.

apache_accesses-day.jpgapache_activity-day.jpgapache_processes-day.jpgcpu-day.jpgmemory-day.jpgprocesses-day.jpgDie Plots für Memory und CPU zeigen keine deutlichen Anstiege. Die Apache-Aktivität, sowie auch dessen Prozesse steigen kontinuierlich im Quasi-Leerlauf.

Abschließend habe ich den mod wieder deaktiviert, da er statt pagespeed nur pagebrake war.

$ sudo a2dismod pagespeed

Die Verzögerungen können sicherlich auch an meinem 1GHz-Server liegen, obwohl die Auslastungsdaten etwas anderes zeigen. Vielleicht ist der Kleine ja wirklich zu lahm für solch tolle Bandbreiteneinsparungen=Komprimierungen. Nur ist für mich fraglich, wie da die Verhältnismäßigkeiten sind. Brauche ich da viel Rechenpower um etwas Bandbreite einzusparen? Bringt das nur was, wenn viele Anfragen auf die einmal komprimerten Daten kommen? Was ist, wenn sich an meinem Output laufend was ändert? Oder ist der mod_pagespeed einfach nur total verbuggt?

Fragen über Fragen! ...is ja auch die beta-Version und vielleicht muss ich mich auch mehr in die Konfiguration einlesen - aber ich versuche es dann mal mit einer späteren Version aus. Danke Google!

Es ist schön zu wissen, dass man mit einem Linux-Server bedenkenlos in neue Hardware umziehen kann. Allerdings hatte ich es noch nie ausprobiert.
Endlich war es soweit, meine alte 500Mhz-Kiste wird durch eine alte 1000Mhz-Kiste ersetzt... mit hoffentlich wenig Aufwand.

So, Festplatte umgebaut, angeschaltet, fertig. Und nun!? Das Netzwerk und jegliche damit zusammenhängenden Dienste liefen nicht. Das Netzwerk ist mit das Wichtigste was einen Server ausmacht. Das ausgerechnet dies nun nicht funktioniert, hatte ich echt nicht gerechnet. Ohje, was nun.

Das Netzwerkgerät eth0 war nun eth1 und wurde schlichtweg nicht benutzt. Schreck lass nach!

Man muss die Zuordnung zu eth0 irgendwie manuell umstellen. Etwas Recherche hat mich auf folgende Datei gebracht:

/etc/udev/rules.d/70-persistent-net.rules
____________________________
# This file maintains persistent names for network interfaces.
# See udev(7) for syntax.
#
# Entries are automatically added by the 75-persistent-net-generator.rules
# file; however you are also free to add your own entries.

# Converted from /etc/iftab on upgrade
#SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:12:34:89:ab:d1", ATTRS{type}=="1", NAME="eth0"


# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="01:23:45:90:bc:d2", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
____________________________

In dieser Datei wird nur die Zuordnung des "network device" von 1 auf 0 gestellt (letzte Zeile) und der alte Eintrag auskommentiert. Nach einem Neustart lief der Kleine und der Umzug war geschafft!


Ich habe immer meine Blog über die Weboberfläche gefüttert. Das war immer recht zeitraubend und hat insbesondere meinen kleinen Küchenserver überfordert. Das Warten hat riesig genervt.

Es gibt da so einige Clientsoftware für Blogs die man benutzen kann. Leider hatte das alles nie funktioniert. Habe ich mich dusselig angestellt?

Heute versuchte ich es mal wieder mit "Bilbo Blogger", dem ehemaligen Blogilo. Im Ubuntu schnell installiert:

sudo apt-get install bilbo

Und jetzt den Blog einrichten:

Im Menü - Blog -> Blog hinzufügen...

Habe ich nach einem Klick auf "Automatische Konfiguration" den Vorschlag bekommen "xmlrpc.php" an die URL zu hängen. Ein Blick in das Webverzeichnis meines Servers sagte mir, dass das eine CGI-Datei namens "mt-xmlrpc.cgi" sein muss.

User: [Mein Webusername]

Passwort: Mein Webuserpasswort]

Danach Folgendes:

Bildschirmfoto-EinneuesBloghinzufügen.jpg

brachte nach einem Klick auf "Automatische Konfiguration"

Bildschirmfoto-Fehler-BilboBlogger.jpg

Nun gut, das sehe ich ein... versucht:

Bildschirmfoto-EinneuesBloghinzufügen-1.jpg

"ID abrufen" geklickt:


Bildschirmfoto-Fehler-BilboBlogger-1.jpg











Der Übersetzungsfehler störte mich weniger als das rote Kreuzchen.

Einiges Herumforschen in den Einstellungen in der Weboberfläche meines MovableType brachte mich darauf, dass ich wohl ein Passwort für Webdienste eingeben muss.

Bildschirmfoto-ProfilbearbeitenMovableTypePro.jpg


Der Klick auf "Anzeigen" hat mir die Erleuchtung gebracht: Ein vom System zufällig gewähltes Passwort ist das im Bilbo zu verwendende.

Der Upload funktioniert großartig ganz gut, nur mit den Bildern gibts bisher noch Probleme. Vielleicht landen durch bilbo jetzt mal ein paar mehr Einträge auf Tobis Blog.


Jeder, der sich entschließt seinen eigenen Server ins Netz zu stellen, möchte auch von außen aus den Internet darauf zugreifen können. Es liegt nichts näher, als einen SSH-Dienst zu installieren. Mit ihm kann man sich von extern einloggen und seinen Server administrieren.

Nun ist es einmal Fakt, dass Botangriffe etc. an der Tagesordnung sind. Das Primärziel solcher Angriffe ist demzufolge dieser Dienst. Die Hoffung auf Erfolg ist hier am größten.

Prinzipiell muss man dem Standarduser "root" die Rechte entziehen, da der Username feststeht was dem Angreifer die Loginversuche vereinfacht. Der eigentliche Administrator des Rechners sollte allerdings den SSH benutzen dürfen, er ist in der Gruppe "admin"

In der Konfigurationsdatei /etc/ssh/sshd_config sind dazu folgende Einträge vorzunehmen:

PermitRootLogin no

AllowGroups admin

Heute hatte ich einmal wieder viele kleine Einlogversuche, und zwar zu diesem SSH-Dienst. Da die Einlogversuche quasi unbegrenzt vorgenommen werden können ohne geblockt zu werden, hat dies meine Nervosität schon einmal gefördert...

Etwas Suchen hat geholfen: Es gibt da ein Tool "denyhosts".


Dieses Tool scannt in regelmässigen Abständen die Protokolldatei /var/log/auth.log in der Authentifizierungsfehler aufgelistet werden. Tauchen von einer IP mehrere Fehler auf, wird diese in die Datei /etc/host.deny eingetragen und somit dauerhaft abgewiesen. Verschiedene Modifikationen dieser Konfiguration können vorgenommen werden. Es gibt selbst auch eine öffentliche hosts.deny-Liste, die erweitert bzw. abgerufen werden kann.


Einfach installiert:
$ sudo apt-get install denyhosts

Prinzipiell muss man nichts konfigurieren. Die Konfigurationsdatei /etc/denyhosts.conf ist quasi selbsterklärend und auch sehr gut kommentiert.

Standardmäßig wird nur der SSH-Dienst überprüft:

BLOCK_SERVICE = sshd

Möchte man die Namensauflösung der IP-Adressen aktivieren:

HOSTNAME_LOOKUP=YES

Sonst habe ich lediglich einige optionale Einträge geändert, welche mir im Falle eines neuen Deny-Eintrages eine Mail schicken:

############ THESE SETTINGS ARE OPTIONAL ############

ADMIN_EMAIL = foo@bar.com

SMTP_FROM = Mein DenyHosts <foo@bar.com>

SMTP_SUBJECT = Tobis DenyHosts Report

#dem Syslog-Dienst bescheid geben

SYSLOG_REPORT=YES
######### THESE SETTINGS ARE SPECIFIC TO DAEMON MODE ##########

DAEMON_LOG = /var/log/denyhosts

DAEMON_SLEEP = 30s

Das war's und schwuppdiwupp waren sechs IP-Adressen in der host.deny:

Ein Auszug aus der von denyhosts generierten Mail an den root:
200.96.33.210 (unknown)
217.133.194.98 (static-217-133-194-98.clienti.tiscali.it)
123.233.245.226 (unknown)
148.243.223.210 (na-148-243-223-210.na.avantel.net.mx)
222.191.251.133 (unknown)
68.167.156.30 (h-68-167-156-30-static.lsanca54.covad.net)

Ab sofort werden diese Hostadressen sofort abgewiesen.

 
Falls sich bei den veröffentlichten IP's jemand auf den Schlips getreten fühlt (unknown) hat wohl in dem Fall ein dynamisches IPech.

Über dieses Archiv

Diese Seite enthält aktuelle Einträge der Kategorie linux server.

backup ist die vorherige Kategorie.

storage ist die nächste Kategorie.

Aktuelle Einträge finden Sie auf der Startseite, alle Einträge in den Archiven.

Archiv

Mai 2014

So Mo Di Mi Do Fr Sa
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Aktuelle Kommentare

  • petruschka: halooo, wer hatt auch was sinn volles, für windows 7 weiterlesen
  • Tobias Hesse: Danke für Eure Kommentare, das mit dem "makeactive" ist 'ne weiterlesen
  • Jürgen: DANKE... Nach vielen erfolglosen Versuchen und Suchem im Netz bin weiterlesen
  • Anonym: Danke für die Info! Ich bin auch über das Problem weiterlesen
  • Patrick: Hi Tobi, danke für deinen Kommentar. Über deine Seite war weiterlesen
Creative Commons License
Dieses Blog steht unter einer Creative Commons-Lizenz.