WiSe16 AK TOPF - Versionsgeschichte

Marcus Mikorski: Kategorie hinzugefügt

2018-08-11T10:30:50Z

Kategorie hinzugefügt

← Nächstältere Version		Version vom 11. August 2018, 12:30 Uhr
Zeile 85:		Zeile 85:
	[[Kategorie:WiSe16]]		[[Kategorie:WiSe16]]
	[[Kategorie:IT]]		[[Kategorie:IT]]
			[[Kategorie:TOPF]]

KerstinK: /* Zusammenfassung */

2016-12-25T13:16:35Z

Zusammenfassung

← Nächstältere Version		Version vom 25. Dezember 2016, 15:16 Uhr
Zeile 74:		Zeile 74:

	== Zusammenfassung ==		== Zusammenfassung ==
	~~In naher Zukunft wird die Mailingliste umziehen, des weiteren wird mit dem StaPF über die Nötigkeit des Ticketsystems und einer Cloud diskutiert werden.~~ Robert ~~schließt sich mit den entsprechenden Leuten kurz.~~		Redeleitung: Robert Löffler (Uni Konstanz)
			Protokoll: Niklas Westermann (Uni Konstanz)

	~~Des weiteren~~ ist der Umzug der Accounts in ein LDAP in Planung.		Ziel des AKs ist es, aktuelle Probleme und Projekte des TOPF (Technischer Organisationsausschuss aller Physikfachschaften) zu erläutern und ist als Austausch- und Informations-AK gedacht.
			In naher Zukunft wird die Mailingliste umziehen, des Weiteren wird mit dem StaPF über die Nötigkeit des Ticketsystems und einer Cloud diskutiert werden. Es soll weiterhin auf ein zentrales Account- und Anmeldesystem hingearbeitet werden.

			Außerdem ist der Umzug der Accounts in ein LDAP in Planung. Dabei sollte sich an das Bundesdatenschutzgesetz gehalten werden und eine eigene Datenschutzerklärung verfasst werden.

	[[Kategorie:AK-Protokolle]]		[[Kategorie:AK-Protokolle]]
	[[Kategorie:WiSe16]]		[[Kategorie:WiSe16]]
	[[Kategorie:IT]]		[[Kategorie:IT]]

Lobachevsky am 12. November 2016 um 18:14 Uhr

2016-11-12T18:14:35Z

← Nächstältere Version		Version vom 12. November 2016, 20:14 Uhr
Zeile 78:		Zeile 78:
	Des weiteren ist der Umzug der Accounts in ein LDAP in Planung.		Des weiteren ist der Umzug der Accounts in ein LDAP in Planung.

	[Kategorie:AK-Protokolle]]		[[Kategorie:AK-Protokolle]]
	[[Kategorie:WiSe16]]		[[Kategorie:WiSe16]]
	[[Kategorie:IT]]		[[Kategorie:IT]]

Lobachevsky: /* Protokoll */

2016-11-12T18:14:16Z

Protokoll

← Nächstältere Version		Version vom 12. November 2016, 20:14 Uhr
Zeile 49:		Zeile 49:
	'''Allgemeine Diskussion'''		'''Allgemeine Diskussion'''
	* Man sollte auf eine Root-Server und keinen VServer benutzen, da eine NextCloud zu viel Ressourcen frisst. Allerdings könnte man sich für weniger Geld einen NextCloud-Server mieten. Außerdem ist die Administrationsarbeit sehr aufwendig. Des weiteren stellt sich die Frage nach der Ausfallsicherheit. Robert hat nachgeschaut, für 10€ bekommen wir eine Nextcloud mit 100GB. Robert redet mit dem StaPF darüber		* Man sollte auf eine Root-Server und keinen VServer benutzen, da eine NextCloud zu viel Ressourcen frisst. Allerdings könnte man sich für weniger Geld einen NextCloud-Server mieten. Außerdem ist die Administrationsarbeit sehr aufwendig. Des weiteren stellt sich die Frage nach der Ausfallsicherheit. Robert hat nachgeschaut, für 10€ bekommen wir eine Nextcloud mit 100GB. Robert redet mit dem StaPF darüber
	* Es kommt die Frage auf, ob der Phabricator auch für andere Projekte genutzt werden kann. Es kann ausprobiert werden, ~~ist aber~~ für ~~ein Projektmanagement~~ nicht ~~besonders sinnvoll~~.		* Es kommt die Frage auf, ob der Phabricator auch für andere Projekte genutzt werden kann. Es kann ausprobiert werden. Einzelne Leute berichten, dass das für sie nicht funktioniert hat.
	* Diskussion über LDAP		* Diskussion über LDAP
	** Aufwand		** Aufwand
Zeile 56:		Zeile 56:
	** Man könnte das ganze über OpenID laufen lassen.		** Man könnte das ganze über OpenID laufen lassen.
	** Da es im Wiki eine Versionierung mithilfe der Benutzer(namen) gibt, sollten die alten Benutzer nicht gelöscht werden. Robert möchte die Nutzer neu anlegen, die Nutzer des Wiki sollte "anständig" migriert werden.		** Da es im Wiki eine Versionierung mithilfe der Benutzer(namen) gibt, sollten die alten Benutzer nicht gelöscht werden. Robert möchte die Nutzer neu anlegen, die Nutzer des Wiki sollte "anständig" migriert werden.
	** Richard ist dagegen, dass wir uns wieder selbst eine Lösung ~~zusammen basteln~~ und damit wieder mehr Arbeit haben.		** Richard ist dagegen, dass wir uns wieder selbst eine Lösung zusammenbasteln und damit wieder mehr Arbeit haben.
	** Bei LDAP gibt es folgenden Probleme: Auf die Rechtevergabe muss sehr viel Wert gelegt werden.		** Bei LDAP gibt es folgenden Probleme: Auf die Rechtevergabe muss sehr viel Wert gelegt werden.
	** Wir wollen ein LDAP, das nicht zu komplex wird.		** Wir wollen ein LDAP, das nicht zu komplex wird.
Zeile 62:		Zeile 62:

	* Richards Anmeldesystem		* Richards Anmeldesystem
	** Dresden benutzt das ~~Anemdlesystem~~ von Richard, Berlin hat evtl. ein selbst erstelltes, Siegen hat noch keine Ahnung		** Dresden benutzt das Anmeldesystem von Richard, Berlin hat evtl. ein selbst erstelltes, Siegen hat noch keine Ahnung
	** Chemie will auch das System von Richard benutzen		** Chemie will auch das System von Richard benutzen
	** Das Frontend ist nicht besonders sicher (das Backend ist sehr sicher), muss es aber auch nicht sein. Allerdings ist es noch ausbaufähig, da anscheinend kleinere Bugs auftreten.		** Das Frontend ist nicht besonders sicher (das Backend ist laut Richard sehr sicher), muss es aber auch nicht sein. Allerdings ist es noch ausbaufähig, da anscheinend kleinere Bugs auftreten.
	** In scala geschrieben		** In scala geschrieben
	** Robert möchte erst auf eine zentrales Accountsystem hinarbeiten und danach auf ein zentrales Anmeldesystem.		** Robert möchte erst auf eine zentrales Accountsystem hinarbeiten und danach auf ein zentrales Anmeldesystem.

Lobachevsky: /* Protokoll */

2016-11-12T18:08:19Z

Protokoll

← Nächstältere Version		Version vom 12. November 2016, 20:08 Uhr
Zeile 34:		Zeile 34:

	== Protokoll ==		== Protokoll ==
	'''~~Robert~~ berichtet:'''		'''Der TOPF berichtet:'''
	* Es gibt noch keinen zentralen LDAP-Server für die Account-Verwaltung		* Es gibt noch keinen zentralen LDAP-Server für die Account-Verwaltung
	* Wir haben einen neuen Mailman (Mailman3, [http://lists.zapf.in] ) mit coolem Management Frontend. Da hin sollen demnächst alle Listen umziehen		* Wir haben einen neuen Mailman (Mailman3, [http://lists.zapf.in] ) mit coolem Management Frontend. Da hin sollen demnächst alle Listen umziehen

Lobachevsky: /* Arbeitskreis: TOPF und IT-Dinge */

2016-11-12T18:07:17Z

Arbeitskreis: TOPF und IT-Dinge

← Nächstältere Version		Version vom 12. November 2016, 20:07 Uhr
Zeile 20:		Zeile 20:
	: Uni Münster		: Uni Münster
	: Uni Siegen		: Uni Siegen
	: ~~Freie Uni~~ Berlin		: FU Berlin

	== Wichtige Informationen zum AK ==		== Wichtige Informationen zum AK ==

ENik am 12. November 2016 um 11:55 Uhr

2016-11-12T11:55:41Z

← Nächstältere Version		Version vom 12. November 2016, 13:55 Uhr
Zeile 37:		Zeile 37:
	* Es gibt noch keinen zentralen LDAP-Server für die Account-Verwaltung		* Es gibt noch keinen zentralen LDAP-Server für die Account-Verwaltung
	* Wir haben einen neuen Mailman (Mailman3, [http://lists.zapf.in] ) mit coolem Management Frontend. Da hin sollen demnächst alle Listen umziehen		* Wir haben einen neuen Mailman (Mailman3, [http://lists.zapf.in] ) mit coolem Management Frontend. Da hin sollen demnächst alle Listen umziehen
	* Es gibt eine neues Design im Wiki. Allerdings gibt es noch ein paar kleine Bugs. Auch der Studienführer ist im neuen Design. Dort und auch bei den Lists kann demnächst SSL aktiviert werden. Der Umzug für die ZaPFList dauert evtl. noch ein bisschen~~, da im neuen Release z.B die Benutzeraccounts nicht mehr so gut verwaltet werden können~~.		* Es gibt eine neues Design im Wiki. Allerdings gibt es noch ein paar kleine Bugs. Auch der Studienführer ist im neuen Design. Dort und auch bei den Lists kann demnächst SSL aktiviert werden. Der Umzug für die ZaPFList dauert evtl. noch ein bisschen.
	* Auf dem Server selbst läuft ein postfix, Richard wirft ein, dass das ein Problem ist, da der Server nicht gewhitelistet ist. Wir brauchen einen etablierten SMTP, das Problem an in Jena war, dass Richards Server kein Sender-Score hatte.		* Auf dem Server selbst läuft ein postfix, Richard wirft ein, dass das ein Problem ist, da der Server nicht gewhitelistet ist. Wir brauchen einen etablierten SMTP, das Problem an in Jena war, dass Richards Server kein Sender-Score hatte.
	* Robert würde sich gerne noch mit dem StaPF zusammen setzen, da der das OpenProject (Ticketsystem) aktuell nicht genutzt wird. Aktuell nutzt es Berlin. Ein Problem ist, dass es oft Verbindungsabbrüche gibt.		* Robert würde sich gerne noch mit dem StaPF zusammen setzen, da der das OpenProject (Ticketsystem) aktuell nicht genutzt wird. Aktuell nutzt es Berlin. Ein Problem ist, dass es oft Verbindungsabbrüche gibt.
	* Der ZaPF e.V. will eine Nextcloud		* Der ZaPF e.V. will eine Nextcloud
	* Mit der Nextcloud und Edupads könnte das OpenProject hinfällig werden. Aktuell wird unter anderem das [http://pad.spline.de/ SplinePad] genutzt.		* Mit der Nextcloud und Edupads könnte das OpenProject hinfällig werden. Aktuell wird unter anderem das [http://pad.spline.de/ SplinePad] genutzt.
	* ~~Robert sucht~~ einen Deckel. Jan (FUB) meldet sich, wer möchte auch?		* Fabs hört auf, wir brauchen einen neuen Deckel. Jan (FUB) meldet sich, wer möchte auch?
	* Robert hätte gerne, dass das Geld für die Domains regelmäßig überwiesen wird.		* Robert hätte gerne, dass das Geld für die Domains regelmäßig überwiesen wird.
	* Die Domains liegen bei INWX.		* Die Domains liegen bei INWX.
Zeile 61:		Zeile 61:
	* Wir sollten uns das Bundesdatenschutzgesetz halten und auch eine Datenschutzerklärung veröffentlichen. Eine Rechtsberatung bzw. eine Absicherung bei Fehlern/Verstößen sollte geplant werden.		* Wir sollten uns das Bundesdatenschutzgesetz halten und auch eine Datenschutzerklärung veröffentlichen. Eine Rechtsberatung bzw. eine Absicherung bei Fehlern/Verstößen sollte geplant werden.

	* ~~AZAS~~		* Richards Anmeldesystem
	** Dresden benutzt das ~~AZAS~~ von Richard, Berlin hat evtl. ein selbst erstelltes, Siegen hat noch keine Ahnung		** Dresden benutzt das Anemdlesystem von Richard, Berlin hat evtl. ein selbst erstelltes, Siegen hat noch keine Ahnung
	** Chemie ~~benutzt~~ auch das ~~AZAS~~		** Chemie will auch das System von Richard benutzen
	** Das Frontend ist nicht sicher (das Backend ist sehr sicher), muss es aber nicht sein. Allerdings ist es noch ausbaufähig, da anscheinend kleinere Bugs auftreten.		** Das Frontend ist nicht besonders sicher (das Backend ist sehr sicher), muss es aber auch nicht sein. Allerdings ist es noch ausbaufähig, da anscheinend kleinere Bugs auftreten.
	** In scala geschrieben		** In scala geschrieben
	** Robert möchte erst auf eine zentrales Accountsystem hinarbeiten und danach auf ein zentrales Anmeldesystem.		** Robert möchte erst auf eine zentrales Accountsystem hinarbeiten und danach auf ein zentrales Anmeldesystem.
Zeile 74:		Zeile 74:

	== Zusammenfassung ==		== Zusammenfassung ==
			In naher Zukunft wird die Mailingliste umziehen, des weiteren wird mit dem StaPF über die Nötigkeit des Ticketsystems und einer Cloud diskutiert werden. Robert schließt sich mit den entsprechenden Leuten kurz.

			Des weiteren ist der Umzug der Accounts in ein LDAP in Planung.

	[[Kategorie:AK-Protokolle]]		[Kategorie:AK-Protokolle]]
	[[Kategorie:WiSe16]]		[[Kategorie:WiSe16]]
	[[Kategorie:IT]]		[[Kategorie:IT]]

ENik am 12. November 2016 um 11:43 Uhr

2016-11-12T11:43:14Z

← Nächstältere Version		Version vom 12. November 2016, 13:43 Uhr
Zeile 9:		Zeile 9:
	: 11:06 Uhr		: 11:06 Uhr
	; Ende		; Ende
	: HH:MM Uhr		: 12:42 Uhr
	; Redeleitung		; Redeleitung
	: Robert Löffler (KN)		: Robert Löffler (KN)
Zeile 37:		Zeile 37:
	* Es gibt noch keinen zentralen LDAP-Server für die Account-Verwaltung		* Es gibt noch keinen zentralen LDAP-Server für die Account-Verwaltung
	* Wir haben einen neuen Mailman (Mailman3, [http://lists.zapf.in] ) mit coolem Management Frontend. Da hin sollen demnächst alle Listen umziehen		* Wir haben einen neuen Mailman (Mailman3, [http://lists.zapf.in] ) mit coolem Management Frontend. Da hin sollen demnächst alle Listen umziehen
	* Es gibt eine neues Design im Wiki. Allerdings gibt es noch ein paar kleine Bugs. Auch der Studienführer ist im neuen Design. Dort und auch bei den Lists kann SSL aktiviert werden. Der Umzug für die ZaPFList dauert evtl. noch ein bisschen, da im neuen Release z.B die Benutzeraccounts nicht mehr so gut verwaltet werden können.		* Es gibt eine neues Design im Wiki. Allerdings gibt es noch ein paar kleine Bugs. Auch der Studienführer ist im neuen Design. Dort und auch bei den Lists kann demnächst SSL aktiviert werden. Der Umzug für die ZaPFList dauert evtl. noch ein bisschen, da im neuen Release z.B die Benutzeraccounts nicht mehr so gut verwaltet werden können.
	* Auf dem Server selbst läuft ein postfix, Richard wirft ein, dass das ein Problem ist, da der Server nicht gewhitelistet ist. Wir brauchen einen etablierten SMTP, das Problem an in Jena war, dass Richards Server kein Sender-Score hatte.		* Auf dem Server selbst läuft ein postfix, Richard wirft ein, dass das ein Problem ist, da der Server nicht gewhitelistet ist. Wir brauchen einen etablierten SMTP, das Problem an in Jena war, dass Richards Server kein Sender-Score hatte.
	* Robert würde sich gerne noch mit dem StaPF zusammen setzen, da der das OpenProject (Ticketsystem) aktuell nicht genutzt wird. Aktuell nutzt es Berlin. Ein Problem ist, dass es oft Verbindungsabbrüche gibt.		* Robert würde sich gerne noch mit dem StaPF zusammen setzen, da der das OpenProject (Ticketsystem) aktuell nicht genutzt wird. Aktuell nutzt es Berlin. Ein Problem ist, dass es oft Verbindungsabbrüche gibt.
Zeile 50:		Zeile 50:
	* Man sollte auf eine Root-Server und keinen VServer benutzen, da eine NextCloud zu viel Ressourcen frisst. Allerdings könnte man sich für weniger Geld einen NextCloud-Server mieten. Außerdem ist die Administrationsarbeit sehr aufwendig. Des weiteren stellt sich die Frage nach der Ausfallsicherheit. Robert hat nachgeschaut, für 10€ bekommen wir eine Nextcloud mit 100GB. Robert redet mit dem StaPF darüber		* Man sollte auf eine Root-Server und keinen VServer benutzen, da eine NextCloud zu viel Ressourcen frisst. Allerdings könnte man sich für weniger Geld einen NextCloud-Server mieten. Außerdem ist die Administrationsarbeit sehr aufwendig. Des weiteren stellt sich die Frage nach der Ausfallsicherheit. Robert hat nachgeschaut, für 10€ bekommen wir eine Nextcloud mit 100GB. Robert redet mit dem StaPF darüber
	* Es kommt die Frage auf, ob der Phabricator auch für andere Projekte genutzt werden kann. Es kann ausprobiert werden, ist aber für ein Projektmanagement nicht besonders sinnvoll.		* Es kommt die Frage auf, ob der Phabricator auch für andere Projekte genutzt werden kann. Es kann ausprobiert werden, ist aber für ein Projektmanagement nicht besonders sinnvoll.
	* ~~Wollen wir wirklich ein~~ LDAP		* Diskussion über LDAP
	** Aufwand		** Aufwand
	** Für ein Zentrales Anmeldesystem nötig		** Für ein Zentrales Anmeldesystem nötig
	** Oauth funktioniert nicht mit Mumble, Etherpad und Mailman, mit LDAP geht das		** Oauth funktioniert nicht mit Mumble, Etherpad und Mailman, mit LDAP geht das
	** Man könnte das ganze über OpenID laufen lassen.		** Man könnte das ganze über OpenID laufen lassen.
	** Da es im Wiki eine Versionierung mithilfe der Benutzer(namen) gibt, sollten die alten Benutzer nicht gelöscht werden. Robert möchte die Nutzer neu anlegen		** Da es im Wiki eine Versionierung mithilfe der Benutzer(namen) gibt, sollten die alten Benutzer nicht gelöscht werden. Robert möchte die Nutzer neu anlegen, die Nutzer des Wiki sollte "anständig" migriert werden.
	** Richard ist dagegen, dass wir uns wieder selbst eine Lösung zusammen basteln und damit wieder mehr Arbeit haben.		** Richard ist dagegen, dass wir uns wieder selbst eine Lösung zusammen basteln und damit wieder mehr Arbeit haben.
	** Bei LDAP gibt es folgenden Probleme: Auf die Rechtevergabe muss sehr viel Wert gelegt werden.		** Bei LDAP gibt es folgenden Probleme: Auf die Rechtevergabe muss sehr viel Wert gelegt werden.
	** Wir wollen ein LDAP, das nicht zu komplex wird.		** Wir wollen ein LDAP, das nicht zu komplex wird.
	* Wir sollten uns das Bundesdatenschutzgesetz halten und auch eine Datenschutzerklärung veröffentlichen. Eine Rechtsberatung bzw. eine Absicherung bei Fehlern/Verstößen sollte geplant werden.		* Wir sollten uns das Bundesdatenschutzgesetz halten und auch eine Datenschutzerklärung veröffentlichen. Eine Rechtsberatung bzw. eine Absicherung bei Fehlern/Verstößen sollte geplant werden.

			* AZAS
			** Dresden benutzt das AZAS von Richard, Berlin hat evtl. ein selbst erstelltes, Siegen hat noch keine Ahnung
			** Chemie benutzt auch das AZAS
			** Das Frontend ist nicht sicher (das Backend ist sehr sicher), muss es aber nicht sein. Allerdings ist es noch ausbaufähig, da anscheinend kleinere Bugs auftreten.
			** In scala geschrieben
			** Robert möchte erst auf eine zentrales Accountsystem hinarbeiten und danach auf ein zentrales Anmeldesystem.
			** Persönliche Tokens wären gut um private Daten zu schützen
			** Richard mag kein System, auf dem gleichzeitig ein Mailserver laufen muss um z.B. die Mails zu verifizieren.
			** Robert lagert diese Diskussion in einen Bier-AK oder ähnlichem aus.

			* Da es keine weiteren Punkte gibt, wird die Sitzung beendet.

	== Zusammenfassung ==		== Zusammenfassung ==


	~~<!--~~
	* Das Ergebnis der Abstimmung:
	** <span style="color:green">'''Anzahl Ja-Stimmen:''' Anzahl</span>
	** <span style="color:black">'''Anzahl Enthaltungen:''' Anzahl</span>
	** <span style="color:red">'''Anzahl Nein-Stimmen:''' Anzahl</span>
	~~-->~~

	[[Kategorie:AK-Protokolle]]		[[Kategorie:AK-Protokolle]]
	[[Kategorie:WiSe16]]		[[Kategorie:WiSe16]]
	[[Kategorie:IT]]		[[Kategorie:IT]]

ENik am 12. November 2016 um 11:25 Uhr

2016-11-12T11:25:53Z

← Nächstältere Version		Version vom 12. November 2016, 13:25 Uhr
Zeile 50:		Zeile 50:
	* Man sollte auf eine Root-Server und keinen VServer benutzen, da eine NextCloud zu viel Ressourcen frisst. Allerdings könnte man sich für weniger Geld einen NextCloud-Server mieten. Außerdem ist die Administrationsarbeit sehr aufwendig. Des weiteren stellt sich die Frage nach der Ausfallsicherheit. Robert hat nachgeschaut, für 10€ bekommen wir eine Nextcloud mit 100GB. Robert redet mit dem StaPF darüber		* Man sollte auf eine Root-Server und keinen VServer benutzen, da eine NextCloud zu viel Ressourcen frisst. Allerdings könnte man sich für weniger Geld einen NextCloud-Server mieten. Außerdem ist die Administrationsarbeit sehr aufwendig. Des weiteren stellt sich die Frage nach der Ausfallsicherheit. Robert hat nachgeschaut, für 10€ bekommen wir eine Nextcloud mit 100GB. Robert redet mit dem StaPF darüber
	* Es kommt die Frage auf, ob der Phabricator auch für andere Projekte genutzt werden kann. Es kann ausprobiert werden, ist aber für ein Projektmanagement nicht besonders sinnvoll.		* Es kommt die Frage auf, ob der Phabricator auch für andere Projekte genutzt werden kann. Es kann ausprobiert werden, ist aber für ein Projektmanagement nicht besonders sinnvoll.
			* Wollen wir wirklich ein LDAP
			** Aufwand
			** Für ein Zentrales Anmeldesystem nötig
			** Oauth funktioniert nicht mit Mumble, Etherpad und Mailman, mit LDAP geht das
			** Man könnte das ganze über OpenID laufen lassen.
			** Da es im Wiki eine Versionierung mithilfe der Benutzer(namen) gibt, sollten die alten Benutzer nicht gelöscht werden. Robert möchte die Nutzer neu anlegen
			** Richard ist dagegen, dass wir uns wieder selbst eine Lösung zusammen basteln und damit wieder mehr Arbeit haben.
			** Bei LDAP gibt es folgenden Probleme: Auf die Rechtevergabe muss sehr viel Wert gelegt werden.
			** Wir wollen ein LDAP, das nicht zu komplex wird.
			* Wir sollten uns das Bundesdatenschutzgesetz halten und auch eine Datenschutzerklärung veröffentlichen. Eine Rechtsberatung bzw. eine Absicherung bei Fehlern/Verstößen sollte geplant werden.

	== Zusammenfassung ==		== Zusammenfassung ==
Zeile 64:		Zeile 73:
	[[Kategorie:AK-Protokolle]]		[[Kategorie:AK-Protokolle]]
	[[Kategorie:WiSe16]]		[[Kategorie:WiSe16]]
			[[Kategorie:IT]]

ENik am 12. November 2016 um 10:52 Uhr

2016-11-12T10:52:48Z

← Nächstältere Version		Version vom 12. November 2016, 12:52 Uhr
Zeile 34:		Zeile 34:

	== Protokoll ==		== Protokoll ==
	Robert berichtet:		'''Robert berichtet:'''
	* Es gibt noch keinen zentralen LDAP-Server für die Account-Verwaltung		* Es gibt noch keinen zentralen LDAP-Server für die Account-Verwaltung
	* Wir haben einen neuen Mailman (Mailman3, [http://lists.zapf.in] ) mit coolem Management Frontend. Da hin sollen demnächst alle Listen umziehen		* Wir haben einen neuen Mailman (Mailman3, [http://lists.zapf.in] ) mit coolem Management Frontend. Da hin sollen demnächst alle Listen umziehen
	* Es gibt eine neues Design im Wiki. Allerdings gibt es noch ein paar kleine Bugs. Auch der Studienführer ist im neuen Design. Dort und auch bei den Lists kann SSL aktiviert werden. Der Umzug für die ZaPFList dauert evtl. noch ein bisschen, da im neuen Release z.B die Benutzeraccounts nicht mehr so gut verwaltet werden können.		* Es gibt eine neues Design im Wiki. Allerdings gibt es noch ein paar kleine Bugs. Auch der Studienführer ist im neuen Design. Dort und auch bei den Lists kann SSL aktiviert werden. Der Umzug für die ZaPFList dauert evtl. noch ein bisschen, da im neuen Release z.B die Benutzeraccounts nicht mehr so gut verwaltet werden können.
	* Auf dem Server selbst läuft ein postfix, Richard wirft ein, dass das ein Problem ist, da der Server nicht gewhitelistet ist. Wir brauchen einen etablierten SMTP, das Problem an in Jena war, dass Richards Server kein Sender-Score hatte.		* Auf dem Server selbst läuft ein postfix, Richard wirft ein, dass das ein Problem ist, da der Server nicht gewhitelistet ist. Wir brauchen einen etablierten SMTP, das Problem an in Jena war, dass Richards Server kein Sender-Score hatte.
	* Robert würde sich gerne noch mit dem ~~STaPf~~ zusammen setzen, da der das OpenProject aktuell nicht genutzt wird. Aktuell nutzt es Berlin. Ein Problem ist, dass es oft Verbindungsabbrüche gibt.		* Robert würde sich gerne noch mit dem StaPF zusammen setzen, da der das OpenProject (Ticketsystem) aktuell nicht genutzt wird. Aktuell nutzt es Berlin. Ein Problem ist, dass es oft Verbindungsabbrüche gibt.
	* Der ZaPF e.V. will eine Nextcloud		* Der ZaPF e.V. will eine Nextcloud
			* Mit der Nextcloud und Edupads könnte das OpenProject hinfällig werden. Aktuell wird unter anderem das [http://pad.spline.de/ SplinePad] genutzt.
			* Robert sucht einen Deckel. Jan (FUB) meldet sich, wer möchte auch?
			* Robert hätte gerne, dass das Geld für die Domains regelmäßig überwiesen wird.
			* Die Domains liegen bei INWX.
			* Die Server an sich liegen bei Strato.

			'''Allgemeine Diskussion'''
			* Man sollte auf eine Root-Server und keinen VServer benutzen, da eine NextCloud zu viel Ressourcen frisst. Allerdings könnte man sich für weniger Geld einen NextCloud-Server mieten. Außerdem ist die Administrationsarbeit sehr aufwendig. Des weiteren stellt sich die Frage nach der Ausfallsicherheit. Robert hat nachgeschaut, für 10€ bekommen wir eine Nextcloud mit 100GB. Robert redet mit dem StaPF darüber
			* Es kommt die Frage auf, ob der Phabricator auch für andere Projekte genutzt werden kann. Es kann ausprobiert werden, ist aber für ein Projektmanagement nicht besonders sinnvoll.


	== Zusammenfassung ==		== Zusammenfassung ==