NETWAYS Web Services: GitLab CE Hosting

This entry is part of 5 in the series NETWAYS Web Services

GitLab CE HostingGitLab CE (Community Edition) ist die frei verfügbare Variante von GitLab, welche alle wichtigen Features von GitLab in einer Open Source Version vereint. GitLab bietet eine webbasierte Oberfläche für Softwareprojekte auf Basis der Versionsverwaltung git. Dazu verfügt GitLab über diverse Management und Bug-Tracking-Funktionalitäten, sowie mit GitLab CI ein System zur kontinuierlichen Integration.

NETWAYS bietet das Hosting von GitLab CE in unserer NETWAYS Web Services an. Wir übernehmen hier nicht nur die Installation und Konfiguration, sondern auch den kompletten Betrieb inkl. regelmäßiger Updates auf die aktuellste Version. Unser Angebot wird verteilt über zwei Rechenzentren in Nürnberg gehostet und betrieben. Somit stellen wir einen sicheren und zuverlässigen Service an einem (sehr schönen) Standort in Deutschland zur Verfügung.

GitLab CE

Alle GitLab CE Instanzen laufen isoliert in einem eigenen Container und alle nötigen Ressourcen sind exklusiv für Ihr Projekt reserviert. Und bei uns sind die GitLab Runner schon mit dabei!

Und wie gewohnt bei NWS – Sie können GitLab CE bei uns 30 Tage kostenfrei testen. Jetzt schnell anmelden!

 

Martin Krodel

Autor: Martin Krodel

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Contributing to projects on GitHub

GitHub Logo

Today I want to share my workflow for contributing to projects hosted on GitHub because I believe it works very well for me and I regularly contribute to various projects. Of course most of this also applies to other hosted Git platforms like GitLab. It will not involve any Git magic as there are other posts to do that. So let’s use adding a check command to Icinga 2 as my example.

The obvious first step is finding the Git repository for the project and reading contribution guidelines because there are some projects which aren’t hosted on GitHub and some have additional requirements like submitting an issue in addition to a pull request. You should always familiarize yourself with and stick to those policies if you want your pull request to be accepted. For Icinga 2 there currently aren’t any additional project-specific guidelines.

Your next step is to create a fork on GitHub and clone the repository. So in the GitHub web interface click on “Fork” and select your own account (or company account as long as you are allowed to push). Once you’ve forked the repository you can check out a local copy using the following command:


git clone git@github.com/dgoetz/icinga2.git

Afterwards you should add another “remote” for the original Git repository in order to be able to update your own repository with changes from the upstream project:


cd icinga2/
git remote add upstream git@github.com:icinga/icinga2.git

After these initial steps you can create a Git branch for your feature or bug fix. Using the “master” branch for pull requests is strongly discouraged because things tend to get complicated once you have more than one pull request. Another recommendation is to use branch names that match the upstream repository’s style. This however is not a hard requirement:


git checkout -b feature/expand-check-foo

This also automatically switches to the newly-created branch which means you can now start to edit files for your pull request. Once you’re done you can add them to the Git index and create a commit. Typically upstream projects have guidelines for this, so do not forget to include documentation, make only one commit out of your work (perhaps by squashing) and so on.


vi itl/plugins-contrib.d/network-components.conf
vi doc/10-icinga-template-library.md
git add itl/plugins-contrib.d/network-components.conf doc/10-icinga-template-library.md
git commit -m "ITL: expanded check foo"

Afterwards push your commit to your forked repository and then create your pull request using the GitHub webinterface:


git push -u origin feature/expand-check-foo

When creating the pull request make sure to provide a detailed description of your changes and the reason why you feel that your pull request should be merged. Keep the setting checked to allow edits from maintainers. Depending on the project make sure to reference any related issues, fill in their pull request template or do whatever else they require for pull requests.

GitHub pull request

Typically once a pull request is created automated tests will be run and a review process by the project team will start, so it’s possible that you’ll be asked to make changes before your pull request is accepted. If this happens simply edit your branch to fix whatever problems were found during the review, amend your commit and force push it to your fork. This will also automatically update your pull request but you might want to provide a comment for the pull request as to what has changed:


vi doc/10-icinga-template-library.md
git add doc/10-icinga-template-library.md
git commit --amend -m "ITL: expanded check foo"
git push -f

Another commonly requested change is that you rebase your branch before the pull request is accepted. This usually happens when significant changes were made to the upstream repository while your pull request was waiting to be merged. In order to rebase your branch the following commands should be all you need, however in some cases you may also have to manually resolve conflicts:


git pull --rebase upstream master
git push -f

And of course you will sometimes want to create additional pull requests. For these make sure to start with a new branch based on the upstream repository:


git checkout master
git pull upstream master
git checkout -b fix/check-bar
...
git push -u origin fix/check-bar

So, this is it, this is my basic workflow for easy contributions on GitHub. I hope it helps you to get involved with your favorite projects and your fixes and features to get upstream. If you prefer to do all step in the command line, you can have a look at GitHub’s command-line wrapper for git hub. If you need more general Git knowledge I recommend the Git book and our training. If you need a GitLab system to play around, have a look at our NWS platform.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.

kostenfreie TLS-Zertifikate mit Let’s Encrypt

Let’s Encrypt hat seit gut einem Jahr die Testphase verlassen und verteilt fleißig Zertifikate – kostenfrei versteht sich. Wo anfangs in der Testphase “nur” wenige Millionen Zertifikate ausgegeben wurden, ist diese Zahl inzwischen kräftig gewachsen – Tendenz steigend. WordPress und andere Dienste setzen Let’s Encrypt in breitem Maße ein um das Internet ein bisschen besser (sicherer) zu machen.

Neben der reinen Absicherung der Verbindung hilft ein Zertifikat noch beim Ranking und dem lästigen Wegklicken von Sicherheitswarnungen bei selbstsignierten Zertifikaten, beispielsweise bei Testumgebungen. Chrome bemängelt seit der Version 39 auch die Sicherheit von normalen HTTP-Verbindungen und kennzeichnet diese als “nicht sicher”.

Die Zertifikate von Let’s Encrypt sind nicht besser oder schlechter als andere Zertifikate – nur kosten sie nichts und sind nicht so lange gültig – durch Automatismen zur Erneuerung eher ein Vorteil als ein Nachteil. Bei Let’s Encrypt gibt es keine Wildcard- oder EV-Zertifikate, wenn der Wunsch nach diesen besteht, greift man lieber zu kommerziellen Produkten. Auch wenn die Validierung mehr Sicherheiten bringen soll, als eine Domain-Validierung (hier wird ein Hash in einem vhost hinterlegt und von Let’s Encrypt geprüft), wird einem ein kommerzielles Produkt nahe gelegt.

Also eignen sich die Zertifikate für folgende Anwendungsfälle: Basisabsicherung von Diensten, wo sonst keine Verschlüsselung unbedingt notwendig wäre (z. B. WordPress-Blog), Absicherung von Staging-Systemen, Absicherung als kostenfreie Zugabe des Hosters, Absicherung von internen Diensten und zur Absicherung von privaten Websiten.

Aber wie kommt man nun zu den Zertifikaten?

Hier gibt es verschiedene Wege, allerdings gehe ich nur kurz auf die Command-Line basierte Beantragung ein. Dafür wird von Let’s Encrypt selbst der Certbot empfohlen, der bringt alles mit.

Nach dem Download / der Installation des Certbots (hier kommt es auf die Distribution an) kann dieser mittels dem einfachen Aufrufs

./certbot-auto

starten. Jetzt werden die weiteren Abhängigkeiten noch aus dem jeweiligen Paketmanager nachinstalliert. Ein Wizard startet und fragt welche Domains abgesichert werden sollen und ob ein automatischer (sicherer) redirect von HTTP auf HTTPS erfolgen soll (Hierzu werden Rewrite-Rules in der VHost-Config angelegt). Der Rest geht von alleine, eine CSR wird erstellt, ein vhost für die Domain-Validierung wird angelegt, es wird von extern gecheckt, ob der String im vhost erreichbar ist, Zertifikat wird ausgeteilt und gleich eingerichtet.

Achtung, nachdem der Wizard angestoßen wurde, wird mehrfach der Webserver neugestartet und Configfiles verändert. Für eine alternative Beantragung mit mehr Eigenverantwortung bitte die Hinweise zu certonly und webroot lesen.

Zertifikat nur 90 Tage gültig – was tun?

Die TLS-Zertifikate von Let’s Encrypt sind nur 90 Tage gültig. Die Beweggründe hierfür sind unterschiedlich. Aber aus meiner Sicht ist dies ein wesentlicher Sicherheitsvorteil. Damit es zu keinen Zertifikatsfehlern kommt, heißt es hier im richtigen Moment die Erneuerung der Zertifikate anzustoßen. Denn ein neues Zertifikat bekommt man erst kurz vor Ablauf des alten Zertifikates. An dieser Stelle komme ich an die vormals angesprochenen Automatismen zurück. So reicht es eigentlich täglich 1-2x einen Cron laufen zu lassen:

./certbot-auto renew

Durch dieses Kommando schaut der Certbot beim jeweiligen Lauf des Crons, ob das Zertifikat in Kürze abläuft. Wenn ja, wird ein neues Zertifikat beantragt und hinterlegt, wenn nicht meldet sich der Certbot nur mit einer kurzen Meldung im Log:

INFO:certbot.renewal:Cert not yet due for renewal

Auch hier sicherheitshalber nochmal der Hinweis, dass alle Abhängigkeiten beim renew aktualisiert werden (zu vermeiden mit dem –no-self-upgrade Flag). Desweiteren wird auch wieder ein vhost angelegt und der Webserver-Dienst durchgestartet.

Auch unsere Kunden mit komplexen Setups hinter Loadbalancern und HA-Clustern können von Let’s Encrypt profitieren – wir bauen hierzu die passende Lösung.

Freuen wir uns auf die nächsten Jahre, der wichtigste Schritt wurde bereits gemacht. Wer bei uns Kunde ist, kann schon heute von diesem tollen Service profitieren.

Georg Mimietz

Autor: Georg Mimietz

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Der Icinga Buildserver, Version 3

Letztes verbliebene Bild des alten Icinga Jenkins

Der Icinga-Buildserver, erreichbar unter https://build.icinga.com, läuft in dieser Form jetzt etwa ein Jahr. Doch gibt es noch immer ein paar Probleme die mit diesem Setup bestehen: So ist das Hinzufügen neuer Jobs noch etwas umständlich, das provisionieren dauert länger als uns lieb ist und besonders übersichtlich ist die Konfiguration auch nicht. Um diese Probleme anzugehen haben wir uns noch einmal mit Puppet und Jenkins auseinandergesetzt.

Wie vorher verwenden wir ein jenkins puppet-modul, nur diesmal haben wir es mit einem speziellen icinga-jenkins Modul erweitert. Dieses Modul erlaubt es uns spezielle pipeline-jobs mit geringem Konfigurationsaufwand zu erstellen. So ist das unterstehende Beispiel alles was zu konfigurieren ist um eine komplette Pipeline zu erstellen. Selbst der spezielle Umgang mir RPM und Deb ist zu großen Teilen vereinheitlicht und funktioniert für alle Projekte gleich.

icinga_build::pipeline:
  icinga2-snapshot:
    control_repo: https://github.com/Icinga/icinga-packaging.git
    control_branch: snapshot
    matrix_deb:
      'debian-jessie': {}

Die Pipeline erstellt dabei nicht nur einen, sondern gleich vier Jobs: “source”, “binary”, “test” und “publish”. Diese verarbeiten die specfiles, bauen das Paket, testen es und veröffentlichen es auf https://packages.icinga.com

In Produktion ist unser Modul noch nicht, aber um den testen und konfigurieren zu können haben wir Vagrant Boxen gebaut. Mit Hilfe derer bauen wir zur Zeit das icinga-jenkins Modul weiter aus um den bestehenden Buildserver komplett mit den neuen Pipelinejobs abbilden zu können. Wir hoffen unseren Buildprozess damit noch einfacher für Entwickler zu machen und dank der neuen Testsphase für Pakete Problemen in Zukunft besser vorzubeugen zu können

Jean-Marcel Flach

Autor: Jean-Marcel Flach

Auch wenn man Anderes vermuten möchte: Jean ist nicht unser französischer Austauschazubi, sondern waschechter Bamberger. Die Uni war ihm zu langweilig, deshalb knöpft er sich nun im Development gleich die kniffligsten Aufgaben vor.

Authentication with OAuth

It’s pretty safe to say, that everyone using the web has already made an account for some website. For the broad masses the most common ones would be social media sites like facebook, youtube and twitter. Then there are also online shopping platforms like e-bay and amazon, and more techie orientated pages like stack overflow and all sorts of version control repositories.
(And of course various others for anything and everything else…)

Third party applications often allow you to sign in with your account from another website.

The good thing is, that you don’t need to create a separate account for every single one, but are offered the possibility to just sign in with an account you created for a different service.

The page for which you want to use a different account needs to request data from the original website and use it to authenticate the user (without their input).
In order to give both the requesting website and the user assurance that the data will be safe and reliable some sort of standardisation is required.

Most commonly used is the open standard for authorisation OAuth.
With OAuth it is possible for users to grant access to their information from a certain website without giving away their credentials.

This is what it looks like when the user reviews the permissions.

In order for the third party application to obtain specific information about a user, it has to request an access token from the authorisation server, and when the user grants the permission, use that token to access the resources from the website.

In our specific case we want users to be able to log in to Icinga Exchange with their GitHub accounts.

If you now also want to integrate GitHub on your website and/or see how it’s done: they have a detailed tutorial here.

Jennifer Mourek

Autor: Jennifer Mourek

Jennifer hat sich nach Ihrem Abitur erst einmal die große weite Welt angesehen, ehe es sie für Ihre Ausbildung zur Fachinformatikerin für Anwendungsentwicklung ab September 2016 nach Nürnberg zu NETWAYS verschlagen hat. Die Lieblingsfreizeitaktivitäten der gebürtigen Steigerwalderin sind das Zocken, Zeichnen und sich mit Freunden und Kollegen auf gemütliche Spiele- und Filmabende zu treffen.

Speed up your work with Alfred 3 Workflows

Make things easy at work. Save time for the important bits. That’s something everyone talks about but there’s no real “that’s mine” guide out there. A while ago I decided to try something new – I switched my entire work place from Linux to macOS. Working with colleagues using their tools on a daily basis made me ask several times – how does that work? How could I use that workflow? Can you show me how the trackpad works? Swiping with two fingers going back in browser history?

Turns out there are a couple of tools which help me save time day by day. Some of them are not part of macOS themselves and thus require you to buy them. If a tool really saves my life (and time) I am willing to do so.

One of these tools is Alfred. Generally speaking Alfred can be used to search your mac, quickly open files and applications, use hotkeys for actions. Things you can achieve with Apple’s Spotlight already. The coolest thing is the additional Alfred Powerpack. This allows you to run shell commands on your macOS. You can extend the functionality by adding custom Alfred workflows. That way you can manage your chat clients, music apps, search the mail application and so on.

Locking your screen requires a somewhat quirky key combination or moving the cursor to hot corners. Both of which I don’t like and therefore just type in “lock” into the Alfred command popup. These days locking my screen is just “Cmd + Space, l, Enter” because Alfred remembers the history. Another tip from Bernd – type “empty” and automatically empty your trash bin.

We’re using Jabber at work, and I’m a heavy Adium user. When I want to chat with a co-worker, I just open Alfred and start typing “im <name>” and a new Adium chat tab opens. This is all thanks to this workflow. If you’re sending an email over the ocean, what time is it? Use this workflow to avoid googling. Another cool tip – if you are for instance converting inches to the metric system, a workflow called units comes in handy.

Yet another workflow is for Github repos which really helps after the migration for all Icinga repositories. Just type in “gh icinga2” and open the corresponding Github repository in your browser. Search for repos or users or open a new issue in a specific repository.

Alfred saves me a lot of time already. Keep focus and develop faster 🙂

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉