openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842022-06-02T13:22:38ZopenSUSE Project Management Tool
Redmine invisAD-setup - action #111974 (In Progress): Problem mit DNS bei Übernahme eines bestehenden ADhttps://progress.opensuse.org/issues/1119742022-06-02T13:22:38Zflaccostefan@invis-server.org
<p>Wenn wir ein AD auf einem neu installierten Server aus einer AD-Vollsicherung eines älteren Servers übernehmen, laufen wir in Probleme mit der DNS Namensauflösung.</p>
<p>Ich habe das ganze mal versucht zu analysieren (einen ähnlichen Fall hatten wir auch beim Wechsel der Sernet- auf eigene Samba-Pakete).</p>
<p>Unter /var/lib/samba existieren aktuell zwei mit "sam.ldb.d" genannte Verzeichnisse, einmal unter "private" und einmal unter "bind-dns/dns". In alten Installationen existiert darüber hinaus ein weiteres unter "private/dns".</p>
<p>Dabei standen früher "bind-dns/dns" und "private/dns" vermutlich über Hardlinks in Beziehung. Gegenwärtig besteht die Beziehung zwischen "bind-dns/dns" und "private/sam.ldb.d". Einzelne der LDB-Dateien sind Hardlinks.</p>
<p>Wird jetzt eine Sicherung eines alten AD wiederhergestellt, existieren wieder alle drei Verzeichnisse, allerdings ohne Hardlinks. Daraus resultiert, dass der Nameserver bind nichts von Veränderungen in den DNS-Daten des AD vorgenommen werden. Dabei spielt es keine Rolle, ob eine Veränderung über unser Portal oder das samba-tool vorgenommen werden, bind bekommt davon nichts mit.</p>
<p>Ich untersuche jetzt welche Dateien per Hardlink miteinander verknüpft sind.</p>
invis-backup - action #104826 (In Progress): LVM Snapshot des Root-Volumes lässt sich mit 5er Ker...https://progress.opensuse.org/issues/1048262022-01-12T07:06:39Zflaccostefan@invis-server.org
<p>Der Linux Kernel lässt das mounten nicht zu, da er nicht zwei Mounts eines BtrFS-Dateisystems mit gleicher UUID zulässt.</p>
<p>D.h. vor dem Mount des Snapshots muss dessen UUID geändert werden.</p>
<p>Infos hier: <a href="https://unix.stackexchange.com/questions/537029/error-for-mount-system-call-failed-file-exists" class="external">https://unix.stackexchange.com/questions/537029/error-for-mount-system-call-failed-file-exists</a></p>
invisAD-setup - action #104730 (Closed): "Direct Rules" der Firewall greifen nicht mehr.https://progress.opensuse.org/issues/1047302022-01-09T13:45:36Zflaccostefan@invis-server.org
<p>Im Firewall-Setup des invis-Servers haben wir vor einiger Zeit einen Satz an "Direct-Rules" hinzugefügt. Hier die zugehörige XML-Datei:</p>
<pre><code><?xml version="1.0" encoding="utf-8"?>
<direct>
<!-- <rule ipv="ipv4" table="nat" chain="POSTROUTING" priority="0">-o intern -j MASQUERADE</rule> -->
<rule ipv="ipv4" table="filter" chain="FORWARD" priority="0">-i vpn -o intern -j ACCEPT</rule>
<rule ipv="ipv4" table="filter" chain="FORWARD" priority="0">-i intern -o vpn -m state --state RELATED,ESTABLISHED -j ACCEPT</rule>
</direct>
</code></pre>
<p>Die hier gesetzten Regeln dienten dazu ein Class-Routing zwischen den Schnittstellen "intern" und "vpn" zu ermöglichen. Beide Schnittstellen sind Teil der Zone "internal". Ohne diese Regel war es nicht möglich via VPN auf Netzwerkkomponenten hinter dem invis-Server zuzugreifen.</p>
<p>Unter openSUSE 15.3 (invis 14.3) scheinen diese Regeln nicht mehr zu greifen.</p>
<p>Vermutlich liegt das daran, dass inzwischen "nftables" anstelle von "iptables" als Firewall-Backend genutzt wird.</p>
invisAD-setup - action #98264 (Closed): EFI-Boot bei Systemen mit Linux MD-RAID Verbündenhttps://progress.opensuse.org/issues/982642021-09-07T13:48:33Zflaccostefan@invis-server.org
<p>Es gibt immer mehr Mainboards, die kein Legacy-Boot mehr kennen, sondern UEFI-Boot erzwingen. Das UEFI-System der Mainboards ist aber nicht in der Lage auf Linux MD-RAID-Verbünde zuzugreifen. D.h. Es muss mindestens eine EFI-Bootpartition vorhanden sein über die das System gestartet wird.</p>
<p>Legt man nur auf einer Platte eine solche Partition an ist das System nicht mehr boot-fähig, wenn genau diese Platte ausfällt. Es ist aber möglich auf allen Platten des Systems eine solche Partition anzulegen und mit Boot-Informationen zu versehen, so dass wahlweise über jede Platte des Systems gebootet werden kann.</p>
<p>Im Thomas Krenn-Wiki gibt es einen Artikel zum Thema:</p>
<p><a href="https://www.thomas-krenn.com/de/wiki/Ubuntu_Software_RAID_mit_redundanten_UEFI_Boot_Eintr%C3%A4gen" class="external">https://www.thomas-krenn.com/de/wiki/Ubuntu_Software_RAID_mit_redundanten_UEFI_Boot_Eintr%C3%A4gen</a></p>
<p>Der Artikel bezieht sich zwar auf Ubuntu, sollte unter openSUSE aber auch umsetzbar sein.</p>
<p>Installiert man ein openSUSE System ist es möglich zwar auf jeder Platte des Systems eine EFI-Partition anzulegen, aber nur eine davon wird nach /boot/efi gemountet und mit der grub-EFI-Datei versehen.</p>
<p>Ziel wäre es ein Script zu schreiben, mit dem weitere während des System-Setups angelegte EFI-Partitionen so vorbereitet werden können, dass über sie gebootet werden kann.</p>
invisAD-setup - action #98042 (In Progress): Release invis-Server 14.3https://progress.opensuse.org/issues/980422021-09-03T06:45:05Zflaccostefan@invis-server.org
<p>invis-Server 14.3 fertigstellen und veröffentlichen.</p>
invisAD-setup - action #97775 (Closed): Postfix Setup erweitern - Relay-by-Sender / Fallback-Relayhttps://progress.opensuse.org/issues/977752021-08-31T14:28:34Zflaccostefan@invis-server.org
<p>Beim Mailversand eines invis-Servers läuft der gesamte augehende Mailverkehr über einen definierten Relay-Host. Das stellt solange kein Problem dar wie der Relayhost für den Versand von Mails der enthaltenen Absende-Domain sendeberechtigt ist (SPF).</p>
<p>Ist das nicht der Fall und auf Empfänger-Seite wird eine SPF-Prüfung gemacht, werden Mails nicht zugestellt.</p>
<p>Konkretes Beispiel. Eine Kundin hat ihre Haupt-Mailadressen bei der Telekom, ergänzend aber auch Mailadressen anderer Domains. Versendet wird über einen kostenpflichtigen Smarthost der Telekom, der den Versand von Mails fremder Domains erlaubt (securesmtprelay.t-online.de). Natürlich hat er keine entsprechenden SPF-Einträge. Prüft jetzt der MX auf Empfängerseite bei Maileingang die SPF-Einträge, verweigert er zu recht die Annahme.</p>
<p>Als Lösungsweg für das Problem können bedingte Transportwege für Postfix konfiguriert werden. D.h. Wenn Absender gleich *@domain-x.de, dann versand via Transportweg sowieso. In den verschiedenen Transport-Definitionen können dann alternative Relay-Hosts verwendet werden.</p>
invisAD-setup - action #97604 (Closed): Passwörter von Mail-Konten im ADhttps://progress.opensuse.org/issues/976042021-08-28T07:06:05Zflaccostefan@invis-server.org
<p>Wir speichern die Passwörter externer Mailkonten im Klartext im AD. Abgesehen davon, dass das grundsätzlich schon unsicher ist, ist es technisch gesehen auch extrem unschön.</p>
<p>Sind Sonderzeicheen und/oder Umlaute enthalten, kann das zu Problemen führen.</p>
<p>Fügt man ein neues Mailkonto mit dem neuen Toolbox-Script "addmailaccount" zum AD hinzu werden Passwörter die Umlaute enthalten automatisch nocht im Klartext, sondern Base64 kodiert im AD gespeichert. Das macht nicht mein Script, sondern das verwendete Tool "ldbadd" bzw. "ldbmodify". Beim Auslesen entsteht dann ein Problem, weil nicht klar ist, ob das PW im Klartext enthalten ist oder Base64-kodiert. Die automatische Erkennung macht die Anwendung eines komplexen regulären Ausdrucks erforderlich (was soweit ok ist).</p>
<p>Trotzdem stellt sich die Frage, ob wir die Passwörter nicht grundsätzlich Base64-kodiert speichern sollten? Das ist zwar noch kein Schutz, vergleichbar mit einer Verschlüsselung sondern maximal ein "Sichtschutz" abder das Handling der Passwörter in irgendwelchen Shellscripts ist wesentlich einfacher, da wir uns nicht mehr mit ekelhaften Sonderzeichern herum schlagen müssen.</p>
<p>Was denkt Ihr. Klartext oder Base64?</p>
<p>Bitte um Rückmeldung.</p>
invisAD-setup - action #97598 (Resolved): diskchecker meldet defekten RAID-Verbund nichthttps://progress.opensuse.org/issues/975982021-08-27T15:43:08Zflaccostefan@invis-server.org
<p>Beim erste Kunden bei dem ich einen invis-Server 14.3 unter Leap 15.3 aufgebaut habe war ein RAID1 Verbund defekt. Vermutlich hat sich eine der beteiligten Platten während des Server-Transports so im Schacht gelockert, dass sie nicht ansprang. Der Server startete über die verbleibende Platte ohne Probleme. diskchecker hat keinerlei Fehler gemeldet. Da es in diesem Moment keine zweite Platte gab wurde sie logischerweise nicht per SMART abgefragt. So weit so logisch. Allerdings wurde der RAID-Verbund als intakt gemeldet, was ein Riesenproblem darstellt.</p>
<p>Die Ursache konnte ich eingrenzen. Im Script fragen wir den Zustand des Verbundes mittels mdadm -D ab und filtern nach einer Zeile in der "State :" steht. Dort wird üblicherweise der Status des Verbundes angegeben. Hier liegt das Problem, ist der RAID-Verbund defekt fehlt diese Zeile in der Ausgabe von mdadm -D. Das dürfte ein Bug in mdadm sein.</p>
<p>Wir generieren aus der Abfrage eine Variable, die in diesem Falle leer bzw. nicht existent ist, wodurch die bestehende Status-Datei aus der das Portal seine Infos bezieht nicht überschrieben wird. Kurz der Status "OK" bleibt auch im Fehlerfall erhalten.</p>
<p>Das ganze muss einerseits von uns noch genauer analysiert werden. Zum anderen müssen wir dafür sorgen, dass eine leere Variable "$status" zwingend zu einer Fehlermeldung im Portal führt.</p>
invisAD-setup - action #81114 (Closed): Erweitern des Administrator-Accounts um POSIX-Attribute u...https://progress.opensuse.org/issues/811142020-12-16T13:23:33Zflaccostefan@invis-server.org
<p>Im aktuellen Zustand hat der Domänen-Administrator eines invis-Servers keinerlei Rechte auf invis-Server, da sein Konto nicht mit POSIX-Attributen ergänzt wurde. D.h. es ist nicht möglich sich beispielsweise per SSH am Server anzumelden. Das schließt natürlich auch "shellinabox" ein.</p>
<p>Weiterhin bekommt der Administrator keine Netzlaufwerke, was gerade bei der Nutzung der Freigabe "service" nervig ist.</p>
<p>Wir sollten das Admin-Konto entsprechend aufwerten.</p>
invisAD-setup - action #81080 (Closed): Kopano Dienste auf anderen Servern betreibenhttps://progress.opensuse.org/issues/810802020-12-15T20:04:14Zflaccostefan@invis-server.org
<p>Sollen einzelne Kopano-Dienste auf anderen Servern als dem invis-Server betrieben werden müssen diese sich per SSL-Schlüssel am Hauptserver anmelden.</p>
<p>Dazu ist auf dem Server ein Verzeichnis für die öffentlichen Schlüssel der Client-Server erforderlich, üblicherweise "/etc/kopano/sslkeys". Dieses sollte im Verlauf des invis-Server-Setups automatisch angelegt werden.</p>
<p>Darüber hinaus sollte ein Toolbox-Script erzeugt werden, welches aus einem neu per easyrsa erzeugten Schlüsselpaar, eine Schlüsseldatei für den Client (Kombi aus private-Key und Zertifikat) und einer Datei für den Server erzeugt. Der Server benötigt nur den öffentlichen Schlüssel des Clients. Dieser muss aus dem Zertifikat des Clients extrahiert und nach /etc/kopano/sslkeys kopiert werden.</p>
invisAD-setup - action #81078 (Closed): Aktualisieren unseres Dehydrated-Setupshttps://progress.opensuse.org/issues/810782020-12-15T19:52:27Zflaccostefan@invis-server.org
<p>Die Konfiguration von Dehydrated sollte um die Direktive "cleanup" ergänzt werden. Das sorgt dafür, dass alte Zertifikate automatisch gelöscht werden.</p>
<p>Um dies umzusetzen müssen unter /etc/dehydrated vom Benutzer dehydrated angelegt werden können. Aufgrund inkorrekter Besitzrechte im derzeitigen Setup klappt das nicht, was Folgefehler nach sich zieht.</p>
<p>Es scheint auch so, dass keine "domain.txt" Datei angelegt wird. Dies sollte während des invis-Server Setups automatisch geschehen.</p>
<p>Das Toolbox-Script "actdehydrated" verwendet noch das Kommando "ifconfig", welches nicht mehr im openSUSE Standard-Setup enthalten ist. Das Script muss auf das Kommando "ip" umgestellt werden.</p>
invisAD-setup - action #81076 (In Progress): DHCP-Server Konfiguration im AD so vorbereiten, dass...https://progress.opensuse.org/issues/810762020-12-15T19:44:33Zflaccostefan@invis-server.org
<p>Dafür müssen die LDIF-Dateien für das Setup des Servers um zwei DHCP-Optionen erweitert werden:</p>
<p>rfc3442-classless-static-routes code 121 = array of integer 8<br>
ms-classless-static-routes code 249 = array of integer 8</p>
<p>Ergänzend sollte ein Shellscript für die invis-Toolbox geschrieben werden, welches die eigentlichen Routen dann in der Subnetz-Deklaration die eigentlichen Routen ergänzt.</p>
invisAD-setup - action #81074 (Closed): Kopano stolpert über PST-Dateien die via Outlook-PST Expo...https://progress.opensuse.org/issues/810742020-12-15T19:34:34Zflaccostefan@invis-server.org
<p>Beim Import solcher PST-Dateien wird der Typ des Inbox-Ordners auf "PF.Imap" geändert. Kopano erkennt den Ordner dann nicht mehr als Mailordner vom Typ "Mail und Bereitstellung" (IPF.Note).</p>
<p>Um dies zu beheben gibt es seitens Kopano ein fertiges Python-Script. Das sollten wir in unsere Toolbox integrieren.</p>
<p>Zu finden ist es hier:</p>
<p><a href="https://stash.kopano.io/projects/KSC/repos/core-tools/browse/ipf-imap-to-note" class="external">https://stash.kopano.io/projects/KSC/repos/core-tools/browse/ipf-imap-to-note</a></p>
invisAD-setup - action #81072 (Closed): mdadm prüft neuerdings jetzt regelmäßig alle Raid-Verbünd...https://progress.opensuse.org/issues/810722020-12-15T19:24:19Zflaccostefan@invis-server.org
<p>Seit einiger Zeit prüft mdadm regelmäßig alle RAID-Verbünde. Unser Script diskchecker erkennt diese Prüfläufe als Fehler und versendet überflüssige Warnmails.</p>
<p>diskchecker muss so angepasst werden, dass es die Prüfläufe als solche erkennt.</p>
invis-server - action #80224 (Closed): CLT Alternativ-Eventhttps://progress.opensuse.org/issues/802242020-11-23T18:28:36Zflaccostefan@invis-server.org
<p>Marcel hat vorgeschlagen parallel zu den kommenden nur virtuellen Chemnitzer-Linux-Tagen ein kleines eigenes Event zu starten bei dem wir uns im kleinen Kreis treffen, ein bisschen basteln und ein paar Vorträge von den CLT streamen können.</p>
<p>Klar ist, dass das nur mit einer deutlichen Lockerung der derzeitigen Corona-Bestimmungen möglich ist. Auch unser gesunder Menschenverstand sollte eine Rolle spielen. Meint wenn die Fallzahlen weiter hoch bleiben sollten wir auch bei gelockerten Bestimmungen davon Abstand nehmen oder die Modalitäten anpassen.</p>
<p>Ich mache das hier mal als Ticket der Kategorie Event auf, dann können wir hier planen.</p>
<p>Termin der virtuellen CLT ist das WE 13./14.03.2021.</p>
<p>Unsere Planung eines solchen Mini-Events sollten wir spätestens eine Woche vorher abgeschlossen haben.</p>