Endlich ist es soweit. Eine neue Major Version von Composer, dem Paket Manager von PHP, ist erschienen.
Was ihr außer einer erheblichen Performance Verbesserung noch alles erwarten könnt, gibt es auf dem offiziellen Blog von Packagist nachzulesen.
Schlagwort: server
Let’s Encrypt zieht drei Millionen Zertifikate zurück
Der Anbieter für kostenlose SSL-Zertifikate Let’s Encrypt muss drei Millionen Zertifikate zurückziehen. Hintergrund ist ein Bug bei der Prüfung von CAA-Records, die nicht nach den vorgegebenen Regeln stattfand. Darum werden heute, am 4. März, etwa drei Millionen Zertifikate ungültig. Laut Let’s Encrypt entspricht dies etwa 2.6% der ausgestellten Zertifikaten.
Nutzer sollten daher umgehend ihre Zertifikate erneuern. Tatsächlich werden vermutlich weitaus weniger Webseiten davon betroffen sein.
Wir von Sitealarm haben alle Domains, bei denen die Zertifikatsprüfung aktiviert ist, bereits überprüft und alle Kunden entsprechend über die Plattformen informiert.
Wir hoffen das der Rückzug keine Webseiten unerreichbar macht und das Netz damit weiterhin sicher bleibt.
SSL Zertifikate mit Let’s Encrypt
Seit dem Frühjahr 2016 ist Let’s Encrypt aus der Beta Version raus. Viele Sponsoren haben ihre Verträge verlängert und durch eine einfache Implementierung findet es auch immer größer Verwendung.
Das Unternehmen hat sich zum Ziel gesetzt, das Web auf HTTPS umzustellen. Ungeschützte Seiten sollen dann Geschichte sein. Um das zu erreichen haben Sie bereits einen Meilenstein erreicht. Sie sind bereits eines der größten CA auf dem Markt. Zusammen mit den prominenten Sponsoren wie Google Chrome, Mozilla oder Ciso gilt Let’s Encrypt auch weiterhin als sehr vertrauenswürdig. Darum spricht hier auch nichts gegen den Produktiven Einsatz.
Let’s Encrypt. Kostenlos!
Was ich in den letzten Monaten auch beobachten konnte: Viele Hosting-Anbieter bieten zusätzlich zu den Standard Paketen noch einen kostenlosen Service um die SSL-Zertifikate von Let’s Encrypt anzubinden. Wenn man das so sieht wird klar, dass damit die Anzahl an unverschlüsselten Verbindungen tatsächlich abnehmen wird.
Doch warum muss man für andere Zertifikate etwas bezahlen? Nun das hat primär mit zwei Dingen zu tun. Zum einen wird Let’s Encrypt von einigen großen Sponsoren unterstützt. Somit rechnet sich das dann zumindest wieder finanziell. Zum anderen hat es dann doch noch etwas mit der Sicherheit zu tun. Es gibt mittlerweile Zertifikate (z.B. im Bankenumfeld) die eine hohe Verschlüsselung garantieren. Das diese dann nicht günstig oder gar kostenlos sind ist eigentlich klar. Doch auch Let’s Encrypt bietet ein hohes Maß an Verschlüsselung. Der Trend geht auf jeden Fall in die Richtung, das kostenlose Zertifikate angeboten werden. So gibt es diese z.B auch bei CloudFlare und StartSSL.
Ausblick
Für 2018 hat Let’s Encrypt bereits die lang ersehnten Wildcard Zertifikate angekündigt. Somit kann man für alle Subdomains noch einfacher die Zertifikate erstellen.
Ich selbst nutze mittlerweile nur noch die Zertifikate von CloudFlare da ich meine Domains schon darüber konfiguriert habe. Doch wer diese Möglichkeit nicht hat, für den ist Let’s Encrypt wirklich zu empfehlen.
In einem weiteren Beitrag werde ich zeigen, wie einfach die Implementierung zusammen mit der automatischen Verlängerung ist. Dies werde ich an einem Beispiel demonstrieren.
Ping: Zeitüberschreitung der Anforderung und Zielhost nicht erreichbar
Haben wir vermutlich alle schon einmal ausgeführt. Ping. Doch was ist Ping? Ping ist das Netzwerk Troubleshooting Tool Nummer 1. Ping sendet ICMP Pakete an ein IP fähiges Gerät. Meist in der Hoffnung, dass dieses Gerät auch antwortet. Aber was bedeutet „Zeitüberschreitung der Anforderung“ und wie unterscheidet es sich mit „Zielhost nicht erreichbar“?
Ich pinge einen Rechner in meinem Netzwerksegment.
Der Rechner antwortet auf das 32 Bytes große Paket in 50-55 ms und der TTL Wert ist 62 (Anzahl der max. Hops). Alles Ok soweit, das Gerät ist erreichbar.
ZEITÜBERSCHREITUNG DER ANFORDERUNG
So, jetzt wird es interessant: Ein Computer mit der IP 192.168.1.4 ist offensichtlich im Netzwerk nicht erreichbar. Meine IP ist 192.168.1.54/24. Die zu testende IP ist 192.168.1.4/24. Das bedeutet, dass sich beide Geräte im gleichen Subnetz und in der gleichen Broadcast Domäne befinden.
Was kann man nun daraus schließen? Viele gehen jetzt davon aus, dass das Gerät nicht erreichbar ist, sprich „kaputt“, ausgeschalten oder nicht mehr im Netzwerk ist.
Zeitüberschreitung der Anforderung im lokalen Subnetz bedeutet, dass das Gerät keine ICMP Pakete in einer gewissen Zeitspanne sendet. Sonst nichts. Es kann mithilfe dieser Information auf nichts anderes geschlossen werden, als auf die Tatsache, dass das Gerät nicht auf einen Ping antwortet.
Ich erkenne mit arp -a, dass die MAC Adresse mithilfe ARP ermittelt wurde. Das heißt zwar nicht zwangsläufig, dass der Computer online ist (ARP Cache), aber ich habe vorher mit arp -d den ARP Cache geleert.
Meist lässt die Windows Firewall ICMP eingehend nicht zu, d.h. das Gerät ist funktionsfähig. Hier die Ansicht in wf.msc:
Beim Aktivieren der IPv4 Regeln antwortet das Gerät.
ZIELHOST NICHT ERREICHBAR
Ich bekomme als Antwort auf einen Ping an einen Computer im lokalen Subnetz die Information: Zielhost nicht erreichbar.
Was kann ich daraus schließen? Hier sieht die Sache anders aus. Meist ist der Computer nicht online und auch der ARP Cache zeigt keine MAC Adresse des Zielcomputers. Das bedeutet, dass auch der ARP Request fehlgeschlagen ist. Es kann in den meisten Fällen davon ausgegangen werden, dass der Computer tatsächlich offline ist.
DigitalOcean: Server Deployment
Im Gegensatz zu anderen Anbietern hat sich DigitalOcean hauptsächlich auf das Deployment von virtuellen Cloud Server konzentriert. Da hier in den vergangenen Jahren ständig optimiert wurde, kann nun in wenigen Sekunden eine neue virtuelle Maschine aufgesetzt werden.
In der Web-Oberfläche muss man zunächst ein Image auswählen dass eine Distribution oder ein anderes Paket wie Node.js, MongoDB, LEMP oder Docker sein kann. Im Anschluss wählt man noch die gewünschte Server Größe. Da gibt es verschiedene Stufen die man auswählen kann. Diese steigen von 512MB RAM für 5$ auf bis zu 64GB RAM für 640$. Der verfügbare Speicher (SSD Disk) steigt auch entsprechend an. Wer mehr Speicherkapazität benötigt kann sich zusätzlich ein Block Storage anhängen. Diese sind aktuell aber nur in NYC1 und SFO2 verfügbar. Die Kosten betragen 0,10$ je GB.
Im Anschluss kann man optional noch den Hostnamen angeben. Außerdem kann man bis zu zehn virtuelle Maschinen gleichzeitig mit demselben Image erstellen. Mit diesen drei Schritten ist man wirklich echt schnell und kann so in kurzer Zeit eine virtuelle Maschine aufsetzen. Wenn man dies einige Male gemacht hat, dauert es bis zum Zugriff auf den Server nur ein bis zwei Minuten.
Ein weitere Vorteil von DigitalOcean ist die sehr übersichtliche API. Hier kann man dann über einen einzigen Befehl einen neuen Server, mit entsprechenden vorinstallierten Anwendungen und SSL-Zertifikaten erstellen. Somit benötigt man auch kein root-Passwort mehr.
Deployment
Doch für was kann man das nun nutzen? Man kann mit DigitalOcean in kurzer Zeit ein komplexes Netzwerk in verschiedenen Datenzentren aufbauen. Denkbar wäre auch das Aufsetzten von Hochverfügbarkeits-Systemen (HA für high availability) die durch die Möglichkeit der Skalierung schnell angepasst werden können. Durch das schnelle Aufsetzten und die Nutzung der API ist es aber auch für Entwickler Teams ein hoher Vorteil. So können einheitliche Server aufgesetzt werden oder im Handumdrehen Test-Server erstellt werden, die die Applikation bereits installiert haben. Wie man dies durch die API realisieren kann, werde ich in einem weiteren Beitrag berichten.