Mein Praktikum bei Netways – Thorben

//Im Namen von Thorben

Erstmal vorweg, ich bin Thorben, 16 Jahre alt und besuche zur zeit das Europa Gymnasium in Gommern (Sachsen-Anhalt, nähe Magdeburg) in der 10. Klasse. Wir hatten die Ankündigung zum Praktikum bekommen und ich wollte irgendwas in Richtung IT machen. Da war es natürlich super, dass ich Ronny Biering kenne, der hier bei Netways arbeitet, über welchem ich dann auch den Kontakt und das Praktikum mit und bei Netways bekam. Nun sollte meine Praktikumsstelle 2 Wochen lang bei Netways sein, was mich echt freute.

Es fing klassisch mit dem Vorstellen jedes Mitarbeiters dieser Firma an und auch mit der Einweisung bei der Kaffeemaschine (wichtigster Mitarbeiter) :). Ich lernte Tim kennen, welcher fortlaufend, neben Sebastian, mein Betreuer des Praktikums sein sollte. Er erklärte mir grob Dinge über die 2 Wochen hier bei Netways und zeigte mir auch diverse Bereiche, wie auch das Rechenzentrum. Meine erste Aufgabe war testweise einen Raspberry PI zum laufen zu bringen und ihm im Anschluss mit dem Netways Dashboard zu versehen. Das ganze wiederholte ich 3 mal, bis ich dann auch schneller als es Tim lieb war, fertig wurde.
Markus Frosch hatte noch einen Vortrag über Passwörter im allgemeinen und über die Benutzung mit Enpass gehalten. Es war recht informativ, sodass ich dieses Programm auch zuhause verwenden werde. Danke dafür.
Danach sollte ich WordPress mit einer Mysql-Datenbank einrichten, womit ich jetzt auch erfolgreich einen eigenen Blog habe. Als auch dies fertig war, „durfte“ ich dann auch die Netzwerk Anschlüsse protokollieren und dann im Anschluss auch die Notebooks der neu ankommenden Praktikanten mit CentOS aufsetzen. Zwischendrin war ich auch im Lager und habe den Bereich mit den Lan Kabeln aufgeräumt und fein säuberlich nach Farbe sortiert. Zur zeit beschäftige ich mich neben dem Blog hier mit dem erledigen einiger Aufgaben, wie einen eigenen Passwort Generator oder auch die Buchstabenhäufigkeit per Bash zu ermitteln. Zum Abschluss bekam ich die Aufgabe, eine html-Seite mit eingebundenen Bildern zu erstellen.

Damit sind meine 2 Wochen Praktikum hier bei Netways auch fast um und ich kann getrost sagen, es war kein Fehler dieses hier zu absolvieren. Ich bekam einen für mich recht großen Einblick in die Shell Oberfläche, da ich nur 2 Jahre mit Delphi zu tun hatte. Im Gegensatz zu Delphi versteh ich jetzt wenigstens mal ein paar Dinge im Bereich der Befehle, womit es im Endeffekt auch Spaß macht die Shell zu benutzen. Auch die Firma an sich ist für mich eine positive Erfahrung in Hinsicht der Hilfe und auch dem Zusammenhalt unter den Mitarbeitern. Und auch Tim, welcher immer ein Ohr für meine Fragen offen hat.

Chrome, certificates and missing_subjectAltNames Part 2 of 1

Actually I wanted to cover this topic in the previous post, but somehow have missed it.

Using the mentioned one liner can lead to typos and/or some strange behaviour on the CA side, especially when using a Windows-CA.

To circumvent this issues, I mentioned “a specially designed *.conf file” which I’d like to elaborate today.

Following steps are necessary:

Create a file “req.conf” in etc/ssl/ (Ubuntu 14.04, pathes may vary) with the following content:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = $YourTLD
ST = $YourState
L = $YourCity
O = $YourCompany
OU = $YourDepatment
CN = $YourCName (e.g. internal.company.tld)
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = *.internal.company.tld
DNS.2 = internal.company.tld
DNS.3 = www.*.internal.company.tld

Essentially, these are the information provided by the “-subj section” in last weeks one liner.

Now you can generate a key:

openssl genrsa -out internal.company.tld.key 4096

and use your new key and the req.conf file to generate a CSR, which, as usually can be fed into your local CA.

openssl req -new -out internal.company.tld.csr -key internal.company.de.key -config req.conf -sha256

This *.conf file can be used as a template for other C/altNames as well and is, in my eyes, more lucid than a one liner.

Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

Chrome, certificates and missing_subjectAltNames

Google has been actively trying to ensure certificate security especially in the last months.

Sometimes this created quite some buzz in the IT World, e.g. when Symantecs policies came into the focus.

Current version 58 of Google Chrome has again adjusted the certificate policy.

Certificates provide two ways to store hostnames: CommonName and SubjectAltName (SAN). RFC 2818 specified in 2000 that CommonName should be deprecated, which Chrome now complies to.

Other browsers are currently still accepting the CommonName, which is mostly used by selfsigned certificates, as in our case :/

Users who wanted to access our internal sites encountered error messages and were forced to use quick and dirty workarounds, such as using a Windows registry “hack”:

Open a cmd-Shell as Administrator and enter:

reg add \HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome /v EnableCommonNameFallbackForLocalAnchors /t REG_DWORD /d 1 /f

which reactivates the fallback to CommonName

As this is just a temporary “solution”, you should issue an RFC 2818 conform certificate. This can be realized by using a complete and compliant certificate signing request (CSR).

You can either use a specially designed *.conf File for this or simply adapt the following shell command:

openssl req -new-key endpoint.com.key -sha256 -nodes  -subj '/C=US/ST=New York/L=New York/O=End Point/OU=Hosting Team/CN=www.endpoint.com/
         emailAddress=administrative-not-existent-address@our-awesome-domain.com/
         subjectAltName=DNS.1=endpoint.com,
         DNS.2=usually-not-convered-domain.endpoint.com,
         DNS.3=multiple-domains-crt.endpoint.com' > www.endpoint.com.csr
The created csr can be fed e.g. into your local CA to issue new certificates which can be rolled out in your environment.
Live long and prosper and be RFC compliant 🙂
Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

Simple Video Chat with jitsi-meet

Oftentimes you have colleagues working on different sites, even different countries and time zones have gotten more and more common in todays world of work.

You can easily keep connected by multiple means like Chat, Email, landline, mobile phones, messaging apps, social networks, VoIP… You get my point.

Most of these means have several disadvantages to consider:

  • no video functionality
  • no sovereignty about the transmitted data
  • no availability of thorough debugging
  • need of dedicated client application

These topics can be tackled by an OpenSource VideoChat Application: jitsi-meet

There is a quick installation guide available, (yes, there are docker images)and you can also try it via a demo system.

The package installs several components: jitsi-videobridge (WebRTC), jitisi-meet (JavaScript), nginx (http access), prosody (XMPP), OpenJDK7 (JRE)

While setting up the system, you’re prompted to configure  the domain name respectively the $IP of the host. In a second step, you’re asked to set a certificate for SSL-encryption.

You’re allowed to use your own certificate or jitsi-meet creates a self-signed certificate for you (this might be handy for having just a quick glance at jitsi-meet)

jitsi-meet then provides an easily accessible chat room for many concurrent user who can (voice)chat, share screens and video chat.

To set up a chat room, simply point your browser (Chrome worked best in our environment) to https://$IP:443 and enter a name for the room into the dialogue box.

You’ll be then redirected to the room and can start setting a password for the room and share the link to your room with others.

This is just a short overview about the possibilities of jitsi-meet, give it a try and have fun!

 

 

 

Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

Starface und Telefon Firmware Update

Bei Netways setzen wir sehr häufig Anwendungen selbst ein ein, bevor wir uns dazu entscheiden, diese Kunden anzubieten. Dies betrifft nicht nur Software, wie bspw. ceph, sondern auch Hardware, wie die in diesem Post angesprochene Starface Telefonieanlage.

Starface basiert auf der Edition Asterisk for Business und ermöglicht ähnliche Funktionalitäten wie eine “reguläre” Linux-Distribution.

So beherrscht Starface nicht nur eine ausgefeilte Benutzer- und Gruppenverwaltung, sondern ist auch in der Lage, die angeschlossenen Telefone zu administrieren. Es lassen sich auch in einer größeren Umgebung Einstellungen wie Kurzwahltasten, Klingeltöne und auch Firmwareupdates leicht und vor allem zentral verteilen. Wer schon einmal alle Telefone einzeln durchgegangen musste, um eine Einstellung zu setzen, wird das zu schätzen wissen.

Wie ist aber nun das konkrete Vorgehen um ein Update der Firmware auszurollen?

Zuerst benötigt man natürlich die passende Firmware selbst, in unserem Fall für das Snom320.

Dieses .bin-File hinterlegt man auf der Starface im passenden Verzeichnis unter /var/firmware:

In den jeweiligen Verzeichnissen liegen die Firmwaredateien, die mit Symlinks den Modellnamen zugeordnet sind. Um ein Update durchzuführen, muss der Symlink folglich auf die neu bezogene Firmware zeigen:

Zuverlässig wird die neue Firmware nach einem Restart der Starface auf alle betroffenen Geräte verteilt. Die Telefone rebooten, beziehen und installieren das Update ohne dass man jedes einzelne Gerät betreuen muss.

Welche weiteren Aufgaben man noch mit einer Starface bewältigen kann, kann man hier einsehen oder wer direkt eine beschaffen möchte, ist bei den Kollegen richtig.

Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!