Der Blog von jemanden der gegen das Web kämpft.
Today I had struggle with using composer in a new docker-environment. For example while trying to install symfony, i received this error:
[Composer\Downloader\TransportException]
The "http://repo.packagist.org/p/provider-2019-07%2464c3c0374a0541958602c66c4b7654eafc0a265b180945a3fef255312d1890f8.json" file could not be downloaded: failed to open stream: HTTP request failed
A little confused I started the diagnose:
composer diag
An key-error showed up:
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys: FAIL
Missing pubkey for tags verification
Missing pubkey for dev verification
Run composer self-update --update-keys to set them up
Checking composer version: OK
Composer version: 1.9.3
PHP version: 7.3.14
PHP binary path: /usr/bin/php7.3
After adding the keys with composer self-update --update-keys the command failed again. Next step was to use the -vvv flag in the command to change the verbose output (to get more details). Still same unexpected result and the only helpful information was the error like above (http failed). Next I checked the url with wget and had to recognise, that the http-request failed, but a https-request succeed. So I performed the following command:
composer config --global repos.packagist composer https://packagist.org
I don't have a clue where the change came from. But right now, I'm happy because it cost a few hours.
Über die Suche nach einer guten Groupware-Lösung landete ich bei Servercow
Vor einigen Wochen musste ich nach einer Lösung für das Problem eines Kunden suchen: Das Setup ist nicht mit der Website gewachsen, was am Ende zu Rankingverlusten führte. Sehr ärgerlich. Aber woran lag es? In erster Linie lag das Problem an der Performance des gewählten Webhostings. Dabei ist es egal welchen Webhoster ich meine. An einem Umzug gab es kein Vorbei. Was aber mit dem Mailhosting machen? Ich selber habe mich bisher immer seht stiefmütterlich mit Mailhosting beschäftigt. Nun war ich gezwungen mir einige Gedanken zu machen.
Gitea im docker Container mit PgSQL als DB und Nginx/Lets Encrypt als Frontend einsetzen
Nicht erst seit der Github-Übernahme durch Microsoft nutze ich einen privaten Server, um private Repositories und einige Kundenprojekte zu hosten. Schon länger habe ich dafür eine Gitea-Instanz im Einsatz. Wer nämlich nicht zu den großen Anbietern GitHub, Bitbucket oder GitLab möchte, hat die Möglichkeit einen eigenen Server zu betreiben.
In diesem Blogbeitrag möchte ich eine kurze Einführung in die Thematik des Git-Hostings geben, bevor ich das Setup von Gitea in einem docker-Container beschreibe.
Sehr bekannt und beliebt ist, ohne jeden Zweifel, GitLab. Fast schon eine Art Pionier in diesem Bereich, war GitLab Vorbild für einige Features der Folgeprojekte. Neben GitLab gibt es aber heute auch noch GitBucket (Server), Gogs und Gitea.
Leseempfehlung zum Thema Mailserver und Anti-Spam
Ich möchte heute auf den Artikel von Thomas Leister hinweisen: Mailserver mit Dovecot, Postfix, MySQL und Rspamd unter Debian 9 Stretch. Ein toller Einstieg in die aktuelle Konfiguration eines Mailservers. Da ich selber vor kurzem meinen Mailserver zu Rspamd migriert habe, hier Rspamd direkt in das Setup aufgenommen wurde, kann ich jedem die Anleitung bzw. Rspamd empfehlen.
Beim tollen Heinlein Support gibt es für Rspamd eine tolle Einführung. Noch immer gibt es keinen englischen oder deutschen Wikipedia-Artikel zum Thema (lediglich einen französischen). Umso attraktiver ist die Dokumentation von Rspamd.
Mit dem Golden-Cage-Pattern sperre ich Trolls aus und schütze meine Nutzer
Es wird sicher so einige Plattformbetreiber geben, die ein Problem mit gewissen Nutzern haben. Nutzer die andere Nutzer beschimpfen, den Ablauf stören oder möglichst viel Schaden verursachen möchten. In den meisten Fällen wird, wenn die Betreiber vom Verhalten erfahren, der Nutzer gesperrt. D.h. der Login ist nicht mehr möglich oder die Portalfunktionen stehen nicht mehr zur Verfügung. Die Absicht hinter einem solchen Vorgehen: Die so indentifizierten unliebsamen Nutzer sollen die Konsequenzen spüren und so auf den "richtigen Weg" gebracht werden. Aber was passiert dann? Die Nutzer erstellen sich einen neuen Account und die Probleme beginnen von vorne. Löschen der Zugänge oder deaktivieren gewisser Funktionen ist kein nachhaltiges Instrument die eigene Community zu schützen.
In diesem Post geht es um das Golden-Cage-Pattern, dass hilft die "bösen Nutzer" besser in den Griff zu bekommen.
Bludit ist eine tolle Alternative zu Wordpress!
Vor vielen Jahren war Wordpress toll. Es war eine schlanke, in PHP-geschriebene, Software, dessen Weiterentwicklung stark durch die Community geprägt wurde. Wordpress wurde zu einer Zeit auf den Markt gebracht, in welche die Entwicklung mit PHP nur selten gewissen Paradigmen folgte. Das Pattern der Wahl war damals "dirty". Zumindest aus heutiger Sicht.
Die Nutzer-orientierte Entwicklung führte dazu, dass Wordpress heute sehr viel kann. Vom schlanken (und fixen) Script ist nicht mehr viel erhalten geblieben. Auch wenn die Entwicklung sich langsam in eine bessere Richtung gewandt hat, ist für mich Wordpress heute (2018) noch immer nicht wieder das Script der Stunde, wenn es um die Realisierung von kleinen Seiten, Single-Pages oder Portfolio-Seiten geht.