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 #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>
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 #43424 (In Progress): Add the functionality to create kopano-ressources to...https://progress.opensuse.org/issues/434242018-11-06T10:03:48Zflaccostefan@invis-server.org
<p>Kopano resources are shared store users with additional attributes "zarafaResourceType" and "zarafaResourceCapacity". Possible values are an integer number for the capacity and "equipment" or "room" for the type. Only resources of type "equipment" can be extended with a capacity value. It means that a resource exists X times.</p>
invis-sub-setup - action #38303 (In Progress): Create a rpm package with basic directories, confi...https://progress.opensuse.org/issues/383032018-07-07T07:49:01Zflaccostefan@invis-server.org
<p>We have to create a first rpm package for the invis-Sub-Server which contains the basic directories, config files and dependencies. The package should be the base for the further development of the invis subsidiary server.</p>
<p>Known dependencies are:</p>
<p>openvpn<br>
krb5-client<br>
samba<br>
owncloud-client</p>
invisAD-setup - action #37414 (In Progress): Implementation of SingleSignOnhttps://progress.opensuse.org/issues/374142018-06-15T07:57:23Zflaccostefan@invis-server.org
<p>Step by step we should implement SSO for as much applications as possible. First step would be to fit the apache2 setup for SSO.</p>
invisAD-setup - action #36115 (Resolved): Password-Handling during sine2 runhttps://progress.opensuse.org/issues/361152018-05-13T09:55:24Zflaccostefan@invis-server.org
<p>We should create all passwords by random pw-generator and put them in to a new setup datafile. => /var/lib/sine/invis_pws. This file should only accessible for root. </p>
<p>Showing this file could be done with "sine2 showpws".</p>
<p>Exception: This will not work for the CA private-key password. </p>
invisAD-setup - action #36108 (Resolved): Connect kimai to ADhttps://progress.opensuse.org/issues/361082018-05-12T12:23:35Zflaccostefan@invis-server.org
<p>sine2 should prepare the connection of kimai to the activedirectory</p>
invisAD-setup - action #36106 (Resolved): Implentation of invoiceplane to invis-server Setuphttps://progress.opensuse.org/issues/361062018-05-12T12:18:17Zflaccostefan@invis-server.org
<p>Implementation of the opensource invoiceplaning Software to invis-Server</p>
invisAD-setup - action #36003 (Resolved): Switch to dehydrated package from distributionhttps://progress.opensuse.org/issues/360032018-05-08T12:17:56Zflaccostefan@invis-server.org
<p>The let's encrypt client dehydrated is now part of the opensuse leap 15 standard repos. We should switch to this package, instead of building our own package.</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 #27090 (Resolved): ldb library conflicthttps://progress.opensuse.org/issues/270902017-10-28T09:08:44Zflaccostefan@invis-server.org
<p>Since one of the last upgrades of the package ldb to version 1.2.x in our samba AD repos, sssd refuces to start after setup. After installing the original openSUSE 42.3 package ldb in version 1.1.29 everything works.</p>
<p>The problem is that our own samba packages are build against the newer ldb package.</p>
<p>I've no idea how we can fix this. Just installing the older package couldn't be the right way, this may cause other dependency problems.</p>