Archiv des Autors: dakira

Ubuntu 17.04: DNS mit dnsmasq statt systemd

Ab Ubuntu 17.04 übernimmt systemd-resolved die Auflösung von DNS-Anfragen. Manchmal möchte man ein bißchen mehr vom lokalen DNS-Server. Vielleicht möchte man zum Beispiel alle auf .dev endenden Domains auf lokale Verzeichnisse umleiten (siehe dazu hier). Hier kommt man mit systemd-resolved nicht mehr weiter.

In Vorgänger-Versionen von Ubuntu konnte man noch dnsmasq nutzen, meist im Zusammenspiel mit dem NetworkManager. Dies wird nun verhindert, bzw. die Konfiguration ist so komplex, dass ich die systemd-Komponente lieber deaktiviere. Dazu muss man sowohl systemd-resolved, wie auch dnsmasq stoppen und deaktivieren. Die dnsmasq-Funktionalität wird danach vom NetworkManager angeboten. Damit das klappt muss der auch wieder die /etc/resolv.conf stellen. Hier ein bißchen Copy-Pasta:

sudo systemctl stop systemd-resolved.service
sudo systemctl disable systemd-resolved.service
sudo systemctl stop dnsmasq.service
sudo systemctl disable dnsmasq.service
sudo mv /etc/resolv.conf{,.bak}
sudo ln -s /var/run/NetworkManager/resolv.conf /etc/resolv.conf
echo -e "[main]\ndns=dnsmasq\n" | sudo tee /etc/NetworkManager/conf.d/enable-dnsmasq.conf
sudo systemctl restart NetworkManager.service

Jetzt sollte man kurz prüfen, ob Domains weiterhin aufgelöst werden. Wenn ja, ist man wieder mit dem guten alten dnsmasq unterwegs. Nur der Vollständigkeit halber hier die Befehle, um das ganze wieder rückgängig zu machen.

sudo rm /etc/NetworkManager/conf.d/enable-dnsmasq.conf
sudo rm /etc/resolv.conf
sudo mv /etc/resolv.conf{.bak,}
sudo systemctl enable systemd-resolved.service
sudo systemctl start systemd-resolved.service
sudo systemctl enable dnsmasq.service
sudo systemctl start dnsmasq.service
sudo systemctl restart NetworkManager.service

Jetzt kann man sich für lokale Entwicklung von PHP-Projekten (Symfony, Drupal, WordPress, Laravel, Magento, u.v.m) sehr einfach Laravel Valet installieren. Wie dies geht habe ich im folgenden Artikel beschrieben.

Gitea oder Gogs statt Github und Gitlab

Update 01/2018: Gogs ist mal wieder seit mehreren Montaten tot bzw. der alleinige Entwickler nicht erreichbar. Ich kann nur ausdrücklich dazu raten auf den Fork Gitea zu setzen.

Ich habe mir den Github-Klon Gogs und dessen Fork Gitea näher angeschaut und bin hellauf begeistert. Weiter unten erkläre ich noch, wie ich Gogs bzw. Gitea TLS-verschlüsselt hinter Nginx laufen lasse. Nun aber erst mal zu Gogs und warum ich es brauche.

Github ist über die Jahre zum defacto-Standard für Opensource-Entwicklung geworden. Das liegt zum einen an den Features, die Github bietet (Pull-Requests, Issues, Wiki). Die Popularität rührt aber auch daher, dass diese Features sehr einfach gehalten sind. Das Issue-Tracking ist extrem rudimentär, alles andere ist aber für viele Overkill. Github hat das Mitmachen einfach gemacht.

Es gibt allerdings auch Gründe, die gegen die Nutzung von Github sprechen. Github selbst ist z.B. keine Opensource Software. Möchte man auch private Repositories erstellen, braucht man ein kostenpflichtiges Konto. Das habe ich zwar, aber trotzdem möchte ich nicht zwangsläufig das Schicksal meines Codes einer Firma überlassen, über die ich keine Kontrolle habe. Dank der Dezentralität von Git schadet es auch nicht mehrgleisig zu fahren (z.B. Mirror auf Github für Pull-Requests und issues).

Die erste Alternative, die ich mir angeschaut habe, war Gitlab. Komplett open source, ähnliche Features wie Github und dazu noch eine integrierte Plattform für Continuous Integration. Nach einem halben Tag Installation und Konfiguration (alles eher komplex) hat sich gezeigt, dass meine Hardware nicht leistungsstark genug ist und ich einen extra Server für Gitlab bräuchte. Wo Web, Mail, Seafile (mit ~100 aktiven Usern), Minecraft und diverse andere Dinge klaglos parallel laufen, läuft Gitlab nicht mal allein flüssig. Wie das auf einem Raspberry Pi laufen soll ist mir schleierhaft.

Der nächste Kandidat war dann schon Gogs und es konnte sofort überzeugen. Auf den ersten Blick bietet Gogs die gleichen Features wie Github. Zum Teil nicht ganz so poliert, manchmal wirkt es aber auch schicker. Gogs ist in Go geschrieben (Gogs = Go Git Service) und so leichtgewichtig (~20MB RAM), dass es sogar auf einem Raspberry Pi ordentlich läuft.

Und Gitea?

Gogs wurde vor kurzem geforkt. Nachdem der zentrale Entwickler wiederholt für Monate nicht erreichbar war hatte die Community genug und hat Gitea erstellt. Die Entwicklung beim Fork läuft schneller und transparenter, als es bei Gogs je der Fall war. Meine Empfehlung lautet also, Gitea statt Gogs einzusetzen. An Features muss man im Vergleich zu Git kaum Abstriche machen. Hier mal eine kleine unvollständige Aufstellung:

  • interner Issue Tracker (extern möglich)
  • internes Wiki (ebenso extern möglich)
  • protected branches
  • Git hooks
  • webhooks
  • deploy keys
  • signierte Commits
  • Authentifizierung auch über LDAP, SMTP, OAuth2, OpenID und PAM
  • 2FA
  • Support für DroneCI und andere


Weiterlesen