Using ArgBash to generate the Call Parameters for Bash-Scripts

Gerade jetzt im aktuellen Linux-Magazin habe ich folgenden Artikel entdeckt: Werkzeuge im Kurztest Tooltipps — Argbash.

Das Tool ArgBash gefällt mir persönlich sehr gut. Und so nutzte ich die Gelegenheit um das Tool gleich einmal zu testen.

Ein guter Start ist das Quickstart Tutorial auf der Dokumentationsseite des Projektes. Ich habe nun als erstes mir das GIT-Repo ausgecheckt.

Ein kurzer Check mit dem Beispiel von der Quickstart Sektion zeigt, dass das Script prima funktioniert:

Damit wird ein kleines Script generiert, welches nur das parsen der o.g. Parameter übernimmt. Natürlich muss dann das Script noch mit Leben gefüllt werden.

Interessanter dürfe dann aber der Abschnitt sein, wo der Parsing-Code in ein extra Script ausgelagert wird. Das muss ich aber noch mal testen:

http://argbash.readthedocs.io/en/latest/example.html#separating-the-parsing-code

How to install the Nextcloud Desktop Client at Ubuntu

Derzeit ist es sehr schwer einen Client für Linux/Ubuntu zu finden, der direkt aus Paketquellen zu installieren geht. Nachfolgend habe ich eine Doku dazu gefunden:

https://help.nextcloud.com/t/linux-distribution-packages-for-the-desktop-clients-help-out/2538/34#post_35

https://gitlab.com/packaging/nextcloud-client/

http://repo.morph027.de/nextcloud-client.php

Repository einbinden und NextCloud-Client installieren:

Wenn beim o.g. Befehl („add-apt-repository“) folgender Fehler kommt, dann muss das Paket „software-properties-common“ nachinstalliert werden:

How to extend the OwnCloud LDAP Schema with additional attributes

In meinem letzten Beitrag hatte ich beschrieben, wie man den LDAP-Server um die Quotadefinitionen für Owncloud, bzw. NextCloud erweitern kann.

Hier möchte ich kurz ergänzen, wie man weitere Attribute hinzufügen kann, um z.B. weitere Cloudinstanzen mit eigenen Quotadefinitionen zu versorgen.

Hier möchte ich einfach kurz den Weg beschreiben, wie dies z.B. mit phpLDAPAdmin erledigt werden kann. Dazu muss man sich im Config-Backend anmelden und dann in die Schemadefinitionen (cn=config => cn=schema) wechseln.

Weiterlesen

LDAP CRC „ldif_read_file: checksum error“ Fehler beheben

Ich habe gerade vor einiger Zeit bei mir im LDAP Server einen Fehler entdeckt, den ich nicht verstanden habe und der mich irgendwie irritiert hat. Ich dachte zuerst schon an meiner Konfiguration sei etwas kaputt.

Es handelt sich um die folgende Fehlermeldung:

Leider ist es schwierig, gerade zu dieser Meldung irgendwie sinnvolle Antworten im Web zu finden, daher möchte ich hier eine Lösung aufzeigen, die bei mir gut funktioniert hat. Der korrekte Weg wäre wohl mit ldapmodify zu arbeiten, da wusste ich aber nicht, wie ich das genau anstellen sollte.
Die Warnung sollte man schon Ernst nehmen. Keine Garantie für irgendwelche nachfolgenden Fehler. Nun gut, bei mir hat es funktioniert.

Als Unterstützung habe ich den Artikel vom Blog LDAP: How to fix „ldif_read_file: checksum error“ benutzt. (Im gerade genannten Blog, gibt es noch einen kleinen Fehler. Wenn ich eine Datei mit „=,{,}“ oder ähnliches im Dateinamen habe, sollte ich noch Anführungszeichen um den Dateinamen setzen. Das ist bei mir natürlich korrigiert.

Als erstes benötigt man das Tool „crc32“. Hier gibt es eine Beschreibung wie es zu installieren ist How to check crc of a file?

Nun zu den Steps an sich:

 

Debian 8.0 – Jessie – PHP 7.0 installieren

Motiviert durch den Artikel auf schroeffu.ch: Debian 8 ‚Jessie‘: PHP7 neben PHP5 installieren habe ich auf meiner VM ebenfalls mal PHP 7.0 installiert.

Angelehnt, an die im o.g. Blog genannten Schritte habe ich folgendes gemacht:

Die php.ini für PHP7.0 musste ich nicht anpassen, da ich meine Anpassungen für den Apache in der zugehörigen VHOST.ini vornehme.

PHP 7.0 aktivieren im Apache:

Wie im Blog oben beschrieben, bitte zwingend immer ein PHP-Modul im Apache aktivieren, da sonst der PHP-Quellcode an den Browser ausgeliefert wird!!

Bei mir im Nextcloud musste ich noch folgende PHP-Pakete nachinstallieren, da ich sonst ziemlich seltsame Fehler bekam:

Die folgende PHP Pakete waren noch notwendig:

 

Managing OwnCloud and NextCloud User Quota with my LDAP Server

Es hat mich schon immer gestört, dass ich mit meinem LDAP-Server zwar die User verwalten kann, aber z.B. die UserQuota für meinen OwnCloud-Server immer noch per Hand in selbigem eintragen muss. Warum eigentlich? Nach etwas Suchen im Internet fand ich das GIT-Repository OwnCloud LDAP Schema von Valery Tschopp. Zuerst war mir nicht klar, ob ich das Schema überhaupt für meine aktuelle NextCloud Installation nutzen könnte, da das Schema für den Owncloud 6.0 Server geschrieben wurde? Zumindest ist die Doku für den 6er Server verlinkt. Nun gut, es funktioniert auch mit dem NextCloud 9.0.53 Server.

Zuerst clonen wir das GIT-Repo:

Ich benutze für meinen LDAP-Server das cn=config Backend. Dafür muss ich mich als root anmelden und dann den Befehl ldapadd benutzen. Daher spiele ich das Schema mit folgendem Commando ein:

Im oben genannten Link und in der README.md stehen die Details zum prüfen der Erweiterung.

Nun muss ich mich am LDAP-Server (an der GUI oder per ldif-patch) anmelden und dem User die Objektklasse „Owncloud“ hinzufügen, um anschließend dann das Attribut „ownCloudQuota“ hinzu fügen. Mache ich dann zur Kontrolle einen ldif Export, sieht das wie folgt aus:

 

Script for testing the getopts shell builtin

Dieses kleine Script zeigt die Möglichkeiten, die mit dem Shell-Builtin „getopts“ bestehen, um die Argumente eines Shell-Scriptes sauber zu parsen.

Creating scripted Cert-Requests without specifying too much data

Vielleicht interessiert es ja den einen oder anderen, wie ich Scriptgesteuert Zertifikatsrequests erstellen kann ohne die Angaben jedes Mal in den Dialog von OpenSSL einzugeben.

Diese Cert-Requests können dann verwendet werden um z.B. bei Startssl.com kostenfreie Zertifikate zu erhalten.

OwnCloud Aktivitäten in Piwik tracken

Bisher gibt es noch kein richtiges Plugin um Aktivitäten in OwnCloud mit Piwik tracken zu können. Leider ist es auch sehr schwierig eine gute Dokumentation zu finden. Die Einzige Dokumentation, die mir persönlich halbwegs plausibel erscheint, ist die im folgenden Link erwähnte Dokumentation: Adding a Piwik Tracking Code Into ownCloud.

Hier noch einmal die kurze Zusammenfassung aus dem Artikel:

  • Anpassung der folgenden Dateien:

core/templates/layout.user.php
core/templates/layout.guest.php
config/config.php

  • In den 2 template-Dateien muss der Piwik-Javascript Code vor dem Body-Tag eingefügt werden.
  • Außerdem ist die Datei config.php wie folgt zu bearbeiten

Am Ende des $CONFIG array ist nun noch folgende Ergänzung einzufügen:

Anm. Die Anpassung der o.g. config.php ist wichtig, da sonst der Piwik-Code nicht korrekt ausgeführt wird.

Weiterhin beruht der o.g. Link zusätzlich auf dem folgenden Support-Thread: https://forum.owncloud.org/viewtopic.php?f=23&t=10500

renew a buggy CMS Keystore with all certificates inside of them

Wie bereits in meinem letzten Beitrag Convert and Export Certificates from a KDB (CMS) Keystore zum Thema Keystores und Zertifikate erklärt, kann man mittels einiger Kommandos des Programms nicht nur den privaten und öffentlichen Schlüssel eines Zertifikates exportieren, sondern auch diese mitsamt der Signerzertifikate in einen neuen Keystore migrieren. Hier möchte ich nun kurz die Befehle erst einmal ablegen, die dazu notwendig sind, um alle Schritte sauber durchführen zu können.

Eventuell stelle ich bei Gelegenheit noch das zugehörige Script ein. Das ist aber im Moment noch nicht fertig.
Viel Spaß beim ausprobieren.
Die folgende Doku hat mir hier sehr gute Dienste geleistet: Use the Key Management Utility (IKEYMAN): IBM HTTP Server.