Composer\Downloader\TransportException - Failed to open stream: HTTP request failed

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.

Günstige durchdachte Groupware-Lösung 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 docker-Container unter Ubuntu 18.04 mit Nginx und Lets Encrypt

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.

Überall Anbieter: Welche Software für privates Git-Hosting?

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: Mailserver mit Dovecot, Postfix, MySQL und Rspamd unter Debian 9 Stretch

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.

Das Golden-Cage-Pattern: Die Alternative zum Löschen und Deaktivieren.

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.