KDE Power Management – so bitte nicht ….

Posted on by

Es gibt Dinge, da enden das Verständnis und die Nachvollziehbarkeit. Und man fragt sich, wie der Open Source Betrieb inzwischen eigentlich funktioniert.

Offenbar immer mehr nach dem Motto: Der User ist zu doof …. und deshalb nehmen wir ihm nützliche Dinge weg, weil einige Leute ihre Vorurteile und ihren Einfluss geltend machen.

Bis KDE 4.4 gab es ein nettes ansprechendes Feature in den KDE Systemeinstellungen – nämlich eine hinreichend umfassende Möglichkeit, sich Profile für das “power management” (hier CPU governor) zusammenzuklicken. Eigentlich genau das, was man sich als Normal-User, aber auch als Entwickler so wünscht, wenn man auf einem Desktop oder Laptop unter wechselnden Bedingungen arbeitet und nicht jede Einstellung zum “power management” über die Konsole eingeben will. Eine runde und wie ich finde auch durchdachte Sache rund um HAL und power-devil …

Aber H. mag das nicht … und H. findet anscheinend, dass die Anwender zu blöd sind, die Folgen ihres Tuns abzuschätzen. Also dringt H. darauf, dass ein halbwegs komfortables Tool zur Einstellung des CPU-Frequenzverhaltens und andere Schrauben für das Energieverhalten eines Systems aus KDE entfernt wird. H. weiss: Das ist nix für eine GUI, denn der GUI-Benutzer ist einfach zu dumm. Und weil H. die KDE-Anwender und moderne CPUs kennt, weiss er auch, dass solche Features zu 99,8% überflüssig ist. So ein Laptop weiss schon, wann er sich drosseln muss ….und überhaupt die Energieveschwendung ….und die Wunder einer effizienten “On Demand” Welt ….

Anstatt aber etwas tun, um den “Dummen” die Folgen ihres Handelns z.B. in Hilfetexten oder an Beispielen in der GUI zu erläutern – nein, da nehmen wir ihnen die Möglichkeit was einzustellen lieber gleich ganz weg. Per Patch – und schon sind bewährte Einstellmöglichkeiten, die der User aber sicher ganz falsch verwenden wird, in KDE 4.5 nicht mehr drin. Am besten wäre es allerdings, auch noch die Einstellmöglichkeiten an der Konsole – sprich die “solid-powermanagement”-Optionen zu beschneiden ….. Blöd irgendwie nur, dass das im Patch beabsichtigte reine On/Off-Schalten von Energiespar-Einstellungen für die CPU-Frequenz auch nicht so recht funktioniert ….

An was erinnert mich diese Art der “Argumentation” doch noch? Wie hies doch gleich das System mit der GUI, bei der der User so wenig wie möglich mit Nachdenken belastet werden soll ? Wollte man mit Linux nicht weg von einer solchen Politik?

Die Phantasie von H. reicht offenbar nicht so weit, dass er sich vorstellen kann, dass es KDE-Nutzer gibt, die grafische Oberflächen nicht nur zum Üben von Openoffice auf einem Laptop einsetzen. Dass man z.B. bei Bedarf (und bequem) ein bestimmtes Power-Management-Profile aktivieren möchte, wenn mehrere VMware Workstations auf einer Linux-Workstation zeitweise mit konstanter Frequenz auf unterschiedlichen CPU-Cores laufen sollen und müssen – sowas kommt in in der Welt von H. nicht vor. Und dass man manchmal die Frequenz konstant auf das niedrigst mögliche Niveau setzen will, um die Performance von Programmen für solche Verhältnisse zu testen – neh’ das braucht es in der on demand Welt nicht. Und dass es einen Bedarf für Powermanagement-Profile bei Anwendern mit älteren Laptops geben mag, die sich nicht alle 2 Jahre ein neues Gerät leisten können? Egal …. Und dass man bei manchen Laptops gezielt die niedrigste CPU-Frequenz einstellen mag, weil sonst die Lüfter unter Linux und KDE laufend anspringen? Egal ….

Und selbst wenn – der typische Linux- und KDE-User kann die Folgen seines Klickens auf all die schönen bunten Features auf dem KDE-Schirm ja eh’ nicht einschätzen ….

Hinweisen wollte ich die anderen dummen 0,02% KDE-Mitbenutzer, die die früheren Möglichkeiten zum Einstellen von Powermanagement-Profilen eventuell doch vermissen, noch auf die Möglichkeit von

solid-powermanagement query cpufreq
und
solid-powermanagement set
cpufreq <value>

Ich meine für die Zeit, bis H. auch das zum Wohle der Anwender, im Sinne des Fortschritts und einer heilen “on demand” Welt eliminiert hat.

Bliebe noch die Diskussion um die Zukunft von HAL – aber auch in einer Zukunft ohne HAL sollte die Frage, ob und warum man dem User Kontroll-Möglichkeiten entzieht, vielleicht in einem anderen Stil diskutiert und evtl. auch über andere Verfahren zur Entscheidung gebracht werden.

Links

http://forum.kde.org/viewtopic.php?f=22&t=88774&p=167797#p167797
http://kubuntuforums.net/forums/index.php?topic=3113359.0
http://osdir.com/ml/kde-devel/2010-03/msg00055.html

http://dot.kde.org/2007/04/24/road-kde-4-solid-brings-hardware-configuration-and-control-kde?page=1
http://wiki.ubuntuusers.de/Solid
http://en.wikipedia.org/wiki/Solid_%28KDE%29

https://bugzilla.redhat.com/show_bug.cgi?id=550486

http://forum.kde.org/viewtopic.php?f=66&t=31708

Kontact, Kmail, Address Book – Nachtrag 2

Posted on by

Nachdem ich gerade auf einem PC mal wieder Opensuse 11.3, KDE 4.5, Kontact und Kmail installiert habe, eine kleine Hilfestellung dazu, wie man Kontact-Adressbücher auch unter Kmail und seiner automatischen Addressbuch-Suche/-Vervollständigung zum Laufen bekommt.

Standardmäßig ist Kontact ja mit einem Adressbuch “Persona Contacts” ausgestattet. Trägt man dort Adressen ein, so erwartet man, dass diese Adressen bei Anlage einer neuen Mail als Vorschläge auftauchen, wenn man die ersten Buchstaben der Adresse in eine Adressleiste der neuen Mail eintippt. Dies ist leider nicht der Fall. Aber ein kleiner Trick – nämlich ein Umweg über die KDE-Systemeinstellungen für Resourcen – führt zum Erfolg. Inzwischen nicht nur für die unter Kontact als “traditionelle” Adressbücher bzeichneten Ressourcen, sondern auch für reine Akonadi Adressbücher.

Vorgehen für ein traditionelles Adressbuch:

Ic beschreibe hier die Schritte beispielhaft für das Adressbuch eines Open-Xchenage-Servers. Das geht aber genauso für Adressbücher auf Ordner, File und VCF-basis.

  • Schritt 1: Man starte Kontact, wechsle dort in den Bereich Kontakte. Klick mit der rechten Maustaste in den Bereich “Address Books”. Auswahl “Add address book”. Nachfolgend Auswahl von “KDE Address Book (traditional)”.
  • Schritt 2: Im folgenden Dialog Auswahl “OpenXchange-Server”. Dann die Server-Angaben vervollständigen. Z.B.:
    URL: http://OX.meinedomaine.de (falls der Server OX heisst und über diesen Namen (DNS) ansprechbar ist).
    USer und Passwort angeben. Danach den Button “Select Folder” wählen und eines der zugänglichen persönlichen oder globalen Adressbücher auf dem Open-Xchange Server auswählen.

  • Schritt 3: Ggf. im Dialog zum OX-Adressbuch auch noch angeben, ob man immer das ganze Adressbuch laden will oder nur die Änderungen seit der letzten Synchronisation. Diese Entscheidung hängt im Besonderen von der Größe des Adressbuchs, der Frequenz der Aktualisierung und der resultierenden System- und Netz-Belastung ab.
  • Schritt 4: Name des Adressbuchs auf dem lokalen System angeben. Dieser Name legt de Bezeichnung als lokaler Folder und auch als Akonadi-Resource fest. Danach “Finish”. Nun sollten die Adressen vom Server geladen und mit dem Inhalt der eben angelegten lokalen KDE-Adsressbuch-Ressource abgeglichen werden.
  • Schritt 5: Dieser Schritt ist von besonderer Bedeutung und muss leider und unverständlicherweise manuell durchgeführt werden! Öffnen von KDE’s “Systemeinstellungen”. Unter KDE 4.5 geht man nun auf den Punkt “Persönliche Informationen / KDE Ressourcen”. Dort wählt man in der Ressourcen-Auswahl “Kontakte”. Dann “Hinzufügen”. In dem nachfolgenden Dialog “OpenXchange-Server”. Die nachfolgenden Punkte entsprechen exakt denen von Schritt 2. Danach klicken wir “Anwenden”.
  • Schritt 6: Über die “Akonadi-Einrichtung” (Startmenü -> Suchen -> “Akonadi”) prüfen, dass das Addressbuch auch als Akonadi-Resource angelegt ist.
  • Schritt 7: Systemeinstellungen schließen, Kontact schließen, ausloggen, KDE neu starten, einloggen, Kmail öffnen.
  • Schritt 8: Testen, dass beim Schreiben einer neuen Mail die automatische Adress-Completion für Adressen aus der angelegten OX-“Address Book”-Ressource funktioniert.

Vorgehen für ein Akonadi-Adressbuch:

Wir können die Beschreibung hier auf die unter Opensuse bereits angelegte Akonadi-Adressbuch-Ressource beschränken. Andere Akonadi-Ressourcen muss man halt vorher anlegen (u.a. über Kontact). Angelegt ist unter OPensuse das Akonadi-Adressbuch “Personal Contacts”.

  • Schritt 1: Verifizieren, das das zu verwendende Akonadi-Adressbuch “Personal Contacts” bereits als Akonadie-Ressource existiert. Hierfür kann man erneut die “Akonadi-Einrichtung” benutzen.
  • Schritt 2: Öffnen von KDE’s “Systemeinstellungen”. Unter KDE 4.5 geht man nun erneut auf den Punkt “Persönliche Informationen / KDE Ressourcen”. Dort wählt man in der Ressourcen-Auswahl “Kontakte”. Dann “Hinzufügen”. Im folgenden Dialog “Akonadi-Adressbücher” wählen. Danach erscheinen in einem weiteren Dialogfenster dann die bereits als Akonadi-Ressourcen erfassten reine Akonadi-Adressbücher, aber auch die traditionellen Adressbücher, die inzwischen als Akonadi Ressourcen erfasst und verfügbar gemacht wurden. Hier wählen wir natürlich die Akonadi-Resource “Personal Contacts”. Abschließend klicken wir auf “Anwenden”.
  • Schritt 3: Systemeinstellungen schließen, Kontact schließen, ausloggen, KDE neu starten, einloggen, Kmail öffnen.
  • Schritt 4: Testen, dass beim Schreiben einer neuen Mail die automatische Adress-Vervollständigung mit Adressen aus der neuen Akonadi-Adressbuch-Resource “Personal Contacts” funktioniert.

Die Akonadi Ressource “Personal Contacts” lässt sich übrigens weiter in verschiedene Unterrordner untergliedern. Auch diese Unterordner kann man als aeparate Adressbuch-Ressourcen ansprechen.

Fazit

Unter Opensuse 11.3 und KDE 4.5 kann man traditionelle Adressbücher und Akonadi-Adressbücher nebeneinander mit Kmail verwenden. Schade nur, dass es nicht mit dem Anlegen der jeweiligen Adressbücher unter Kontact getan ist, sondern dass der User zusätzlich manuell “Ressourcen”-Einstellungen in den “Systemeinstellungen” vornehmen muss.

Man versteht, dass die Ressourcenverwaltung unter den KDE-Systemeinstellungen künftig eine sehr weitgehende Flexibilität und sehr feine Anpassungen bzgl. der von den KDE-Programmen tatsächlich einzusetzenden Ressourcen bieten wird. Im Moment ist dies für Kontact-Anwender aber nicht ersichtlich – zumal im Falle von OX-Kalendern tatsächlich ein automatischer Eintrag als KDE-Ressource erfolgt. Hier sollten die KDE-Entwickler die Usability verbessern und weitere Hinweise und Dialoge in Kontacts Adrssbuc-Bereich einbauen.

Lokale MySQL-/PhpMyAdmin-Installation

Posted on by

Als IT-Mensch ist man oft unterwegs und möchte gerne die Zeit mit seinem Laptop für Entwicklungsarbeiten benutzen – in meinem Fall für LAMP-Applikationen. Für derartige Web-Applikationen benötigt man auf einem solchen lokalen Test- und Entwicklungssystem neben einem Apache-Web-Server i.d.R. auch einen lokalen Datenbankserver, den man dann eventuell mit PhpMyAdmin verwalten will. Ich gebe hier ein paar kurze Hinweise zur Installation von MySQL unter Opensuse 11.3. Wir besprechen hier nur die einfachst mögliche Installation. Sind keine speziellen Anforderungen gegeben, reicht das für Entwicklertests vieler einfacher Anwendungen schon aus.

PhpMyAdmin und vermutlich auch die zu testenden PHP-Applikationen erfordern einen bereits vorhandenen Web-Server mit PHP-Modul. Wie man sich den verschafft, habe ich in einem früheren Beitrag dargestellt.

https://linux-blog.anracom.com/2010/07/25/lokaler-apache-test-server-fur-php5/

MySQL-Installation

Die MySQL-Installation unter Opensuse 11 ist mit Yast recht einfach. Für den Server und einige nützliche Tools habe ich folgende Pakete aus dem Standard-SuSE-Repository installiert. (Für aktuellere Versionen und Varianten von MySQl werfe man bei Bedarf einen Blick in folgendes Repository: http://download.opensuse.org/repositories/server:/database/openSUSE_11.3/ )

  • mysql-community-server
  • mysql-community-server-client (!)
  • libmysqlclient16
  • libmysqlclient_r16
  • libmysqld0
  • libqt4-sql-mysql
  • php5-mysql
  • mysql-administrator
  • mysql-gui-tools
  • mysql-query-browser
  • mysql-workbench
  • mytop
  • qt3-mysql
  • perl-DBD-mysql

Nachtrag 20.04.2011:
Die Funktionalität des Pakets “mysql-administrator” ist mittlerweile im Paket “mysql-workbench” aufgegangen. Unter Opensuse 11.4 existiert das Paket “mysql-administrator” deswegen nicht mehr.

(Nebenbei: Man achte auf die feine Unterscheidung in der Paketbezeichnung, die mit der Übernahme von Sun durch Oracle Einzug gehalten hat. Es heißt jetzt an zwei Stellen : community. Ein Synonym für künftig eingeschränkte Funktionalität? Ich ahne schon, dass ich mich bald wieder intensiv mit Postgres auseinandersetzen werde. Überhaupt tauchen Oracle-Embleme inzwischen an jeder Ecke im Linux-System auf. Da merkt man erst, was wir möglicherweise mit Sun verloren haben. Aber das ist ein Thema für sich …. ).

Die genannten Pakete ziehen unter Yast ggf. die Installation weiterer benötigter Pakete nach sich.

Nachtrag – 10.06.2012:
Inzwischen hat ja unter Opensuse 12.3 die Maria DB den MySQL Community Server von Oracle ersetzt. Die Paketliste ändert sich dann in etwa wie folgt. Ich gebe auch einige Pakete an, die vielleicht nicht jeder unbedingt braucht; das hängt davon ab, welche andere SW auf die MySQL-DB zugreifen soll.

  • mariadb
  • mariadb-client
  • mariadb-errormessages
  • mariadb-tools
  • libmysqld18
  • libmysqlclient18
  • libqt4-sql-mysql
  • qt3-mysql
  • mysql-workbench
  • mysql-community-server-errormessages
  • libmysqlcppconn6
  • libgda-3_0-mysql
  • php5-mysql
  • php5-pear-DB
  • perl-DBD-mysql
  • python-mysql
  • libreoffice-base-drivers-mysql
  • mytop

MySQL-Root-Account

Nach der Installation startet man den Datenbankserver unter Opensuse mit ”
rcmysql start”. Der Administrator-Account für die MySQL-Datenbank muss nun gesichert werden, damit nicht jeder Zugriff auf die Verwaltung des Datenbanksystems hat. Das erforderliche MySQL-Root-Passwort setzt man auf der Kommandozeile mit

# mysqladmin   -u   root    password    ‘ein_passendes_Passwort’

(Die Anführungszeichen sind ernst zu nehmen. Der ‘root’-User für MySQL ist übrigens nicht mit dem Linux-System-Verwalter-Account zu verwechseln!).

Nachtrag – 20.04.2011:
Ist der eigene PC/Server benannt und einer Domaine zugeordnet – etwa als “mytux.mydomain.de” -, sollte man zusätzlich

mysqladmin   -u    root    -h    mytux.mydomain.de    password    ‘ein_passendes_Passwort’    -p

ausführen. Man wird dabei nach dem zuvor angegebenen MySQL-Root-Passwort gefragt.

Nachtrag – 10.06.2013:
Unter Opensuse kommt es dabei oft zu einem Fehler der Art “Host ‘mytux.mydomain.de’ is not allowed to connect to this MySQL server”. Ursache ist, dass der Servername nicht in voll qualifizierter Form in die zentrale Tabelle ‘user’ der MySQL-DB eingetragen wurde. Man korrigiert das wie folgt:

# mysql -u root -p
Enter Password :

mysql> use mysql;

mysql> update user set host=”mytux.mydomain.de” where host=”mytux”;
mysql> flush privileges;
mysql> exit;
# mysqladmin   -u    root    -h    mytux.mydomain.de    password    ‘ein_passendes_Passwort’    -p

Alle nachfolgenden Verwaltungsaufgaben – wie die Anlage neuer User und deren Zugriffsrechte von verschiedenen Arbeitsstationen aus – kann man danach mit dem Kommandozeilentool “mysqladmin” oder mit dem grafischen Tool “MySQL Administrator”
/usr/bin/mysql-administrator
durchführen.

Nachtrag – 10.06.2013:
“mysql-administrator” ist als separates Tool seit Opensuse 11.4 verschwunden. Unter aktuellen SuSE-Versionen benutzt muss man dann die Admin-Tools der grafischen “mysql-workbench”, die man per

# mysql-workbench &

aufruft.

Letzteres Tool bietet sich für umfassendere Konfigurationsarbeiten bzgl. der Datenbank als (System-) root an, da die Hauptkonfigurationsdateien

“/etc/my.cnf”
“/etc/mysqlaccess.conf”

aus Sicherheitsgründen nur für root schreibbar angelegt werden.

Hinweis: Will man sich den “MySQL Administrator” graphisch auf die eigene KDE-Useroberfläche oder in den “Arbeitsflächen-Ordner” legen, so gibt man in der Konfiguration des Plasma-Icons als Programmaufruf

“/usr/bin/xdg-su   -c   /usr/bin/mysql-administrator”

an – um den grafischen sudo-Berechtigungsdialog für die Eingabe des root-passwords auf den Schirm zu bekommen. Ähnliches gilt für die Workbench.

Das Kommandozeilentool “mysql” ruft man über

mysql   -u   root    -p

auf und gibt dann danach das oben gesetzte MySQL-root-Passwort ein.

Für einen lokalen Testserver ist das oben Beschriebene als Ausgangsbasis für weitere Arbeiten (Anlegen und Konfiguration der benötigten Datenbanken und Tabellen) hinreichend. Für eine Produktiv-Umgebung sollte man besser eine “secure installation” durchführen. Genaueres dazu findet man unter den Links am Ende des Artikels.

Minimale PhpMyAdmin-Installation

Für unseren
lokalen Testserver wollen wir nun PhpMyAdmin installieren. Auch hier besprechen wir nur die einfachst mögliche Implementierung. Voraussetzung ist, dass auf dem Apache-Server PHP5 installiert ist.

Zunächst prüfen wir, dass zusätzlich folgende Pakete installiert sind:

  • php5-mysql
  • php5-zip
  • php5-bz2
  • php5-mcrypt
  • mcrypt

und bei Bedarf ggf.

  • php5-pear
  • php5-pear-Crypt_Blowfish

Dann laden wir uns von der Seite

http://www.phpmyadmin.net/home_page/downloads.php

phpMyAdmin-3.3.5-all-languages.tar.gz

herunter und entpacken die Dateien in einem lokalen Verzeichnis. Wir gehen davon aus, dass unser lokaler Webserver ein DocumentRoot-Verzeichnis

/srv/www/htdocs

und eine zugehörige Default-Domaine aufweist. Wir legen nun ein Verzeichnis

/srv/www/htdocs/phpmyad

an und kopieren dorthin den Inhalt (!) des vorher aus dem tar-Archiv erzeugten Verzeichnisses “phpMyAdmin-3.3.4-all-languages”.

Danach legen wir ein Verzeichnis

/srv/www/htdocs/phpmyad/config

an und machen es temporär für die Welt schreibbar

chmod 757 /srv/www/htdocs/phpmyad/config

Nun öffnen wir einen lokalen Browser und geben als Adresse an

http://localhost/phpmyad/setup

Auf der neuen Seite drüken wir den Button “Neuer Server”. Im folgenden Dialog “Grundeinstellungen” lassen wir alles unverändert (u.a. den Hostnamen auf “localhost” ) und wählen als Auth-Typ “cookie”. Wir wechseln nun zum Reiter “Serverkonfiguration” und erlauben dort den “root”-Login, damit wir danach Datenbanken anlegen können. Wir speichern dann die Einstellungen. Auf der folgenden Seite wählen wir ggf. “Deutsch” als voreingestellte Sprache und speichern erneut. Wir drücken nun abschließend den Knopf “Laden”.

Im nachfolgenden Schritt kopieren wir die frisch erzeugte config-Datei in das phpmyad-Verzeichnis:

  cp         /srv/www/htdocs/phpmyad/config/config.inc.php          /srv/www/htdocs/phpmyad/

Danach geben wir im Browser ein

http://localhost/phpmyad/

Im nachfolgenden Dialog authentifizieren wir uns als “root” (dies ist der mySQL-root-user) mit dem Passwort, das wir oben am Ende der MySQL-Installation vergeben hatten. Danach sollte die PhpMyAdmin-Oberfläche auftauchen. Nun können wir auf einfache Weise evtl. vorhande Datenbanken importieren, User dazu anlegen und die benötigten Rechte vergeben !

Hinweis:
Die Warnungen und Informationen zur sicheren Verbindung und zur Deaktivierung bestimmter Möglichkeiten sollten uns nachdenklich machen und zu weiteren Arbeiten anregen. Für einen lokalen Testserver ist das ggf. nicht wichtig – wohl aber in Produktivumgebungen! In diesem Beitrag sparen wir uns aber eine Vertiefung.

Abschließender Schritt: Die Schreibrechte auf dem Verzeichnis “config” entfernen wir aus Sicherheitsgründen wieder.

Nachtrag 10.06.2012:
Für aktuelle Versionen von phpMyAdmin geht die Installation in praktisch identischer Weise vor sich. Allerdings will man nach kurzer Zeit sicher die Einstellungen zur aktuellen GUI individualisieren – u.a. weil die zusätzlichen Textangaben zu den Icons viel zuviel Platz wegnehmen. Das nervt total.

Um das in den neuesten Versionen zu erreichen, muss man zusätzliche “config”-Verwaltungstabellen und einen “control user” anlegen. Letzterer muss dann passende Berechtigungen bekommen. Ferner
sind Einträge in der Datei “config.inc.php” zu ergänzen. Zum Anlegen der Verwaltungstabellen kann man die entsprechenden SQL-Statements über ein File “examples/create_tables.sql” importieren. Das File liegt unter dem Wurzelverzeichnis der phpmyadmin-Installation – im oben beschriebenen Fall also unter

/srv/www/htdocs/phpmyad/examples/create_tables.sql

Beschrieben ist das Vorgehen u.a. in folgenden Beiträgen:
http://docs.phpmyadmin.net/en/latest/setup.html#phpmyadmin-configuration-storage
und hier:
http://docs.phpmyadmin.net/en/latest/setup.html#using-authentication-modes
sowie hier:
http://stackoverflow.com/questions/11506224/connection-for-controluser-as-defined-in-your-configuration-failed-phpmyadmin-xa

Der letzte Beitrag fasst netterweise die erforderlichen Schritte zusammen.

Bei der Änderung der “config.inc.php” sind sowohl der “control user” und sein Passwort als auch diverse Tabellennamen der Datenbank “phpmyadmin” für den jeweiligen Server einzutragen. Diese Datenbank wurde beim Import der Datei “examples/create_tables.sq” angelegt.

Bitte beachtet bei den Ausführungen zur “config.inc.php” im letzten Link, dass die Tabellennamen inzwischen einen doppelten Unterstrich nach dem “pma” aufweisen! Also jeweils “pma__” und nicht “pma_” !
Wie die Tabellennamen unter der Datenbank “phpmyadmin” >> “pma_db” in der jeweiligen phpMyAdmin-Installation tatsächlich genau aussehen, prüft man am besten mit phpMyAdmin selbst.

Das ganze Theater bzgl. der GUI-Verwaltung ist aus meiner Sicht zu komplex gemacht. Vielleicht beschreibe ich das mal im Detail in einem eigenen Artikel.

Links

http://de.opensuse.org/MySQL
http://de.opensuse.org/Apache/SSL,_MySQL_und_PHP
http://www.susegeek.com/internet-browser/install-configure-lamp-apachemysqlphp-in-opensuse-110/
http://dev.mysql.com/doc/refman/5.1/de/installing.html
http://dev.mysql.com/doc/refman/5.1/de/default-privileges.html
http://www.howtoforge.com/perfect-server-opensuse11-p4
http://www.unixmen.com/linux-tutorials/237-install-lamp-in-openuse-110-and-111

Lokaler Apache/PHP-Testserver

Posted on by

Ich entwickle oft “PHP 5”-Programme – auch unterwegs. Auf einem Laptop musste ich vor kurzem einen lokalen Apache-Server einrichten, um auch ohne Netzwerkanbindung Programme testen zu können. Der Server sollte natürlich PHP5 unterstützen und für eine bestimmte Testdomaine – “devdomain” – SSL-fähig sein. Hierzu muss man auf die Schnelle virtuelle Domainen einrichten. Das Ganze unter Opensuse 11.3.

Vielleicht ist die nachfolgende Vorgehensweise zur Lösung dieser Aufgabenstellung auch für andere interessant.

/etc/host-Einträge

Der Rechner soll später autonom – d.h. ohne Netzverbindung funktionieren. Ein DNS-Dienst ist für ein rein lokales System überflüssig. Für einen lokalen, autonomen Testserver kann für die notwendigen Einträge in der Datei “/etc/hosts” das Loopback-Interface verwenden. Die Einträge können dann etwa so aussehen:

127.0.0.1         localhost.localdomain         localhost

127.0.0.2         mylap.myprivatedomain.de         mylap

127.0.0.2         devdomain

Der erste Eintrag ist ein Standard Opensuse-Entrag, wie er bei einer automatischen Installation erzeugt wird. Den zweiten benötige ich für andere Programme. Interessant für unsere Problemstellung ist die dritte Zeile. Die dortige IP-Adresse ist u.a. wichtig für das spätere Aufsetzen der IP-basierten virtuellen Domaine “devdomain”.

Es gibt im Internet immer wieder Diskussionen um die Verwendung der Loopback-Adresse – ich denke, die oft angeführten Gegen-Argumente kann man im Zusammenhang mit dem beschriebenen Szenario getrost ignorieren. Ein System mit aktiven Netzwerkschnittstellen benötigt natürlich noch mehr Einträge an passender Stelle in der “/etc/hosts” und ggf. eine Adress-Systematisierung über einen DNS-Server. Aber die Funktionalität eines autonomen Entwicklungs- und Test-Systems ist mit den Loopback-Adressen wirklich in hinreichender Weise gegeben.

Für die korrekte lokale Namensauflösung sollte “files” die Reihenfolge der Ressourcen im “hosts”-Eintrag der Datei “/etc/nsswitch.conf” anführen:

hosts:       files mdns4_minimal [NOTFOUND=return] dns

Grundinstallation Apache

Apache2 kann man unter Opensuse einfach über die Yast und die dortige Paketverwaltung installieren. Folgende Pakete aus dem Opensuse 11.3 Standard-Repository habe ich installiert:

  • apache2 (!)
  • apache2-devel (!)
  • apache2-doc
  • apache2-example-pages (!)
  • apache2-mod_dnssd
  • apache2-mod_perl
  • apache2-mod_php5 (!)
  • apache2-mod_python
  • apache2-prefork (!)
  • apache2-utils (!)
  • libapr-util1 (!)
  • libapr-util1-devel (!)
  • libapr1 (!)
  • libapr1-devel (!)

Nach der Installation und einem “rcapache2 start” sollte ein

http://localhost

im Browser bereits eine Seite mit dem schönen Text “It works!” anzeigen. Danach trägt man mit Yast den Apache2-Server in die Run-Level-Konfiguration ein, damit er automatisch z.B. in den Levels 3 und 5 gestartet wird.

Grundinstallation PHP5

Für eine relativ umfassende PHP5-Unterstützung sind für mich in der Regel folgende Pakete/Module von
Bedeutung:

apache2-mod_php5, php-doc, php5, php5-bcmath, php5-bz2, php5-ctype, php5-devel, php5-dom, php5-gd, php5-hash, php5-iconv, php5-imagick, php5-json, php5-mbstring, php5-mcrypt, php5-mysql, php5-pdo, php5-pear, php5-phar, php5-sqlite, php5-tidy, php5-tokenizer, php5-xdebug, php5-xmlreader, php5-xmlwriter, php5-zip, php5-zlib

Die Zusammenstellung kann für umfangreiche Entwicklungsszenarien natürlich komplexer aussehen.

Hinweis zur Aktualisierung der PHP-Installation:
Um eine aktuelle PHP5-Installation unter Opensuse 11.2 zu erhalten (PHP 5.3.3) muss man ggf. die passenden Repositories unter

http://download.opensuse.org/repositories/server:/php/
http://download.opensuse.org/repositories/server:/php:/extensions/

in die Paketverwaltung einbinden. Über das zweite der genannten Repositories erhält man z.B. das Xdebug-RPM.

Modifikation an der php.ini

Auf einem Entwicklungssystem will man man Fehlermeldunge zu PHP5-Programmen sehen. Evtl. hat man auch Programme, die mit der Kurzform der Script-Tags “” statt lauffähig sein sollen. Um beim Einsatz der Funktion “date()” Warnungen zu vermeiden, stellt man auch die Standardzeitzone für das PHP-Modul ein. Für all das muss man entsprechende Modifikationen an der Datei

“/etc/php5/apache2/php.ini”

vornehmen. Entsprechende Einträge (plus ein paar mehr) :

  • short_open_tag = On
  • error_reporting = E_ALL & ~E_DEPRECATED
  • display_errors = On
  • log_errors = On
  • ignore_repeated_errors = Off
  • ignore_repeated_source = Off
  • register_globals = Off (immer gut)
  • include_path = “.:/usr/share/php5:/usr/share/php5/PEAR” (PEAR soll funktionieren)
  • date.timezone = Europe/Berlin

“Spiel-Zertifikat und SSL-Aktivierung unter Opensuse 11.3

Viele meiner PHP-Frameworks für Kunden erzwingen in der Regel einen HTTPS-Verbindung. Wenn ich das lokal testen will, komme ich um SSL also nicht herum. SSL geht nur über IP-basierte virtuelle Domainen. Für den Standardhost “localhost” ist dann zudem eine zweite separate virtuelle Domaine einzurichten.

SSL geht nicht ohne ein Minimal-Zertifikat. Für lokale Testzwecke reicht ein “Spiel-Zertifikat”. (Im Browser fügt man dann bei Warnungen eine Ausnahmeregel für das Zertifikat ein.)

Unter Opensuse 11.3 erreicht man die notwendige Grundausstattung des Apache-Servers unter Benutzung von Apache-Tools durch folgende Kommandos:

  • a2enmod ssl
  • a2enflag SSL
  • /usr/bin/gensslcert (als root absetzen)
  • cp /etc/apache2/vhosts.d/vhost-ssl.template /etc/apache2/vhosts.d/vhost-ssl.conf
  • Anpassung der vhost-Dateien (s.u.)

Ein paralleler Blick in die “sysconfig”-Dateien des SUSE-Systems ist hier nicht verkehrt. Dafür kann man z.B. den sysconfig-Editor von Yast heranziehen. Im dortigen kategoriebaum bewegt man sich in den Zweig

“Netzwerke   >>>   WWW   >>>   Apache2”.

Unter dem Eintrag “APACHE_MODULES” sollte man folgendes finden:

authz_host actions alias auth_basic authz_groupfile authn_file authz_user autoindex cgi dir include log_config mime negotiation setenvif status userdir asis imagemap ssl php5 authz_default

Unter dem Eintrag APACHE_SERVER_FLAGS sollte SSL
auftauchen:

SSL

Hinweise:

  • Ein Extra-RPM für das SSL-Modul muss unter Opensuse 11.3 nicht installiert werden.
  • gensslcert erzeugt nur eine Spiel-Cert. Dabei werden folgende Dateien überschrieben:
  • /etc/apache2/ssl.crt/ca.crt
  • /etc/apache2/ssl.key/server.key
  • /etc/apache2/ssl.crt/server.crt
  • /etc/apache2/ssl.csr/server.csr
  • Der Virtual-Host für die SSL-Domaine muss IP-basiert (!) angelegt werden – also nicht namensbasiert. “*”-Angaben für die IP-Adressen werden mit Fehlermeldungen quittiert. In unserem Beispiel werden für das autonome Testsystem die Loopback-Adressen herangezogen.
  • Man darf nicht vergessen, dass man für einen Standardzugang “http://localhost” eine eigene virtuelle Domaine einrichten muss, da es bei virtuellen Domainen ohne Vorkehrungen keinen Standard-Host (Default-Web-Server) mehr gibt.

Konfigurationsdateien

Nachfolgend gebe ich (etwas verkürzt) an, welche Grundeinträge in zwei Konfigurationsdateien unter dem Verzeichnis

/etc/apache2/vhosts.d

notwendig sind, um das Ziel zu erreichen,

  • einen Standardhost ohne SSL-Verschlüsselung unter “http://localhost”
  • eine Testdomaine “devdomain” für Entwicklungszwecke über “https://devdomain”

ansprechen zu können:

Inhalt der Datei “ip-based_vhosts.conf” für den Standardserver

<VirtualHost *>

DocumentRoot /srv/www/htdocs

DirectoryIndex index.html index.html.var index.htm index.php index.php5

<Directory “/srv/www/htdocs”>

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from all

</Directory>

</VirtualHost>

Hinweise:

  • Der Name der Datei kann beliebig gewählt werden !
  • Es wird hier kein “server-name angegeben” !!!! – Default-Server
  • Das Root-Verzeichnis für den Standardhost ist hier “/srv/www/htdocs”. Dort sind die Web-Dateien und PHP-Programme anzulegen.

Inhalt der Datei “vhost-ssl.conf” für den IP-basierten, SSL-Server für die Domaine “devdomain”

<IfDefine SSL>

<IfDefine !NOSSL>

<VirtualHost 127.0.0.2:443>

DocumentRoot “/srv/www/htdocs/Entwicklung/devdomain/trunk/”

ServerName
devdomain:443

ErrorLog /var/log/apache2/error_log

TransferLog /var/log/apache2/access_log

SSLEngine on

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

SSLCertificateFile /etc/apache2/ssl.crt/server.crt

SSLCertificateKeyFile /etc/apache2/ssl.key/server.key

<Files ~ “\.(cgi|shtml|phtml|php3?)$”>

SSLOptions +StdEnvVars

</Files>

<Directory “/srv/www/cgi-bin”>

SSLOptions +StdEnvVars

</Directory>

SetEnvIf User-Agent “.*MSIE.*” \

nokeepalive ssl-unclean-shutdown \

downgrade-1.0 force-response-1.0

CustomLog /var/log/apache2/ssl_request_log ssl_combined

</VirtualHost>

</IfDefine>

</IfDefine>

Hinweise:

  • Der Host muss eine IP-Adresse erhalten – hier die lokale Loopback-Adresse.
  • Der Servername (vergl. mit /etc/hosts) wird in einer speziellen, separaten Zeile eingetragen.
  • Die IP-Adresse muss mit dem angegebenen Namen des Servers auch in der Datei “/etc/hosts” eigetragen sein !
  • Das DocumentRoot-Verzeichnis habe ich deshalb mit dem “trunk”-Zweig ausgestattet, um die Verzeichnisstruktur eines an Eclipse angebundenes SVN-Repositories zu berücksichtigen. Das kann man natürlich auch anders machen.

Nach dem Anlegen der Dateien kann man nun die neue Konfiguration nach einem “rcapache2 restart” testen. Dazu legt man im Verzeichnis

/srv/www/htdocs/Entwicklung/devdomain/trunk/

eine kleine Testdatei an oder kopiert die “index.html” aus dem Pfad “/srv/www/htdocs” dorthin. Firefox sollte beim Aufruf der Adresse “https://devdomain” keine SSL-bezogene Fehlermeldung anzeigen, sondern nur wegen des nicht vertrauenswürdigen Zertifikats warnen. Der Warnung begegnet man mit einer dauerhaften Ausnahme-Regel. Danach sollte die Test-Datei angezeigt werden. Taucht wieder Erwarten eine Meldung “ssl_error_rx_record_too_long” auf, so ist etwas an der Apache-Konfiguration faul und man muss nacharbeiten.

Das ist natürlich nur eine Ruck-Zuck-Installation eines lokalen Testservers für den Hausgebrauch auf einem PC oder Laptop. (Ein ordentlich aufgesetzter Apache2 sieht anders aus). Aber mit der obigen Konfiguration lassen sich schon bestens PHP-Programme testen.

Viel Spaß also beim PHP-Entwickeln unterwegs – und natürlich unter Linux !

Ergänzung 02.10.2012:

Eine knappe Grundinstallationsanleitung zu Apache2, MySQL, PHP (LAMP) unter Opensuse 12.1 findet man übrigens unter:
http://www.
liveconfig.com/de/kb/9.html

Links

http://de.opensuse.org/Apache/SSL-Anleitung
http://de.opensuse.org/Apache
http://www.schirmacher.de/display/INFO/Apache+SSL+Zertifikat+erstellen+und+installieren
http://wiki.ubuntuusers.de/Apache/SSL
http://aktuell.de.selfhtml.org/artikel/server/apacheconf/apconf12.htm
http://de.opensuse.org/Apache/Schnellstartanleitung

Vererbung von ext3-/ext4-Gruppenrechten

Posted on by

Immer mal wieder fragt mich jemand, was er tun muss, damit Dateien oder Unterverzeichnisse unterhalb eines bestimmten ext3- oder ext4-Verzeichnisses auf einem Linux-System immer mit der gleichen Gruppe und (!) immer mit den gleichen Gruppen-Rechten erzeugt werden.

Problemstellung

Das Problem der Vererbung von GIDs und Gruppenrechten tritt z.B. immer dann auf, wenn mehrere Entwickler einer Gruppe auf einem Verzeichnis arbeiten und neu erzeugte Dateien auch allen anderen Benutzern der Entwicklergruppe mit gleichen Rechten zugänglich gemacht werden sollen. Und das, ohne dass man beim Erzeugen der neuen Dateien und Verzeichnisse spezielle Rechteänderungen über das “chmod”-Kommando vornehmen müsste.

Offenbar ist das Thema weniger trivial, als man meinen möchte. Denn manchmal liest man in Tutorials, dass es genügen würde, das SetGID-Bit für das betroffene Directory zu setzen. Das stimmt so leider nicht – und so mancher beginnt dann mit

“chgrp -R”     und     “chmod -R”

zu experimentieren. Was auch nicht hilft, weil das nur einmalige – wenn auch rekursive – Änderungen im betroffenen Zweig des Dateibaums herbeiführt. Das eigentliche Ziel ist aber, die richtige Gruppenzugehörigkeit und die notwendigen Rechte (meist Schreibrechte) schon beim Erzeugen einer Datei zu erhalten.

Liegen die Dateien auf einem Fremdrechner, so kann man eine Lösung über Samba erreichen. Wir wollen hier aber eine native Lösung für beschreiben.

Die richtige Antwort auf dieses Problem ist eine Kombination aus ACLs und dem SetGID-Bit.

Vorgehen

Wir nehmen zwei User eines Systems – “alpha” (uid 1001; dieser User wird der Entwicklunsgleiter) und “beta” (uid 1002). Beide seine Mitglieder der Gruppe “users” (gid 100). umask habe den Standardwert

umask 022

Was ist nun zu tun?

Schritt 1: Anlegen einer gemeinsamen Usergruppe
Als root: Anlegen einer neuen Gruppe “entwickler” (gid: 101) und Zuordnen der beiden User zu dieser Gruppe. (Unter Opensuse z.B. mit Hilfe von Yast; ansonsten mit “groupadd” und “usermod -A” – siehe die man-Seiten).

Schritt 2: Check, ob ACLs für das Filesystem aktiviert sind
Als root: Prüfe, ob das Filesystems, in dem das Verzeichnis für die Gruppenarbeit angelegt wird, mit der option “acl” gemounted wird. In der Datei “/etc/fstab” sollte sich dafür ein Eintrag der Form

/dev/myFileSystem     /myMountPoint     ext4     acl,user_xattr     1 2

finden. “myFileSystem” steht hier für das betroffene Filesystem. “/myMountPoint” steht dagegegen für das Verzeichnis, auf dem das Filesystem gemounted wird. Entscheidend ist die Option “acl”.

Schritt 3: Anlegen des Verzeichnisses für die gemeinsame Entwicklungsarbeit
Als root oder Entwicklungsleiter “alpha”: Anlegen des Arbeitsverzeichnisses, unter dem die gemeinsame Projektarbeit vor sich gehen soll. Z.B.:

mkdir   /myMountPoint/Entwicklung

Danach Ändern der Gruppe und der Rechte

chgrp   entwicklung     /myMountPoint/Entwicklung
chmod   775     /myMountPoint/Entwicklung

Schritt 4: Setzen des SetGID-Bits
Als Entwicklungsleiter “alpha”:

chmod   g+s     /myMountPoint/Entwicklung

Von nun an erben alle Verzeichnisse und Dateien, die unterhalb des Verzeichnisses “/myMountPoint/Entwicklung” angelegt werden, die die Gruppenzugehörigkeit zur Gruppe “entwicklung”.

Schritt 5: Setzen der ACL-Maske
Als Entwicklungsleiter “alpha”:

cd  /myMountPoint

setfacl -m     m::rwx     Entwicklung
n
Diese Maske setzt die maximal möglichen Rechte für das Verzeichnis “Entwicklung”.

Schritt 6: Setzen der Default-Rechte für künftige Dateien und Unterverzeichnisse
Als Entwicklungsleiter “alpha”:

cd   /myMountPoint

setfacl -dm     g:entwicklung:rwx     Entwicklung

Schritt 7: Prüfen der Rechte für neue Dateien und Unterverzeichnisse
Als Gruppenmitglied “beta”:

cd   /myMountPoint/Entwicklung

touch   test
ls -l
-rw-rw-r–+ 1     beta     entwicklung     0     20. Jul 20:18     test

mkdir   testdir
ls -l
drwxrwsr-x+ 2     beta     entwicklung     4096     20. Jul     21:20     testdir

touch   testdir/test2
ls -l   testdir
-rw-rw-r–+ 1     beta     entwicklung     0     20. Jul     21:22     test2

Viel Spaß nun beim Arbeiten in der Gruppe !

Links
http://wiki.ubuntuusers.de/chmod#SGID-Bit
http://wiki.ubuntuusers.de/ACL#Verzeichnisse