In gewissen Situationen ist ein typisches CMS wie WordPress oder Drupal einfach nicht das richtige und man möchte doch im Endeffekt gerne ein eigenes System schreiben. Insbesondere gillt dies für Anforderungen, wo Performance eine hohe Priorität spielt.
In diesem Fall geht man meistens eine Ebene tiefer und baut sich ein eigenes System auf.
Siehe hier meine Youtube Tutorial Videos auf dem offiziellen CakePHP Channel um mehr über das Thema zu erfahren:
Der PHP Composer ist ein Package-Management Tool ähnlich dem NPM oder Yarn welcher in der JavaScript-Welt bekannt ist.
Warum braucht man Dependency-Management?
Kaum jemand baut Webseiten komplett von 0 auf – d.h. Usermanagement inkl. Rollen, Medienverwaltung, Login etc.
Also wäre es ja nicht schlecht diese schon implementierten Code-Blöcke in das eigene Tool zu übernehmen, oder?
Jedoch wie bei jeder Software-Entwicklung hängt es immer sehr von der Version ab wie kompatibel 2 Code-Blöcke miteinander sind.
Genau für dieses Problem gibt es den Composer.
Composer weiß durch die Daten in der composer.json bzw. composer.lock welche Module in welcher Version installiert werden sollen und wovon diese Module wieder abhängig sind damit diese auch automatisch installiert werden.
Mit diesen 4 Zeilen von PHP wird eine composer.phar in das aktuelle Verzeichniss gelegt.
D.h. über den folgenden Befehl können Composer-Befehle durchgeführt werden:
php composer.phar list
Damit aber Composer „global“ zur Verfügung steht muss ein User mit Admin Rechten diese Datei noch verschieben
mv composer.phar /usr/local/bin/composer
Da jeder Linux und MacOS User den Pfad /usr/local/bin/ in seiner $PATH Variable hat kann somit jeder User Composer Befehle wie folgt ausführen:
composer list
Verwendung
Hier werden ein paar essentielle Funktionalitäten vom Composer beschrieben
composer list
Zeigt alle zur Verfügung stehenden Composer Befehle an
composer create-project <boilerplate-name>
Initialisiert ein Composer-Projekt mit einem gewissen „Boilerplate“ und erzeugt eine composer.json im aktuellen Verzeichnis.
composer require <modulenmae>
Fügt das gewünschte Modul zur composer.json hinzu und führt ein composer update durch.
composer remove <modulenmae>
Entfernt das gewünschte Modul aus der composer.json und aus dem Dateisystem.
composer update
Aktualisiert die aktuell installierten Module mit den neuesten, in der composer.json definierten Updates. Die Versionen der neu installierten Module werden in der composer.lock gespeichert.
composer install
Wenn eine composer.lock vorhanden ist werden die darin enthaltenen Module in der angegebenen Verion installiert. Wenn keine composer.lock vorhanden ist werden die aktuellsten Versionen laut composer.json installiert und eine composer.lock generiert.
composer self-update
Aktualisiert die installierte Composer Version
composer outdated --direct
Zeigt alle Module an, die aktualisiert werden können. Das –direct heist, dass nur Modul-Updates angezeigt werden, die in der composer.json definiert sind und nicht weitere Dependencies dahinter.
Aufbau der composer.json
Die simpelste Version einer composer.json kann über den Befehl composer init generiert werden:
Prinzipiell steht hier nur wie der Name des Modul ist devguide/myapp, wer der Author des Moduls ist und ob es Dependencies zu diesem Modul gibt.
require vs. require-dev
Wie üblich in der Software-Entwicklung gibt es häufig eine Produktionsumgebung und eine Testumgebung
Damit Module in der Produktionsumgebung nicht installiert werden müssen einerseits diese in dem require-dev Bereich stehen, andererseits müssen die Module in der Produktionsumgebung auch mit der folgenden Option installiert werden:
composer install --no-dev
Somit bleiben alle Development-Module, die das Leben für uns Entwickler vereinfachen, nur auf der Testumgebung und nehmen keinen Platz auf der Live-Seite ein.
Schreibweise für die Versionen
Name
Kurzschreibweise
Version Range
Exact Version
1.0.2
1.0.2
Version Range
>=1.0 <2.0
>=1.0 <2.0
>=1.0 <1.1 || >=1.2
>=1.0 <1.1 || >=1.2
Hyphenated Version Range
1.0 – 2.0
>=1.0.0 <2.1
1.0.0 – 2.1.0
>=1.0.0 <=2.1.0
Wildcard Version Range
1.0.*
>=1.0 <1.1
Tile Version Range
~1.2
>=1.2 <2.0
~1.2.3
>=1.2.3 <1.3.0
Caret Version Range
^1.2.3
>=1.2.3 <2.0.0
Composer Patches
Wie überall bei der Softwareentwicklung funktionieren nicht immer die aktuellen Versionen zu 100% wie gewünscht.
Bevor aber eine neue Version vom Composer Modul Hersteller veröffentlicht wird gibt es meistens Patches, die angewewendet werden können.
Diese sind ganz normale .patch Files, die über GIT erstellt werden können.
Hier wird also das Modul drupal/recaptcha gepatched werden.
Wenn composer install oder composer update durchgeführt wird, sollte der Patch wie folgt angezeigt werden:
Probleme beim Patching
Wie hier zu sehen kann der Patch nicht heruntergeladen werden, da er unter der URL nicht erreichbar ist.
Hier bitte einfach die URL überprüfen ob diese auch wirklich 100% korrekt ist.
Hier ist zu sehen, dass der Patch nicht anwendbar ist.
Dies hat meistens den Grund, dass das installierte Modul den angegebenen Patch schon inkludiert hat.
Hier würde ich empfehlen den Changelog des Moduls durchzusehen ob der angegebene Patch nicht schon in einer neuen Version angewandt wurde. Dann braucht man natürlich den Patch nicht mehr händisch durchführen.
Probleme beim Update Prozess
Hier könnte es diverse Probleme geben
Berechtigungsproblem
PHP Memory Limit Problem
Hier kommt es natürlich immer sehr auf die Fehlermeldung an, die gerade angezeigt wird.
Das Problem mit dem Memory Limit muss über die php.ini gelöst werden. D.h. über
In dieser Datei sollte der folgende Eintrag auf mind. 3G erhöht werden (zu mindest für Drupal Projekte)
memory_limit = 3G
Berechtigunngsprobleme müssen immer je nach aktueller Umgebung gelöst werden.
Während des Update Vorgangs ist die Seite NICHT bedienbar bzw. wird Fehlermeldung anzeigen. Hier wird prinzipiell empfohlen den Wartungsmodus einzuschalten oder den gesamten Webserver kurzzeitig zu deaktivieren.
Installierte Module entsprechen nicht der composer.json bzw composer.lock
Manchmal kann es vorkommen, dass beim installieren bzw. aktualisieren von Composer Modules (bzw. Drupal Modules) nicht die richtige Version installiert wird bzw. eine defekte Version installiert.
Die einfachste Lösung hier ist es alle automatisch generierten Dateien und Ordner zu löschen und über den Composer neu zu installieren. Also:
Datenbanken dienen dazu Informationen so effizient wie möglich zu speichern aber auch gleichzeitig in eine gewünschte Struktur zu bringen, um damit zu arbeiten bzw. diese auszulesen und zu aktualisieren.
Welche Arten von Datenbanken gibt es?
Hier gibt es 2 Hauptunterscheidungen:
SQL
Die „Structured Query Language“ (kurz SQL) ist KEINE „Programmiersprache“ in der Hinsicht, da sie nicht Turing-Vollständig ist.
SQL dient mehr dazu in einer semantischen Schreibart Informationen verwaltbar zu machen.
Beispiel: „Gib mir alle Benutzer aus welche älter als 25 sind“ ist im SQL so etwas ähnliches wie (abhängig von der SQL Struktur)
SELECT * FROM users WHERE age > 25
In SQL basierenden Datenbank-Systemen besteht die Struktur immer aus: Datenbanken, Tabellen und Spalten
Man kann es sich sehr gut vorstellen wenn man eine SQL Datenbank mit einer Excel Tabelle vergleicht.
1 Datenbank = 1 Excel-Datei 1 Tabelle = 1 Excel-Blatt in der Excel-Datei 1 Spalte = 1 Spalte in einem Excel-Blatt
Die am meisten verwendeten Befehle bei SQL Datenbanken sind:
SELECT
UPDATE
DELETE
INSERT
CREATE DATABASE
CREATE TABLE
Bekannte SQL Datenbank-Server Software:
MySQL bzw. MariaDB
PostgreSQL
Oracle
Microsoft SQL
Hauptmerkmal von SQL Datenbanken sind die Verbindungen (aka „Relationen“), die zwischen Spalten hergestellt werden können. Deswegen werden SQL Datenbanken immer als „relationale Datebanken“ bezeichnet.
NoSQL
Im Gegensatz zu SQL basierenden Datenbanken besteht bei NoSQL Datenbanken keine „fixe“ Struktur wie die Daten strukturiert bzw. aufgebaut werden müssen.
Je nach verwendeter NoSQL-Server Software können die Daten in folgenden Strukturen gespeichert werden:
Column based (ähnlich zu SQL)
Document based
Graph based
Key-Value based
Vorteil dieser „Freiheit“ ist es z.B. auch im Live-Betrieb die vorhandenen Datenstrukturen leicht erweitern zu können, da Felder pro Eintrag extra gespeichert werden und keinen Einfluss auf schon vorhandene Daten bzw. Strukturen haben.
Beispiel für ein Query in einer Document based Datenbank (hier MongoDB):
myCursor = db.inventory.find( {} )
Hier werden alle Einträge aus der Collection „inventory“ ausgegeben.
Der „System Daemon“ (kurz systemd) ist ein Programm, der unter anderem das initialisieren und verwalten von Linux-Services wie z.B. den SSH-Daemon (sshd) oder den NGINX Webserver ermöglicht.
Wieso brauche ich den systemd?
So wie auf einem Desktop-Rechner nicht immer alle Programme gleichzeitig offen sein sollen ist es auf einem Server auch gleich.
Mit dem systemd kann einerseits eingestellt werden welche Programme beim starten des Servers automatisch gestartet werden, andererseits gibt es aber auch diverse andere Befehle, die das verwalten der Services ermöglichen.
Wichtigste Befehle
systemctl
Zeige alle im systemd geladenen Services und deren Status an
systemctl start nginx
Starte den Service nginx
systemctl stop nginx
Stoppe den Service nginx
systemctl restart nginx
Startet den Service nginx komplett neu (bricht ALLE aktuellen Verbindungen ab)
systemctl reload nginx
Ladet die aktuellste Konfiguration für den Service nginx neu ein (bricht KEINE aktuellen Verbindungen ab)
systemctl status nginx
Zeige den aktuellen Status des angegeben Service an
systemctl enable nginx
Füge einen Service zum Autostart hinzu
systemctl disable nginx
Entferne einen Service vom Autostart
Ich habe keinen systemd in meiner Linux Installation!
Abhängig von der verwendeten Distribution und Version ist der systemd nicht standardmäßig installiert und konfiguriert.
Die meisten bekanntesten Distributionen haben schon vor einigen Jahren den Wechsel zu systemd durchgeführt wie z.B. Ubuntu seit 2015, Debian seit 2014, CentOS seit 2014, Arch seit 2012 und Fedora seit 2011. Siehe HIER für die aktuelle Liste.
Vorgänger zu systemd waren z.B. initd oder SysVinit (wieder abhängig von der verwendeten Distribution)
Wo befinden sich die Config-Dateien für die ganzen schon vorhandenen Services?
Die von der Distribution standardmäßig vorhandenen Services befinden sich in /lib/systemd/system.
Alle im Nachhinein installierten Services befinden sich in /etc/systemd/system.
Ebenso kann jeder vorhandene User selbst auch eigene Services in ~/.config/systemd/user erstellen.
Wie in den vorherigen Beiträgen schon beschrieben wissen wir nun, was IP-Adressen sind und wie sich prinzipiell ein IP-Netzwerk aufbaut.
Wir gehen vom dem Beispiel aus dem Beitrag „Was ist eine IP-Adresse?“ aus, dass eine IP-Adresse ähnlich ist wie eine Anschrift eines Hauses. Nun können wir sagen, dass ein Port ein spezieller Eingang (Tür, Fenster oder was auch immer) zu dem Haus ist, der zu einer speziellen Anwendung führt.
Port-Nummer können von 0 bis 65535 gehen, wobei aber eben gewisse Port-Nummern schon vordefiniert sind.
Unterteilt wird dieser Bereich in
System Ports (0 – 1023)
Hier befinden sich die vordefinierten bzw. standardisierten Ports
User Ports (1024 – 49151)
User können hier (wenn noch nicht vergeben) selber Ports für ihre Anwendungen definieren
Dynamic Ports (49152 – 65535)
Dieser Bereich wird primär für die Port-Zuweisung verwendet, welche von Betriebssystem dynamisch erstellt werden
Im folgendem Screenshot ist ein Auszug von Wireshark zu sehen, der einen vom Betriebssystem automatisch generierten dynamic Port verwendet um eine HTTPS-Anfrage (Port 443) an meinen Server (192.168.0.2) sendet.
Da ich alle meine Seiten über HTTPS gesichert habe sehen wir hier keine weitere Daten (wie z.b. das HTTP Protokoll) weil vorher schon die TLSv1.2 Verschlüsselung durchgeführt wurde.
Damit aber nicht jeder einfach jeden Port irgendwie willkürlich verwenden kann wurden standardisierte Ports für schon vorhandene Protokolle definiert.
Das ursprüngliche FTP Protokoll wurde 1985 entwickelt um Dateien über das IP-Protokoll zu versenden. Datentransfer läuft üblicherweise über Port 21.
Hauptproblem hierbei ist aber, dass die Authentifizierung NICHT VERSCHLÜSSELT läuft, d.h. wenn jemand im Netzwerk über z.B. WireShark die IP Pakete „mithört“ kann dieser ohne Probleme die Zugangsdaten auslesen.
Es wird dadurch aktuell nicht empfohlen!
FTP mit implizitem SSL
FTP mit implizitem SSL ist als nächstes entwickelt worden um das Hauptproblem von FTP zu beheben – keine Verschlüsselung. Datentransfer läuft üblicherweise über Port 990 wobei aber hier bevor ein Login oder Daten transferiert werden eine SSL oder TLS Verbindung hergestellt wird (abhängig von Server-Konfiguration). Die Basis des FTP Protokoll bleibt aber die gleiche!
Abhängig von der Server-Konfiguration (primär der gewählten Verschlüsselungsart) kann diese Methode im Live Betrieb verwendet werden, da eben eine komplett verschlüsselte Verbindung mit dieser Übertragungsmethode vorausgesetzt wird.
FTP mit explizitem TLS
FTP mit explizitem TLS ist etwas flexibler wie FTP implizitem SSL. Einerseits wird wieder die Verbindung über den Standard FTP Port 21 hergestellt wird, nur dass der Client die Möglichkeit hat nur den Login oder den gesamten Datenverkehr über eine TLS Verbindung durchzuführen.
Problem hierbei ist aber, dass von einer Zertifizierungsstelle das FTPS-Zertifikat signiert werden (was üblicherweise Kosten verursacht) muss um keine Warnung beim verbinden zum FTPS Server zu bekommen. Außer man verwendet ein selbst signiertes Zertifikat, welches aber wie gesagt am Client eine Warnung beim Verbindungsaufbau anzeigt. Aktuell habe ich keinen Weg gefunden über Let’s Encrypt ein Zertifikat für FTPS zu generieren (wie für die HTTPS Zertifikate).
Im Vergleich hierzu benötigt SFTP kein eigenes Zertifikat da hier die Verschlüsselung schon vom SSH Protokoll über die Public-Key-Auth erledigt wird.
SFTP
Das SSH File Transfer Protocol hat in der Hinsicht nichts mehr mit dem ursprünglichen FTP Protokoll zu tun da es auf dem SSH Protokoll aufbaut und alle Befehle über eine, verschlüsselte Verbindung sendet.
Daher ist diese Übertragungsmethode aktuell eine empfohlene Variante welche recht einfach eingerichtet werden kann, da das SFTP Subsystem im standardmäßig installierten SSH-Daemon bei einem Linux System nur aktiviert werden muss. Im Vergleich dazu muss für eine FTP Verbindung (egal ob verschlüsselt oder nicht) immer ein eigener FTP-Server wie z.B. VSFTP oder ProFTP installiert und konfiguriert werden.
rsync
rsync ist ein Programm, welches ebenso auf dem SSH Protokoll aufgebaut ist wie SFTP. Der Hauptunterschied ist hier aber, dass nur Daten über das Netzwerk geschickt werden, die sich auch wirklich zwischen den beiden Rechner geändert haben und nicht die gesamten Dateien.
„rsync“ ist ein Programm, welches das synchronisieren von 2 entweder lokalen oder entfernten Ordner erlaubt. Einfach gesagt, es ist eine bessere Variante vom Befehl „cp“ mit dem Dateien und Ordner kopiert werden können. Hauptmerkmal hier ist, dass es auf dem SSH-Protokoll aufbaut.
Kann ich nicht FTP oder SFTP auch nehmen?
Einfach gesagt: FTP => NEIN, SFTP => OK aber nicht so gut wie rsync
Genauere Beschreibung von Datei-Übertragungsmethoden siehe HIER.
Wieso ist rsync besser als SFTP wenn beide auf SSH basieren?
Wenn rsync auf beiden Seiten installiert ist werden NUR die Änderungen in den jeweiligen Dateien übertragen, die auch Änderungen beinhalten. Hierfür verwendet rsync einen „Delta-Kodierungs-Algorithmus“ und spart hiermit sehr viel Traffic.
Wie verwende ich rsync mit entfernten Rechner?
Voraussetzung: rsync muss auf beiden Seiten installiert sein! Kann über den Befehl „rsync --version“ herausgefunden werden. Es sollte aktuell (September 2019) mind. Version 3 installiert sein.
Gehen wir von folgenden 2 Systemen aus:
Der aktuelle Rechner (PC1), auf dem ein Ordner vorhanden ist, der auf einen extern erreichbaren Rechner (PC2) kopiert werden soll.
Befehl
rsync -aP <source> <destination>
D.h. wir sind am PC1 eingeloggt und haben im aktuellen Verzeichnis im Terminal einen Ordner wie z.B. „wordpress“ den wir auf den entfernten Rechner PC2 in den absoluten Pfad /var/www/html kopieren wollen. Für unseren entfernten Rechner nehmen wir einfach als Server-Adresse devguide.at und als Benutzer „admin“ her.
Was passiert nun? Wenn sonst nichts eingestellt ist wird entweder der Transfer nicht stattfinden oder es wird nach einem Passwort für den Benutzer „admin“ gefragt. Das hängt ganz davon ab wie der SSH-Daemon von PC2 eingestellt ist.
Damit wir aber nicht bei jedem neuen Transfer das Passwort eingeben müssen wird hier von einer schon eingerichteten „Public-Key-Auth“ ausgegangen. Siehe hierzu HIER für weitere Details.
D.h. nun haben wir eine fertig eingerichtete „Public-Key-Auth“ und wir können uns testweise ohne Passwort mit dem Befehl
ssh admin@devguide.at
auf PC2 anmelden.
Nun sollte der folgende Befehl ohne Probleme funktionieren:
Ich möchte wirklich nur die Dateien aus <source> am <destination> haben und nichts anderes!
Standardmäßig lässt rsync alle Dateien in Ruhe, die auf der <destination> Seite vorhanden sind aber nicht auf der <source> Seite vorhanden waren.
Jedoch gibt es Situationen, wo dies nicht gewünscht wird und sozusagen immer nur der <source> Stand auf die <destination> Seite geladen werden soll und sonst alles in dem angegebenen Ordner auf der <destination> Seite gelöscht werden soll.
Unicast bedeutet das versenden von Daten von Interface A zu Interface B.
Multicast bedeutet das versenden von Daten an eine spezielle, vordefinierte Gruppe an Interfaces.
Beispiele für IPv6 Multicast-Adressen:
IP-Adresse
Verwendung
ff02::1
Alle Nodes im lokalen Netzwerk
ff02::2
Alle Router im lokalen Netzwerk
ff05::1:5
DHCP Server im lokalen Netzwerk
ff02::1:2
DHCPv6 Server im lokalen Netzwerk
Broadcast ist im Prinzip eine spezielle Variante von einem Multicast – nämlich das alle Geräte in einem Netzwerk die Daten erhalten.
D.h. am Beispiel von einem 192.168.0.0/24 Netzwerk kann 192.168.0.255 (Broadcast-Adresse) angepingt werden und alle Interfaces in diesem Netzwerk antworten.
Gehen wir vom Beispiel aus, dass im eigenen System keine temporären IPv6-Adressen vorhanden wären und der Client bzw. das Interface über SLAAC eine automatisch generierte IPv6 Adresse erhält, welche sich ja aus der MAC-Adresse des jeweiligen Interfaces generiert.
Wenn diese generierte IPv6-Adresse jetzt zur Verbindung nach außen ins Internet verwendet wird, wäre es für externe Tracking-Tools recht einfach ein User-Profil von dieser IP-Adresse zu erstellen, da ja die MAC-Adresse teil der IP-Adresse ist.
Daher wurden temporäre IPv6-Adressen eingeführt, welche sich zufällig beim Verbinden in das Internet generieren. Diese IPv6-Adressen werden dann hergenommen, wenn Daten aus dem Internet angefragt werden. Da diese regelmäßig gelöscht bzw. erneuert werden, ist es für externe Tracking-Tools nicht möglich rein über die IPv6-Adresse ein User-Profil zu erstellen und die Privatsphäre des Users ist gewährt.
Secured IPv6-Adressen
ACHTUNG: Diese Information ist noch nicht 100% bestätigt und reine Vermutung!
Secured IPv6-Adressen bleiben eindeutig für ein Interface in einem bestimmten Netzwerk.
Zum Beispiel erhält man immer die gleiche secured IPv6 Adresse im Netzwerk zuhause oder in der Firma damit dort z.B. eine spezielle Freigabe nur für diese IP erteilt werden kann.
Aktuell sieht man diese „secured“ IPv6-Adressen nur auf MacOS (Stand Juni 2019)
Was ist der Unterschied zwischen einem Client und einem Interface?
Als Client wird prinzipiell ein Computer definiert, der im Netzwerk vorhanden ist. Jedoch kann ein Client mehrere Netzwerk-Interfaces haben, um mit mehren unterschiedlichen Netzwerken gleichzeitig zu kommunizieren.
Kann ein Interface mehrere IP-Adressen haben?
Ja! Bei IPv6 ist dies ja schon „Standard“ da es ja eine „Link Local“ und eine „Globale“ Adresse gibt, jedoch können auch bei IPv4 einem Interface mehrere IP-Adressen zugewiesen werden.
Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen
Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.
