Mal ehrlich: Viele von uns sind froh, wenn sie einen Webserver halbwegs unfallfrei betreiben können. Die gängigen Linux-Distributionen machen es einem leicht, schnell ein funktionierendes System mit Apache, PHP und MySQL aufzusetzen.
Doch die Standard-Einstellungen sind oft optimierungswürdig. Zwei einfache Möglichkeiten, den RAM-Bedarf des neuen, hochglänzenden Servers auf debian-artigen Distributionen erheblich zu reduzieren, zeige ich Euch hier.
Vor einigen Monaten hatte ich über die Freuden der automatischen Informationsaufbereitung geschrieben. Und über das Zwei-Komponenten-Setup, das ich dafür verwende: einen RSS-Aggregator sowie das “Social Media Cockpit” – darunter verstehe ich eine Plattform, die nicht nur zum Konsumieren von Inhalten, sondern auch zum Interagieren auf sozialen Netzwerken geeignet ist.
Ersteres ist relativ unspektakulär: RSS-Aggregatoren sind Brot-und-Butter-Anwendungen. Ob man nun den Google Reader benutzt, Netvibes, Pageflakes oder etwas Selbstgehostetes, spielt keine große Rolle. (Von dem hier beschriebenen Posh bin ich allerdings mittlerweile wieder zu Netvibes zurückgekehrt – Posh hat mir dann doch zu viele ärgerliche, unprofessionelle Fehlerchen, die das Arbeiten damit auf Dauer eher lästig gestaltet haben.) Aber das nur nebenbei.
Knackiger werden die Anforderungen bei der zweiten Komponente, dem Social Media Cockpit. Hier ist nicht nur das übersichtliche Zusammenführen der Aktivitäts-Streams gefragt, sondern auch eine leistungsfähige Interaktion mit den sozialen Netzwerken. In letzter Zeit habe ich die gängigen kostenlosen Tools durchprobiert – hier folgt ein kurzer Erfahrungsbericht.
Weiterlesen: [Social Media Cockpits – ein Überflug]
Nachdem ich im ersten Teil beschrieben habe, wie ich automatisch lokale (d.h. auf dem Server selbst liegende) Sicherungen wichtiger Dateien und der Datenbanken erzeuge, wird es nun Zeit, das Ganze zu einem “echten” Backup auszubauen.
Natürlich empfiehlt es sich, die Sicherungen herunterzuladen und auf dem heimischen PC nochmals abzulegen. Aber wie es der Zufall will, kann es passieren, dass man einmal etwas wiederherstellen muss, wenn man gerade unterwegs ist und nur ein Notebook mit UMTS – oder noch schlimmer, nur ein Internet-Cafe – zur Verfügung steht. Mit diesen Mitteln kommt man vielleicht per Putty auf den Server, aber nicht an die Backups, die jetzt so dringend nötig wären.
Die hier vorgestellte Lösung kommt, wenn sie fertig eingerichtet ist, mit einem Shell-Zugang auf den Server aus, um jede beliebige Datei, Datenbank oder auch ganze Verzeichnisse wiederherstellen zu können. Um sie nutzen zu können, ist ein Root-Zugang auf dem Server oder VPS erforderlich. Und wieder gelten alle hier gemachten Angaben für Debian.
Die Sicherungen selbst werden wir bei Amazon S3 lagern, in der Cloud also. Damit keine unbefugten Augen unsere Daten ausspähen, werden wir alles verschlüsseln. Amazon garantiert eine Verfügbarkeit von 99,99% (das ist deutlich besser als bei den meisten Webhosting-Providern), und auch wenn es sich hierbei um einen bezahlten Service handelt, liegen die monatlichen Kosten tatsächlich nur im Pfennigbereich. (Eine Preisübersicht findet sich hier.)
Abgeschaut habe ich mir die Vorgehensweise in einem Posting von Michael Martin (ProBlogDesign) und gebe die nötigen Schritte hier mit Michaels freundlicher Genehmigung übersetzt und etwas erweitert wider.
Weiterlesen: [Webserver-Backup für Dummies 2: Backup in der Cloud]
Heute geht es um ein ausgesprochen lästiges Thema. Dies ist die dunkle Seite des Webmaster-Daseins. Das unkreative Pflichtprogramm. Schrecklich, im Ernst.
Backups sind ja bekanntlich was für Feiglinge. Aber diejenigen unter uns, die einen Webserver betreiben, kennen vielleicht das Gefühl, das einen beschleicht, wenn die Kiste auf einmal nicht mehr erreichbar ist:
Ups. Ob nur der Apache abgestürzt ist? Oder ist es etwas Schlimmeres? Hat vielleicht das Script, das ich vorgestern installiert habe, Fürchterliches angerichtet? Oder ist die Festplatte / das Mainboard / eine andere wichtige Komponente abgeraucht?
Herzschlag und Körpertemperatur steigen. Adrenalin wird ausgeschüttet. Wir gehen nervös auf und ab. Die beste Ehefrau von allen beginnt zu fragen, ob alles in Ordnung ist.
Irgendwann hat dann der Hosting-Provider die Maschine gebootet, die Website ist wieder da, und wir beruhigen uns allmählich.
Dass der letzte Zeitpunkt, an dem wir alles per FTP runtergesichert haben, vielleicht schon die eine oder andere Woche her ist, rückt erst einmal wieder in den Hintergrund, und wir sagen uns, na klar müssen wir uns dann mal bald um eine gute Backup-Routine kümmern. Aber da im Augenblick erstmal wieder alles funktioniert, hat das ja noch einen Moment Zeit. Und so lehnen wir uns wieder zurück – bis zum nächsten Adrenalinschub.
So, ihr Prokrastinatoren dieser Welt. Das ist unverantwortlich. Und ihr wisst es.
Shared Hosting
Wer auf einem Shared-Hosting-Account unterwegs ist, kann sich schlimmstenfalls nicht auf ein providerseitiges Backup verlassen. Wer die Möglichkeit hat, über eine Administrations-Oberfläche wie z.B. cPanel selbst Backups zu erstellen, sollte das tun – und sich die Backups in regelmäßigen Abständen herunterladen. Ansonsten eben per Handarbeit mit MySQLDumper und FTP. Das deckt bei Billighosting dann auch schon das Spektrum der Möglichkeiten ab. Ja, ihr Shared-Hosting-Kunden müsst euch zwingen, immer wieder diese lästige Aufgabe zu erledigen.
Der eigene Root-Server
Wer aber einen eigenen Server (oder auch einen VPS) mit Root-Zugriff betreibt, dem stehen weitreichende Alternativen zur Automatisierung von Backups offen. Und wer das nicht nutzt, ist selbst schuld. Vor allem, wenn mehrere Websites (und vielleicht sogar Kunden-Websites) auf dem Server gehostet werden. Aber es ist nicht wirklich schwierig. Das Root-Dasein bringt viele wunderbare Vorteile mit sich, und die werden wir nutzen. Dummerweise stößt man oft beim Recherchieren auf lauter Geek-Speak-Howtos, von denen man keine Ahnung hat, wie man sie für die eigene Situation konkret umsetzen kann.
Also genug der Vorrede – das hier heißt schließlich Klartext – und direkt zur konkreten Nutzung. Im ersten Schritt beschreibe ich, wie ich auf Root-Servern mit Debian vollautomatisch Backups wichtiger Dateien und der MySQL-Datenbanken in einem separaten Bereich auf dem Server anlege. Der zweite Teil des Artikels wird sich dann mit der weiteren Verarztung dieser Backups beschäftigen.
Weiterlesen: [Webserver-Backup für Dummies 1: Lokales Backup]
Im ersten Teil des Artikels habe ich ein Plädoyer für die automatisierte Vogelperspektive gehalten.
Nicht: “Ich verschaffe mir einen Überblick”, sondern “Der Überblick kommt zu mir”.
Nicht: “Die Vorzimmerdame stellt mir morgens die Presseclippings zusammen” – ich habe leider keine, also Vorzimmerdame meine ich -, sondern: “Fleißige elektrische Bienchen bereiten mir die Neuigkeiten, die mich interessieren, permanent auf”. So wie es sich für Informationsarbeiter gehört.
Im zweiten Teil versuche ich nun etwas mehr ins Konkrete abzugleiten.
Ich bin Informationsarbeiter in einem Informationsberuf, der sich um das Web dreht. Mein Job ist es, informiert zu sein. Mein Job ist es außerdem, zu kommunizieren. Mit den verschiedensten Zielgruppen: Menschen, die von mir etwas gelöst haben möchten. Menschen, mit denen ich gemeinsam an etwas arbeite. Menschen, mit denen man sensationell kreative Diskussionen führen kann. Menschen, die mir etwas sagen, was ich noch nicht wusste. Menschen, denen ich durch meine Erfahrung helfen kann.
Das Informiert-Sein ist meistens Voraussetzung dafür, diese Gespräche sinnvoll führen zu können. Wie könnte ich zum Beispiel mit jemandem produktiv über die aktuellen Social-Media-Trends sprechen, wenn ich sie gar nicht kenne?
Das träge Zeitalter der Zeitungen ist vorbei, auch wenn “unzweinullige Menschen” das vielleicht noch nicht so sehen. Ja, das Lesen des Feuilletons und fundierter Hintergrundinformationen hat natürlich immer noch seine Berechtigung. Es hilft dabei, sich gelegentlich etwas zurückzunehmen und mal wieder die Vogelperspektive einzunehmen, sich über die großen Zusammenhänge klar zu werden. Aber wenn es um das Medium geht, in dem wir arbeiten, haben traditionelle Medien eine viel zu geringe Frequenz. Wir sind nämlich schon mittendrin im Realtime-Netz. Pusubhubbub lässt grüßen.
Die Weisheit der Masse ist ein Phänomen, das überhaupt nur online und mit den Informationstechnologien, die sich heutzutage immer schneller entwickeln, in dieser Form stattfinden kann. Menschen reden online über alle erdenklichen Themen. Manche oberflächlich, manche mit Expertenwissen, manche negativ, positiv, alle Facetten sind vertreten. Und natürlich passieren die Gespräche über genau die Themen, die uns Informationsarbeiter bewegen, online. Oder wer will allen Ernstes Einzelheiten über die neueste pfiffige Verknüpfung mehrerer APIs zu einem genialen Mashup in irgendeiner Print-Publikation nachlesen, acht Wochen nachdem dieses Mashup veröffentlicht wurde und alle Welt schon in hellem Aufruhr darüber ist?
Das ist das Feld, in dem wir Informationsarbeiter uns bewegen. Wir tragen unsere Informationen online zusammen und diskutieren sie sowohl online, indem wir darüber bloggen und twittern, aber auch offline, indem wir uns zum Beispiel mit den Kollegen zusammen einen Kaffee holen und über die denkbaren Implikationen sprechen. Wir müssen diese Kollegen aber in der Regel nicht erst von Adam und Eva an in das Thema einführen, weil sie uns schon auf Twitter gefolgt sind, oder unseren Blogeintrag zum Thema gelesen und schon kommentiert haben. Sie sind bereits mittendrin.
Unzweinullige Menschen, die mein Blog lesen oder meine Aktivitäten in sozialen Netzwerken verfolgen, haben mich manchmal tatsächlich schon gefragt: “Klaus, surfst du eigentlich den ganzen Tag im Internet, oder woher kommt das, dass du so viele Infos postest?”
Den ganzen Tag surfen? Gott bewahre. Dazu bin ich viel zu sehr ein Effizienz-Junkie. Zielloses Herumgesurfe ist nicht effizient – es ist ein Zeichen von Prokrastination und davon, dass man nicht weiß, was man mit seiner Zeit Besseres anfangen soll. Böse. Böse.
Was diese Menschen offenbar noch nicht erfahren haben, ist, dass das heutige Web nicht mehr das Web der neunziger Jahre ist. Damals konnte man tatsächlich nur “surfen” – also über die vorgegebenen Links von Seite zu Seite hüpfen -, es gab noch keine Suchmaschinen, man war ziemlich ziellos unterwegs. Damals war das zweifellos ganz irre. Ich erinnere mich noch gut, wie ich Anfang 1993 (da stand das Web kurz vor der Freigabe für kommerzielle Zwecke) im Rahmen meiner ersten Internet-Erfahrungen völlig begeistert war, dass ich von einer amerikanischen Hochschulseite per Link plötzlich auf einer japanischen Universität gelandet war, die Einzelheiten zu ihren astronomischen Forschungsgebieten veröffentlichte. Wahnsinn, Japan! Die Globalisierung hat so einen Geruch nach Aufbruch und Abenteuer! (Und meine Telefonrechnung machte dank eines langsamen 2400-Baud-Modems ebenfalls einen Quantensprung.)
Informationsarbeiter gehen heute nicht mehr so vor. Wir haben begriffen, dass es inzwischen Möglichkeiten gibt, wie wir an die Informationen kommen, ohne ständig hier- und dorthin surfen zu müssen. Wir lassen sie uns nämlich frei Haus liefern.
Mit Feed-Readern, Aggregatoren und allerlei anderen Instrumenten sorgen wir dafür, dass das prokrastinierende Herumgesurfe ein Ende hat. Wir definieren, was uns interessiert, und bekommen dann genau diese Themen, nach unseren Vorlieben gefiltert, aktiv von wundersamen Automatismen auf unseren Desktop oder in unseren Browser geschoben. Und das ist Effizienz. So bleiben wir informiert, so verteilen wir schnell Informationen weiter, und so sind wir sofort im Gespräch über die neuesten Entwicklungen.
Wie ich das für mich genau nutze, schreibe ich im zweiten Teil. Weil, heute abend bin ich müde, und nicht mehr effizient genug. Ich wünsche allen Informationsarbeitern ein erholsames Wochenende mit ausreichend Offline-Zeit und vielleicht auch dem einen oder anderen guten Zeitungsartikel.
Hier gibt es ein kurzes E-Book, in dem glasklar und prägnant sieben gute Gründe aufgeführt werden, die für das Scheitern von Intranets verantwortlich sein können. Netterweise wird auch aufgezeigt, wie man es stattdessen besser machen kann.
Why your marketing intranet fails
Auch wenn sich das E-Book auf Intranets von Marketing-Agenturen bezieht, gibt es keinen Grund, die aufgestellten Thesen nicht auch auf andere Intranets anzuwenden. Für Führungskräfte und Intranet-Verantwortliche ein Augenöffner.
Seit heute früh ist mein Blog – wohl dank der Beschreibung der Migration von Joomla nach WordPress – bei der Google-Blogsuche konstant auf Platz 1 für den Begriff “WordPress”. Heiliger Strohsack. Dabei hab ich doch gar kein SEO betrieben und komme gerade erst frisch zu WordPress …

Nach meinem arbeitsreichen Migrations-Wochenende kommt hier für Gleichgesinnte eine Übersicht der Vorgehensweise. Vielleicht kann ja manch einer etwas damit anfangen.
Ausgangslage: Das alte Blog lief auf einer sicherheitsgepatchten Fossil-Version Joomla 1.0.13 (jaja, ich weiß). Alle Blogfunktionalitäten, die über die rückwärts chronologische Darstellung von Beiträgen hinausgingen, waren durch Joomla-Extensions angeflanscht (Kommentare: JomComment, Ping: Weblog Ping, usw.).
Aufgabenstellung: Ohne mühselige Copy&Paste-Arien die Inhalte auf WordPress 3 migrieren.
Weiterlesen: [Migration von Joomla 1.0.x nach WordPress 3]
… zumindest auf diesem Blog. Seit heute läuft es mit WordPress.
Nach fast einem Jahr des Nichtbloggens und meiner immer geringer werdenden Sympathie zu Joomla werde ich hier in Zukunft die Themen etwas weiter fassen. Es gibt ja schließlich nicht nur Joomla, Mambo usw. In den letzten Monaten habe ich mich intensiv mit vielen anderen Technologien und Konzepten beschäftigt, über die es auch vieles zu schreiben gibt.
Leider konnten bei der Umstellung die bisherigen Kommentare nicht mit transferiert werden. Tut mir leid, Leute. Aber das bringt dieser Neustart leider mit sich. Die Links klemmen hier und da vielleicht auch noch ein wenig.
Auf ein Neues!
|
|
|
Letzte Kommentare