Installiert man Drupal fällt zuerst auf, das das „Backend“ ein eigenes Theme bekommen hat und nicht mehr identisch mit dem Frontend Theme ist. Es sind also out-of-the Box ein Theme für Frontend und ein Theme für das Backend installiert und aktiviert. Hier wird wohl dem Umstand Rechnung getragen, dass das alte „Garlend“ Theme für Administrationszwecke eher suboptimal war und nur schwer anpassbar war. Der Admin Bereich wirkt nun deutlich aufgeräumter und übersichtlicher. Man hat merklich an der Usability Schraube gedreht. Eine weitere Neuerung, die schnell ins Auge sticht ist, dass sich die Anzahl der Core Module erhöht hat. So ist z.B. das  Image Modul sofort bei jeder Installation dabei. Jeder Content Type hat default mässig auch ein „Image Feld“. Außerdem sind ImageCache, ImageField und FileField sofort aktiviert. Weitere Module können nun auch direkt über das Backend installiert werden, was z.B. von WordPress kennt. Man kann nun auch Installationsprofile anlegen. Damit ist es z.B. möglich eine firmeninterne Standart Drupal Installation an- zulegen, bei der diverse Module und Einstellungen automatisch installiert werden. Einstellarbeit wird dadurch reduziert. jQueryUI hat es nun auch zu den Core Modulen geschafft. Außerdem ist es wohl möglich eine „MulitSite“ Installtion anzulegen.

Wann erscheint Drupal 7?

Derzeit liegt Drupal 7 in einer frühen alpha Version vor. Genaue Angaben, wann die erste „stable“ Version erscheinen soll, gibt es derzeit nicht. Von den Core Entwicklern gibt es nur ein „Wenn it‘s done“ zu lesen. Den Meinungen in der Community zu beurteilen. ist wohl nicht vor Jahresende mit einer finalen Version zu rechnen. Bevor produktive Projekte mit Drupal 7 umgesetzt werden können, bleibt zudem abzuwarten welche wichtigen Module bis dahin für diese Version verfügbar sind.

Anforderungen

Zuerst fällt auf, dass bei Drupal 7 mindestens PHP in Version 5.2.0 benötigt wird. Ob dies auf auf eine Objekt Orientierte Entwicklung (OOP) zurückzuführen ist, (die erst ab PHP 5 möglich wäre) werden wir später klären. Drupal 7 benötigt im Vergleich zu Drupal 6 ein mehr als doppelt so hoches Arbeitsspeicher Limit wie Drupal 6. Dies muss allerdings nicht unbedingt schlecht sein
Eine Neuerung in Drupal 7 ist, dass nicht zwangsweise MySQL als Datenbank benötigt wird, sondern (fast) jedes beliebige Datenbank System benutzt werden kann.strong>Ist Drupal 7 Objekt Orientiert?
Neben den allgemeinen Änderungen, die wohl hauptsächlich die Anwenderschicht interessieren dürfte, schauen wir nun mal unter die Haube, was sich für die Entwickler ändert. Das Drupal 7 nun PHP 5.2 als Anforderung stellt, könnte auf eine OOP Struktur hinweisen. Eine Umsetzung mit OOP würde einiges leichter machen, so sind nach Ansicht der meisten Entwickler die Umsetzung von Design Patterns nur mit OOP Systemen möglich, der Code wäre leichter zu lesen, Core Methoden könnten endlich überschrieben werden.
Der Drupal Core besteht aus 2 Verzeichnissen, einem include Verzeichnis und einem Core Modul Verzeichnis. Im Include Verzeichnis findet man die größte Änderung – die Datenbank Funktionen. Die wurden nämlich durch den PHP Abstraktions Layer ersetzt – und ist OOP. Damit ist es möglich Drupal z.B. auch mit einer Oracle Datenbank zu betreiben. Außerdem ist es nun leichter möglich Datenbank Abfragen leichter zusammen zuhacken.
Schaut man sich nun die Drupal Core Module an, wird man festellen, dass sich nicht viel geändert hat. Vom prinziplillen Aufbau hat sich nicht viel geändert, die funktionale Programmierung bleibt, statt Objekte gibt es weiter hin Arrays und statt Klassen gibt es immer noch Module.
Die Antwort lautet – nein Drupal 7 ist nicht Objekt orientiert.

Ist Drupal 7 abwärtskompatibel?

Die Frage kann man so nicht direkt beantworten. Es wird wohl so wie in den vergangenen Versionen sein, dass es Möglichkeiten gibt bestehende Projekte zu portieren. Da sich aber auch diesmal die Drupal API ändern wird, kann man von keiner generellen abwärtskompatibilität sprechen

Fazit

Drupal 7 wird sicherlich einige Kritikpunkte der alten Versionen ausmerzen, den Code teilweise entschlacken, und manche Dinge leichtermachen – aber aus Programmierersicht kein großer neuer Schritt sein. Man wird so wie ich das für diesem Moment beurteilen kann, an der Usability Schraube drehen, viele bewährte Module gleich in den Core mit aufnehmen, die Übersicht im Backend vereinfachen, aber unter der Haube bleibt es zumindest im groben und ganzen gleich.

Nach derzeitigen Informationen ist es allerdings weiterhin nicht möglich, direkt den Wlan-key auszelesen, wohl aber kann man gefälschte Pakete in das fremde Netz einschleusen. Zum Einsatz kommt hier eine “Man in the middle” Attacke, bei der der Datenverkehr des Opfers abgefangen wird und über das eigene System geleitet wird. Eine Einschränkung gibt es dennoch. Die beschriebene Methode funktioniert nur mit WPA Systemen die auf den “Temporal Key Integrity Protocol” (TKIP) Algorithmus nutzen. Alle Geräte die auf den Advanced Encryption Standard (AES) setzen, sind hiervon nich betroffen.

Sicherheitsmaßnahmen

Erstmal: WPA Systeme mit AES oder WPA2 Systeme können nach wie vor als sicher eingestuft werden.In allen fällen sollte man natürlich auf die Qualität des Passwortes achten, sodass BruteForce Attacken oder Wörterbuchattacken nicht soleicht möglich sind. Insbesondere sollte man die maximale Key Länge von 63 Zeichen voll ausgenutzt werden und aus einem Mix aus Buchstaben, Zahlen und Zeichen bestehen. Ansonsten gelten nach wie vor die üblichen Sicherheitsmaßnahmen:

- Die Routerkonfiguration sollte nicht via WLAN möglich sein
- Die SSID sollte geändert werden und sollte keine Rückschlüsse auf die eingesetze Hardware geben
- regelmässige Firmware Updates des Routers

Allgemein

Google Wave besteht aus einem Webangebot (wave.google.com) sowie einem XMPP basierentem Protokoll, welches zum Großteil als Open Sorce und offenes Protokoll zur Verfügung gestellt werden soll. Es wird somit möglich sein komplett eigene Wave Applications zu implementieren. Zudem stellt Google eine API zur Verfügung mit der  bequem eigene Erweiterungen entwickelt werden können.

Wie funktioniert das ganze?
Der Benutzer kann aus der Wave Anwendung heraus eine “Welle” starten und andere Benutzer zur Mitarbeit einladen. Man kann die Wave sinngemäß mit einem Thread im Forum , einem Chatverlauf in ICQ oder einer Konversation von mehreren Emails vergleichen. Dieser Welle fügt man nun Personen als “Empfänger” hinzu. . Nun kann jeder hinzugefügte Nutzer in Echzeit an der Wave arbeiten, Medienobjekte hinzufügen oder Texte ändern. Die Änderungen sind dann sofort für alle sichtbar, so dass es zu keinem Versionskonflikt kommen kann. Die hinzugefügten Empfänger müssen keine natürlichen Personen sein, sondern können auch z.B. “Robots” sein, die eine gewesse Aufgabe erfüllen. Man kann z.B. mit einem Klick einen Blog Robot oder Facebook Robot hinzufügen. Die Wave (z.B. eine Umfrage) ist dann sofort auch auf dem eigenen Blog oder in dem Facebook Account sichtbar. Schreibt nun ein Facebook User einen Kommentar dazu, ist der Kommentar neben den Blogkommentaren zentral in der Wave zu lesen (man braucht also keinen Google Wave Account um in einer Wave zu agieren!). Änderungen, egal auf welcher Plattform sind überall sofort zu sehen.

Eine Wave kann mit jedlichem Inhalt gefüllt werden, so kann man z.b. via Drag und Drop Bilder reinziehen, und gleichzeit in Facebook und auf dem eigenen Blog veröffentlichen. Löscht man ein Bild aus der Wave sind die Änderungen sofort und überall sichtbar. Macht man eine internationale Konferenz, fügt man einfach einen Translate Robot hinzu, der in Echtzeit die Wave in die entsprechende Sprache übersetzt. Natürlich kann man seine eigenen Robots schreiben, oder über die API jeden belieben Inhalt einfügen. Die Möglichkeiten sind nahezu unbegrenzt. Oder einfach den ne Runde Schach gegen den besten Freund spielen

Der Clou an der Sache ist allerdings, das es dank des offenen Standarts möglich sein wird eigene Wave server aufzusetzen, die <b> komplett autark von Google agieren können</b>. Ähnlich wie bei dem E-Mail System kann aber dennoch der eigene Waveserver in echtzeit mit anderen Wave  server agieren. Man kann also wenn man in Firma A ist, eine Person aus Firma B der Wave hinzufügen. Das dürfte alle Google Kritiker freuen.Alle Änderungen an einer Wave können durch die Playback funktion jederzeit sichtbar gemacht werden und zurückgesetzt werden. Das macht Wave gleichzeitig  zu einem sehr schönen Versionierungssystem. Eine Wave kann jederzeit mit neuen Empfängern dupilziert werden, so ist es z.b. möglich aus einer Entwicklerversion mit ein wenigen Klicks ein “Rollout” auf den Produktivserver zu machen.So einfach die Idee hinter Wave auch ist, umso mehr darf man gespannt sein was sich daraus entwickelt. Ende September sollen laut Google ca. 100 000 Benutzer Accounts vergeben werden.

Ich werde mich die nächsten Tage mit der Wave API sowie mit dem Entwickeln eigener Wave Robots beschäftigen. In Teil 2 wir hierzu dann mehr zu lesen sein.

Die optimale Hardware

Voll im Trend liegen heute dedizierte Rootserver, die man bei vielen Hostern mittlerweile für einen Apple und ein Ei günstig anmieten kann.Doch leider hat man hier oft nur begrenzte Auswahlmöglichkeiten an der Hardwareausstattung. Ich möchte dennoch kurz auf die wichtigsten Anforderungen an die Hardware bei einem  reinen Datenbank Server eingehen. Zunächst sollte man erwähnen, dass jegliche Festplattenzugriffe generell zu langsam für Datenbankanwendungen sind. Ziel sollte es also sein, speichergesättigte Datenbanken, sprich nach Möglichkeit alle Daten in den Speicher legen, und die Schreibzugriffe so niedrig wie möglich  halten, zu bauen. Am Speicher sollte man also als letztes sparen! MySQL arbeitet mit einer Einprozessor Architektur. Ein MySQL Server besitzt mehrere Service Threads und einen Handler Thread  pro Verbindung, die sich alle den gemeinsamen Speicher des Prozesses teilen. Viel RAM ist zwar gut, es nützt uns allerding reichlich wenig, wenn wir diesen nicht mit einzelnen Prozessen ansprechen können. Mit anderen Worten: Eine 64 Bit CPU ist hier im Jahre 2007 Stand der Dinge. Will man mehr als 3GB RAM adressieren, kommt ein 64 Bit Betriebssystem noch hinzu. Sollen die Schreizugriffe auch optimiert werden, muss man Geld in den Datendurchsatz bei den Festplatten investieren. Reichen hier schnelle Platten ansich nicht mehr aus, sollte man die Anzahl der Spindeln erhöhen,  z. B. ein RAID 10 in Betracht ziehen. Ich selbst habe ein solches Setup noch nicht gefahren, verfüge hierzu also über keinerlei Erfahrungswerte. Die eigentliche CPU Leistung ist bei den heute standardmäßig verbauten Prozessoren eher vernachlässigbar.

Die Konfiguration  

In der Regel wird der MySQL Server über die my.cnf konfiguriert. Es ist aber auch möglich zur Laufzeit verschiedene Variablen  über den Prompt zu ändern. Aber nun zu den wichtigsten Optionen:

 Querycache 

Der Querycache sollte sich  mittlerweile rumgesprochen haben. Potenziell lassen sich bei Datenbanken mit wenigen Schreibzugriffe, hohe Performance Steigerungen erzielen. Die Konfiguration des Query Cache erfolgt über die gleichnamige Variable in der [mysqld] Sektion. In einem MySQL Kommandozeilenclient kann man sich die aktuelle Einstellung mit show variables like “query_cache%” ansehen. Der Query Cache legt bereits ausgeführte Abfragen in den Speicher. Führt man also z.b. die gleiche SELECT Abfrage 2 mal hintereinander aus, wird der 2. Aufruf wesentlich schneller abgearbeitet,  da er nicht wirklich ausgeführt wird, sondern das Ergebnis direkt aus dem Speicher kommt. Viele wissen allerdings nicht, dass es hier auf die wirklich identische Schreibweise ankommt. Ein “select x=2 where y=1″ ist in diesem Sinne nicht identisch mit “Select x=2 where y=1″ . Generell geht das mit dem Cache auch nur solange gut, bis es zu einer Veränderung der zugrundeliegenden Base Table kommt. Daher wird beispielsweise nach einem INSERT das entsprechende Query aus dem Cache gelöscht. 

query_cache_limit

Hiermit wird die maximale Größe des Result Sets bestimmt – also die maximale Größe des Ergebnisses einer Abfrage die in den Cache kommen soll. Es macht bei den meisten Anwendungen wenig Sinn den Cache mit wenigen großen Querrys vollzustopfen und somit andere wichtigere Querries rausfliegen zu lassen. 

query_cache_type

0 (Off) Query Cache ist ausgeschaltet, alle anderen Query Cache Parameter werden übersprungen. 1 (ON) hier werden sofern möglich alle Querries in den Cache aufgenommen, mit Ausnahme von solchen, die nicht konstante Funktionsaufrufe (wie z.b. rand() now(),..) enthalten. Mit 2 (On Demand) werden nur Querys aufgenommen, die ausdrücklich mit SQL_CACHE makiert sind. 

query_cache_size

Hier wird festgelegt wieviel Arbeitspeicher für den Query Cache reserviert werden soll.  Die Größe ist nachtürlich von Anwendung zu Anwendung verschieden. Man muss hier ein wenig rumexperimentieren. Mit einem SHOW STATUS kann dies leicht kontrolliert werden.Wird ein Schreiblock auf eine Tabelle gelegt, werden Querrys aus dem Cache dennoch ausgeliefert. Möchte man dies vermeiden, muss man die Option query_cache_wlock_invalidate auf 1 setzen.  Nach der ganzen Einstellerei sollte man sich  nun mal einen Überblick über das ganze mit einem “SHOW STATUS LIKE ‘%qc’” verschaffen. Je nachdem wie lange der Server schon läuft sollte in etwa sowas zu sehen sein:  

mysql> show status like "qc%";

+-------------------------+-----------+

| Variable_name           | Value     |

+-------------------------+-----------+

| Qcache_free_blocks      | 1 |

| Qcache_free_memory      | 113943576 |

| Qcache_hits             | 11 |

| Qcache_inserts          | 216961140 |

| Qcache_lowmem_prunes    | 0         |

| Qcache_not_cached       | 44 |

| Qcache_queries_in_cache | 100 |

| Qcache_total_blocks     | 35 |

+-------------------------+-----------+

8 rows in set (0.00 sec)

 In diesem Bespiel sieht man, das der Cache noch nie übergelaufen ist (prunes), 44 Querrys konnten nicht gecached werden. Sollte der prunes Wert mit der Lauftzeit steigen, ist der Query Cache offensichtlich zu klein und sollte größer gestellt werden. wenn der Qcache_free_blocks Wert Groß wird, dann fragmentiert der Qcache. Abhilfe schaft hier eine andere Größe der Blocksize die mit qcache_min_block_size eingestellt werden kann. 

 Key Buffer

Ebenfalls in der [mysqld] Sektion findet man die key_buffer Option.   Aber erst zum Hintergrund. MySQL legt die Daten chronologisch in eine MYD File ab. Vergleichen kann man dies mit einer Bücherei. Hier werden neu gekaufte Bücher einfach hinten ans Regal angestellt, wenn Lücken vorhanden sind, werden diese aufgefüllt. Um die Bücher nun besser finden zu können gibt es in jeder verschiedene Indexe, z.b. einen Schlagwortkatalog oder einen Autorenkatalog, mit denen man die Bücher sehr einfach finden kann.Bei MySQL legt man einen  Index mit CREATE INDEX an. Der Befehl geht dann die Spalte durch, merkt sich die Werte für jeden Wert und die Datensatznummer, in der der Wert zu finden ist. Dann müssen die Werte sortiert werden, und hierfür wird Platz benötigt. Und dieser Platz sollte sehr großzügig bemessen werden. Beispiel: Nehmen wir an, wir möchten einen Index auf eine INTEGER SPALTE, wird pro Datensatz 4 Byte für das Integer plus 4 Byte für den Zeiger auf die Daten benötigt. Bei 20 Millionen Einträgen sind das also ca. 152 MB. Das stimmt so aber noch nicht ganz. Denn eine Index File wird in Blöcke von key_cache_block_size Byte größe angelegt. In der Bibliothek sind die Indexeinträge auch Gruppiert, es gibt z.b. eine Block “A”, “B” etc. Es macht aber keinen Sinn die Blöcke von anfang an komplett voll zu machen, denn dann müßte bei jedem neuen Eintrag der komplette index “verschoben” werden. Das Verschieben macht auch MySQL und wird Rebalancing genannt. Damit dies nicht jedes mal passieren muss, sollte man die Blöcke nur zu 2/3 füllen. Bei unseren Beispiel heisst es allso 8 Byte pro Zeile geteilt durch 2/3, dann kommt man auf ca.  228 MB 

Allgemein zu Ettercap 

Neulich bin ich auf sein interessantes Tool zur Netzwerküberwachung gestoßen. Es handelt sich um das Open-Source Tool Ettercap mit dem Sniffing auf IP und auf ARP-Basis, sowie Echtzeitkontrolle über Verbindungen selbst in geswitchten Netzwerken,inhaltsbezogene Filterung und aktive sowie passive Analysen von einzelnen Hosts oder ganzen Netzwerken möglich ist. Offiziell handelt es sich um ein Sicherheitstool, kann aber aufgrund seiner nahezu unbegrenzten Möglichkeiten auch für “Man-in-the-Middle” Angriffe missbraucht werden. Da Ettercap Pakete bereits auf ARP Ebene abfängt, ist es sogar möglich verschlüsselte Verbindungen zu belauschen. Trotz der gefährlichen Nachteile, eignet sich das Tool, wenn es sinnvoll angewendet wird, perpekt zur Netzwerkanalyse im eigenen Netz. Verfügbar ist Ettercap für zahlreiche Linux Verisonen, BSD Derivate, Solaris, Mac OS X wie auch Windows.

Funktionsweise von Ettercap 

Ettercap arbeitet mit dem Funktionsprinzip des “ARP-Spoffing”. Hierbei werden vom Sender  an das “Opfer” manipulierte  ARP Pakte mit seiner eigenen MAC Adresse gesendet. So ist ein einschleusen von gefälschten Adresspaaren in den Zwischenspeicher möglich (Cache Poisoning). Da das ARP Protokoll keine weiteren Abfragen und Sicherheitsmechanismen hat, werden vom Client alle weiteren Pakete erst über den Angreifer geschickt. Der Angreifer leitet dann alle Pakte (unbemerkt) weiter an den eigentlichen Empfänger (Men-in-the-middle). 

Wie kann sich gegen Angriffe mit Ettercap schützen?

Mit erscheinen von Ettercap bieten auch geswichte Netzwerke mittlerweile keinen wirklichen Schutz mehr.  Es gibt allerdings möglichkeiten das sog. ARP Spoofing zu verhindern.  So ist es mit statischen ARP Einträgen möglich eine Manipulation zu verhindern. Dies ist natürlich mit hohem administrativen Aufwand verbunden. Man könnte allerdings z.b. das Standart Gateway fest eintragen. Ein weiterer Lösungsansatz besteht darin, die einzelnen Host im Netz soweit wie möglich mittels eins VLANs (Virtuell LAN)  zu isolieren. Da nur auf Ethernetebene ARP zum Einsatz kommt, ist es bei isolierten Hosts nicht möglich Opfer eines solchen Angriffs zu werden. Allerdings stellen die meisten gänigen Router nur eine begrenzte Anzahl von VLANs zur Verfügung, wodurch es kaum möglich sein wird, jeden einzelen Host zu Isolieren. Bei diveresn Serverhostern (z.b. Hetzner) wird diese Technik allerdings erfolgreich eingesetzt, um eben Spoofing im Servernetz nicht zu ermöglichen. 

 Spass mit Ettercap 

Ja, man kann auch lustige Dinge mit Ettercap machen, und so seine Kollegen ärgern (ACHTUNG! Ettercap nie (!!!) im Unternehmensnetz ungefragt einsetzen, damit kann man sich mächtig Ärger einfangen!!).  So Kann man quasi live Webseiten, die der Kollege aufruft manipulieren und z. B. Bilder austauschen.