Seite 6 von 25

Updates KW29

In dieser Woche überwiegen leider die unfertigen Dinge. Im git sieht man den Wald vor lauter Branch-Bäumen nicht (okay, ich lege 50 Cent in die Kasse für schlechte Wortspiele). Aber mindestens zwei große Themenbereiche, in denen sich etwas getan hat, gibt es:

Verwaltung:

  • der Zugriff von API-Keys wird nicht mehr durch einzelne Berechtigungen, sondern durch Rollen geregelt. Diese Rollen sind üblicherweise „$resource.reader“, „$resource.editor“ und „$resource.admin“, wobei $resource für alle möglichen Ressourcen stehen kann („ftp_accounts“, „mailboxes“, „cloud_vps“, etc). Die Reader-Rolle kann, wie der Name schon sagt, nur lesen, Editoren können lesen und ändern, aber nicht erstellen oder löschen. Admins haben Vollzugriff. Der Vorteil ist, dass wir die Aktionen, welche eine Rolle ausführen darf, so flexibler definieren können.
  • die API-Key-Verwaltung wurde überarbeitet
  • für API-Keys wird nun der Zeitpunkt der letzten Verwendung gespeichert
  • die Hilfe wurde um einen Artikel mit Informationen zur API ergänzt, wenngleich der Artikel ohne Liste der API-Endpoints noch ziemlich unvollständig ist (hey, Swagger…!)
  • zxcvbn.js wurde in ein separates Javascript-File verschoben, das nur geladen wird, wenn ein Passwort-Input auf der Seite angezeigt wird. Vorher wurde es immer geladen, wenn ein Passwort-Input auf der Seite vorhanden war, egal ob es angezeigt wurde oder nicht.

Reseller-Verwaltung:

  • die Webseiten-Liste gibt nun auch die PHP-Version der Webseite zurück

Webhosting:

  • auf einem Teil der MySQL-Server ist seit heute das InnoDB-File-Format „Barracuda“ testweise aktiviert (MySQL-Dokumentation). Damit werden nun auch die „COMPRESSED“- und „DYNAMIC“-Zeilen-Formate für InnoDB unterstützt. Zudem ist die Option „large prefix“ nun aktiviert. Sofern der Test in den nächsten Tagen keine Probleme aufwirft rollen wir die Änderung auf alle MySQL-Server aus. Ein Beispiel für Software, welche diese Einstellungen benötigt, ist Moodle.

Nächste Woche wird die Liste wohl um einiges länger, da wie erwähnt eine ganze Reihe von Änderungen an der Verwaltung (Datenbanken, E-Mail-Verwaltung, Zahlungsmethoden, …) momentan auf Q&A und letzten Feinschliff warten, bevor sie online gehen können. Aber dazu nächste Woche mehr. Und bis dahin wünsche ich ein schönes Wochenende!

Updates KW28

Was für eine Woche! Unser Mitbewerber Domainfactory wurde gehackt, nachdem sie ihre DSGVO-Umsetzung versaut und Kundendaten in einen öffentlichen Feed geloggt haben. Da frage ich mich, wieso man überhaupt einen Kundendatensatz in einer Produktiv-Umgebung in einen Feed loggt. Sowas würde mir nicht einmal in den Sinn kommen. Das ist wirklich ein starkes Stück.

Aber im Gegensatz zur Domainfactory haben wir gute Neuigkeiten:

Verwaltung:

  • die PHP-Fehler-Logs sind nun in der Verwaltung verlinkt
  • Verbesserung: die API-Response für das PHP-Error-Log (/usercp/php_error_log.json) gibt die Uhrzeit des Log-Eintrags in ISO8601 aus
  • Verbesserung: in der Anzeige der PHP-Error-Logs werden „notices“ und „deprecation warning“ nun in einer besser lesbaren Farbe dargestellt
  • Verbesserung: Postleitzahlen müssen nun nur noch eine Ziffer enthalten, nicht mehr vollständig aus Ziffern bestehen (bspw. UK, Niederlande)
  • Verbesserung: für Umzüge von .es-Domains verlangt das System keinen AuthCode mehr
  • Verbesserung: bei Umzügen von Accounts zwischen Webhosting-Servern wird nun ein Live-Status angezeigt
  • Bugfix: bestimmte belegte Domains konnten nicht als Inklusiv-Domains in den Warenkorb gelegt werden, obwohl sie korrekt als Inklusiv-Domains ausgezeichnet waren

Reseller-Verwaltung (Agentur):

  • Single-Sign-In hinzugefügt (ohne Login in den Kunden-Account wechseln)
  • die Domain-Erinnerungen werden zusammengefasst in einer Liste versendet (nur für Domains, die direkt im Reseller-Account liegen)
  • White-Label-Mail-Server hinzugefügt: ssl-secured.email (Webmail, IMAPS, POPS, SMTPS)

Webhosting:

  • sind mehrere gültige SSL-Zertifkate vorhanden wird nun das zuletzt hinzugefügte verwendet

Wir haben noch einiges an Änderungen an unserem Admin-Interface und am Rechnungssystem vorgenommen und ein paar Kleinigkeiten verbessert oder behoben, die aber weniger interessant sind. Und wenn es Wünsche gibt, was hier demnächst stehen soll, nehmen wir per Support gerne Ideen, Verbesserungsvorschläge und Kritik entgegen! Und nun ein schönes Wochenende!

Updates KW27

Nach einer kurzen Pause – man kann auch im Sommer krank werden – habe ich heute endlich wieder Gelegenheit, aktuelle Neuigkeiten anzubringen:

Verwaltung:

  • Die WordPress-Verwaltung ist freigegeben. WordPress-Installationen lassen sich unter „Websites & Domains“ mit einem Klick auf „verwalten“ neben der WordPress-Versionsnummer verwalten.
  • Eine erste Version eines Log-Viewers für PHP-Error-Logs wurde hinzugefügt. Die Verlinkung auf der Fehlerseite und in der Verwaltung folgt, derzeit ist er nur für „Kenner“ erreichbar.
  • Bugfix: der Neukunden-Rabatt wurde bei der Anzeige „nächste Zahlung“ für Webhosting-Pakete in der Verwaltung nicht berücksichtigt (Danke für den Hinweis, Dirk!).

Reseller-Verwaltung (Bildungsträger):

  • Bugfix: beim Anlegen von Schüler-Accounts wurden diese nicht dem ausgewählten Kurs zugeordnet
  • Verbesserung: Kurse können nun, mit allen zugehörigen Accounts, gelöscht werden

Webhosting

  • Wir testen seit kurzem den Tideways-Profiler für Profiling von Kunden-Anwendungen im Rahmen von Support-Tickets – wer gerne wissen möchte, wo seine Anwendung lahmt, kann uns gerne ein Support-Ticket (support@lima-city.de) schreiben.
  • Verbesserung: das Backup- und Restore-System benutzt nun als Standard-Character-Set für MySQL-Backups „utf8mb4“

Natürlich gab es noch Dutzende weiterer Änderungen (u.a. verbesserte Aufräum-Scripte für alte Backups, Anpassungen an Load Balancer Queue Sizes, …), aber die sind weniger spannend. Nächste Woche geht es hier mit einer kleinen Tour durch das WordPress-Tool weiter. Bis dahin wünsche ich ein schönes Wochenende!

Updates

Diese Woche haben wir weniger „sichtbare“, aber dafür genauso wichtige Änderungen vorgenommen. Mit unserer wachsenden Zahl von Kunden und Bestellungen steigt leider auch die Anzahl der betrügerischen Bestellungen und Buchungen, sei es mit gestohlenen PayPal-Accounts, Kreditkarten oder Bankverbindungen. Wir haben alleine in den letzten 4 Wochen einen Anstieg von betrügerischen Kreditkartentransaktionen um 600% (nein, da ist keine Null zu viel) verzeichnet. Tatsächlich ist das Volumen an betrügerischen und geblockten Kreditkarten-Transaktionen um ein vielfaches größer als der reguläre Umsatz (was natürlich auch daran liegt, dass die Betrüger es mehrfach versuchen). Dementsprechend haben wir momentan eine Menge mit Risk Management zu tun, was naturgemäß eine Sache ist, bei der man schlecht detailliert über Maßnahmen sprechen kann. Aber kommen wir zu dem, über das wir sprechen können:

Als große, aber schon behandelte Änderung haben wir HTTP/2 eingeführt. Zudem gab es diverse kleine und große Änderungen:

Verwaltung:

  • Bugfix beim Hinzufügen von IDN-Domains in den Warenkorb, wenn die Unicode-Version verwendet wird
  • Bugfix/Change: nach dem Einrichten eines PayPal-Abos für Webhosting-Pakete hat PayPal die Weiterleitung zu uns geändert. Wir bekommen die Abo-ID nicht mehr übergeben und können daher auch keine sinnvollen Informationen mehr anzeigen. Thanks, PayPal!
  • Verbesserung bei der Zahlungsverarbeitung: in bestimmten Fällen wurden Rechnungen, für die SEPA-Lastschrift als Zahlungsmethode gewählt wurde, mit Guthaben verrechnet, obwohl das nicht gewünscht wurde
  • Verbesserung WordPress-Toolkit: Plugins, die aktiv sind, werden nun beim Löschen automatisch deaktiviert. Vorher war ein separates Deaktivieren vor dem Löschen notwendig
  • Verbesserung WordPress-Toolkit: die Konsolen-Ausgabe von Tasks (core update, theme/plugin update, activate, deactivate, uninstall, …) werden nun aufgezeichnet

Infrastruktur:

  • durch die höhere Request-Parallelisierung von HTTP/2 war es für Webseiten, die viele Ressourcen einbinden (z.B. >500 Bilder) einfach möglich, Besucher durch die Firewall komplett auszusperren (inkl. IP-Bann auf dem gesamten Web-Frontend). Entsprechende Limits wurden vorsorglich erhöht
  • Rate-Limiting von Web-Requests angepasst, so dass Anfragen, die wegen Überschreitungen mehrerer Limits abgelehnt werden, nicht mehr verzögert werden (die „Verzögerungstaktik“ einiger Limits erzeugt eine gleichmäßigere Auslastung in Burst-Situationen)
  • Bugfix für ein Problem, bei dem Clients beim Brute-Forcing von FTP-Logins nicht gesperrt wurden

Zudem wurde in der letzten Woche einiges an Grafik, Layout und Animationen (yeah, wir bekommen Animationen auf der Webseite!) vorangebracht. Außerdem gab es noch einiges an internen Änderungen an der Build-Pipeline für unseren Frontend-Code. Unsere aktuelle Frontend-Generation (die noch nicht überall im Einsatz ist, aber immer häufiger verwendet wird) basiert auf ES6 und React.js, das von Brunch und Babel gebaut wird. Cooles Zeug! Und nun: schönes Wochenende! 🙂

Neu: HTTP/2

HTTP/2 ist die Weiterentwicklung von HTTP, dem Web-Standard, der für die Kommunikation zwischen Browser und Server zuständig ist. Das HTTP-Protokoll wurde 1991 eingeführt und ist inzwischen etwas in die Jahre gekommen, denn das Web hat sich wesentlich verändert. Eine Webseite besteht nicht mehr aus einem, sondern aus sehr vielen Anfragen nach Bildern, CSS, Javascript, Videos uvm. Zudem wird Verschlüsselung als immer wichtiger erachtet, wobei HTTP gar keine Verschlüsselung spezifiziert, sondern dafür auf HTTPS verweist.

HTTP/2 hingegen beseitigt viele dieser Schwierigkeiten und bringt einige Features mit sich:

  • HTTP/2 hat eine Möglichkeit, den Verbindungstyp (HTTP 1.0, 1.1 oder 2.0) auszuhandeln
  • HTTP/2 baut nur eine einzelne Verbindung auf, auf der alle Kommunikation abgewickelt wird (Multiplexing)
  • es werden dank Multiplexing weniger Verbindungen benötigt
  • HTTP-Header werden komprimiert
  • der Server kann per „Push“ weitere Anfragen direkt an den Browser liefern, selbst wenn der Browser sie noch nicht angefragt hat (z.B. für Vorab-Laden)

Insgesamt hat HTTP/2 eine deutlich modernere Ausrichtung als das in die Jahre gekommene HTTP 1.0/1.1. Diese Vorteile wollen wir natürlich auch unseren Kunden verschaffen.

Deshalb haben wir in den letzten 48 Stunden für alle Webseiten auf lima-city HTTP/2 ausgerollt!

Die Webseiten für Besucher per HTTPS bereitzustellen ist letztendlich die Leistung, die wir für unsere Kunden erbringen. Die Änderung ist also ganz enorm in den Auswirkungen und dem Risiko, für unsere Kunden und für uns (wir garantieren unseren Kunden Verfügbarkeit – ein Problem beim Rollout hätte uns auch wirtschaftlich enorm schaden können). Ein weiterer Blog-Post darüber, wie und unter welchen Kriterien solche Entscheidungen getroffen werden und wie unser technischer Aufbau zusammen mit der Nutzung unserer eigenen Cloud uns ermöglicht, solche Änderungen gefahrlos zu testen folgt bald! 🙂

Update-Freitag

Es tut sich einiges bei lima-city, und damit das nicht alles hinter verschlossenen Türen passiert, gibt es mal wieder ein paar Update-Infos von uns. Vor einiger Zeit hatte ich schon damit begonnen, Freitags Update-Infos zu lima-city bereitzustellen und hatte das nach einiger Zeit erst einmal wieder gestoppt. Ich greife das nun wieder auf, vielleicht etwas unregelmäßiger, aber wir werden sehen. Hier die wichtigsten Änderungen aus dieser Woche nach Themen:

Verwaltung:

  • im Domain-Check ist die Registrierung und der Umzug von Premium-Domains hinzugefügt worden
  • es werden die Reports des CERT-Bund nun automatisch an unsere Kunden weitergeleitet
  • Bugfix SSL-Zertifikat-Verlängerung: ignoriert nun bekannt problematische Hostnamen
  • Bugfix SSL-Zertifikat-Verlängerung: das bestehende Zertifikat wurde gleichzeitig zur Ausstellung des neuen Zertifikats gelöscht, dadurch war in einigen Fällen für einige Sekunden (~30s) kein SSL-Zertifikat vorhanden. Die Schritte laufen nun nacheinander ab.
  • Bugfix WordPress-Toolkit: kann nun WordPress-Installationen verwalten, die „localhost“ als Datenbank-Hostnamen eingestellt haben
  • Bugfix Restore-System: die Restore-Liste zeigt keinen Fehler mehr an, wenn das Backup zu einem Restore gelöscht wurde
  • Bugfix/Verbesserung Restore-System: entferne Datenbank-Backups aus der Liste, die Verwirrung stiften können
  • Verbesserung ADV-Vertrag: nach Vertragsschluss wird das PDF per E-Mail verschickt

Webhosting:

  • Update auf Apache 2.4.29 (Premium-Webspace)
  • Monitoring verbessert für Fälle, in denen Apache-Prozesse nicht korrekt beendet werden können und „hängen“ (z.B. unendliches warten auf einen Socket nach einem Segfault von PHP-FPM)
  • Filter für ausgehenden Traffic an Command & Control-Server der Malware „Citadel“
  • Updates an der Build-Infrastuktur zum automatischen Bauen von PHP-Paketen nach einem Release auf php.net

Wir arbeiten noch immer an dem neuen WordPress-Toolkit, das sich in großen Schritten der Fertigstellung nähert. Es sind noch zwei Punkte offen, die wir vor einem Release an alle Kunden beheben müssen und zwei weitere Verbesserungsmöglichkeiten würden wir auch noch gerne umsetzen.

Bis dahin wünschen wir ein schönes Wochenende bei dem schönen Wetter!

EU-DSGVO: Vertrag zur Auftragsdatenverarbeitung jetzt abschließen!

Noch eine Woche, dann ist Weihnachten…. erm, EU-DSGVO! Aktuell ein großes Thema, täglich bekommt man E-Mails dazu, und da dürfen wir nicht fehlen. Wir müssen unsere Kunden in diesem Fall als Auftragsdatenverarbeiter unterstützen, um ihre Webseite für die EU-DSGVO vorzubereiten. Dazu ist ein Vertrag zur Auftragsdatenverarbeitung notwendig! Aber der Reihe nach:

Viele Kunden fragen uns: was ist der Vertrag zur Auftragsdatenverarbeitung, und in welchen Fällen brauche ich ihn? Der ADV-Vertrag regelt, wie lima-city personenbezogene Daten, mit denen wir im Rahmen von Webhosting, Cloud-VPS oder E-Mail in Kontakt kommen, verarbeitet. Dieser Vertrag ist immer dann notwendig, wenn ein Kunde bei uns personenbezogene Daten verarbeitet. Verarbeiten bedeutet dabei alles, was irgendwie mit personenbezogenen Daten zu tun hat: speichern, übertragen, verändern, zusammenführen, etc. Auf dem Webspace ist ein klassischer Fall das Kontaktformular (der Absender gibt Name und E-Mail-Adresse an). Aber schon der Einsatz einer Firewall – was wir natürlich tun, sonst könnten wir u.a. nicht die Vorgaben der EU-DSGVO einhalten – beinhaltet die Nutzung von personenbezogenen Daten: die IP-Adresse wird dabei mit einer Liste von IP-Adressen, die gesperrt sind, abgeglichen – und schon ist die IP-Adresse „genutzt“ und damit werden personenbezogene Daten verarbeitet. Ein modernes Datenverarbeitungssystem mit einer Schnittstelle wie HTTP/HTTPS muss zwingend personenbezogene Daten verarbeiten, ansonsten kann es nicht sicher gestaltet werden. Die Katze beißt sich da in den Schwanz: wer ein sicheres Datenverarbeitungssystem betreiben will, muss dafür personenbezogene Daten (=IP-Adressen) verarbeiten und muss die dann wieder angemessen schützen – wozu wiederum die Verarbeitung personenbezogener Daten notwendig ist. Bei E-Mail-Postfächern ist es ebenfalls unmöglich, keine personenbezogenen Daten zu verarbeiten. Wann immer man eine E-Mail von einem „menschlichen Absender“ empfängt, sind darin personenbezogene Daten enthalten, in der Signatur, der Name des Absenders selbst ist personenbezogen, die E-Mail-Adresse häufig ebenfalls, etc.

Zusammengefasst: Wenn man ein E-Mail-Postfach auf unseren E-Mail-Servern benutzt oder eine Webseite bei uns hosted oder Cloud-VPS betreibt, dann ist dieser Vertrag notwendig. Ein häufiges Missverständnis ist übrigens, dass das neu ist: tatsächlich ist dieser Vertrag seit der Neufassung vom Bundesdatenschutzgesetz von 1990 – also mittlerweile 28 Jahre – notwendig, aber jetzt wird es plötzlich ernst genommen.

Wie schließe ich den Vertrag ab? Der Vertrag zur Auftragsdatenverarbeitung lässt sich ganz einfach in der Verwaltung unter dem Menüpunkt „ADV-Vertrag“ ausfüllen und abschließen. Dazu muss angegeben werden, welche Daten-Typen und zu welchem Zweck (Vertragsdaten, Personenstammdaten, Daten zur Lohnabrechnung, etc.) über welche Betroffenen (Kunden, Mitarbeiter, etc.) gespeichert werden. Für unsere Kunden mit kostenpflichtigen Webhosting-Paketen (Premium-Paket, Mini, Starter, Business, Excellence) ist es kostenlos möglich, bis zu 5 Verträge je Account anzulegen.

Bei dem kostenlosen Webspace müssen wir zur Refinanzierung von Aufwand und Verpflichtungen, die uns aus den Verträgen entsteht, eine Gebühr berechnen. Derzeit berechnen wir 10 € (inkl. USt) pro Jahr für den Abschluss eines Vertrags zur Auftragsdatenverarbeitung für Kunden mit kostenlosem Webspace. Eine einmalige Gebühr haben wir verworfen, da die Verpflichtungen aus dem Vertrag über Jahre laufen können, und zum anderen unsere Kunden keinen Anreiz hätten, ihre Verträge und Auftragsdatenverarbeitung regelmäßig zu prüfen. In einem Jahr (Juni 2019) werden wir dann prüfen, wie sich die Kosten für die ADV-Verträge für den kostenlosen Webspace entwickeln und entscheiden, ob wir die Gebühr nach unten oder oben anpassen müssen oder vielleicht sogar auf sie verzichten können. Kunden mit kostenlosem Webspace, die einen solchen Vertrag schließen möchten, wenden sich bitte per Mail an den Support.

Die Umsetzung der EU-DSGVO ist keine einmalige Sache, die nach dem 25.5.2018 abgeschlossen ist, sondern es sollen Prozesse, Systeme und Regelungen schaffen, die den Datenschutz dauerhaft garantieren und laufend optimiert und angepasst werden. Dementsprechend ist eine regelmäßige Prüfung der Verträge im Sinne aller.

Wenn noch Fragen offen sind: die Kommentarfunktion ist geöffnet und wie immer freut sich der Support über E-Mail 🙂 – Und nun ein schönes, verlängertes Wochenende!

Update: die Einschätzung zur Verarbeitung personenbezogener Daten bei Webhosting wurde korrigiert.

Updates: SSH und WordPress-Staging & -Toolkit

Diese Woche haben wir endlich das langersehnte SSH für alle Kunden ausgerollt. Über die Woche verteilt haben wir für einen immer größeren Prozentsatz der Kunden das Feature freigeschaltet, bis heute endlich die Freigabe für alle Kunden erfolgte. Im Gegensatz zu vielen anderen Hostern verwenden wir bei SSH keine komplizierten und nervigen Chroots, sondern sorgen mit AppArmor und Seccomp für die nötige Trennung zwischen Accounts, so dass Kunden nichts falsch machen *können*. Nebenbei fiel eine nützliche Idee für ein sehr interessantes Sicherheitskonzept für die Webseiten (=nie mehr ein gehacktes WordPress!) dabei heraus, an der wir forschen.

Nach dem Erreichen dieses Meilensteins kündigen wir direkt das nächste Feature an: wir arbeiten bereits seit einiger Zeit an einem WordPress-Toolkit, bestehend aus einem Menü für die Verwaltung von Plugins, Themes, Sprachpaketen und Updates über die lima-city Verwaltung, ohne dass das WordPress angefasst werden muss. Zudem haben wir ein wunderbar funktionierendes WordPress-Staging mit optionalem One-Click-Update gebaut.

WordPress-Staging ist bisher nicht so häufig anzutreffen, dass jeder gleich weiß, was damit gemeint ist: Staging-Systeme sind Kopien von Live-Systemen, die zum Testen und Prüfen gedacht sind. Das WordPress-Staging ermöglicht es auf einer Kopie der WordPress-Installation, gefahrlos Änderungen (Updates, Plugin-Installationen, größere Änderungen, Theme-Wechsel, Konfigurationsanpassungen etc.) am WordPress vorzunehmen ohne dass die Live-Seite sich während der „Wartungsarbeiten“ ändert, oder eine Wartungsseite angezeigt werden muss. Dafür gibt es eine Extra-Webseite (z.B. staging.meinblog.de für ein WordPress auf meinblog.de), damit man auch mit mehreren Leuten ausprobieren, testen und ändern kann. Wenn alles einwandfrei funktioniert wird die Live-Seite mit der Staging-Kopie überschrieben. Zudem kann die Staging-Kopie einfach wieder gelöscht werden, wenn etwas schief gegangen ist. Oder vielleicht möchte man einfach nur mal etwas testen, ohne dass es später live gehen soll – auch das ist kein Problem.

Integriert ist das optionale und absolut risikofreie „One Click Update“. Jeder kennt sicher die Situation, dass man etwas „kaputt-updated“, nach dem Update geht gar nichts mehr. Das passiert mit dem Staging-Tool nie wieder: beim Anlegen der Kopie kann wenn gewünscht direkt die gesamte Installation mit Plugins, Updates und Themes aktualisiert werden. Ein Klick in der Verwaltung genügt also, um eine Kopie der WordPress-Installation auf einer neuen Webseite zu erstellen und diese zu updaten. Dann kann in Ruhe auf der Kopie getestet werden, ob alles funktioniert, und wenn das der Fall ist, lässt sich das Update mit einem Klick in der Verwaltung live schalten. Wenn nicht: dann geht’s ab in die Mülltonne damit.

Wir werden das neue Tool (das schon bei einigen Kunden im Testbetrieb ist) nächste Woche noch optisch überarbeiten und dann live schalten, man darf also gespannt sein! Bis dahin ein schönes Wochenende, und nichts am WordPress kaputt machen 😉

Neu: Hosted Memcached Beta

Bei der Migration eines Kunden auf unsere Plattform haben wir vor kurzem ein kleines Nebenprojekt umgesetzt: Hosted Memcached.

Memcached ist der Klassiker unter den Cache-Servern. Da Anfragen in PHP isoliert sind (der PHP-Prozess vergisst alle Daten, wenn er den Request bearbeitet hat), können Daten, die man über mehrere Anfragen hinweg benötigt wie Sessions, Datenbank-Daten, Daten von APIs, etc. nicht mehrfach verwendet werden. Hier setzt Memcached an und bietet einen dauerhaft laufenden Server-Prozess, mit dem PHP kommunizieren kann und darin Daten in Text- oder Binärform ablegen und wieder abrufen kann. Üblicherweise werden in Memcache Sessions und Datenbank-Abfragen zwischengespeichert. Beim Ablegen von Daten gibt man gleichzeitig an, wie lange Memcached die Daten behalten soll (z.B. 5 Minuten), um immer „frische“ Daten zu erhalten. Bekannte Nutzer von Memcached mit riesigen Installationen sind Wikipedia oder Facebook.

Memcached funktioniert mit diversen PHP-Softwares und verbessert die Leistung: ownCloud, nextCloud, Magento, Shopware, Contao, Joomla, Woltlab Burning Board, Drupal.

Wir bieten unseren Kunden mit Paket „Business“ und aufwärts ab sofort zum Testen einen gehosteten, privaten Memcached-Server mit 128 MB Kapazität kostenlos an. Die Kapazität lässt sich selbstverständlich erhöhen, für viele Anwendungsfälle reicht ein kleiner Cache allerdings aus. Der Memcached-Server wird ausschließlich von einem Kunden genutzt und nicht geteilt.

Interessiert an einer Aktivierung von Memcache? Fragen? Frag uns!

Transaktionsbestätigung

Da kommt die Post und ich wundere mich über einen A4-Umschlag, der offensichtlich von einem Kunden kommt. Was mag darin wohl sein? Dokumente für einen Domain-Umzug? Ein unterschriebener Vertrag?

Nein! Es ist ein Ausdruck einer PayPal-Transaktionsbestätigung. Vom 18.8.2016.

Es bleibt ein großes Fragezeichen. Man muss nicht alles verstehen.

« Ältere Beiträge Neuere Beiträge »

© 2025 lima-city Blog

Theme von Anders NorénHoch ↑