openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842020-12-15T19:52:27ZopenSUSE Project Management Tool
Redmine 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 #67495 (Closed): dokuwiki setup with sine2 failshttps://progress.opensuse.org/issues/674952020-05-31T12:12:40Zflaccostefan@invis-server.org
<p>It seems that one of the plugins has changed his download url.</p>
invisAD-setup - action #67189 (Rejected): easyrsa batch modehttps://progress.opensuse.org/issues/671892020-05-24T09:14:53Zflaccostefan@invis-server.org
<p>It's possible to use easyrsa in a batch mode, which means no requests during easyrsa jobs. This is a little dangerous but this would create the opportunity to do easyrsa jobs via the invis-Portal.</p>
<p>A disadvantage is that we have to save the password of the ca-key in a file on the server.</p>
<p>Feedback wanted!</p>
invisAD-setup - action #63634 (New): We should publish a list with the expiry dates of all VPN cl...https://progress.opensuse.org/issues/636342020-02-20T07:36:54Zflaccostefan@invis-server.org
<p>The VPN client certs we create have a 24 month time to live. Actually the users have no information about this, the don't know when there clients certs epxire. More than once this caused problems in practice.</p>
invisAD-setup - action #63631 (Closed): We should publish the CRL expiration date via invis portalhttps://progress.opensuse.org/issues/636312020-02-20T07:32:14Zflaccostefan@invis-server.org
<p>Our CRL (Certification Revocation List) expires 6 month after creation. We should publish this date via invis-Portal.</p>
invisAD-setup - action #54389 (New): DNS-Updates via DHCP-Server should be possiblehttps://progress.opensuse.org/issues/543892019-07-18T06:37:55Zflaccostefan@invis-server.org
<p>In our setup every try to update DNS-Records dynamically fails:</p>
<p>Unable to add forward map from LANCOM_884_VOIP.baettenhausen.local to 192.168.1.205: REFUSED</p>
<p>This should be possible.</p>
<p>How to setup: <a href="https://wiki.samba.org/index.php/BIND9_DLZ_DNS_Back_End#Setting_up_BIND" class="external">https://wiki.samba.org/index.php/BIND9_DLZ_DNS_Back_End#Setting_up_BIND</a></p>
invisAD-setup - action #52019 (Closed): invis-Portal: Add a new function-sitehttps://progress.opensuse.org/issues/520192019-05-27T08:25:26Zflaccostefan@invis-server.org
<p>It should be possible to execute some administrative shell-scripts via invis-portal.</p>
invisAD-setup - action #51920 (Closed): invis-Server Setup Test with openSUSE Leap 15.1https://progress.opensuse.org/issues/519202019-05-23T10:05:12Zflaccostefan@invis-server.org
<p>We should build invis-Server 14.1 on base of Leap 15.1</p>
invisAD-setup - action #51869 (Closed): Build new own Samba-packageshttps://progress.opensuse.org/issues/518692019-05-22T16:22:30Zflaccostefan@invis-server.org
<p>Caused by problems with the MIT-Kerberos implementation and it's "experimental" state, we must build again own Samba-packages with Heimdal-Kerberos and switch our setup back to these own packages.</p>
invisAD-setup - action #51386 (Closed): invis-Server should be compatile with Btrfs.https://progress.opensuse.org/issues/513862019-05-12T07:25:07Zflaccostefan@invis-server.org
<p>First testinstallation with Btrfs on the Root-Volume shows that it was impossible to boot the server after setup with sine2.</p>
invisAD-setup - action #51383 (Closed): invis-Portal: Filter for Hostlisthttps://progress.opensuse.org/issues/513832019-05-12T07:21:37Zflaccostefan@invis-server.org
<p>It should be possible to filter the elements of the hostlist by type like we do it in the userlist.</p>
invisAD-setup - action #47072 (Closed): Check our DHCP-LDAP Schemahttps://progress.opensuse.org/issues/470722019-02-03T10:47:39Zflaccostefan@invis-server.org
<p>During an Upgrade from Samba 4.6 to 4.7 with MIT Kerberos, it is necessary to run "samba-tool dbcheck --cross-ncs --fix".</p>
<p>dbcheck throws some errors related to our dhcpd-LDAP Schema. We have to check this.</p>
<p>Errors:</p>
<hr>
<p>ERROR: Normalisation error for attribute mayContain in CN=iscDhcpClass,CN=Schema,CN=Configuration,DC=140-net,DC=loc<br>
value 'iscDhcpSubClassesDN' should be 'iscDhcpSubclassesDN'<br>
Not fixing attribute mayContain<br>
ERROR: Duplicate values for attribute 'mayContain' in 'CN=iscDhcpClass,CN=Schema,CN=Configuration,DC=140-net,DC=loc'<br>
Values contain a duplicate: [iscDhcpSubClassesDN,iscDhcpOptionsDN,iscDhcpStatements,iscDhcpComments,iscDhcpOption]/[iscDhcpSubClassesDN]!<br>
Not fixing attribute 'mayContain'<br>
ERROR: Not fixing missing 'name' on 'CN=iscDhcpClass,CN=Schema,CN=Configuration,DC=140-net,DC=loc'<br>
ERROR: Normalisation error for attribute mustContain in CN=iscDhcpFailOverPeer,CN=Schema,CN=Configuration,DC=140-net,DC=loc<br>
value 'iscDhcpFailoverPrimaryPort' should be 'iscDhcpFailOverPrimaryPort'<br>
Not fixing attribute mustContain<br>
ERROR: Duplicate values for attribute 'mustContain' in 'CN=iscDhcpFailOverPeer,CN=Schema,CN=Configuration,DC=140-net,DC=loc'<br>
Values contain a duplicate: [cn,iscDhcpFailOverPrimaryServer,iscDhcpFailOverSecondaryServer,iscDhcpFailoverPrimaryPort,iscDhcpFailOverSecondaryPort]/[iscDhcpFailOverPrimaryServer,iscDhcpFailoverPrimaryPort,cn,iscDhcpFailOverSecondaryServer]!<br>
Not fixing attribute 'mustContain'<br>
ERROR: Not fixing missing 'name' on 'CN=iscDhcpFailOverPeer,CN=Schema,CN=Configuration,DC=140-net,DC=loc'<br>
ERROR: incorrect DN SID component for member in object CN=Domain Users,CN=Users,DC=140-net,DC=loc - ;;;;;;;;CN=<a href="mailto:postmaster@140-net.loc">postmaster@140-net.loc</a>,CN=Users,DC=140-net,DC=loc<br>
Not fixing SID component mismatch</p>
<hr>
invis-sub-setup - action #46718 (In Progress): Create a setup-script for invis-sub-serverhttps://progress.opensuse.org/issues/467182019-01-26T15:49:46Zflaccostefan@invis-server.org
<p>Major steps to realize with this Script:</p>
<ol>
<li>Establish an openVPN connection to the main invis-server</li>
<li>Join the Domain as a "Read Only Domain Controller" (RODC)</li>
<li>Setup sssd</li>
<li>Setup local samba shares</li>
<li>realize (owncloud based) data synchronization between sub and main-server</li>
</ol>
<p>Some of these steps are already realized inside the joininvis-script from the invisAD-client package.</p>
<p>Joining the domain as a rodc (<a href="https://de.wikipedia.org/wiki/Read_Only_Domain_Controller" class="external">https://de.wikipedia.org/wiki/Read_Only_Domain_Controller</a>) instead of a simple member server seems to be the better way. In a productive environment at one of our custumers I tried to realize a subsidiary server as a simple member-server. Nearly every time the vpn-connection caused by a not very stable internet-connection, I had to rejoin the domain with the sub-server to give the sub-users access to their local samba-shares. </p>
invisAD-setup - action #46472 (Rejected): Evaluation: EGroupwarehttps://progress.opensuse.org/issues/464722019-01-21T16:26:15Zflaccostefan@invis-server.org
<p>invis-Servers use Kopano as their primary groupware system. Earlier versions of the invis server also included group-e. Group-es focus differs completely from Kopano. Features like project-management or time-tracking turned Group-e from a simple groupware to a tool which has the possibility to manage a lot of business workflows. After the group-e maintainers stopped the group-e developement, I was looking for an alternate system. The first idea was to include Tine20, but it was to complex.</p>
<p>In the very early days of invis-server they included EGroupware but I kicked it in favor of group-e. Now EGroupware did giant steps forward. We should evaluate if it is possible to integrate EGroupware as an alternative to Kopano for customers which want to manage their whole business with an extended groupware system.</p>
<p>Questions:</p>
<ol>
<li>Is it possible to combine EGroupware with ActiveDirectory based user-management?</li>
<li>Is it possible to automate EGroupwares setup and configuration?</li>
<li>Can EGroupware fit the needs of our target group or is it much to complex?</li>
</ol>
<p>A possible implementation of EGroupware will not change the Role of Kopano as our preferred groupware system. </p>
invisAD-setup - action #46121 (Rejected): CalDAV to CalDAV synchronization (Server to Server)https://progress.opensuse.org/issues/461212019-01-14T19:25:31Zflaccostefan@invis-server.org
<p>We should evaluate if it is possible to integrate a CalDAV to CalDAV synchronization tool into the invis-Server.</p>
<p>Background: With Kopano or other groupware systems we have a CalDAV Server inside invis-Server. A lot of our (FSP) customers use additional business-software systems which also ships calendar and scheduling components inside. Some of them are CalDAV servers.</p>
<p>For our customers it's difficult to decide which system they should use. Having the possibility to synchronize these systems could be a cool and extremely useful feature.</p>