PHP-FPM Einstellungen optimieren

Heute geht es darum den unter PHP Nutzern bekannten FastCGI Process Manager (FPM) richtig zu konfigurieren und zu optimieren. (https://php-fpm.org/)

Die meisten PHP Anwendungen verwenden Heutzutage den PHP-FPM um Ihre PHP Anwendungen auszuliefern. In Kombination mit NGINX als Webserver ist dies mit einer der effektivsten Methoden eine Webanwendung mit PHP im Produktiveinsatz laufen zu lassen.

Der Teufel steckt im Detail

Bei FPM reichen schon ein paar falsch gesetzte Werte und schon startet der FPM Prozess nicht mehr oder der Speicher des Servers läuft voll oder oder oder ... die Liste ist lang ;)

Häufige Fehler die auftreten können:
  • FPM Master Prozess startet nicht mehr
  • RAM des Servers läuft voll
  • "server reached max_children"

Prüfen ob PHP-FPM Prozess läuft

Das Beispiel zeigt die PHP-FPM Prozesse und für welche pool Konfiguration / User diese ist, in dem Falle zu sehen "web1" da unter ISPConfig der erste angelegt Host "web1" ist.
ps aux | grep fpm

PHP-FPM Konfiguration anpassen

In diesem Beispiel hier zeige ich euch wie Ihr die Konfiguration anpasst anhand einer ISPConfig Standard Installation mit einer angelegten Webseite. Dazu bearbeiten wir die Datei:

nano /etc/php/7.0/fpm/pool.d/web1.conf

Der Inhalt der Datei sieht dann so aus (kann je nach Installation abweichen):

[web1]

listen = /var/lib/php7.0-fpm/web1.sock
listen.owner = web1
listen.group = www-data
listen.mode = 0660

user = web1
group = www-data

pm = dynamic
pm.max_children = 50
pm.start_servers = 12
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 1000

....
....

Ich werde jetzt die wichtigsten Einstellung im Detail erklären und euch gegebenenfalls Hinweise dazu geben. Aber fangen wir direkt an mit der wohl wichtigsten Einstellung "pm.max_children".

Wichtigste PHP-FPM Einstellungen einfach erklärt

  • pm (string)
    • es gibt 3 mögliche Einstellungen, dynamic ist meistens die beste Wahl
      • static - Anzahl der Kindprozesse ist fest (pm.max_children)
      • ondemand - Kindprozess wird erst erstellt wenn er benötigt wird (pm.start_servers)
      • dynamic - dynamische Einstellung der Kindprozesse (benötigt folgenden Einstellungen: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers)
  • pm.max_children (int)
    • Anzahl der Kindprozesse die erstellt werden wenn pm = static oder die maximale Anzahl der Kindprozesse wenn pm = dynamic. Einstellung ist notwendig!
  • pm.start_servers (int)
    • Anzahl an Kindprozessen, die beim Start erstellt werden. Wird nur verwendet, wenn pm auf dynamic gesetzt ist. Standardwert: min_spare_servers + (max_spare_servers - min_spare_servers) / 2.
  • pm.min_spare_servers (int)
    • gewünschte Mindestanzahl an Prozessen. Wird nur genutzt, wenn pm auf dynamic gesetzt ist. Zwingend notwendig!
  • pm.max_spare_servers (int)
    • gewünschte Maximalanzahl an Prozessen. Wird nur genutzt, wenn pm auf dynamic gesetzt ist. Zwingend notwendig!
  • pm.max_requests (int)
    • Anzahl der Requests bis der FPM Prozess neustartet, hilft Memory Leaks in einigen PHP Libs zu fixen
Noch viele weitere und detailliertere Beschreibungen könnt Ihr in der Dokumentation von PHP finden.

Optimalen Wert für "pm.max_children" bestimmen

Um den perfekten Wert für pm.max_children zu finden muss man zuerst herausfinden wieviel Speicher ein FPM Prozess mit der aktuellen Anwendung verbraucht. Dazu können wir auf 2 verschiedenen Befehle zurück greifen.

ps -ylC php-fpm7.0 --sort:rss

Das sollte dann in etwa so bei euch aussehen:
Für uns von Bedeutung ist die Spalte "RSS" diese gibt den Speicherverbrauch des Prozesses in Kilobyte an. Also wären 43868 rund ~ 43MB für diesen Prozess. Um das ganze etwas zu vereinfachen können wir aber einfach den Befehl ausführen und erhalten den Durchschnitt.

ps --no-headers -o "rss,cmd" -C php-fpm7.0 | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"Mb") }'

// Output
34Mb

Mit diesem Verbrauchswert können wir nun den passenden Wert für pm.max_children berechnen. Dazu nehme ich einfach mal ein Beispiel (einen VPS der 2GB RAM hat).
  • VPS mit 2 GB RAM
    • wir ziehen 256 MB ab da noch andere Dienste auf dem VPS laufen
    • uns bleiben 1792 MB Ram
      • Formel: max_children = Free RAM VPS / RAM pro Prozess
      • max_children = 1792 / 34
      • = 52,7 = ~ 52
Der Ideale Wert für diesen VPS wäre also pm.max_children = 52. Natürlich sollte man diesen Wert nicht einfach Blind übernehmen! Ändert eure Einstellungen und dann testet wie sich euer Server verhält. Wenn Ihr eure Konfiguration angepasst habt, startet Ihr am besten euer FPM neu. Dies könnt Ihr mit folgendem Befehl machen:

sudo /etc/init.d/php7.0-fpm restart

Resümee

Ein optimal Konfigurierter PHP-FPM Service erspart euch auf eurem Produktivsystem eine Menge ärger. Denn niemand möchte einen überlaufenden Speicher oder eine langsame PHP Anwendung nur weil der FPM Dienst falsch konfiguriert ist. Nehmt euch die Zeit ermittelt die optimalen Werte und setzt diese dann um. Oft hilft es auch die Logs regelmäßig zu checken um sehen ob alles ohne Probleme funktioniert und ob nicht doch der Server bald an seine Grenzen kommt. 

Ich hoffe ich konnte dem ein oder anderem das Mysterium PHP-FPM näher bringen und wünsche euch viel Erfolg beim optimieren eurer Einstellungen.

Monero/AEON Mining mit XMR-STAK 2.0

Tutorial Monero Mining Ubuntu (XMR-STAK 2.0)

Neue Version XMR-STAK 2.0.0 ausprobiert!

Der Entwickler "fireice-uk" hat eine neue Version von seiner beliebten Mining Software XMR-STAK veröffentlicht. Grund für uns sich diese einmal etwas genauer anzuschauen.

Laut Changelog haben wir in dieser Version einige interessante Änderungen. Denn die Software vereint jetzt alle drei Versionen zu einer Software. Wir benötigen also nicht mehr extra den XMR-STAK-CPU, XMR-STAK-AMD oder XMR-STAK-NVIDA Miner sondern können bequem alles aus einer Hand installieren und konfigurieren. Außerdem unterstützt die Software jetzt die Kryptowährung AEON, welche wie Monero auf einen ähnlichen Hash Algorithmus zurück greift (CryptoNote Lite). Dieser ist für Smartphones optimiert. Wie ich finde auch eine interessante Kryptowährung. Wer mehr darüber wissen möchte kann gern mal auf der offiziellen Seite vorbeischauen.

Hier jetzt noch einmal der komplette Changelog der Vollständigkeit halber.

Features
  • 10% boost to CPUs without hardware AES
  • Supports all common backends (CPU/x86, AMD-GPU and NVIDIA-GPU)
  • Supports all common OS (Linux, Windows and MacOS)
  • Supports algorithm cryptonight for Monero (XMR) and cryptonight-light (AEON)
  • Guided start (no need to edit a config file for the first start)
  • Automatic configuration for each mining backend
  • Allows to tweak each core or gpu by hand
  • Supports backup pools
  • TLS support
  • HTML statistics
  • JSON API for monitoring
  • Support the new stratum statistics extension
  • Easy precompiled and portable Linux binary

Installation XMR-STAK 2.0 unter Ubuntu

Das neue XMR-STAK bietet jetzt auch eine bereits kompilierte Version welche man portable typisch nur noch herunterladen muss und ausführen kann. Dies spart das selbst kompilieren.

// wir legen uns einen Ordner an
mkdir xmr-stak-portable
// download
wget https://github.com/fireice-uk/xmr-stak/archive/v2.0.0.tar.gz
// entpacken das Archiv
tar xzf xmr-stak-portbin-linux.tar.gz
// starten
./xmr-stak.sh

XMR-STAK 2.0 Setup Assistent

Nach dem wir alles heruntergeladen haben und das Programm starten, müssen wir einige Fragen beantworten welche das Setup darstellen. Wie so etwas aussehen kann seht Ihr im folgenden Beispiel.

// starten
./xmr-stak.sh 
Please enter:
- Currency: 'monero' or 'aeon'
monero
- Pool address: e.g. pool.usxmrpool.com:3333
pool.supportxmr.com:3333
- Username (wallet address or pool login):
423gorEqp1GR1Rn431fwuQVmrSAw7v86z3CygoeLsbr6EvenAMeKus1CiZgXana9b1RjnAPbaxyBL4CP5QpdL8PK88KkdRi
- Password (mostly empty or x):
Worker-CPU-01
- Does this pool port support TLS/SSL? Use no if unknown. (y/N)
N
- Do you want to use nicehash on this pool? (y/n)
n
- Do you want to use multiple pools? (y/n)
n
Configuration stored in file 'config.txt'

Unsere Einstellungen kann man nachträglich jederzeit ändern. Das Programm erzeugt 2 Dateien welche im aktuellen Verzeichnis erstellt werden.


  • config.txt - Allgemeine Einstellungen
  • cpu.txt - Einstellungen fürs CPU Mining
Ich vermute mit einer entsprechenden Grafikkarte würde dann dort noch eine Konfiguration für die Grafikkarte zu finden sein. Nach der Konfiguration ist der Miner fertig und einsatzbereit.

Automatisches deployen / installieren auf Server / VPS

Die neue Version ermöglicht es uns außerdem die Installation auf einem Server / VPS in wenigen Sekunden vorzunehmen. Dafür benötigen wir nur eine einmalig auf unsere Zecke eingestellte config.txt die über eine Webadresse verfügbar ist (z.B. http://meine-domain.de/config.txt).

Auf unserem Server legen wir dann ein kleines Bash Script mit folgendem Inhalt an.

#!/bin/bash
curl -O `curl -s https://api.github.com/repos/fireice-uk/xmr-stak/releases/latest | grep -o 'browser_download_url.*xmr-stak-portbin-linux.tar.gz' | sed 's/.*"//'`
curl -O http://meine-domain.de/config.txt
tar xzf xmr-stak-portbin-linux.tar.gz
./xmr-stak.sh

Dieses Script führen wir dann aus und in wenigen Sekunden haben wir ein lauffähiges Mining Setup auf unserem Server. Einfacher geht es nicht oder?

Wer noch wissen möchte wie das ganze im Hintergrund ausführen kann ohne beim schließen des Terminals das Mining zu beenden sollte sich meinen anderen Artikel noch einmal ansehen.

Was sagt Ihr zu der neuen Version? Findet Ihr die Verbesserungen gut und sinnvoll? Schreibt mir gern eure Meinung dazu in die Kommentare. Falls Ihr Fehler gefunden habt meldet diese bitte auch in den Kommentaren.

Viel Spass beim Minig

Kostenlos mit dem Usenet verbinden - So gehts!

Usenet? Ja Usenet!

Ihr wolltet schon immer wissen was das Usenet ist und wie man sich damit verbinden kann? Dann seid Ihr hier genau richtig. Denn heute wollen wir eine einfache Möglichkeit zeigen wie Ihr euch damit verbinden könnt.

Was ist denn das Usenet?

Wir fangen zunächst mit den Grundlagen an. Der uns allgemein bekannte Begriff "Usenet" steht für "Unix User Network" und auf deutsch "Unix Benutzer Netzwerk". Man kann sich das Usenet wie ein zweites globales Internet vorstellen. Es ist sozusagen ein zweites Netzwerk welches es schon lange vor dem WWW gab. Das Usenet kann man dann noch mal unterteilen einmal in das normale Usenet und dann in das "Binary Usenet". Das normale Usenet ist gedacht um sich mit Nachrichten auszutauschen in sogenannten Newsgroups, in der anderen Version kann man zusätzlich noch Binar Dateien anhängen, dass heißt man kann Dateien austauschen. Die Möglichkeit Dateien auszutauschen macht das Usenet erst richtig interessant.

Den passenden Newsserver finden

Um sich mit dem Usenet zu verbinden benötigt man vorher einen entsprechenden Newsserver und hierbei unterscheiden wir 3 Arten.
  • Offene Newsserver (offen für Alle, meist nur Lesezugriff)
  • Freie Newsserver (offen aber meist nur mit Registrierung nutzbar)
  • Bezahlte Newsserver (Zugang muss bezahlt werden)
Eine sehr ausführliche Liste zu offenen und freien Newsservern habe ich auf der Seite "TopUsenet" gefunden. Dort habt Ihr eine ausführliche und detaillierte Liste mit entsprechenden Newsservern. Ein paar Beispiele für Newsserver wären:
  • Universität Hohenheim - news.uni-hohenheim.de
  • Mozilla - news.mozilla.org

Kostenlose Usenet Newsreader Software

Da wir jetzt einen entsprechenden Newsserver gefunden haben der uns interessiert, wollen wir uns natürlich auch damit verbinden. Für die Verbindung zu einem Usenet Newsserver benötigen wir einen sogenannten Newsreader. Dies ist Software bzw Client mit dem wir uns verbinden und die auf dem Server gespeicherten Informationen abrufen können.
  • Sabnzbd - Kostenlos, viele Funktionen, stätig weiterentwickelt
  • Newsbin - Testversion verfügbar, sehr guter Newsreader
  • Agent - Testversion verfügbar, Browser + Suche
  • Grabit - Kostenlos, Browser + Suche, klasse Newsreader

Verbinden mit Sabnzbd Usenet Reader

Jetzt geht es ans eingemachte :) Wir werden uns jetzt mit dem Usenet verbinden mit der freien Software "Sabnzbd". Nachdem wir das Programm heruntergeladen und installiert haben. Starten wir das Setup. Es öffnet sich ein Browserfenster mit folgendem Inhalt.
Nach der Sprachauswahl müssen wir die Server Zugangsdaten eingeben. In diesem Beispiel haben wir den freien Mozilla Server eingetragen. Hier könnt Ihr natürlich eure entsprechenden Daten eingeben.
Ob alles richtig ist könnt Ihr mit einen Klick auf "Server überprüfen" testen. Bei Erfolg grün bei Misserfolg rot. Danach ist das Setup schon abgeschlossen.
Glückwunsch Ihr habt euch erfolgreich mit einem Usenet Server verbunden

Warum ist das Usenet so beliebt?

Klar kostenlos Filme, Serien, Spiele und Pornos!

Das hat ein paar einfache Gründe. Da im Binary Usenet Dateien ausgetauscht werden können wird dies für viele nicht ganz so legale Arten von Downloads ausgenutzt. Viele kostenpflichtige Usenet Anbieter werben auch damit, dass man bei Ihnen alles mögliche ohne Limit herunterladen kann. Darunter fallen Filme, Serien, Spiele und sogar Pornos. Bei solchen Angeboten sind aber auch viele schwarze Schafe, die einem zum Beispiel getarnt als Serie ein Virus unterjubeln wollen. Also solltet Ihr falls Ihr so ein Angebot nutzt lieber zwei mal hinsehen und die geladenen Dateien vorher mit einer Anti-Virensoftware prüfen. Durch die schiere Anzahl der diversen Newsgroups kann man so gut wie alles finden im Usenet. Es ist quasi ein Paradies für Downloader.

Es gibt sehr viele kostenpflichtige Usenet Anbieter, ich werde hier nur ein kleine Liste der verschiedenen Anbieter aufzählen:

Abschluss

Abschließend kann man sagen, dass Usenet ist ein sehr interessanter Ort. Wenn man einmal verstanden hat wie das Usenet funktioniert dann ist es sehr einfach zu nutzen und eröffnet spannende Möglichkeiten. Wer wirklich die volle Bandbreite des Usenet kennen lernen will sollte mal bei einem Anbieter wie Usenet.nl vorbeischauen.

In diesem Sinne, viel Spaß beim ausprobieren.

Quellen: 

Webserver NGINX Performance Tuning

Schnell? Schneller? NGINX? Performance!!!


Heute beschäftigen wir uns mit dem Thema NGINX und Performance Optimierung. Wir wissen alle das der NGINX der König unter den Webservern ist und deshalb schauen wir uns heute an, wie wir das letzte Fünkchen Geschwindigkeit aus dem Webserver herausholen. Zu dem Zeitpunkt wo ich diesen Beitrag schreibe gibt es den NGINX in der Stable Version 1.12.1 (Download).

Backup der NGINX Config

Als erstes ist es wichtig eure aktuelle funktionierende NGINX Konfiguration zu sichern (Kopie davon erstellen) damit wir nichts zu fürchten haben falls etwas nicht ganz so läuft wie von euch erhofft. Die Konfiguration findet Ihr z.B. bei Ubuntu unter /etc/nginx/nginx.conf

Performance? Optimieren!

Jetzt werde ich euch einzelne NGINX Core Module Direktiven vorstellen die euch helfen werden eure Webserver Performance zu steigern. Ich versuche dabei kurz und verständlich die Werte zu erklären. Alle folgenden Werte können in der nginx.conf bearbeitet oder hinzugefügt werden.

worker_processes auto;
Gibt an wie viele NGINX Worker Prozesse laufen. auto = automatische Erkennung. Generell gilt, man kann auch die Anzahl der verfügbaren CPU Cores angeben. (z.B. VPS mit 2 Kernen = auf 2 stellen).

worker_connections 1024;
Gibt an wie viele gleichzeitige Verbindungen pro Worker aufgebaut werden können. Die maximale Anzahl der Clients wird also wie folgt Berechnet. max Clients = worker_processes * worker_connections. Tip: hier ein wenig testen wie viel euer Server schafft.

use epoll;
Wichtig für Linux Server um viele Clients in einem Thread zu verarbeiten.

multi_accept on;
Dadurch werden so viele neue Verbindungen wie möglich akzeptiert von einem Worker Prozess.

sendfile on;
Kopiert Daten von einem FD (File Descriptor) zu einem innerhalb des Linux Kernels. Das ist schneller als read() + write()

tcp_nopush on;
Sendet den Request Header in einem Stück, dies ist besser als viele kleine.

tcp_nodelay on;
Aktiviert die TCP Option TCP_NODELAY. Daten werden nicht mehr im BUffer zwischen gespeichert, sondern gleich verschickt.

access_log off;
Um schwache Festplatten zu entlasten und den HDD I/O zu verbessern.

gzip on;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/json application/xml;
gzip_disable msie6;
Komprimiert die ausgegebenen Dateien, dies spart Traffic. Sollte nur bei ausreichend CPU Leistung aktiviert werden!

reset_timedout_connection on;
Erlaubt es dem Server die Verbindung zu nicht antwortenden Clients zu schließen. Das spart Arbeitsspeicher.

client_body_timeout 10;
Der Request Timeout. Standard ist bei 60. Falls keine Dateien auf eurer Seite hochgeladen werden sollte der Timeout reduziert werden z.B. auf 10 Sekunden

send_timeout 2;
Wenn der Client nicht mehr reagiert und nichts empfängt dann stoppe (Standard ist 60). Spart Arbeitsspeicher.

keepalive_timeout 30;
Schließt die Verbindung nach der angegebenen Zeit. Standard ist 75. Hier kann etwas experimentiert werden.

keepalive_requests 100;
Wie viele Keep Alive Requests gemacht werden können. Standard ist 100. Beachtet wie viele gleichzeitigen Besucher Ihr auf eurer Seite erwartet.

server_tokens off;
Erhöht die Sicherheit. Der Server schickt keine Version etc mehr heraus.

open_file_cache max=100000 inactive=20s; 
open_file_cache_valid 30s; 
open_file_cache_min_uses 2;
open_file_cache_errors on;
Der Cache kann die Performance steigern, die optimalen Werte solltet Ihr durch testen herausbekommen. Eine detaillierte Erklärung dazu findet Ihr hier

Beispiel Konfiguration für einen 2 Kern VPS (/etc/nginx/nginx.conf)


user www-data;
worker_processes 2;
pid /run/nginx.pid;

events {
        worker_connections 1024;
        use epoll;
        multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 30; # default 75
        keepalive_requests 100;   # default 100
        reset_timedout_connection on;
        client_body_timeout 10; # default 60
        send_timeout 10; # default 60
        types_hash_max_size 2048;
        server_tokens off;
        
        # File Cache
        open_file_cache max=100000 inactive=20s; 
        open_file_cache_valid 30s; 
        open_file_cache_min_uses 2;
        open_file_cache_errors on;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

        access_log off;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        #gzip on;
        #gzip_disable "msie6";

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

Wichtig für Dateiuploads in Verbindung mit NGINX

Falls Ihr auf eurer Seite einen Upload von Dateien anbietet solltet Ihr in eurer vhost Config noch folgende NGINX Einstellungen setzen.

        client_max_body_size 1G;
        client_body_buffer_size 1024k;

In diesem Beispiel ist er möglich Dateien von einer größe von 1 GB auf den Server zu laden.

Konfiguration neu einlesen oder NGINX neustarten

Um die ganzen neuen Einstellungen zu testen könnt Ihr die Config neu einlesen lassen:

# /etc/init.d/nginx reload

Oder Ihr startet den Webserver einfach neu.

# /etc/init.d/nginx restart

Falls etwas falsch sein sollte würde an dieser Stelle eine entsprechende Meldung erscheinen. Abschließend hoffe ich das euch das ein oder andere Helfen konnte und Ihr eure Server Performance steigern konntet. Über Verbesserungsvorschläge und Tips würde ich mich sehr freuen. Schreibt es in die Kommentare ;)

Buchempfehlung über NGINX

Vor 2 Jahren habe ich mir das Buch "Nginx HTTP Server" bei Amazon bestellt. Damit habe ich begonnen mich in die Materie einzuarbeiten. Dort sind alle grundlegenden Elemente des Webservers sehr gut und ausführlich erklärt. Für komplette Neueinsteiger zu empfehlen.

Fortgeschrittene sollten sich das demnächst erhältliche Taschenbuch "Nginx: A Practical Guide to High Performance"  von Stephen Corona (Autor) mal genauer ansehen. Es wirkt auf den ersten Eindruck sehr interessant und vielleicht bekommt man von Ihm wertvolle Tips für eine optimale Konfiguration. Lasst es mich wissen falls jemand das Buch empfehlen kann.

Quellen:

Ubuntu 16.04 einrichten von SSL / HTTPS unter NGINX

Einleitung

Im Jahre 2017 sollte SSL Standard für jede Webseite sein. Warum das leider immer noch nicht so ist liegt vielleicht daran, dass viele Leute abgeschreckt sind von der Einrichtung oder nicht wissen wie es umgesetzt wird. In diesem kleinen Tutorial, möchte ich euch Heute zeigen, wie einfach es doch ist SSL unter Ubuntu mit einem NGINX Webserver einzurichten.

Voraussetzungen

Eine kleine Liste mit Dingen die ich für dieses Tutorial voraussetze.
  • Ubuntu Server
  • NGINX Server installiert
  • OpenSSL installiert
Außerdem solltet Ihr auf eurem Server die entsprechenden "root" oder "sudo" Rechte haben. Wenn ihr das alles habt können wir auch schon beginnen.

Schritt 1 - Zertifikat erzeugen

Als erstes brauchen wir einen Ort wo wir das Zertifikat ablegen und speichern wollen. Da es sich hier um ein Zertifikat für den NGINX handelt erzeugen wir einfach im NGINX Ordner einen weiteren Ordner "ssl".

  sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt

Kurze Erklärung zu dem Befehl:
  • openssl: Standard Konsolen Programm um Zertifikate zu erstellen
  • req: sagt aus das wir eine X.509 Signierungsanfrage erstellen wollen. X.509 ist ein Standard für SSL und TSL
  • -x509: Die Option sagt aus das wir ein selbst signiertes Zertifikat erstellen wollen
  • -nodes: Teilt OpenSSL mit das wir keine Passwortabfrage bei dem Zertifikat benötigen. Wäre auch schlecht da NGINX dann bei Neustarts immer danach fragen würde
  • -days 365: Anzahl der Tage wie lange das Zert. gültig ist
  • -newkey rsa:2048: Sagt das wir einen neuen Schlüssel und Zertifikat mit einem 2048 Bit Schlüssel möchten
  • -keyout: Gibt OpenSSL einen Ort an wo der Schlüssel gespeichert werden soll
  • -out: Gibt OpenSSL einen Ort an wo das Zertifikat gespeichert werden soll
Anschließend wirst du nach einigen Angaben gefragt. Diese kannst du leer lassen oder ausfüllen.
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Die von dir erstelleten Dateien werden in dem angegebenen Ordner abgespeichert.

Schritt 2 - NGINX Konfigurieren

Ein Vorteil von NGINX gegenüber dem Apache ist das man HTTPS/SSL in der selben Vhost Config aktivieren kann wo auch HTTP konfiguriert ist. Wir bearbeiten dazu unsere Standard Konfiguration unter.

nano /etc/nginx/sites-available/default

Wir fügen 4 Zeilen hinzu.

server {
        # ipv4 http
        listen 80 default_server;
        # ipv6 http
        listen [::]:80 default_server;
        # ADDED ipv4 https
        listen 443 ssl default_server;
        # ADDED ipv6 https
        listen [::]:443 ssl default_server;

        server_name default;

        root   /var/www/application/public;

        index index.html index.htm index.php index.cgi index.pl index.xhtml;

        # ADDED ssl settings
        ssl_certificate         /etc/nginx/ssl/nginx.crt;
        ssl_certificate_key     /etc/nginx/ssl/nginx.key;

        # log
        error_log /var/www/application/log/error.log;
        access_log /var/www/application/log/access.log combined;

        # rewrite
        location / {
            try_files $uri $uri/ /index.php;
        }

        # php socket
        location ~ \.php$ {
            try_files $uri =404;
            include /etc/nginx/fastcgi_params;
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_pass unix:/run/php/php7.1-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_intercept_errors on;
        }

}

Die ersten beiden hinzugefügten Zeilen kümmern sich darum das der NGINX auf den richtigen Port lauscht und IPv4 und IPv6 anfragen annimmt.

Die anderen 2 kümmern sich darum das der NGINX den Schlüssel und das Zertifikat läd.

Danach starten wir neu uns schauen ob alles klappt.

sudo service nginx restart
ODER
sudo /etc/init.d/nginx restart

Nach erfolgreichem Neustart sollte unsere Seite unter http und https erreichbar sein.

HTTPS testen

Um unsere Konfiguration zu testen erstellen wir in unsrem Verzeichnis (/var/www/application/public) eine index.html zum testen. Unsere Seite dann unter beiden Adressen erreichbar sein

http://server_domain_or_IP
UND
https://server_domain_or_IP:443

Hinweiß: In den meisten Browsern muss man noch das Zertifikat akzeptieren damit die Seite dargestellt wird. Denn euer Lokales Zertifikat gilt in den Browsern als nicht sicher.

Abschluss

Abschließend ist zu sagen, dass der Aufwand SSL einzurichten doch relativ gering ist und für lokale Tests sehr zu empfehlen ist. Wenn eure Applikation lokal zu 100% läuft, solltet Ihr den Schritt nicht scheuen auch Live SSL mit einem richtigen Zertifikat zu verwenden. Richtige Zertifikate bekommt Ihr dank "Lets Encrypt" quasi für 0€.

Viel Spass beim testen. Bei Fragen benutzt bitte die Kommentare.

Debug SplObjectStorage, ArrayObject und update Xdebug

Unser Thema: SplObjectStorage, ArrayObject debuggen

Hallo,
heute dreht sich alles um die Frage:
"Wie kann man PHP Klassen die von SplObjectStorage oder ArrayObject erben debuggen und dessen Inhalt sehen?"

Mein Problem

In meinem PHP Projekt benutze ich viele Collection Klassen die von ArrayObject erben. (Erklärung: ArrayObject ist eine PHP interne Klasse die es erlaubt Objekte so wie Arrays arbeiten zu lassen. PHP.net).

Dabei ist mir aufgefallen das ich den Inhalt von solchen Collections nicht in PHPStorm debuggen kann. Ich erhielt nur Meldungen wie "can not get property".

Nach kurzer Recherche im Internet fand ich ich dann auch die Ursache des Problems.





Die Ursache

Die Ursache des Problems war eine veraltet Xdebug Version. In meinem Fall war es die Version 2.2.3 welche die Darstellung von solchen Objekten nicht unterstützte.

Die Lösung

Das Problem war also gefunden nun musste es nur noch gelöst werden. Der Fehler in Xdebug wurde in der Version 2.3.3 behoben. Also musste ich nur eine Version installieren die >2.3.3 ist. (Xdebug Bug Ticket)

Xdebug updaten >2.3.3

Um Xdebug zu aktualisieren müssen wir eigentlich nur eine aktuelle Version herunterladen diese kompilieren und aktivieren. Wie das geht erkläre ich euch jetzt.

Xdebug Wizard hilft euch

Um einfach die für euch empfohlene Xdebug Version herauszufinden könnt Ihr den von der Xdebug Homepage bereitgestellten Wizard benutzen. Xdebug Wizard

Dem Wizard müsst Ihr nur den Inhalt eurer PHPInfo übergeben. Dazu einfach eine Datei anlegen (z.B. info.php) mit dem Inhalt:
<?php echo phpinfo(); 
Den Inhalt der Seite kopiert Ihr mit Strg + A (alles Markieren) und Strg + C (kopieren) in das Feld auf der Wizard Seite.

Der Wizard erzeugt euch dann eine Ausgabe mit einer passenden Installationsanleitung für euer System.

Xdebug herunterladen und kompilieren

  • In /tmp Verzeichnis wechseln
    • Befehl: cd /tmp
  • Xdebug herunterladen
    • Befehl: wget http://xdebug.org/files/xdebug-2.4.1.tgz
  • Archiv entpacken
    • Befehl: tar -xvzf xdebug-2.4.1.tgz
  • In entpackte Verzeichnis wechseln
    • Befehl: cd xdebug-2.4.1
  • Build initialisieren
    • Befehl: phpize
  • Konfigurieren
    • Befehl: ./configure
  • Builden
    • Befehl: make
  • Kompiliertes Modul in PHP Ordner kopieren
    • Befehl: cp modules/xdebug.so /usr/lib/php5/20121212
  • Falls nötig Extension Pfad anpassen in der php.ini
    • nano /etc/php5/apache2/php.ini
    • Einfügen: zend_extension = /usr/lib/php5/20121212/xdebug.so
Bei mir war der letzte Schritt nicht nötig da in meiner php.ini nur die Extension per Name "xdebug.so" geladen wird.

Wichtig! Nach den Änderungen PHP/Apache neustarten, damit die Änderungen wirksam werden.

Ergebnis

Eure phpinfo Datei sollte nun die aktuell installierte Version von Xdebug anzeigen. In etwa so:
Nachdem alles geklappt hat könnt Ihr nun ohne Probleme solche ArrayObject Klassen debuggen :)

Falls Ihr Probleme oder Anregungen habt schreibt diese bitte in die Kommentare.

Viel Spass und bis bald.

Selbstsigniertes Zertifikat erstellen und mit NGINX benutzen


Hi, wer NGINX und SSL benutzen möchte dazu aber kein Geld ausgeben will kann dies mit einem selbstsignierten Zertifikat machen. Dies wird aber nicht für Produktivsysteme geraten!

Als erstes erstellen wir uns einen Ordner im nginx Verzeichnis wo wir die Zertifikate generieren.
mkdir /etc/nginx/https
cd /etc/nginx/https
Zertifikate erzeugen:
openssl genrsa -out example.key 2048
openssl req -new -key example.key -out example.csr

Dabei kann man einige Daten angeben... oder auch nicht ;)
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Mecklenburg-Vorpommern
Locality Name (eg, city) []:Neubrandenburg 
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example Inc
Organizational Unit Name (eg, section) []:Skunk works
Common Name (e.g. server FQDN or YOUR name) []:example.org
Email Address []:webmaster@example.org

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Unser nun selbst erstelltes Zertifikat wird nun von uns selbst signiert für 730 Tage.
openssl x509 -req -days 730 -in example.csr -signkey example.key -out example.crt

Wir können nun unsere Zertifikate in NGINX einbinden. Dies passiert in der "server {}" Direktive.
server {
        listen 80;
        listen 443 ssl;

        root /var/www/example/root;
        index index.html index.htm;
 
        server_name example.com;

        ssl_certificate /etc/nginx/ssl/example.crt;
        ssl_certificate_key /etc/nginx/ssl/example.key;
}

Nach der Änderung den Webserver neustarten:
service nginx restart (oder /etc/init.d/nginx restart)

https / ssl sollte nun für eure Seite funktionieren. Da die Zertifikate selbst ausgestellt wurden müssen diese im Browser beim aufruf der Seite noch vertraut werden. Wer das nicht will sollte sich ein Zertifikat mit hilfe von "Lets Encrypt" erstellen.

Installieren der neusten NGINX Version unter Ubuntu 15.10


Hi,
ich möchte euch hier zeigen wie Ihr die neuste NGINX Version unter Ubuntu 15.10 installiert.

Das Problem welches Ubuntu hat ist das nicht die neuste Version des Webservers in den Repos vorhanden ist. Aber zum Glück pflegt das NGINX Team ein eigenes "apt" Repository. Und dieses machen wir uns zunutze :)


1. NGINX "Signing Key" hinzufügen
curl http://nginx.org/keys/nginx_signing.key | apt-key add -
2. NGINX Repo zur source list hinzufügen
echo -e "deb http://nginx.org/packages/mainline/ubuntu/ `lsb_release -cs` nginx\ndeb-src http://nginx.org/packages/mainline/ubuntu/ `lsb_release -cs` nginx" > /etc/apt/sources.list.d/nginx.list
3. Paket Index aktualisieren
apt-get update
4. Neuste NGINX Version installieren :)
apt-get install nginx
5. Fertig!
nginx -v
Du solltest nun die aktuelle Versionsnummer deines NGINX Webservers sehen.

Hinweiß: Die hier installierte Version beinhaltet das HTTP2 / SSL Modul bereits

Ubuntu/Debian SSH Key erzeugen


Ubuntu SSH Key erzeugen und mit Github und Gitlab verwenden

Um sich ohne Passwort zu authentifizieren benötigt man oft einen SSH Key (Public Key). Hier in diesem Artikel erkläre ich euch kurz wie Ihr diesen erzeugen und benutzen könnt. (Artikel ist für Ubuntu/Debian System gedacht).
Bei dem Public-Key-Verfahren wird eine asymmetrische Verschlüsselung genutzt um den Benutzer zu authentifizieren. Der (oder die) öffentliche(n) Schlüssel des Benutzers befindet sich dabei in der Datei ~/.ssh/authorized_keys des Zielsystems, der private Schlüssel in einer Datei (meist id_rsa) im Verzeichnis ~/.ssh auf dem lokalen System, wo er zusätzlich von einer "pass phrase" geschützt wird. Wenn man sich nun mit der Public-Key-Methode auf einem SSH-Server anmelden möchte, so schickt der Server dem Klienten eine zufällig generierte Challenge. Der Klient verschlüsselt diesen Datenblock mit seinem privaten Schlüssel, (wofür nötigenfalls die Passphrase abgefragt wird,) und wenn der Server diesen Chiffre mit dem zugehörigen öffentlichen Schlüssel wieder entschlüsseln kann, ist die Identität des Benutzers bestätigt. Quelle

SSH Key erzeugen

ssh-keygen -t rsa -b 4096 

Erzeugt eine ähnlich aussehende Ausgabe:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 user@client.local
The key's randomart image is:
+--[ RSA 4096]----+
|                 |
|                 |
|                 |
|         +    .  |
|        S    E   |
|         .  + +  |
|          .o . o.|
|         o.oo. oo|
|          ==o.BO+|
+-----------------+

SSH Ordner

Der erstellte Key sollte nun in eurem SSH Ordner unter ... zu finden sein.
/home/user/.ssh/

SSH anzeigen und zu Github/Gitlab kopieren

Nun den Inhalt des Public Keys (.pub) in euren Github / Gitlab Account unter SSH Keys hinterlegen. Einfach den Inhalt der Datei mit dem Befehl cat ausgeben lassen und kopieren.
cat id_rsa.pub


Fertig :)

Xdebug.ini für Remote Debugging in PHPStorm


Komplett voreingestellte xdebug.ini für Ubuntu 14.04 direkt zur Verwendung mit PHPStorm.
Download: xdebug.ini


Code:
[debug]
zend_extension=xdebug.so

; Using Xdebug
;
; Q:  phpinfo() reports that Xdebug is installed and enabled, yet I still don't get any stacktraces when an error
;     happens.
; A1: You have to search through all your PHP libraries and include files for any "set_error_handler" calls.
;     If there are any, you have to either comment it out, or change the body of the handler function to call
;     xdebug_* api functions.
; A2: You do not have set [display_errors] to 1 in php.ini
; Q:  Xdebug doesn't format output.
; A:  Make sure you have PHP's [html_errors] set to 1 in php.ini
; Q:  The debug client doesn't receive any connections, what do I do wrong?
; A:  You probably forgot to set the environment variable or to add the necessary information to your URL. See the
;     documentation for more information.
;
;
; Related Links:
;
; FAQ: http://xdebug.org/docs/faq
; Related Settings: http://www.xdebug.org/docs/all_settings
;
;
; Author: Frank Göldner
; Stand : Nov 2011



; ===| basics |===

; Controls which IDE Key Xdebug should pass on to the DBGp debugger handler. The default is based on environment
; settings. First the environment setting DBGP_IDEKEY is consulted, then USER and as last USERNAME. The default is set
; to the first environment variable that is found. If none could be found the setting has as default ''.
; Type: string, Default value: *complex*
xdebug.idekey = "PHPSTORM"

; This is the base url for the links from the function traces and error message to the manual pages of the function
; from the message. It is advisable to set this setting to use the closest mirror.
; Type: string, Default value: http://www.php.net
xdebug.manual_url = "http://de.php.net/"

; Controls the protection mechanism for infinite recursion protection. The value of this setting is the maximum level
; of nested functions that are allowed before the script will be aborted.
; Type: integer, Default value: 100
xdebug.max_nesting_level = 110



; If this setting is 1, then stacktraces will be shown by default on an error event. You can disable showing
; stacktraces from your code with xdebug_disable(). As this is one of the basic functions of Xdebug, it is advisable
; to leave this setting set to 1.
; Type: boolean, Default value: 1
xdebug.default_enable = 1

; When this setting is set to on, the tracing of function calls will be enabled just before the script is run. This
; makes it possible to trace code in the auto_prepend_file.
; Type: boolean, Default value: 0
;xdebug.auto_trace = 0

; When this setting is set to 1, Xdebug will show a stack trace whenever an exception is raised - even if this
; exception is actually caught.
; Type: integer, Default value: 0
xdebug.show_exception_trace = 0

; If this setting is 1, then Xdebug will disable the @ (shut-up) operator so that notices, warnings and errors are no
; longer hidden.
; Type: boolean, Default value: 0, Introduced in Xdebug 2.1
xdebug.scream = 0

; If this setting is 1, Xdebug will color var_dumps and stack traces output when in CLI mode.
; Type: boolean, Default value: 0, Introduced in Xdebug 2.2
xdebug.cli_color = 1




; ===| level of detail |===

; When this setting is set to something != 0 Xdebug's generated stack dumps in error situations will also show all
; variables in the top-most scope. Beware that this might generate a lot of information, and is therefore turned off
; by default.
; Type: integer, Default value: 0
xdebug.show_local_vars = 0

; When this setting is set to something != 0 Xdebug's human-readable generated trace files will show the difference in
; memory usage between function calls. If Xdebug is configured to generate computer-readable trace files then they will
; always show this information.
; Type: integer, Default value: 0
xdebug.show_mem_delta = 0

; Controls the amount of array children and object's properties are shown when variables are displayed with either
; xdebug_var_dump(), xdebug.show_local_vars or through Function Traces. This setting does not have any influence on the
; number of children that is send to the client through the Remote Debugging feature.
; Type: integer, Default value: 128
xdebug.var_display_max_children = 256

; Controls the maximum string length that is shown when variables are displayed with either xdebug_var_dump(),
; xdebug.show_local_vars or through Function Traces. This setting does not have any influence on the amount of data
; that is send to the client through the Remote Debugging feature.
; Type: integer, Default value: 512
xdebug.var_display_max_data = 1024

; Type: integer, Default value: 3
; Controls how many nested levels of array elements and object properties are when variables are displayed with either
; xdebug_var_dump(), xdebug.show_local_vars or through Function Traces. This setting does not have any influence on the
; depth of children that is send to the client through the Remote Debugging feature.
xdebug.var_display_max_depth = 3

; This setting, defaulting to 0, controls whether Xdebug should add variable assignments to function traces.
; Type: boolean, Default value: 0, Introduced in Xdebug 2.1
xdebug.collect_assignments = 0

; This setting, defaulting to 1, controls whether Xdebug should write the filename used in include(), include_once(),
; require() or require_once() to the trace files.
; Type: boolean, Default value: 1
xdebug.collect_includes = 1

; This setting, defaulting to 0, controls whether Xdebug should collect the parameters passed to functions when a
; function call is recorded in either the function trace or the stack trace.
;
; The setting defaults to 0 because for very large scripts it may use huge amounts of memory and therefore make it
; impossible for the huge script to run. You can most safely turn this setting on, but you can expect some problems in
; scripts with a lot of function calls and/or huge data structures as parameters. Xdebug 2 will not have this problem
; with increased memory usage, as it will never store this information in memory. Instead it will only be written to
; disk. This means that you need to have a look at the disk usage though.
;
; This setting can have four different values. For each of the values a different amount of information is shown. Below
; you will see what information each of the values provides. See also the introduction of the feature Stack Traces for
; a few screenshots.

; Value   Argument Information Shown
; 0       None.
; 1       Type and number of elements (f.e. string(6), array(8)).
; 2       Type and number of elements, with a tool tip for the full information 1.
; 3       Full variable contents (with the limits respected as set by xdebug.var_display_max_children,
;         xdebug.var_display_max_data and xdebug.var_display_max_depth.
; 4       Full variable contents and variable name.
; Type: integer, Default value: 0
xdebug.collect_params = 4

; This setting, defaulting to 0, controls whether Xdebug should write the return value of function calls to the trace
; files.
; Type: boolean, Default value: 0
xdebug.collect_return = 0

; This setting tells Xdebug to gather information about which variables are used in a certain scope. This analysis can
; be quite slow as Xdebug has to reverse engineer PHP's opcode arrays. This setting will not record which values the
; different variables have, for that use xdebug.collect_params. This setting needs to be enabled only if you wish to
; use xdebug_get_declared_vars().
; Type: boolean, Default value: 0
xdebug.collect_vars = 0

; * = COOKIE, FILES, GET, POST, REQUEST, SERVER, SESSION. These seven settings control which data from the superglobals
; is shown when an error situation occurs. Each php.ini setting can consist of a comma seperated list of variables from
; this superglobal to dump, but make sure you do not add spaces in this setting. In order to dump the REMOTE_ADDR and
; the REQUEST_METHOD when an error occurs, add this setting:
; xdebug.dump.SERVER = REMOTE_ADDR,REQUEST_METHOD
;
; Type: string, Default value: Empty
; xdebug.dump.* = ?

; Controls whether the values of the superglobals as defined by the xdebug.dump.* settings whould be shown or not.
; Type: boolean, Default value: 1
xdebug.dump_globals = 1

; Controls whether the values of the superglobals should be dumped on all error situations (set to 0) or only on the
; first (set to 1).
; Type: boolean, Default value: 1
xdebug.dump_once = 1

; If you want to dump undefined values from the superglobals you should set this setting to 1, otherwise leave it set
; to 0.
; Type: boolean, Default value: 0
xdebug.dump_undefined = 0

; Controls whether Xdebug should enforce 'extended_info' mode for the PHP parser; this allows Xdebug to do file/line
; breakpoints with the remote debugger. When tracing or profiling scripts you generally want to turn off this option as
; PHP's generated oparrays will increase with about a third of the size slowing down your scripts. This setting can not
; be set in your scripts with ini_set(), but only in php.ini.
; Type: integer, Default value: 1
xdebug.extended_info = 1

; By default Xdebug overloads var_dump() with its own improved version for displaying variables when the html_errors
; php.ini setting is set to 1. In case you do not want that, you can set this setting to 0, but check first if it's not
; smarter to turn off html_errors.
; Type: boolean, Default value: 1, Introduced in Xdebug 2.1
xdebug.overload_var_dump = 1




; ===| remote settings |===

; This switch controls whether Xdebug should try to contact a debug client which is listening on the host and port as
; set with the settings xdebug.remote_host and xdebug.remote_port. If a connection can not be established the script
; will just continue as if this setting was 0.
; Type: boolean, Default value: 0
xdebug.remote_enable = 1

; Normally you need to use a specific HTTP GET/POST variable to start remote debugging (see Remote Debugging). When
; this setting is set to 1, Xdebug will always attempt to start a remote debugging session and try to connect to a
; client, even if the GET/POST/COOKIE variable was not present.
; Type: boolean, Default value: 0
xdebug.remote_autostart = 0

; If enabled, the xdebug.remote_host setting is ignored and Xdebug will try to connect to the client that made the HTTP
; request. It checks the $_SERVER['REMOTE_ADDR'] variable to find out which IP address to use. Please note that there
; is no filter available, and anybody who can connect to the webserver will then be able to start a debugging session,
; even if their address does not match xdebug.remote_host.
; Type: boolean, Default value: 0, Introduced in Xdebug 2.1
xdebug.remote_connect_back = 1

; Selects the host where the debug client is running, you can either use a host name or an IP address. This setting is
; ignored if xdebug.remote_connect_back is enabled.
; Type: string, Default value: localhost
xdebug.remote_host = "192......"
; deine UNIDEV IP falls ifconfig gesperrt -> ip -4 -o addr show eth0 | awk -F"[/, ]" '{print $7 }'
;xdebug.remote_host = "127.0.0.1"

; This setting can be used to increase (or decrease) the time that the remote debugging session stays alive via the
; session cookie.
; Type: integer, Default value: 3600, Introduced in Xdebug 2.1
xdebug.remote_cookie_expire_time = 3600

; Can be either 'php3' which selects the old PHP 3 style debugger output, 'gdb' which enables the GDB like debugger
; interface or 'dbgp' - the debugger protocol. The DBGp protocol is more widely supported by clients. See more
; information in the introduction for Remote Debugging.
;
; Note: Xdebug 2.1 and later only support 'dbgp' as protocol.
; Type: string, Default value: dbgp
xdebug.remote_handler = "dbgp"

; If set to a value, it is used as filename to a file to which all remote debugger communications are logged. The file
; is always opened in append-mode, and will therefore not be overwritten by default. There is no concurrency protection
; available. The format of the file looks something like:
; Log opened at 2007-05-27 14:28:15
; ->
;
;
; Type: string, Default value:
; xdebug.remote_log =

; Selects when a debug connection is initiated. This setting can have two different values:
; req
;   Xdebug will try to connect to the debug client as soon as the script starts.
; jit
;   Xdebug will only try to connect to the debug client as soon as an error condition occurs.
; Type: string, Default value: req
xdebug.remote_mode = "req"

; The port to which Xdebug tries to connect on the remote host. Port 9000 is the default for both the client and the
; bundled debugclient. As many clients use this port number, it is best to leave this setting unchanged.
; Type: integer, Default value: 9000
xdebug.remote_port = 9002




; ===| trace options |===

; When this setting is set to on, the tracing of function calls will be enabled just before the script is run. This
; makes it possible to trace code in the auto_prepend_file.
; Type: boolean, Default value: 0
xdebug.auto_trace = 0

; When this setting is set to 1, you can trigger the generation of trace files by using the XDEBUG_TRACE GET/POST
; parameter, or set a cookie with the name XDEBUG_TRACE. This will then write the trace data to defined directory.
; In order to prevent Xdebug to generate trace files for each request, you need to set xdebug.auto_trace to 0.
; Type: boolean, Default value: 0, Introduced in Xdebug 2.2
xdebug.trace_enable_trigger = 0

; When set to '1' the trace files will be appended to, instead of being overwritten in subsequent requests.
; Type: integer, Default value: 0
xdebug.trace_options = 0

; The directory where the tracing files will be written to, make sure that the user who the PHP will be running as has
; write permissions to that directory.
; Type: string, Default value: /tmp
;xdebug.trace_output_dir = "/data/h.test/projects/_tracer/"

; This setting determines the name of the file that is used to dump traces into. The setting specifies the format with
; format specifiers, very similar to sprintf() and strftime(). There are several format specifiers that can be used to
; format the file name. The '.xt' extension is always added automatically.

; The possible format specifiers are:
;
; Spec Meaning                                  Example Format     Example Filename
; %c   crc32 of the current working directory   trace.%c           trace.1258863198.xt
; %p   pid                                      trace.%p           trace.5174.xt
; %r   random number                            trace.%r           trace.072db0.xt
; %s   script name²                             cachegrind.out.%s  cachegrind.out._home_httpd_html_test_xdebug_test_php
; %t   timestamp (seconds)                      trace.%t           trace.1179434742.xt
; %u   timestamp (microseconds)                 trace.%u           trace.1179434749_642382.xt
; %H   $_SERVER['HTTP_HOST']                    trace.%H           trace.kossu.xt
; %R   $_SERVER['REQUEST_URI']                  trace.%R           trace._test_xdebug_test_php_var=1_var2=2.xt
; %U   $_SERVER['UNIQUE_ID']³                   trace.%U           trace.TRX4n38AAAEAAB9gBFkAAAAB.xt
; %S   session_id (from $_COOKIE if set)        trace.%S           trace.c70c1ec2375af58f74b390bbdd2a679d.xt
; %%   literal %                                trace.%%           trace.%%.xt
;
; ²This one is not available for trace file names.
; ³New in version 2.2. This one is set by Apache's mod_unique_id module
; Type: string, Default value: trace.%c
xdebug.trace_output_name = "trace.%c"

; The format of the trace file.Value  Description
; 0   shows a human readable indented trace file with: time index, memory usage, memory delta (if the setting
;     xdebug.show_mem_delta is enabled), level, function name, function parameters (if the setting
;     xdebug.collect_params is enabled), filename and line number.
; 1   writes a computer readable format which has two different records. There are different records for entering a
;     stack frame, and leaving a stack frame. The table below lists the fields in each type of record. Fields are tab
;     separated.
;
; Fields for the computerized format:
; Record type 1      2           3           4           5             6               7                                           8                                   9           10
; Entry       level  function #  always '0'  time index  memory usage  function name   user-defined (1) or internal function (0)   name of the include/require file    filename    line number
; Exit        level  function #  always '1'  time index  memory usage  -------------------------------------------------------  empty  -------------------------------------------------------
;
; See the introduction of Function Traces for a few examples.
; Type: integer, Default value: 0
xdebug.trace_format = 0




; ===| Profiling |===

; When this setting is set to 1, profiler files will not be overwritten when a new request would map to the same file
; (depnding on the xdebug.profiler_output_name setting. Instead the file will be appended to with the new profile.
; Type: integer, Default value: 0
xdebug.profiler_append = 0

; Enables Xdebug's profiler which creates files in the profile output directory. Those files can be read by KCacheGrind
; to visualize your data. This setting can not be set in your script with ini_set(). If you want to selectively enable
; the profiler, please set xdebug.profiler_enable_trigger to 1 instead of using this setting.
; Type: integer, Default value: 0
xdebug.profiler_enable = 0

; When this setting is set to 1, you can trigger the generation of profiler files by using the XDEBUG_PROFILE GET/POST
; parameter, or set a cookie with the name XDEBUG_PROFILE. This will then write the profiler data to defined directory.
; In order to prevent the profiler to generate profile files for each request, you need to set xdebug.profiler_enable
; to 0.
; Type: integer, Default value: 0
xdebug.profiler_enable_trigger = 0

; The directory where the profiler output will be written to, make sure that the user who the PHP will be running as
; has write permissions to that directory. This setting can not be set in your script with ini_set().
; Type: string, Default value: /tmp
;xdebug.profiler_output_dir = "/data/f.goeldner/projects/profiler/"

; This setting determines the name of the file that is used to dump traces into. The setting specifies the format with
; format specifiers, very similar to sprintf() and strftime(). There are several format specifiers that can be used to
; format the file name.
;
; See the xdebug.trace_output_name documentation for the supported specifiers.
; Type: string, Default value: cachegrind.out.%p
xdebug.profiler_output_name = "cachegrind.out.%p"

Linux Bash History durchsuchen und Limit erhöhen


Linux Bash History durchsuchen und Speicherlimit erhöhen


Viele kennen vielleicht das Problem das man auf der Konsole ein komplexen Befehl ausgeführt hatte aber diesen nicht mehr vollständig kennt. Da in Linux ausgeführte Befehle standardmä0ig in der Bash History (~/.bash_history) gespeichert werden ist es relativ leicht seine bereits genutzten Befehle wieder zu finden. Um die History zu durchsuchen genügt es diesen Befehl auszuführen:

Bash History durchsuchen:
  history | grep "MeinSuchwort"

Die History speichert Standardmäßig 2000 Befehle. Einigen Leuten ist das aber einfach zu wenig und Sie hätten gern das Ihre History 10.000 Einträge speichert. Um das zu ermöglichen muss man folgende Änderungen vornehmen.

Bash History Limit erhöhen:
bashrc bearbeiten:
 
  nano ~/.bashrc

Limit anpassen:
 
  HISTSIZE=10000
  HISTFILESIZE=10000

HISTSIZE - Anzahl der zu speichernden Befehle in der Bash Session
HISTFILESIZE - Anzahl der enthaltenen Zeilen die in die history Datei gespeichert werden

Viel Spass beim erweitern eurer Bast History ;)