Systemumgebung:

WordPress auf einem vServer (mit Apache2) installiert

Bild Unicorn-Wallpaper: Copyright wpthestestdata.wordpress.com

Fehlermeldung

Beim Zuschneiden Deines Bildes ist ein Fehler aufgetreten.

Fehlerursache:

Das PHP-Modul php-gd ist nicht installiert.

Fehlerbehebung:

Die GD Graphics Library zur dynamischen Bearbeitung von Bildern ist nachzuinstallieren und der Apache-Server neu zu starten.

apt-get install php5-gd
service apache2 reload

Kontrolle der Aktivierung

Zur Prüfung, ob die php5-gd Unterstützung aktiv ist, kann folgender Befehl in der Kommando-Shell abgesetzt werden. Als Antwort sollte das System ein simples „gd“ zurückgeben.

$ php5 -m | grep -i gd

oder

oder Ausgabe einer Liste der installierten PHP-Module

php -m

oder ein kleines PHP-Skript schreiben und sich die installierten PHP-Module ansehen

<?php  phpinfo();  ?>

Wenn man mit Adobe Illustrator arbeitet, dann steht früher oder später auch ein Grafiktablet auf der Wunschliste.
Ich habe mich für das Graphics Tablet M708 von Ugee entschieden, welches es augenblicklich zum Sonderpreis von knapp 60 EUR anstatt für 100 EUR zu kaufen gibt.

Das Grafiktablet ist wirklich gut und eine Kaufempfehlung wert, allerdings läuft es nach der Installation des Gerätetreibers unter Windows 7 nicht sofort und im Internet lies sich auch kein Hinweis finden, woran dies liegen könnte.

Problembeschreibung

Trotz Installation des Grafiktablet Gerätetreibers des Herstellers reagiert das am USB-Port angeschlossene Gerät nicht. Der Mauszeiger läßt sich durch den Grafiktablet-Stift nicht bewegen.

Lösung

1. Start/Systemsteuerung/Programme/Programme und Funktionen aufrufen

2. Bei der Funktion Tablet PC-Komponenten einen Haken setzen

Viel Spaß beim Arbeiten mit dem Tablet

Manfred

Copyright: wampserver.com

Fehlermeldung:

Systemumgebung: WAMP 2.5, Win 7 Pro

In der Datei php_error.log finden sich folgende zwei Fehlermeldungen, die beim Hochfahren des WAMP-Servers geworfen werden.

[09-Feb-2016 08:21:30 UTC] PHP Warning:  PHP Startup: Unable to load dynamic library ‚c:/wamp/bin/php/php5.5.12/ext/php_ldap.dll‚ – Das angegebene Modul wurde nicht gefunden.

[09-Feb-2016 08:21:31 UTC] PHP Warning:  PHP Startup: Unable to load dynamic library ‚c:/wamp/bin/php/php5.5.12/ext/php_intl.dll‚ – Das angegebene Modul wurde nicht gefunden.

Lösung:

Vermutlicher Hintergrund der Warnungen:

Es wurden individuelle Pfade bei der WAMP-Installation gesetzt.

Die Symlinks im apache/bin Verzeichnis müssen neu gesetzt werden.

Glücklicherweise kann das die WAMP Installation selbst korrigieren. Man muss dazu nur im WampServer 2.5 Menü, zum Punkt Apache / Version gehen und dann auf die Versionsnummer (im Screenshot: 2.4.9) anklicken.  Daraufhin fährt der WampServer selbst herunter und wieder hoch. 

Links

Als Webentwickler arbeite und kämpfe ich mit CSS-Stylesheets. Warum ich das Wort „kämpfen“ verwende, das können Sie in diesem Artikel lesen.

Wildwuchs bei Stylesheets

Wenn man sich den Quellcode einer Internetseite ansieht, dann staunt man teilweise nicht schlecht. Oft werden im besten Fall 5 bis 10 verschiedene Stylesheets eingebunden, teilweise sind es aber auch mal an die zwanzig CSS-Dateien.

Das ist nicht nur schlecht für die Ladezeit der Seite (Performance, Google Page Speed), sondern auch für die Qualität der Seite, da durch das gegenseitige Überschreiben der Stylesheet-Befehle teilweise ungewünschte Resultate entstehen (z.B. ein Plugin funktioniert nicht/nicht mehr wie gewünscht)  

Ursache des Wildwuchs

Um die eigene Funktionalität zu gewährleisten, bringen insbesondere drei Komponenten ihre eigenen Stylesheets mit:

• das WordPress Theme selbst
• Frameworks wie Bootstrap
• die Mehrheit der Plugins

1.) #id- und .class-Bezeichner

Bei Smartphones hat man sich inzwischen glücklicherweise bezüglich der Ladegeräte auf einen Standard geeinigt. Bei den id- und class-Bezeichnern innerhalb der Stylesheets wäre es jedoch Utopie anzunehmen, dass dies irgendwann einmal geschieht. Die CSS-Klasse für den Hauptinhaltsbereich heißt dann bei dem einen #container, beim anderen #main-container, dann wieder #page, u.s.w. 

Insbesondere, wenn man mehrere Domains besitzt oder als Webagentur, heißt es dann jedes Mal wieder aufs Neue die css-Bezeichner z.B. für das Menü anzupassen.

2.) Browser Kompatibilität

Schwierig wird es, wenn die Themes und Frameworks CSS-Grundinitialisierungen (CSS-Resets) vornehmen [1].

Die Absicht dahinter ist zunächst einmal gut und nachvollziehbar. Man möchte, dass Browser Inkompatibilitäten vermieden werden, damit sichergestellt werden kann, das ein responsives Design in den gängigen Browsern auch gleich dargestellt wird. Aber die Autoren der Themes und Frameworks haben verschiedene Meinungen was Basis eines Stylesheets sein müßte und kochen bei verschiedenen Punkten ihre eigenen Süppchen. 

Nun könnte man sich zwar für die eine oder andere CSS-Reset vorgehensweise entscheiden und die andere deaktivieren, aber so einfach ist dies dann doch nicht, wenn das Theme oder das Framework auf gerade den eigenen, mitgelieferten Resetanweisungen beruht.

3.) Namensraum

Ein drittes Problem bei den Stylesheetdateien ist die Namensgebung.

Was liegt näher, als bei einem Plugin, welches spezielle Buttons zur Verfügung stellt, nicht auch eine Klasse mit .button zu bezeichnen. Installiert man dann ein anderes Plugin, wobei es nicht unbedingt ein zweites Button-Plugin sein muss, sondern  z.B. ein Shortcode Plugin (uuups, auch hier werden immer Buttons-Shortcodes mitgeliefert), dann ist die Wahrscheinlichkeit sehr groß, dass auch dieser Entwickler eine seiner CSS-Klassen mit .button bezeichnet hat. 

Namenskonflikte sind bei so  wenig Kreativität unvermeidlich.

Leider arbeiten die wenigsten Pluginentwickler mit eigenen Namensräumen und liefern damit einen rebusteren, qualitativ besseren Code.

Erkannte Problematik (Reglementierung)

Der aufmerksame Leser dieses Artikels mag nun einwenden, dass ich mich im ersten Punkt für  genormte Bezeichner ausgesprochen habe, um dann im dritten Punkt genau das Gegenteil zu fordern, nähmlich individuelle Bezeichner. 

Dies ist nur scheinbar ein Widerspruch. Die Namensgebung für die #id-Selektoren sollte geregelt sein, die für die .class-Selektoren hingegen nicht.

Links, die sie interessieren könnten:

Fehlermeldung im E-Mail Client Thunderbird

Senden der Nachricht fehlgeschlagen.
Die Nachricht konnte nicht gesendet werden, weil die Verbindung mit dem SMTP-Server mail.ihr-smtp-server.de ihre Ablaufzeit (Timeout) überschritten hat. Versuchen Sie es nochmals oder kontaktieren Sie Ihren Netzwerkadministrator.

Probleme bei der Suche nach der Fehlerursache

• Das E-Mail Programm lief bisher ohne Probleme. (Keiner war’s)
• Es wurden keine Programm-Updates auf dem Computer eingespielt. (Keiner war’s)
• Das Versenden von E-Mails ist nicht mehr möglich. Der Zeitpunkt, ab dem dieser Fehler auftrat, ist jedoch nicht bekannt. Das ist wenig hilfreich für das Eingrenzen der Fehlerursache.
• Fischen im Trüben: Keiner war’s, aber irgendetwas muss sich doch verändert haben. Änderungen an den Firewalleinstellungen des Computers? Letzte Updates des Virenscanners auf dem Desktoprechner?
• Wenn es nicht am lokalen Rechner, sondern am externen SMTP-Server liegt und dort ein Software-Update (Betriebssystem oder ähnliches) aufgespielt wurde, dann hätte man schlechte Karten für eine Fehlerbehebung.
• Benutzer der E-Mail Clients sind in Panik (keine E-Mails mehr verschickbar, keine Antworten mehr auf Anfragen möglich). Zeitdruck für Lösungsfindung.

Fehlerursache

Die Fehlerursache war letztendlich der Wechsel des Internetrouters gewesen. Von einem Fritz!Box Router war auf einen Speedport W 724V Typ A von der Telekom gewechselt worden (mit IP-Telefonie und DSL-Vectoring).  Die Probleme beim Verschicken von E-Mails wurden erst zwei Tage später bemerkt und nicht in Zusammenhang mit dieser Umstellung gebracht.

Konfigurationsmenü des Speedport W 724 V

Der Speedport Router filtert IP-Adressen.

In der Grundeinstellung wird zur „Reduzierung des weltweiten E-Mail Spam-Aufkommens „eine Liste von Postausgangsservern abgefragt (siehe Screenshot).

Ist der verwendete Firmen E-Mail Server hier nicht dabei, dann kommt es zur eingangs erhaltenen Fehlermeldung, dass die E-Mail Nachricht nicht gesendet werden konnte.

Fehlerbehebung

Entweder das Häkchen bei der Checkbox „Liste der sicheren E-Mail-Server“ entfernen oder weiter unten den eigenen E-Mail Server zur Liste der erlaubten E-Mail Server hinzufügen.

Fazit

Sehr ärgerliches Problem.  Der normale PC Benutzer ist damit vollkommen überfordert. In der Bedienungsanleitung des Speedport Routers müßte zwingend ein Hinweis aufgenommen werden, der auf diese Problematik (E-Mail Versand) hinweist.

Ansonsten war der Speedport W 724 V Router wohl auch ein „Montagsgerät“. Alle Veränderungen im Konfigurationsmenü ließen sich zwar scheinbar abspeichern, aber sobald man zur Kontrolle eine Aktualisierung des Bildschirms (Funktionstaste F5 oder Browser-Seitenrefresh) vornahm, sah man, dass immer noch die ursprüngliche Einstellung aktiv war. Da half auch ein Neustart des Routers oder ein vom Stromnetznehmen nichts.

Empfehlung*

Letztendlich war der Wechsel zum neuen Vectoring fähigen DSL Router Fritz!Box 7490 von avm die schnellste Lösung. 

Ans Netz angeschlossen,

Zugangsdaten der Telekom eingegeben.

Läuft.

So sollte es sein.

Wie kann man die Heimnetz IP-Adresse  verändern?

Der Router Fritz!Box 7490 (DSL mit Vectoring und IP-Telefonie) wird werksseitig mit der internen Heimnetz IP-Adresse 192.168.178.1 ausgeliefert.

Was nun aber, wenn schon ein internes Netz mit einem anderen Nummernkreis z.B. 192.178.50.xx vorhanden ist, mit statisch vergebenen Geräte IP-Adressen u.a. auch für die Drucker?

Problem: 

Im Handbuch heißt es, dass man im Geräte Administrationsprogramm unter Heimnetz/Netzwerkeinstellungen einfach unter IP4 die neue interne IP-Adresse eingeben soll.  Leider existiert auf der Maske aber dieser Einstellungspunkt nicht.  Ist das Handbuch hier falsch, nicht up-to-date?

Lösung:

Es gibt einen Expertenmodus für die Administration des Fritz!Box Routers. Darauf muss man erst einmal kommen oder diesen per Zufall finden.

Aktivierbar ist der Expertenmodus über das Drei-Punkte Zeichen ganz rechts oben.

Aktiviert man diesen Expertenmodus, dann werden in den Masken viel mehr Einstellungsmöglichkeiten angezeigt, u.a. auch eine Möglichkeit den internen IP-Adressbereich zu ändern.

Viel Spaß mit der FritzBox

Manfred

Level: Programmierer

Der folgende Artikel beschreibt meine Vorgehensweise bei einer Fehlersuche mit der Fehlermeldung

WordPress toolkit – Call to undefined function efine()

Ausgangssituation und Fehlerbeschreibung:

• WordPress wurde auf einem neuen Rootserver mit der Administrationsoberfläche Plesk vollkommen neu eingerichtet
• beim Aufruf der Seite unter dem Domainnamen, bleibt die Seite absolut leer (HTML-Sourcecode ist auch absolut leer)

Ursachenforschung:

• Check: Im Hauptverzeichnis sind alle WordPress Dateien und Verzeichnisse sind im Hauptverzeichnis der Domain angelegt
• Check: Die Datenbank existiert, die Standard WordPress Tabellen sind angelegt
• Plesk: Beim Aufruf der Domain-Einstellungsinformationen wird die folgende Fehlermeldung angezeigt:

WordPress toolkit – Call to undefined function efine() in /usr/share/plesk-wp-cli/php/WP_CLI/Runner.php(847)

In der Fehlermeldung oben heißt es „WordPress toolkit“ das ist eine Plesk Zusatzfunktion und das Verzeichnis …/plesk-wp-cli/…“ deutet auch auf eine Plesk internes Programm hin.

Google-Fehlersuche:

Das Suchen der Fehlermeldung bei Google ergibt zwar Behebungsvorschläge

z.B. mit der Überschrift „WP-CLI can fail cryptically when parsing custom wp-config.php“ [1]

aber die Lösungsvorschläge scheinen mir den Fehler nur zu kaschieren, einen Workaround zu bieten, aber nicht wirklich die Ursache anzugehen.

Fehleranalyse und Ursachenhypothese:

Ich hätte wenig Verständnis dafür, dass nach einer Grundinstallation von Plesk, auf einem neueingerichteten Server mit Ubuntu 14 LTS ein Fehler in einem Plesk-Skript (…/plesk-wp-cli/…) auftritt.

Das Verzeichnis plesk-wp-cli deutet darauf hin, dass WP-CLI Funktionen zum Einsatz kommen.

• WP-CLI ist ein Set von Befehlszeilenbefehlen, mit welchen man WordPress Installationen verwalten (managen) kann [2]. 
• Das „I“ in CLI steht für Interpreter. 
• Die Google Fehlersuche hat zwar keine konkrete Lösungshilfe gegeben, aber das „parsing custom wp-config.php“ [1] bringt mich auf die Idee, dass sich in der wp-config.php vielleicht ein Verschreibfehler eingeschlichen hat, der dann beim Abarbeiten der Befehlszeilen (parsing) das ganze System zum „Absturz“ brachte.

Abschluss

Die Ursachenhypothese stellte sich als zutreffend heraus. 
In einer Zeile in der wp-config.php stand ein

„efine() ….“  anstatt richtigerweise „define()“

Hinweis:

Auch wenn der Fehler damit behoben ist und die WordPress Anwendung danach aufrufbar ist, kann es sein, dass im Cache des Browsers (z.B. bei Firefox der Fall) die Plesk-Hosting-Einstellungen Seite immer noch gespeichert ist und die Fehlermeldung „…efine()“ noch angezeigt wird.

Wenn das Leeren des Browser-Caches nicht hilft (Fehlermeldung wird immer noch in Plesk angezeigt), dann in Plesk den Button „WordPress syncronisieren“ aufrufen!

Links:

Beim Aufsetzen einer WordPress Multisite hat man die Möglichkeit,  die Unterblogs als Subdomains oder in Unterverzeichnissen einzurichten. In diesem Artikel möchte ich keine Stellung beziehen für oder gegen eine dieser beiden Möglichkeiten. Wohl aber das PRO-Subdomain Argument, dass Subdomains besser für das Suchmaschinenranking sind, kritisch in Frage stellen.

WordPress Multisite Subdomains

Die Argumentation vieler lautet ja, dass für Google die Domains

• meineDomain.de
• www.meineDomain.de
• handtasche.meineDomain.de
• buegelbrett.meineDomain.de
• xyz.meineDomain.de
• … u.s.w.
  

verschiedene Domains sind und man daher bei Einrichtung von Subdomains dort Seriosität und Ranking-Juice aufbauen könnte, um diese dann auf die Hauptdomain zu vererben.

So in der Art, ich setze mal schnell zwanzig Suddomain Websites auf (durchaus mit gutem, einzigartigen Inhalt) und verweise dann auf eine zentrale Domain, die dann die ganze Ranking-Power, der von mir selbst gepflegten Seiten, erbt.

Subdomainbewertung kritisch Hinterfragen

Google hat 200 bis 300 Kriterien nach denen es eine Website bewertet, um diese dann bei der Suchergebnisanzeige entsprechend zu positionieren. (Wieviel Kriterien es genau sind und mit welcher Wertigkeit diese eingehen, ist ein großes Geheimnis bei Google und unterliegt auch periodischen Veränderungen.)

Ja, für Google sind Verweise von externen Websites auf eine andere Domain ein Indiz dafür, dass die Zieldomain einem potentiellen Besucher zu diesem Thema nützliche, interessante Inhalte zeigen würde.

Aber wie kann man nur annehmen, dass Google soviel Energie, Knowhow und Geld in die Optimierung seiner Suchalgorithmen investiert und dann Google so absolut dumm ist, dass der Suchmaschinenriese nicht merkt, dass die Subdomains einzig und allein mit dem Hintergedanken der Manipulation des Suchmaschinenrankings aufgesetzt wurden.

• Für Google ist es doch glasklar, dass der Besitzer der Domain  meineDomain.de auch gleichzeitig der Domaininhaber von handtasche.meineDomain.de ist
• Bei der Auflösung der Domain meineDomain.de und handtasche.meineDomain.de wird die gleiche Server IP-Adresse zurückgeliefert. (–> interner und kein externer Link von einer fremden Domain [4])

Mein Fazit:

Google ist doch nicht so dumm und lässt sich so leicht austricksen. Wenn ich Google wäre, würde ich diese einfach zu durchschauenden und einfach zu verifizierenden SEO-Manipulationsversuche weiterhin nicht kommentieren und insgeheim die Zielseite sogar abstufen.

Der vielfach zu lesende Rat WordPress Multisite-Blogs wegen SEO-Vorteilen als Subdomains anzulegen, ist falsch. Da schreibt ein Pseudo-SEO Experte vom anderen ab, ohne zuvor die grauen Zellen im Kopf eingeschaltet zu haben.

Links

[3] Matt Cutt: Should I structure my site using subdomains or subdirectories?

Quick-Tipp: Verzeichnis Windows.old löschen

Bei der Umstellung von Windows 7 / Windows 8 auf Windows 10 werden die alten Betriebssystemdateien in den Ordner Windows.old verschoben. Diese Vorgehensweise von Microsoft ermöglicht es,  wieder den alten Zustand vor dem Betriebssystemupgradeversuch herstellen zu können, falls bei dem Betriebssystemupgrade doch einmal etwas schief geht.

Dieser Ordner Windows.old kann schon einmal bis zu 40 GB groß sein, wenn man in der Vergangenheit fleissig Betriebssystemupdates eingespielt hat.

Ist man sich sicher, dass man nicht mehr auf das alte Betriebssystem zurück möchte (alle alten Treiber funktionieren, …), dann kann man natürlich auch seine Festplatte von dieser Altlast bereinigen.

Ein direkter Löschversuch des Ordners Windows.old ist bei mir gescheitert. (Windows löscht erst den Ordner mit den Dateien, um diesen dann sofort wieder aus dem Papierkorb zu recyclen, den Ordner mit den Dateien wiederherzustellen.)

Dies heißt nun nicht, dass man den Windows.old Ordner nicht löschen kann, sondern nur, dass Microsoft sich hier eine andere Vorgehensweise für das Löschen dieses speziellen Ordners wünscht, bei der dann auch die internen Verknüpfungen zu den Wiederherstellungsfunktionen von Windows mitgeändert werden.

Man kann den Ordner Windows.old löschen, indem man über die Systembereinigung des Bootlaufwerks (in der Regel C:/ ) geht und dort die Schaltfläche „Systembereinigung“ drückt.  Dann erhät man eine Checkbox-Auswahlliste, in der auch ein Eintrag „Vorherige Windows-Installation(en)“ aufgeführt ist.

Im folgenden Beispiel (siehe Screenshot) konnten so fast 14 GB an Festplattenplatz wieder freigegeben werden.

Links:

Bei der Installation der lokalen Webserverumgebung WAMP 3.0.4 [1] erhielt ich mehrere Fehlermeldungen. Der folgende Artikel beschreibt die aufgetretenen Probleme und deren Lösungen.

Ausgangssituation

• Rechner mit Windows 7 Professional
• ehem. WAMP 2.5 Version wurde gelöscht

Aufgetretene Fehler

Vorab zu ladende DDL’s

Eigentlich hätte ich angenommen, dass bei einer Grundinstallation von WAMP [1] alle benötigten Programm-Libraries und auch Windows-Dateien mitinstalliert werden, dem scheint aber nicht so zu sein.

Bei der Installation der 3.0.4 Version von WAMP wird als fehlend und nachzuinstallieren gemeldet:

• vcruntime140.dll
• ap-ms-win-crt-runtime-l1-1-0.dll

Beide dll’s sind im Internet kostenlos von Microsoft herunterzuladen.
(Anmerk.: Ich hätte diese beiden Dateien als Anhang zu diesem Blogbeitrag zur Verfügung gestellt, aber aus Copyrightgründen, bitte von Microsoft selbst herunterladen.) 

Bei vcruntime140.dll ist darauf zu achten, dass man die richtige Betriebssystemversion 32 oder 64bit nimmt.

Bei der ap-ms-win-crt-runtime-l1-1-0.dll Datei installiert man am besten gleich die ganze Library vc_redist.x86.exe von Microsoft nach.

Nach der Nachinstallation dieser beiden DLL’s ist der Rechner nochmals herunter- und hochzufahren.

Installation als Administrator

Installiert man WAMP 3 nach der Installation der fehlenden DDL’s, scheint dies auch zu klappen. Wenn man allerdings die Startseite des Apache Webservers aufruft (http://localhost), dann kann man nur erstaunt wieder eine andere Fehlermeldung zur Kenntnis nehmen:

Die Lösung ist:

WAMP 3.0 nochmals vollkommen zu deinstallieren und mit Administratorrechten erneut installieren.

Als Grund für diese Fehlermeldung findet man im WampServer-Forum [3] folgende Aussage, die ich hiermit zitiere:

Regarding the existance (or not) of a php.ini file in the Apache folder.

Since WAMPServer 2.5 we have been using SYMLINKS or as they are sometimes called in Windows – Junctions.

This means that a SYMLINK is placed into the \wamp\bin\apache\apache{version}\bin folder pointing to the php.ini file that actually lives in \wamp\bin\php\php{version} folder. The actual file is NO LONGER copied, just a symlink is created.

Now of course this symlink while called ‚php.ini` actually points to the ‚\wamp\bin\php\php{version}\phpForApache.ini‘ file as this contains the config that is relevant to a PHP run as an Apache module which is how WAMPServer runs PHP.

The \wamp\bin\php\php{version}\php.ini file is used only for the PHP CLI (Command Line Interface) i.e. when you run PHP from the command line in a Windows Command Window.

Quelle: [3], December 01 2015, Posted by: RiggsFolly

 

Fazit und gelbe Karte an WAMP:

Es gibt meines Erachtens zwei gute Distributionen für lokale Webserver (WAMP [1] und Xampp [2]).

Die Installation von WAMP in der Version 2.0 bis 2.5 war immer problemlos.

Warum das Entwicklerteam um WAMP nun die Anwender bei der Version 3.0 mit solchen Problemen konfrontiert, ist für mich nicht nachvollziehbar.

Wenn die Version 3.0 höhere Installationsvoraussetzungen hat, d.h. Microsoft Libraries verwendet, die standardmäßig bei Windows 7 nicht vorhanden sind, dann muss man diese entweder im Installationspaket mitliefern oder die Abhängigkeit von Microsoft-Libraries beenden und die Software auf andere Fundamente stellen. Es genügt auf keinen Fall bei der Installation eine elend lange Liste von vorab zu installierender Libraries aufzulisten. Jeder normale Anwender ist damit überfordert.

Ich spreche hiermit eine gelbe Karte für das Entwickler-/Organisationsteam von WAMP 3.0.4 aus, weil ich kurz davor bin, jedem davon abzuraten, WAMP zu installieren, wenn doch eine Xampp Installation mehr oder weniger eine One-Click Aktion ist.

Links:

Es ist recht einfach in Ubuntu 14.0.3 (Desktop-Version) ein Icon für ein Terminalfenster links in der Menüleiste einzurichten.

Schritt 1: Tastenkombination

 Der schnellste Weg ein Fenster zu öffnen, indem man Linuxbefehle eingeben kann (Terminalfenster, Shellfenster, Command-Prompt-Fenster) ist, über die Tastenkombination Ctrl + Alt + T .

Daraufhin öffnet sich ein Terminalfenster auf dem Desktop und gleichzeitig wird das Terminalicon links in der Menüleiste des Ubuntu Desktops angezeigt.

Schritt 1a (Alternative): Anwendungssuche

Um zunächst einmal ein Terminalfenster zu öffnen, kann man alternativ auch über das Anwendungssuchicon gehen und dort als Suchbegriff „Terminal“ eingeben.

Schritt 3: Icon fixieren

Auf das Terminal-Icon mit der rechte Maustaste klicken und den Menüeintrag „Lock to Launcher“ auswählen.  Das war es auch schon. Selbst nach dem Schließen des Terminalfensters bleibt das Icon in der linken Menüleiste erhalten.

Aufgabenstellung: 

Ein Benutzer soll einer Gruppe mit besonderen Ausführungsrechten zugeordnet werden.

Problem:

Bei den Ubuntu „Einstellungen“ findet sich nur ein Aufrufpunkt (User Accounts/Benutzerkonten) bei dem man nur minimale Angaben zum Benutzer machen kann.  Dies steht im Widerspruch zu vielen Anleitungen im Internet, bei denen man „Benutzer und Gruppenzugehörigkeit“ verwalten kann.

Screenshot:  Benutzer Aufrufmöglichkeit ohne Gruppenverwaltung

Gruppenverwaltung fehlt

Screenshot:  Minimale Einstellmöglichkeiten zum Benutzer

Lösung:

Die Benutzerverwaltung ist – im Vergleich zu früheren Versionen – stark abgespeckt worden. Es besteht standardmäßig nur die Möglichkeit, Benutzer anzulegen. Das Ändern der Gruppenzugehörigkeit über eine grafische Oberfläche ist nicht mehr möglich, dazu muss die Anwendung gnome-system-tools installiert werden.
Quelle: Wiki Ubuntu [1]

Paket-Nachinstallation

Diese abgespeckte Version läßt sich einigermaßen leicht nachrüsten. Dazu muss über ein Terminalfenster [2] das Paket gnome-system-tools nachinstalliert werden.

sudo apt-get install gnome-system-tools

Das grafische Werkzeug findet sich danach im Startmenü unter „Users and Groups“/„Benutzer und Gruppen“.

Zu beachten:  Gegebenenfalls muss man sich einmal neu anmelden, um die Benutzerdaten des Systems erstmalig einzulesen. 

Quellen und Links:

Ausgangssituation

Windows 10 Professional läuft auf einem Desktop Rechner als Host und das Betriebssystem Ubuntu 14.04.03 als Gastbetriebssystem in VirtualBox (von Oracle) .

Problem

Obwohl der Windows Ordner  D:\VM-Austausch in Virtualbox als Austauschverzeichnis eingetragen wurde, ist dieser zwar im Dateisystem von Ubuntu sichtbar, aber nicht aufrufbar. Es erscheint eine Meldung, dass der Benutzer keine ausreichenden Benutzerrechte hätte.

Lösung

Man muss den Benutzer in Ubuntu einer Gruppe zuweisen, die Zugriffsrechte auf den Austauschordner hat.

Im folgenden Video zeige ich, wie man den betreffenden Benutzer über die Gruppenverwaltung der richtigen Gruppe zuweist.

Quellen und Links:

Für den Betrieb eines eigenen Mailservers, müssen drei Grundvoraussetzungen erfüllt sein.

1. Hostname
   Dem Server sollte ein vollständiger Hostname (FQSN – Fully Qualified Server Name) zugeordnet sein.
   Im folgenden Screenshot beispielsweise:
   mail.einDomainname.de
2. Reverse-DNS Eintrag
   Es ist ein Reverse DNS Eintrag anzulegen.
   Hintergrund: Früher war es möglich, einen Mailserver ohne Reverse DNS Eintrag zu betreiben. Ab 2015 sind aber die großen E-Mail Dienste wie (t-online, web.de, gmx.de, …) aus Spam-Vermeidungsgründen dazu übergegangen, nur noch E-Mails von Mailservern zu akzeptieren, die einen Reverse DNS Eintrag besitzen.
   Einfach auch einmal nach „Reverse DNS Lookup“ googeln und sich anschauen, wie augenblicklich der Reverse-DNS-Eintrag des eigenen Servers (IP eingeben) aussieht.
3. Server Zertifikat
   Viele E-Mail Clients möchten nur mit Mailservern kommunizieren, die ein gültiges SSL-Server Zertifikat besitzen.
   (s.a. Blogartikel: …)

Anmerkungen und Best Practices

• Der vollständige Hostname ist frei wählbar. Die Verwendung eines Domainnamens, den man selbst auch besitzt, ist guter Stil.
  (Bsp.: mail.einDomainname.de)
• Ein Reverse-DNS-Eintrag sollte mit dem Hostnamen, den der Mailserver beim Verbindungsaufbau an der jeweiligen IP-Adresse nennt, übereinstimmen.
• Auf einem Mailserver mit einer IP werden oft mehrere Domains gehostet. Das ist kein Problem.
  In der Praxis bedeutet dies, dass wenn z.B. die Domains
  • abc.de
  • def.de
  • ghi.de
  • jkl.de

alle auf dem gleichen Mailserver liegen, alle auf mail.einDomainname.de als POP3 Adresse zugreifen. Das Auflösen und Zuordnen zur richtigen E-Mail Adresse macht der E-Mail Server alleine.

Ziel

Erzeugen eines SSL-Server Zertifikats.

Ausgangssystem

• Server mit Ubuntu 14.0.3 LTS
• Administration: Plesk 12.5

Hintergrund

Insbesondere Mailserver werden mit einem SSL-Zertifikat ausgestattet, welches eine Gültigkeitsdauer von einem bis zwei Jahre hat. Wenn dieses abläuft, wird man gefragt, ob man denn wirklich eine Internetverbindung mit einer Website möchte, die ein ungültiges Zertifikat hat.

Drückt man auf die Schaltfläche „Details“, dann erhält man weitere Informationen zu diesem ungültigen Zertifikat. In unserem Fall ist es schlichtweg abgelaufen.

Wird auf dem Server Plesk 12.5 als Server-Verwaltungssoftware eingesetzt, dann findet sich ein Menüpunkt „SSL-Zertifikat“ unter „Serververwaltung/Tools & Einstellungen/Sicherheit“.

Daraufhin öffnet sich eine Maske zur Verwaltung der Server SSL-Zertifikate.

Im nebenstehenden Screenshot (anklickbar zum Vergrößern) sieht man, dass auf dem Beispielserver ein Zertifikat vorliegt, welches als Standard-Zertifikat eingerichtet wurde und allen Domains vom Typ „Webhosting“ (hier 5) automatisch zugewiesen wurde.

Dieses Zertifikat ist in unserem Fall abgelaufen, kann aber als zugewiesenes Standardzertifikat augenblicklich nicht gelöscht werden. 

Server-Zertifikat

Das Erzeugen und Zuordnen eines Server-Zertifikats läßt sich in zwei Arbeitsschritten leicht vornehmen. (Minimale Kenntnisse, wie die Verwendung von PuTTY werden vorausgesetzt.)

Schritt 1: Server Zertifikat erzeugen

• Melden Sie sich mit einem Programm wie PuTTY auf ihren Server an.
• Wechseln Sie in ein Verzeichnis, auf welches sie mit FileZilla Zugriff haben.
• Führen sie in der Command-Shell den folgenden, kompakten Befehl ein, der ihnen die zwei benötigten Dateien (server.crt und server.key) in einem Rutsch erzeugt .
• Und laden Sie dann anschließend die beiden Dateien (server.key  und server.crt) auf ihren Desktop-Rechner herunter.

openssl req -new -days 999 -newkey rsa:4096bits -sha512 -x509 -nodes -out server.crt -keyout server.key

Schritt 2: Hochladen der Server Zertifikatdateien mit Plesk

Es ist so einfach, dass es fast schon peinlich ist, den Vorgang zu beschreiben.

• Auf der obigen SSL-Zertifikats Eingabemaske die Schaltfläche „Hinzufügen“ drücken.
• Dem neuen Zertifikat einen internen Namen für die SSL-Zertifikatsverwaltung geben. (Zur Orientierung: Das bisherige Zertifikat hieß „default certificate“.)
• Die beiden Dateien „server.key und server.cert“ hochladen.
• Das neue Zertifikat zum „Standard-Zertifikat“ machen.
• Löschen des evtl. vorhandenen, abgelaufenen SSL-Zertifikats

Das war es auch schon.  Damit ist der E-Mail Server, was das SSL-Zertifikat betrifft, zufrieden gestellt.

Zusammenfassend

• Ein E-Mail Server braucht keine domain-spezifischen SSL-Zertifikate, die man kaufen muss oder mit Let’s Encrypt erzeugen kann!
• Die Erzeugung und Zuordnung eines Server-Zertifikats ist mit minimalen Serverkenntnissen leicht vorzunehmen.

Links

[1] Perfect-Knowhow.de: Drei wichtige Punkte für den Betrieb eines Mailservers

[2] Manitu Wiki: Selbst-signiertes SSL-Zertifikat erstellen

[3] Wikipedia: FQDN – Fully Qualified Domain Name

In diesem Blogartikel werde ich erklären, warum ich es für keine gute Idee halte, bei Websites, die mit WordPress arbeiten, serverseitig „nginx“ als Performance Booster einzusetzen.

Doch zunächst einmal eine Kurzeinführung zu nginx.

Warum überhaupt nginx vor Apache vorschalten?

Übersetzung eines Textabschnitts aus dem „Administrator’s Guide, Plesk 12.0“ [1]:

Apache mit nginx

Durch die Installation von nginx auf einem Webserver, auf welchem Kunden Websites gehostet werden, kann man dessen Performance verbessern.

Nginx ist ein ergänzender high-performance web server, welcher typischerweise als Reverse Proxy Server eingesetzt wird. Dieser Webserver wurde speziell dafür konzipiert, große Mengen von statischen Inhalten (Bilder, Videos, CSS- und XML-Dateien u.s.w.) auszuliefern.

Im Vergleich zu Apache ist nginx viel leistungsfähiger, wenn es um die Verarbeitung gleichzeitiger Anfragen geht. Ein weiterer Vorteil von nginx gegenüber Apache ist der bedeutend geringere Hauptspeicherbedarf pro Client-Anfrage. 

Um die Vorteile, die nginx bietet, effektiv zu nutzen, konfiguriert Plesk den webserver nginx als Reverse Proxy Server, welcher zwischen der Client-Anfrage und dem Apache Server steht.

…

nginx Vorteile verpuffen bei WordPress

Der nginx Vorteil, dass statische Seiten schneller ausgeliefert werden, kommt meines Erachtens bei WordPress Anwendungen nicht zu tragen. Wir haben in der Regel keine statischen HTML Seiten. Selbst die Seiten, deren Inhalt sich nicht verändern, werden mit PHP und der Datenbank zusammengebaut.

Auch bei dem klassischen, statischen Seiteninhalt „Bild“ hat sich ein Wandel vollzogen. Zum einen erfordert ein Responsive Design eine dynamische, automatische Umrechnung auf andere Darstellungsgrößen und zum anderen gibt es die Möglichkeit, solche Inhalte (auch Word- oder PDF-Dateien) auf CDN’s (Content Delivery Network) auszulagern.

Mein Fazit: Verwendung von nginx bei WordPress Websites

Man sollte jedes System möglichst schlank halten. Jede zusätzliche Komponente bringt seine eigenen Probleme, Bugs und Konfigurationsanforderungen mit sich. Jede zusätzliche Komponente erhöht das Risiko (Lauffähigkeit des Gesamtsystems [4]). Jede zusätzliche Komponente, erfordert weiteren Maintenance Aufwand und Spezial-KnowHow.

Wenn die Komponente wie im Fall von Plesk 12.5, dann noch von Plesk falsch installiert und konfiguriert wird und Probleme bei einer Standardinstallation bereitet, dann hat man von den theoretischen Vorteilen, die ein vorgeschalteter nginx Proxyserver bieten könnte, gar nichts mehr. Man muss und sollte nicht auf jeden Zug aufspringen, wie schön auch die Werbeversprechen sein sollten.

Links und Websites zu diesem Thema

Fehlerbeschreibung

Auf einem Server wird Ubuntu 14.04.03 LTS eingerichtet, danach die Server Administrationsoberfläche Plesk.
Danach eingerichtete Domains sind mit einem Browser auch sofort aufrufbar.
Aber: Sobald der Server einmal herunter- und hochgefahren wird, lassen sich die Websites nicht mehr aufrufen.

Systemumgebung

Bei der Software handelt es sich um die offizielle Ubuntu-Linux-64bit Version und das offizielle Plesk-Installer Skript, welches die Dateien vom Plesk-Server herunterlädt.

Server

Ursprünglich erschien der Fehler mit dem Browser-Seitentitel „Problem loading page“ in einem virtuellen Ubuntu 14.04 Gastsystem (VirtualBox). 

Da ich zunächst davon ausging, dass möglicherweise die Anwendung Plesk sich nicht in einer virtuellen Maschine installieren lässt, habe ich die Installation nochmals auf einem vServer im Netz und einen lokalen, dedizierten Rechner vorgenommen. In allen drei Fällen, zeigte sich der Fehler, dass nach einem Reset des frisch aufgesetzten Servers, die eingerichteten Domains nicht mehr zugreifbar waren.

Unable to connect

Firefox can’t establish a connection to the server at example.com.

    The site could be temporarily unavailable or too busy. Try again in a few moments. If you are unable to load any pages, check your computer’s network connection.  If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web.

Fehlerbehebungsversuche, die zu nichts führten

Um den „Unable to connect“ Fehler zu beheben, habe ich natürlich im Internet gegoogled und bin dabei auf so manche Seite gestoßen. Leider war deren Fehlerursache nicht die meine.

Hier eine Auflistung von Ansatzpunkten, die zwar nicht bei mir geholfen haben, vielleicht jedoch bei anderen zielführend sein können:

• IP4: Was ich versucht hatte, war, für lokale Installationen die FritzBox 7490bzw. bei der Netzinstallation den Server auf IP4 zu beschränken. –> keine Verbesserung
• Netzwerkverbindung: Die lokale Adresse war  192.168.xxx.aaa.  Die Netzwerkadresse per Ping geprüft, ebenso wie die Einträge in der hosts-Datei.
  –> Netzwerkadresse stimmte und die DNS-Auflösung war auch richtig.
• Firewall: Es ist ein Ubuntu System. Ich weiss nicht, wie dort die Firewall-Einstellungen nach der Grundinstallation sind, aber die Tatsache, dass zunächst alle Internetaufrufe klappen und manchmal nach Aufruf der virtuellen Maschine der Aufruf von google.de zwar möglich ist, aber die Domains nicht mehr, spricht m.E. nicht für eine Konfigurationseinstellung der Firewall. (Anmerk.: Dass die Nichtzugreifbarkeit auf die Websites erst nach dem ersten Server-Reset sich einstellt, habe ich erst im Laufe der Fehlersuche herausgefunden.)

  Abfrage nach aktiver Firewall (Softwarepaket ufw) in Ubuntu 14.04  

• Temporarily unavailable:  Dass die Internetseite temporär nicht verfügbar sein soll, halte ich für abwegig. So ein Zufall gibt es nicht bei verschiedenen Webserver (VirtualBox, Netzserver, lokaler dedizierter Rechner).
• Network Proxy deaktivieren
  
• Firefox DSN Prefetching
  Ich habe in about:config das „Firefox DSN Prefetching“ auf true gestellt
  –> keine Änderung, weiterhin Fehlermeldung
• IPv6 im Firefox Browser deaktiviert
  Ich habe in about:config das „IPv6“ deaktiviert
  –> keine Änderung, weiterhin Fehlermeldung
• Browserabhängigkeit abklären
  Ich bin der Vermutung nachgegangen, dass es vielleicht am Firefox-Browser liegt und habe zusätzlich auf Ubuntu 14.04 noch den Google Chrome Browser installiert. –> Unverändert erscheint die „Problem loading page“ Seite. Kein Aufruf der Domains möglich
• Clear Cookies in Recent History
  –> keine Änderung, weiterhin Fehlermeldung
• Server Certificate Error
  –> wäre zu schön gewesen, aber die Einspielung eines Server Zertifikats half auch nichts
  

Zwischenproblem:  Eine Website wurde als HTTPS-Seite aufgerufen, obwohl die Seite bei den Hostingeinstellungen ohne SSL definiert wurde. Es scheint so zu sein, dass Websites einem Plesk Service Plan zugewiesen werden und wenn in diesem Serviceplan SSL steht, dann überschreibt dies die individuelle Einstellung. Also Serviceplan geändert und syncronisiert.

Fehlerursache: 

Nach ein paar Tagen Fehlersuche bin ich letztendlich darauf gestoßen, dass in den neuaufgesetzten Servern, neben Apache auch nginx als Proxy-Webserver läuft oder zumindest hätte aktiv laufen müssen.

Zu irgendeinem Zeitpunkt scheint Odin als Hersteller von Plesk entschieden zu haben, im Intallationsskript dem Apache Webserver einen nginx Webserver als Proxyserver vorzuschalten. Dass es dabei zu Problemen kommt, scheint schon mehr als ein Jahr bekannt zu sein [3]. Dass der Bug zwar bekannt, aber nicht mit hochdruck gefixt wird und man weiterhin ein fehlerhaftes Installationsskript auf die Endnutzer loslässt, ist für mich … .  Da kann ich nur den Kopf schütteln.

Der Fehler „Unable to connect“ ist beliebig nachstellbar/reproduzierbar. Unmittelbar nach der Grundinstallation von Plesk 12.5 läuft alles und die Websites der Domains sind aufrufbar, nach dem ersten Serverreset wird einem die nichtssagende „Unable to connect“ Fehlermeldung präsentiert.

Bei einem Neustart des Servers werden von Plesk die Konfigurationsdateien ausgelesen. Dort ist der Server so konfiguriert, dass Apache mit nginx als Proxyserver (Annahme der eingehenden Anfragen) läuft. Nur leider, wird bei einem Serverneustart aus irgendeinem Grund nginx nicht gestartet.

Dass dies wirklich die Fehlerursache ist, lässt sich unmittelbar auf dem Server prüfen. Einfach

# /etc/init.d/nginx start

eingeben und der Seitenaufruffehler ist verschwunden, bis zum nächsten Neustart behoben.

Dass dies (nginx als Serveradmin starten) zwar ein Workaround, aber letztendlich keine befriedigende Lösung ist, mag jedem einleuchten. Wer garantiert mir, dass der Server nicht zur Unzeit einmal Rebootet wird? Der Reboot zunächst dann unbemerkt bleibt und  danach keiner zur Stelle ist, der den Bug zuordnen kann und weiss, wie man ihn schnell fixed.

Welcher Kunde wird akzeptieren, dass sein Webauftritt für Stunden oder vielleicht Tage, gar nicht aufrufbar war? Das ist nicht akzeptabel.

Ich habe mir daher grundlegende Gedanken über nginx gerade auch beim Einsatz bei Websites, die auf WordPress als Contentsystem beruhen, gemacht und bin zu der Entscheidung gekommen, nginx zum augenblicklichen Zeitpunkt bei Plesk generell zu deaktivieren (s.a. meinen Blogbeitrag „Warum ich nginx nicht einsetze“ [5]).

Nginx Befehle

aktuelle nginx Einstellung aus der Plesk-Konfigurationsdatei auslesen

# /usr/local/psa/admin/bin/nginxmng -s
#     enabled

Nach dieser obigen Antwort sollte der nginx Server aktiviert sein. Dies kann aber dem realen Status des nginx-Webservers wiedersprechen

# /etc/init.d/nginx status
#     nginx is not running

Dabei wäre es so einfach.
Nginx starten

# /etc/init.d/nginx start

nginx in Plesk deaktivieren

Um den Server auf eine Konfiguration mit nur einem Apache Webserver (also ohne nginx als vorgeschalteten Proxy-Server) zurückzusetzen, sollte man allerdings nicht über das Terminalfenster gehen und dort „nginx stop“ eingeben, sondern man sollte den Service Reverse Proxy Server (nginx) unter Tools & Einstellungen > Service Verwaltung stoppen.

Wichtig zu wissen: Der Start- und Stop-Button der Admin Oberfläche startet und stoppt nicht nur den nginx Service, sondern verändert auch die Serverkonfigurationsdateien (ganz wichtig!).

(s.a. Plesk Administrators Guide [6]).

Links

[2] MozillaSupport: Firefox can’t load websites but other browsers can

[3] Plesk: Problem loading page

[4] Plesk: Wie Sie nginx auf dem Plesk Server aktivieren

[5] Perfect-Knowhow.de: Warum ich nginx nicht einsetze

[6] Plesk: Administrator’s Guide 12.5

Auf dem WordPress Camp 2016 in Frankfurt wurde von vielen Rednern empfohlen, WordPress auf einem Server mit PHP 7 laufen zu lassen, damit man von dem enormen Geschwindigkeitsschub dieser neuen Version profitieren könnte.

Das stimmt zwar im Prinzip schon, aber der Knackpunkt dabei ist, dass nach einer serverseitigen Umstellung von z.B. PHP 5.6 auf PHP 7.0 so manch eine Website nicht mehr lauffähig ist.

Dann ist nichts mit Halbierung der Ladezeit, sondern dann ist Weltuntergangsstimmung angesagt.

Ich habe auf dem WordPress Camp mit jemanden vom Core-Team von WordPress gesprochen. Dieser bedauert zwar, dass man augenblicklich noch immer als Mindestanforderung für WordPress bei der Version 5.2.4 ist und sich schwertut, diese Mindestanforderung anzuheben, aber die Codebasis des Core’s von WordPress ist soweit sauber, so dass WordPress auf einem Server mit PHP 7 läuft.

Das eigentliche Problem liegt bei manchen der 46.000 Plugins, mit denen man WordPress erweitern kann. Viele davon verwenden „deprecated functions“ oder mysql-Befehle, die in der PHP 7 Version nicht mehr unterstützt werden, mit der Folge, dass eine Website nicht mehr sauber läuft, bis zu dem Exterm, dass die Website nicht mehr aufrufbar ist.

Auch so manches kostenloses Theme und das eine oder andere kommerzielle Theme mag PHP-Code verwenden, der nicht PHP 7 kompatible ist!

Fazit

• Man prüfe erst die Lauffähigkeit der Website unter PHP 7 auf einem Zweitsystem bevor man den Produktionsserver auf PHP 7 umstellt. 
• Je mehr Plugins zur eigentlichen WordPress installation installiert sind, desto größer die Gefahr, dass die Website unter PHP 7 nicht mehr einwandfrei läuft.
• Auch Themes sind betroffen und können „deprecated“ functions oder „deprecated“ mysql_… Befehle enthalten und somit die Ursache für Laufzeitproblemen unter PHP 7 sein.

Ausgangssituation

Auf dem Server mit dem Betriebssystem Ubuntu 14.04.03 sind vier verschiedene PHP-Versionen  installiert 

• Plesk-PHP 5.5.38
• Plesk-PHP 5.6.25
• Plesk-PHP 7.0.10
• Server-PHP 5.5.9

Die PHP-Version 5.5.9, welches in diesem Beispiel auch die niedrigste PHP-Version ist, wurde bei der Installation des Servers angelegt, liegt im Verzeichnis /usr/lib  und wird von allen Programmen auf dem Server verwendet, die einen PHP-Interpreter verwenden. 

Die anderen PHP-Versionen hat das Server-Administrationstool Plesk mitgebracht und lassen sich über dieses installieren/deinstallieren und domainspezifisch zuordnen. Gerade wenn man mehrere Domains auf einem Server hostet und die Anwendungen dieser Domains unterschiedliche Versionsstände der PHP-Versionen erfordern, ist dies von grundlegender Bedeutung.

Anmerk.: Natürlich könnte man denken, je höher, desto besser, also das schnelle PHP 7.0 für alle Anwendungen, wird schon passen :-).  Aber dem ist nicht so.
Beispielsweise gibt es bei WordPress durchaus ein paar, eigentlich sehr gute Plugins, die aber unter PHP 7.0 nicht laufen, weil sie z.B. als deprecated markierte Funktionen verwenden, die in PHP 7.0 nicht mehr implementiert wurden. Dann muss man sich für diese Domain dann vielleicht mit PHP 5.6 begnügen.

Aufgabenstellung

Einige der auf dem Entwicklungsserver laufenden Programme wurden geupgraded und erzwingen geradezu, dass die vom Server als Standard bereitgestellte PHP Version angehoben wird. Die Anhebung soll auf PHP 5.6 erfolgen, wobei hierbei die von Plesk installierte Version mitbenutzt werden soll.

Ermittlung des Ist-Zustands

Version der derzeitigen Standardversion

Verzeichnispfad der derzeitigen PHP-Standardversion

Temporäres Setzen der Umgebungsvariable PATH

Wichtig: Bei dieser Variante liegt die Betonung auf temporär, also nur geeignet, für Testzwecke. Man kann untersuchen, wie Programme sich verhalten würden, wenn die PHP-Version umgestellt wäre.

Der geänderte Inhalt der Variable PATH ist nur solange gültig, wie die aktuelle Terminal-Session läuft.

Setzen des PHP 5.6 Pfades vor (dies ist wichtig) dem bisherigen Pfad

Kontrolle, dass die neue PHP-Version nun als Default PHP Version verwendet wird

Permanentes Setzen der Umgebungsvariable PATH

Es gibt ein paar Stellen (Dateien), die geeignet sind systemweite Umgebungsvariablen zu setzen (siehe Ubuntu Documentation [1]).

Mein Favorit ist die Datei

/etc/environment

Dort habe ich dann auch auf diesem Testsystem den PHP-Verzeichnispfad der Plesk-PHP 5.6 Version vor allen anderen Pfaddefinitionen eingestellt und den Server neu gebootet.

Links

Alle Installationsanweisungen, die ich im Internet gefunden habe, beziehen sich auf veraltete Ubuntu-, Netbeans- und PHPUnit-Versionen und sind nicht mehr 1:1 umzusetzen. 

Deshalb werde ich im folgenden Blogartikel eine vollständige Netbeans 8.1 Installation beschreiben (Stand 20. Sept. 2016).

Installation von Netbeans 8.1

NEU: Die IDE Netbeans 8.1 bring eine bundled JVM schon mit sich. Also keine Notwendigkeit zuvor Java zu installieren.

Unter netbeans.org [2] ist die aktuelle Version der IDE (hier PHP-Developer Edition) herunterzuladen.

netbeans-8.1-php-linux-x64.sh

Dann die folgenden Befehle in einem Terminalfenster mit Adminstratorrechten (sudo su) ausführen.

Für die heruntergeladene Datei die Ausführungsberechtigung setzen.

    chmod +x 

Installationsverzeichnis wählen

    z.B.   /usr/local/netbeans8

Netbeans kann nun aufrufen werden.

Anmerk.: Ich persönlich tue dies im Administratormodus (sudo su), da ich als workspace für meine Projekte auch Verzeichnisse außerhalb des Benutzerverzeichnisses $HOME/$USER benutzen möchte.

sudo su
/usr/local/netbeans8/bin/netbeans

Highlight: Wenn xDebug auf dem Server schon installiert ist. wird dieses von Netbeans selbst sofort automatisch erkannt und steht direkt nach der Installation zur Verfügung!

Neben dem Debuggen ist es für mich auch unabdingbar, dass der Programmcode getestet werden kann. Ohne dies ist eine Entwicklungs-IDE einfach nicht vollständig. Deshalb hier noch als Ergänzung und Abschluss, die Installation des Erweitungspackages PHPUnit.

Installation von phpunit 5.5.0

Als Programmierer gehört für mich die das Testen des Codes zu jedem Programmodul dazu. Deshalb noch die Beschreibung der Installation von PHPUnit.

Die Version 5.5. von PHPUnit hat als Systemvoraussetzung PHP 5.6!

➜ wget https://phar.phpunit.de/phpunit.phar
➜ chmod +x phpunit.phar
➜ sudo mv phpunit.phar /usr/local/bin/phpunit
➜ phpunit --version
PHPUnit 5.5.4 by Sebastian Bergmann and contributors.

Installation von PHPUnit Skeleton Generator

➜ wget https://phar.phpunit.de/phpunit-skelgen.phar
➜ chmod +x phpunit-skelgen.phar
➜ mv phpunit-skelgen.phar /usr/local/bin/phpunit-skelgen
➜ phpunit-skelgen --version
phpunit-skelgen 2.0.1 by Sebastian Bergmann.

Damit ist die Installation von Netbeans 8.1 incl. der Erweiterung PHPUnit abgeschlossen.

In einem Folgebeitrag werde ich das Anlegen eines PHP-Projekts unter Netbeans 8.1 beschreiben und zeigen, wie PHPUnit für ein neuangelegtes Projekt zu konfigurieren ist.

Spiel Spaß beim programmieren!

Blogmaster: Manfred Roos

Links