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 #45731 (Closed): Bug: firewalld is blocking everything until it's restartedhttps://progress.opensuse.org/issues/457312019-01-04T15:54:45Zflaccostefan@invis-server.org
<p>After a reboot of an invis server the new firwalld daemon is blocking everything until it is restarted.</p>
invisAD-setup - action #43313 (Closed): Create an upgrade path from samba 4.6 to 4.7 with MIT ker...https://progress.opensuse.org/issues/433132018-11-03T12:40:58Zflaccostefan@invis-server.org
<p>We have to do upgrade tests with our heimdal based samba 4.6 setups to samba 4.7 with MT kerberos</p>
invisAD-setup - action #35946 (Rejected): GroupPolicies to rollout software to windows-clientshttps://progress.opensuse.org/issues/359462018-05-06T11:58:51Zflaccostefan@invis-server.org
<p>We should add GPOs to the invis-Server AD for an automatic rollout software-packages like Kopano-Outlook-Extension, Kopano-Deskapp or ownCloud-Client to the connected windows clients</p>
invisAD-client - action #31636 (In Progress): bringing invis-client package to opensuse factoryhttps://progress.opensuse.org/issues/316362018-02-10T17:01:11Zflaccostefan@invis-server.org
<p>In github (<a href="https://github.com/invisserver/invisAD-client" class="external">https://github.com/invisserver/invisAD-client</a>) I startet a very small invis-client project. It's goal is to add opensuse Linux workstations to an invis-server AD domain. Using this tool is a litlle bit complicated because it has to be cloned from github before using it.</p>
<p>We should bring this as a rpm package into opensuse-factory to make it easy for opensuse clients to join an invis-server domain.</p>
<p>Steps:</p>
<ol>
<li>build a package in spins:invis:testing</li>
<li>request to add it to factory</li>
</ol>
invisAD-setup - action #25802 (Closed): Switch to firewalldhttps://progress.opensuse.org/issues/258022017-10-05T17:36:44Zflaccostefan@invis-server.org
<p>The upcoming openSUSE leap 15 replaces the traditional SuSEfirewall2 with the firewalld system. Therefor we have to migrate our fw-settings from SuSEfirewall2 to firewalld. SuSEfirewall2 is not completely replaced, but we decided to switch firewalld. The migration script susefirewall2-to-firewalld will help to migrate.</p>
invis-server - action #23880 (Closed): Chemnitzer Linux Tage 2018https://progress.opensuse.org/issues/238802017-09-02T21:43:55Zflaccostefan@invis-server.org
<p>Presenting invis-Server at CLT 2018</p>
invis-server - action #23664 (Closed): OpenRheinRuhrhttps://progress.opensuse.org/issues/236642017-08-26T07:19:14Zflaccostefan@invis-server.org
<p>Presenting invis-Server at OpenRheinRuhr.</p>
<p>Staff: Stefan, Ines, Ingo, (Dimitri?)</p>
invis-server - action #23662 (Closed): Kieler Linux Tagehttps://progress.opensuse.org/issues/236622017-08-26T07:10:26Zflaccostefan@invis-server.org
<p>Presenting invis-Server at Kieler Linux Tage.</p>
<p>Staff: Stefan, Ines</p>
<p>invis-Server Talk: <a href="http://www.kilux.de/index.php?seite=programm.html&untermenu=Besucher-Info#325" class="external">http://www.kilux.de/index.php?seite=programm.html&untermenu=Besucher-Info#325</a></p>