Location-Aware Settings With ControlPlane

Part of my “arriving at the office in the morning” ritual involves quitting all my personal applications (e.g. Sonos), re-enabling my work e-mail account and a whole slew of other tiny changes that differentiate my work environment from my home environment. While in itself this isn’t too much of a hassle it does get rather tedious after a while. Especially so if I forget to start certain apps like my Jabber client and don’t realize that until much later.

The ControlPlane application promises to solve this exact problem by running specific actions whenever it detects a location change.

In order to do this you first have to set up “contexts”: These are essentially the locations you want ControlPlane to be aware of. As a starting point I’ve created two contexts “Home” and “Work” for my most-frequently used locations:

The next step involves telling ControlPlane what kind of information it should use to determine where you are. ControlPlane supports a wide variety of so-called evidence sources for this, some of which include:

  • IP address range, nearby WiFi networks
  • Attached devices (screens, USB and bluetooth devices)
  • Bonjour services (e.g. AppleTV)

Once you’ve made up your mind about which evidence sources to use you need to actually configure rules for these sources. An example would be “If my laptop can see the WiFi network ‘netways’ I’m in the ‘Work’ environment.” You also get to choose a confidence rating for each of those rules. This is useful if some of your rules could potentially also match in other, unrelated environments – for example because the IP address range you’re using at work is also commonly used by other companies.

Once you’re sufficiently confident that your location detection rules are working reliably you can set up actions which ControlPlane automatically performs whenever you enter or leave a certain location:

For my personal use I’ve found the built-in library of actions to be quite useful. However, there are a few things that even ControlPlane doesn’t support out of the box – like disabling specific e-mail and Jabber accounts. Luckily it does let you can run arbitrary external applications, including ones you’ve built with macOS’s Script Editor application:

Gunnar Beutner

Autor: Gunnar Beutner

Vor seinem Eintritt bei NETWAYS arbeitete Gunnar bei einem großen deutschen Hostingprovider, wo er bereits viel Erfahrung in der Softwareentwicklung für das Servermanagement sammeln konnte. Bei uns kümmert er sich vor allem um verschiedene Kundenprojekte, aber auch eigene Tools wie inGraph oder Icinga2.

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.

Ceph – CRUSH rules über die CLI

Über die CRUSH Map ist es möglich zu beinflussen wie Ceph seine Objekte repliziert und verteilt. Die Standard CRUSH Map verteilt die Daten, sodass jeweils nur eine Kopie per Host abgelegt wird.

Wenn nun ein Ceph Cluster andere Prioritäten voraussieht, bspw. Hosts sich ein Netz, oder ein Rack mit gleicher Stromversorgung teilen, oder im gleichen Rechenzentrum stehen, sprich die Failure Domains anders aufgeteilt sind, ist es möglich diese Abhängigkeiten in der CRUSH Map zu berücksichtigen.

Beispielsweise wollen wir unseren Cluster mit einer Replikation von 3 auf eine 2er Replikation zurücksetzen. Da sich jedoch 2 Hosts einen Rack teilen, wollen wir das auch in unserer CRUSH Map abbilden und das über die CLI:

Ausgangslage:

[root@box12 ~]# ceph osd tree
ID WEIGHT  TYPE NAME                       UP/DOWN REWEIGHT PRIMARY-AFFINITY 
-6 0.33110 datacenter dc03                                                   
-1 0.33110     root datacenter01                                             
-5 0.33110         datacenter datacenter02                                   
-4 0.11037             host box14                                            
 6 0.03679                 osd.6                up  1.00000          1.00000 
 7 0.03679                 osd.7                up  1.00000          1.00000 
 8 0.03679                 osd.8                up  1.00000          1.00000 
-3 0.11037             host box13                                            
 3 0.03679                 osd.3                up  1.00000          1.00000 
 4 0.03679                 osd.4                up  1.00000          1.00000 
 5 0.03679                 osd.5                up  1.00000          1.00000 
-2 0.11037             host box12                                            
 0 0.03679                 osd.0                up  1.00000          1.00000 
 1 0.03679                 osd.1                up  1.00000          1.00000 
 2 0.03679                 osd.2                up  1.00000          1.00000 

Wir erstellen die beiden Racks:

[root@box12 ~]# ceph osd crush add-bucket rack1 rack
added bucket rack1 type rack to crush map
[root@box12 ~]# ceph osd crush add-bucket rack2 rack
added bucket rack2 type rack to crush map

Die Racks wurden erstellt:

[root@box12 ~]# ceph osd tree
ID  WEIGHT  TYPE NAME                       UP/DOWN REWEIGHT PRIMARY-AFFINITY                                                      
 -8       0 rack rack2                                                        
 -7       0 rack rack1                                                        
 -6 0.33110 datacenter dc03                                                   
 -1 0.33110     root datacenter01                                             
 -5 0.33110         datacenter datacenter02                                   
 -4 0.11037             host box14                                            
  6 0.03679                 osd.6                up  1.00000          1.00000 
  7 0.03679                 osd.7                up  1.00000          1.00000 
  8 0.03679                 osd.8                up  1.00000          1.00000 
 -3 0.11037             host box13                                            
  3 0.03679                 osd.3                up  1.00000          1.00000 
  4 0.03679                 osd.4                up  1.00000          1.00000 
  5 0.03679                 osd.5                up  1.00000          1.00000 
 -2 0.11037             host box12                                            
  0 0.03679                 osd.0                up  1.00000          1.00000 
  1 0.03679                 osd.1                up  1.00000          1.00000 
  2 0.03679                 osd.2                up  1.00000          1.00000 

Nun verschieben wir die Hosts 14 & 13 nach Rack1 und 12 nach Rack2:

[root@box12 ~]# ceph osd crush move box14 rack=rack1
moved item id -4 name 'box14' to location {rack=rack1} in crush map
[root@box12 ~]# ceph osd crush move box13 rack=rack1
moved item id -3 name 'box13' to location {rack=rack1} in crush map
[root@box12 ~]# ceph osd crush move box12 rack=rack2
moved item id -2 name 'box12' to location {rack=rack2} in crush map

Und die Racks in das Rechenzentrum(datacenter02):

[root@box12 ~]# ceph osd crush move  rack1 datacenter=datacenter02
moved item id -7 name 'rack1' to location {datacenter=datacenter02} in crush map
[root@box12 ~]# ceph osd crush move  rack2 datacenter=datacenter02
moved item id -8 name 'rack2' to location {datacenter=datacenter02} in crush map

Das ganze sieht dann so aus:

[root@box12 ~]# ceph osd tree
ID  WEIGHT  TYPE NAME                       UP/DOWN REWEIGHT PRIMARY-AFFINITY                                                       
 -6 0.33110 datacenter dc03                                                   
 -1 0.33110     root datacenter01                                             
 -5 0.33110         datacenter datacenter02                                   
 -7 0.22073             rack rack1                                            
 -4 0.11037                 host box14                                        
  6 0.03679                     osd.6            up  1.00000          1.00000 
  7 0.03679                     osd.7            up  1.00000          1.00000 
  8 0.03679                     osd.8            up  1.00000          1.00000 
 -3 0.11037                 host box13                                        
  3 0.03679                     osd.3            up  1.00000          1.00000 
  4 0.03679                     osd.4            up  1.00000          1.00000 
  5 0.03679                     osd.5            up  1.00000          1.00000 
 -8 0.11037             rack rack2                                            
 -2 0.11037                 host box12                                        
  0 0.03679                     osd.0            up  1.00000          1.00000 
  1 0.03679                     osd.1            up  1.00000          1.00000 
  2 0.03679                     osd.2            up  1.00000          1.00000 

Im nächsten Schritt lassen wir uns automatisch eine CRUSH Rule erstellen und ausgeben:

[root@box12 ~]# ceph osd crush rule create-simple ceph-blog datacenter01 rack

[root@box12 ~]# ceph osd crush rule ls
[
    "ceph-blog",
    "test03"
]

‘datacenter01 rack’ sagt hier, dass beim datacenter01 begonnen werden soll und alle Kindknoten(leaf) vom Typ rack ausgewählt werden sollen.

Wir lassen uns die CRUSH Rule ausgeben:

[root@box12 ~]# ceph osd crush rule dump ceph-blog
{
    "rule_id": 0,
    "rule_name": "ceph-blog",
    "ruleset": 0,
    "type": 1,
    "min_size": 1,
    "max_size": 10,
    "steps": [
        {
            "op": "take",
            "item": -1,
            "item_name": "datacenter01"
        },
        {
            "op": "chooseleaf_firstn",
            "num": 0,
            "type": "rack"
        },
        {
            "op": "emit"
        }
    ]
}

Sieht gut aus.

Der Pool rbd soll die Rule anwenden:

[root@box12 ~]# ceph osd pool set rbd crush_ruleset 0
set pool 0 crush_ruleset to 0

Funktioniert’s?

[root@box12 ~]# ceph osd map rbd test
osdmap e421 pool 'rbd' (0) object 'test' -> pg 0.40e8aab5 (0.b5) -> up ([4,0], p4) acting ([4,0,6], p4)

Das test Objekt wird weiterhin über die 3 Hosts verteilt.

Wir setzen die Replikation von 3 auf 2:

[root@box12 ~]# ceph osd pool get rbd size
size: 3
[root@box12 ~]# ceph osd pool set rbd size 2
set pool 0 size to 2

Ceph verteilt die Objekte. Nur Geduld:

[root@box12 ~]# ceph -s
    cluster e4d48d99-6a00-4697-b0c5-4e9b3123e5a3
     health HEALTH_ERR
            60 pgs are stuck inactive for more than 300 seconds
            60 pgs peering
            60 pgs stuck inactive
            27 pgs stuck unclean
            recovery 3/45 objects degraded (6.667%)
            recovery 3/45 objects misplaced (6.667%)
     monmap e4: 3 mons at {box12=192.168.33.22:6789/0,box13=192.168.33.23:6789/0,box14=192.168.33.24:6789/0}
            election epoch 82, quorum 0,1,2 box12,box13,box14
     osdmap e424: 9 osds: 9 up, 9 in
            flags sortbitwise
      pgmap v150494: 270 pgs, 1 pools, 10942 kB data, 21 objects
            150 GB used, 189 GB / 339 GB avail
            3/45 objects degraded (6.667%)
            3/45 objects misplaced (6.667%)
                 183 active+clean
                  35 peering
                  27 active+remapped
                  25 remapped+peering

Nach ‘ner Weile ist der Cluster wieder im OK Status:

[root@box12 ~]# ceph -s
    cluster e4d48d99-6a00-4697-b0c5-4e9b3123e5a3
     health HEALTH_OK
     monmap e4: 3 mons at {box12=192.168.33.22:6789/0,box13=192.168.33.23:6789/0,box14=192.168.33.24:6789/0}
            election epoch 82, quorum 0,1,2 box12,box13,box14
     osdmap e424: 9 osds: 9 up, 9 in
            flags sortbitwise
      pgmap v150497: 270 pgs, 1 pools, 10942 kB data, 21 objects
            149 GB used, 189 GB / 339 GB avail
                 270 active+clean

Gucken wir uns nochmal die Verteilung der Objekte an:

[root@box12 ~]# ceph osd map rbd test
osdmap e424 pool 'rbd' (0) object 'test' -> pg 0.40e8aab5 (0.b5) -> up ([4,0], p4) acting ([4,0], p4)

Sieht besser aus.

Vielleicht nur ein Zufall. Wir stoppen OSD.0 auf box12. Die Daten sollten weiterhin jeweils zwischen beiden Racks repliziert werden:

[root@box12 ~]# systemctl stop ceph-osd@0
[root@box12 ~]# ceph osd tree
ID  WEIGHT  TYPE NAME                       UP/DOWN REWEIGHT PRIMARY-AFFINITY                                                       
 -6 0.33110 datacenter dc03                                                   
 -1 0.33110     root datacenter01                                             
 -5 0.33110         datacenter datacenter02                                   
 -7 0.22073             rack rack1                                            
 -4 0.11037                 host box14                                        
  6 0.03679                     osd.6            up  1.00000          1.00000 
  7 0.03679                     osd.7            up  1.00000          1.00000 
  8 0.03679                     osd.8            up  1.00000          1.00000 
 -3 0.11037                 host box13                                        
  3 0.03679                     osd.3            up  1.00000          1.00000 
  4 0.03679                     osd.4            up  1.00000          1.00000 
  5 0.03679                     osd.5            up  1.00000          1.00000 
 -8 0.11037             rack rack2                                            
 -2 0.11037                 host box12                                        
  0 0.03679                     osd.0          down        0          1.00000 
  1 0.03679                     osd.1            up  1.00000          1.00000 
  2 0.03679                     osd.2            up  1.00000          1.00000 

Der Cluster verteilt wieder neu… Nur Geduld:

[root@box12 ~]# ceph osd map rbd test
osdmap e426 pool 'rbd' (0) object 'test' -> pg 0.40e8aab5 (0.b5) -> up ([4], p4) acting ([4], p4)

[root@box12 ~]# ceph -s
    cluster e4d48d99-6a00-4697-b0c5-4e9b3123e5a3
     health HEALTH_WARN
            96 pgs degraded
            31 pgs stuck unclean
            96 pgs undersized
            recovery 10/42 objects degraded (23.810%)
            1/9 in osds are down
     monmap e4: 3 mons at {box12=192.168.33.22:6789/0,box13=192.168.33.23:6789/0,box14=192.168.33.24:6789/0}
            election epoch 82, quorum 0,1,2 box12,box13,box14
     osdmap e426: 9 osds: 8 up, 9 in; 96 remapped pgs
            flags sortbitwise,require_jewel_osds
      pgmap v150626: 270 pgs, 1 pools, 10942 kB data, 21 objects
            149 GB used, 189 GB / 339 GB avail
            10/42 objects degraded (23.810%)
                 174 active+clean
                  96 active+undersized+degraded

Nach einer Weile:

[root@box12 ~]# ceph -s
    cluster e4d48d99-6a00-4697-b0c5-4e9b3123e5a3
     health HEALTH_OK
     monmap e4: 3 mons at {box12=192.168.33.22:6789/0,box13=192.168.33.23:6789/0,box14=192.168.33.24:6789/0}
            election epoch 82, quorum 0,1,2 box12,box13,box14
     osdmap e429: 9 osds: 8 up, 8 in
            flags sortbitwise,require_jewel_osds
      pgmap v150925: 270 pgs, 1 pools, 14071 kB data, 22 objects
            132 GB used, 168 GB / 301 GB avail
                 270 active+clean

Wir testen erneut:

[root@box12 ~]# ceph osd map rbd test
osdmap e429 pool 'rbd' (0) object 'test' -> pg 0.40e8aab5 (0.b5) -> up ([4,1], p4) acting ([4,1], p4)

Das Objekt liegt einmal in Rack1 und einmal in Rack2. Passt!

Noch nicht genug? Ihr habt Interesse noch mehr über Ceph zu erfahren? Dann besucht doch unsere Schulung: Ceph Schulung 😉

Weiterführendes: http://www.crss.ucsc.edu/media/papers/weil-sc06.pdf

Deniz Armagan

Autor: Deniz Armagan

Deniz hat in Worms Kommunikationsinformatik studiert und anschließend noch ein Zusatzstudium in IT-Security in Darmstadt draufgesetzt. Als er das Angebot von NETWAYS bekam, hat er sich schweren Herzens entschlossen, sein Studium abzubrechen und ist nach Nürnberg gezogen. Deniz ist ein sehr bescheidener Mensch, er liebt fahrende Züge und startende PCs - also im Grunde funktionierende Sachen - weswegen er in unserem Support-Team auch super aufgehoben ist.

Wird auch mal Zeit, dass einer reagiert…

Dass unsere Gesellschaft es sich gut und gerne möglichst bequem macht hat Bernd schon hinreichend ausgeführt.

Dies gilt allerdings nicht nur im politischen Kontext, sondern auch im IT-Kontext.

Paradebeispiel

M$ Windows gehört aktuell der Löwenanteil des Desktop-PC-Marktes – aber nicht unbedingt der Qualität wegen, sondern u.a. aus folgendem Grund:

Einige (vor allem im gewerblichen Bereich) häufig unumgängliche “Killer-Apps” wie M$ Office oder Adobe Photoshop laufen schlichtweg nur auf Windows (oder Mac OS).

Um von diesem hoch unsicheren, kostenpflichtigen, spionierenden und nicht-quelloffenen Betriebssystem wegzukommen, muss der Benutzer zumindest folgende Hürden überwinden:

  • (darauf kommen, dass überhaupt ein Betriebssystem außer Windows und Mac OS existiert)
  • bspw. GNU/Linux herunterladen und auf CD/DVD/USB-Stick brennen
  • davon booten und das System installieren
  • sich in das System und die Unterschiede zu Windows einarbeiten
  • Alternativen für ihre Killer-Apps suchen (sofern überhaupt vorhanden!)
  • sich in letztgenannte einarbeiten…

In solchen Fällen habe ich volles Verständnis für den Sieg der Faulheit. Henry Ford hat mal gesagt:

Denken ist die schwerste Arbeit, die es gibt. Das ist wahrscheinlich auch der Grund, warum sich so wenige Leute damit beschäftigen.

Aber das geht auch viel einfacher – ohne als böser Raubkopierer vom rechten Weg abzukommen – mit …

ReactOS

ReactOS ist keine GNU/Linux-Distribution, die es sich zur Aufgabe gemacht hat, Windows äußerlich möglichst ähnlich zu sehen.

Es ist ein eigenständiges, von Grund auf geschriebenes Betriebssystem, dessen Ziel es ist, möglichst vollständig zu Windows kompatibel zu sein.

Ich selbst habe ReactOS ausprobiert und teile meine Erfahrungen hier mit euch…

Ran an die Buletten!

Wie üblich habe ich das OS in einer virtuellen Maschine ausprobiert – konkret mit VirtualBox. Nachdem ich das ISO-Abbild heruntergeladen habe erstellte ich eine neue virtuelle Maschine…

Es ist wichtig, dass das Modell der (virtuellen) Netzwerkkarte mit dem von mir gewählten übereinstimmt (3. Bild) – sonst kann es passieren, dass das Netzwerk überhaupt nicht funktioniert.

Sobald der Bootvorgang abgeschlossen war, fand ich einen Windows-XP-ähnlichen Assistenten vor – mit dem Unterschied, dass ich die Sprache frei wählen konnte. (Pfeiltasten oben/unten, dann Eingabetaste)

Sobald das vollbracht ist, muss eigentlich nur noch die Eingabetaste malträtiert werden, bis dieser Assistent durch ist…

Dann gilt es einen Neustart abzuwarten. Beim darauf folgenden Assistenten muss man fast genau so wenig den Kopf anstrengen.

Ich habe zwar Name und Organisation angegeben, hätte aber auch genau so gut immer nur direkt “weiter” drücken können…

Nachdem einem weiteren Neustart kann man auch schon loslegen. Fehlermeldungen wie diese habe ich für meinen Teil bedenkenlos weggeklickt:

Aber…

Da war noch was…

Ein gesunder Geist in einem gesunden Körper. Und ein guter Web-Browser auf einem guten Betriebssystem.

Ich habe die Firefox-Versionen 3.6, 28 und 45 aus dem ReactOS-Paketmanager (Ja, Paketmanager! 😀 ) ausprobiert und meine, dass 28 aktuell der beste Kompromiss aus Funktionalität und Stabilität ist…

Fazit

Ist ReactOS nun für den Produktivbetrieb zu empfehlen?

Meiner Meinung nach noch definitiv nicht.

Neben der o.g. mangelhaften Unterstützung von Netzwerkkarten ist das System (… wie sagt man da noch gleich politisch korrekt …) leicht absturzgefährdet.

Konkret habe ich versucht, mir Visual Studio 2015 Community herunterzuladen (erstmal nur herunterzuladen!) …

(-.-“)

Alexander Klimov

Autor: Alexander Aleksandrovič Klimov

Alexander hat Ende 2013 mit einem Praktikum bei NETWAYS gestartet. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 und seiner Ausbildung bei uns friedliche Wege.

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!

Icinga 2 Best Practice Teil 4: Host Templates und Services

Heute soll es um die Strukturierung von Services und deren Zuordnungen zu Gruppen von Hosts gehen. Ein Host Template kann zur Zusammenfassung von Informationen einer Gruppe von Hosts dienen und damit mehrere unterschiedliche Services für den jeweiligen Host anziehen. Wir wollen in den folgenden Beispielen Linux Hosts überwachen. Dort neben, wie schon in Teil 3 beschrieben, der Belegung der Dateisysteme auch in Abhängigkeit in welchem Netzsegment der Host angeschlossen ist, ob die Zeit synchron zum Zeitserver läuft.

template Host "linux-host" {
  import "generic-host"

  vars.os = "Linux"
  vars.disks["disk /"] = {
    disk_partition = "/"
  }
}

apply Service "time" {
  import "generic-service"

  check_command = "ntp_time"
  command_endpoint = host_name

  assign where host.vars.os == "Linux"
}

Es gibt zwei Netze mit je eigenem Zeitserver. Um dieses abzubilden, definieren wir für jedes Netz ein eigenes Host-Template:

template Host "dmz-net" {
  vars.ntp_address = "172.16.2.99"
}
template Host "lan-net" {
  vars.ntp_address = "172.16.1.99"
}

Diese beiden Templates enthalten nur netzspezifische Informationen, in unserem Beispiel auch nur den jeweilig zuständigen Zeitserver. Der Service-Check time mit dem Plugin check_ntp_time ermittelt die Differenz zwischen der lokalen Zeit des Hosts und der Zeit des NTP-Servers, der in ntp_address angegeben ist. Nun müssen wir für einen Host im internen Netzwerk lan-net nur noch beide Templates zusammen bringen:

object Host "host.example.org" {
  import "linux-host"
  import "lan-net"
  import "postgres-dbms"

  address = "172.16.1.11"
}

Habe wir weitere Services, die abhängig vom Netzsegment unterschiedlich zu konfigurieren sind, können diese Informationen den Netz-Templates hinzugefügt werden. Ein weiteres Beispiel wäre hier die Überwachung unterschiedlicher Domain Name Services. Diese Konzept der Stapelung von Host templates kann natürlich noch weitergeführt werden, z.B. auf Applikationen wie einen Postgresql basierendes Datenbank-Management-Systems bezogen. Ggf. muss jedoch auf die Reihenfolge der Importe geachtet werden, wenn Werte überschrieben werden sollen.

Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.