AG:Liquid/Betriebsdoku

Arbeitsgruppen

ständige Arbeitsgruppen	—	Inhaltliche Arbeitsgruppen	—	Operative Arbeitsgruppen
Strategie & Kampagnen Außenvertretung Inneres				Technik Liquid & Wiki

Übersicht über alle Arbeitsgruppen

Inhaltsverzeichnis

1 Einleitung
2 Prozesse LiquidFeedback-System
3 Prozesse Abgleich Mitgliederverwaltung und LiquidFeedback-System
4 LiquidFeedback-System
5 Arbeitsdokumente

Einleitung

Die Piratenpartei Österreichs betreibt die Software LiquidFeedback zur Meinungs- und Willensbildung und für Abstimmungen in der Partei. Direkte Programm- und Geschäftsordnungsänderungen sind in Satzung und Bundesgeschäftsordnung vorgesehen.

Dieses Dokument ist ganz stark an der Betriebsdoku der Piratenpartei Deutschland unter http://wiki.piratenpartei.de/LQPP/Betriebsdoku orientiert und in Teilen von dort kopiert.

Die Software besteht aus zwei Teilen, und zwar zum einen LiquidFeedback-Core, bestehend aus einer PostgreSQL-Datenbank und Dienstprogrammen, sowie zum anderen LiquidFeedback-Frontend, welches ein Webfrontend zur Datenbank von LiquidFeedback-Core ist. Zum Betrieb der Software werden abhängige Softwarekomponenten sowie weitere Dienstprogramme benötigt.

Auf den folgenden Seiten veröffentlicht der Anbieter Informationen zur Software sowie die Software selber unter einer MIT/X11-Lizenz zur freien Verwendung durch jeden:

Formale Grundlage des LiquidFeedback-Systembetriebs bilden die folgenden Beschlüsse:

TODO

Dieses Dokument wird durch die Arbeitsgruppe LiquidFeedback gepflegt.

Prozesse LiquidFeedback-System

Die in diesem Bereich des Dokumentes aufgeführten Prozesse werden auf den Betrieb des LiquidFeedback-Systems angewendet.

Prozess Änderung Softwarekomponenten

Änderungen an der Auswahl der verwendeten Softwarekomponenten werden durch die Administratoren vorgenommen, sofern dies für den Systembetrieb erforderlich oder zweckdienlich ist. Änderungen an der Auswahl der Softwarekomponenten, die Einfluss auf wesentliche Funktionsmerkmale des Systems haben, müssen in Einklang mit der Geschäftsordnung stehen und der Bundesgeschäftsführung zur Kenntnis gebracht werden. Alle Änderungen der verwendeten Softwarekomponenten werden durch die Administratoren im Verzeichnis Softwarekomponenten dokumentiert.

Prozess Einspielen Update

Sofern für Softwarekomponenten ein Update zur Verfügung steht, kann dieses durch die Administratoren eingespielt werden. Wenn das Update Einfluss auf wesentliche Funktionsmerkmale des Systems hat, muss es in Einklang mit der Geschäftsordnung stehen und der Bundesgeschäftsführung zur Kenntnis gebracht werden. Das Einspielen von Updates wird durch die Administratoren im Verzeichnis Softwarekomponenten dokumentiert.

Prozess Änderung Konfiguration

Änderungen an der Konfiguration der verwendeten Softwarekomponenten werden durch die Administratoren durchgeführt, sofern dies für den Systembetrieb erforderlich oder zweckdienlich ist. Konfigurationänderungen, die Einfluss auf wesentliche Funktionsmerkmale des Systems haben, müssen in Einklang mit der Geschäftsordnung stehen und der Bundesgeschäftsführung zur Kenntnis gebracht werden. Alle Änderungen der Konfiguration sind durch die Administratoren im Verzeichnis Konfigurationsänderungen zu dokumentieren. Dieses Verzeichnis wird durch die Administratoren teilweise nicht-öffentlich geführt. Mitgliedern der Taskforce Technik und der Bundesgeschäftsführung wird jederzeit Einsicht gewährt. Das Verzeichnis Konfigurationsänderungen wird mittels eines Revisionskontrollsystems (ein Wiki-System) elektronisch geführt. Der Datenbestand des Revisionskontrollsystems unterliegt dem Prozess Datensicherung.

Prozess Überprüfung auf sicherheitsrelevante Meldungen

Für alle verwendeten Softwarekomponenten werden durch die Administratoren regelmäßig – mindestens wöchentlich – die Seiten mit Sicherheitsmeldungen der Anbieter der eingesetzten Softwarekomponenten auf für den Systembetrieb relevante Meldungen überprüft. Für alle Softwarekomponenten, für die das automatisierte Bereitstellen von Sicherheitsupdates zur Verfügung steht, wird stattdessen regelmäßig durch die Administratoren überprüft, ob Sicherheitsupdates zur Installation anstehen. Sofern sich ergibt, dass Sicherheitsupdates durchzuführen sind, wird nach dem Prozess Einspielen Sicherheitsupdate vorgegangen.

Prozess Einspielen Sicherheitsupdate

Sofern durch den Prozess Überprüfung sicherheitsrelevanter Meldungen oder auf andere Art durch die Administratoren festgestellt wird, dass, um den Systembetrieb zu gewährleisten, ein Sicherheitsupdate einzuspielen ist, wird dieses Sicherheitsupdate durch die Administratoren unverzüglich eingespielt. Das Einspielen eines Sicherheitsupdates wird entsprechend dem Prozess Einspielen Update dokumentiert.

Prozess Überwachung Verfügbarkeit

Es wird ein automatisiertes Verfahren betrieben, das laufend die Verfügbarkeit der angebotenen Dienste überprüft. Bei Kenntniserlangung einer Nichtverfügbarkeit leiten die Administratoren unverzüglich geeignete Maßnahmen zu Wiederherstellung der Verfügbarkeit ein. Die Ereignisse der Nichtverfügbarkeit sind durch das eingesetzte Verfahren zu dokumentieren.

Prozess Überwachung Systemressourcen

Es wird ein automatisiertes Verfahren betrieben, das laufend die für den Systembetrieb relevanten Ressourceninformationen protokolliert. Hierzu gehören insbesondere:

Auslastung der CPU,
Auslastung des Arbeitsspeichers,
Auslastung des Festplattenspeichers,
Auslastung des Festplatten-IO,
Auslastung des Netzwerk-IO.

Die protokollierten Daten werden durch die Administratoren regelmäßig – mindestens wöchentlich – auf bevorstehende Engpässe von Ressourcen überprüft. Wenn aufgrund der protokollierten Daten anzunehmen ist, dass Engpässe an Ressourcen bevorstehen, ergreifen die Administratoren geeignete Maßnahmen, um nicht mehr benötigte Ressourcen freizugeben. Sofern anzunehmen ist, dass die zu erwartenden Engpässe nur durch Bereitstellung weiterer Ressourcen vermieden werden können, ist die Taskforce Technik und die Bundesgeschäftsführung hierüber unverzüglich in Kenntnis zu setzen.

Prozess Datensicherung

Prozess Überprüfung der Datensicherung

Prozess Wiederherstellung einer Datensicherung

Prozess Zugriffsberechtigung

Die Zugriffsberechtigung „Teilnehmer“ wird durch die Mitgliederverwaltung gemäß Satzung und Bundesgeschäftsordnung erteilt und wieder entzogen. Bei vorübergehendem Verlust der Stimmberechtigung in der Partei wird durch die Mitgliederverwaltung die Zugriffsberechtigung vorübergehend entzogen und bei Wiedererlangung der Stimmberechtigung wieder erteilt. Die Erteilung und der Entzug der Zugriffsberechtigung erfolgt automatisch, es erfolgt keine manuelle Dokumentation. Das nähere Verfahren wird in den unter Abgleich Mitgliederverwaltung und LiquidFeedback-System dargestellten Prozessen beschrieben.

Die Zugriffsberechtigung „Administrator LiquidFeedback“ wird durch die AG Technik erteilt und auch wieder entzogen. Das Erteilen bzw. der Entzug der Berechtigung wird im Verzeichnis Zugriffsberechtigungen dokumentiert. Die Zugriffsberechtigung darf nur durch die Person ausgeübt werden, der sie erteilt wurde. Eine Weitergabe der Zugriffsberechtigung ist unzulässig. Die technische Durchführung der Erteilung bzw. des Entzugs des Zugriffs erfolgt durch die Administratoren.

Prozess Sicherheitsaudit

Zur unabhängigen fachlichen Überprüfung der sicherheitsrelevanten organisatorischen und technischen Maßnahmen des Betriebs von LiquidFeedback wird ein fortlaufendes IT-Sicherheitsaudit durchgeführt. Dieses wird durch die Taskforce Technik beauftragt. Sofern aufgrund dieses Prozesses Mängel an Prozessen festgestellt werden, werden durch die Taskforce Technik geeignete Änderungen vorgenommen, um diese abzustellen. Sofern Mängel an der Ausführung der Prozesse festgestellt werden, werden durch die Ausführenden geeignete Maßnahmen getroffen, um diese abzustellen.

Prozess Erreichbarkeit in dringlichen Angelegenheiten

Jede an den in diesem Dokument beschriebenen Prozessen beteiligten Stellen stellt einen Rufnummernplan auf, der die Reihenfolge festlegt, in der die Mitarbeiter der Stelle im Falle einer dringlichen Angelegenheit durch die anderen beteiligten Stellen erreichbar sind. Die Rufnummernpläne werden nicht-öffentlich geführt und werden den anderen beteiligten Stellen bekanntgegeben. Änderungen an einem Rufnummernplan werden unverzüglich allen anderen beteiligten Stellen bekanntgegeben.

Prozess Disaster Recovery

Dieser Prozess wird nach dem Eintritt von Unglücksfällen, wie beispielsweise technischen oder menschlichen Fehlern, Naturereignissen oder außerrechtlichen Zuständen, angewendet. Die einzelnen Unterbereiche finden nur Anwendung, wenn es aufgrund des Unglücksfalls notwendig oder zweckmäßig ist.

Überprüfung und ggfs. Wiederherstellung der personellen Arbeitsfähigkeit

Es wird durch die Bundesgeschäftsführung geprüft, ob die personelle Arbeitsfähigkeit der beauftragten Administratoren gegeben ist. Im Bedarfsfalle sind weitere Administratoren zu beauftragen.

Überprüfung und ggfs. Wiederherstellung der Infrastruktur- und Hardwarekomponenten

Die Administratoren überprüfen die Funktionsfähigkeit der Infrastruktur- und Hardwarekomponenten und vergewissern sich ggfs. von der Arbeitsfähigkeit der beauftragten Rechenzentren. Sofern Infrastruktur- oder Hardwarekomponenten ersetzt werden müssen oder ein beauftragtes Rechenzentrum nicht mehr arbeitsfähig ist, teilen die Administratoren dies der Taskforce Technik und der Bundesgeschäftsführung unter Angabe von Lösungsmöglichkeiten mit.

Überprüfung und ggfs. Wiederherstellung der Softwarekomponenten und Konfiguration

Die Administratoren überprüfen alle verwendeten Softwarekomponenten einschließlich ihrer Konfiguration auf Funktionsfähigkeit. Sofern Softwarekomponenten nicht funktionsfähig sind, werden diese durch die Administratoren erneut eingespielt. Hierbei wird jeweils die letzte im Verzeichnis Softwarekomponenten dokumentierte Version eingespielt. Sind Konfigurationsdaten fehlerhaft oder verloren, werden diese von den Administratoren durch den jeweils letzten durch den Prozess Änderung Konfiguration dokumentierten Konfigurationsstand ersetzt. Sofern die Softwarekomponenten einschließlich ihrer Konfiguration in erheblichem Maße verloren oder anderweitig funktionsunfähig sind, wird das entsprechende Rechnersystem – entsprechend dem Dokument Installationsskript sowie den vorgenannten Regelungen hinsichtlich der Versionen der Softwarekomponenten und der Konfiguration – durch die Administratoren vollständig neu eingerichtet.

Überprüfung und ggfs. Wiederherstellung von Daten

Die Administratoren überprüfen, ob die Daten des Systems vollständig sind. Sofern Daten ganz oder teilweise verloren gegangen sind, werden diese unter Anwendung des Prozess Wiederherstellung einer Datensicherung wiederhergestellt.

Löschung unzulässiger Inhalte

Die Administratoren sind dazu berechtigt, zweifelsfrei unzulässige Inhalte im Sinne der Nutzungsbedingungen eigenständig zu löschen. Im Zweifelsfalle informieren die Administratoren die Taskforce Justitia und die Bundesgeschäftsführung über fragwürdige Inhalte, falls diese den Administratoren zur Kenntnis kommen. Jede Löschung wird öffentlich dokumentiert.

Prozess physikalische Absicherung (Zutrittskontrolle)

Die für den Systembetrieb von LiquidFeedback verwendeten Datenverarbeitungsanlagen werden in Rechenzentren betrieben. Die Zutrittskontrolle ist daher nur durch das Rechenzentrum durchführbar. Dies wird bei der Auswahl von Rechenzentren berücksichtigt. Die entsprechenden Verfahrensbeschreibungen der Rechenzentren werden vor Abschluss eines Vertrages geprüft.

Prozess Protokollierung manueller Datenbankabfragen und -eingaben

Manuelle Abfragen und Eingaben von Daten in die Datenbank von LiquidFeedback werden durch die Administratoren über SQL-Abfragen durchgeführt. Da über SQL-Anfragen prinzipiell jegliche Art von Abfragen und Eingaben durchführbar sind, werden alle Datenbankeingriffe protokolliert (siehe Logbuch: Datenbankeingriffe).

Prozess Sperrung von Accounts nach Verstoß gegen die Nutzungsbedingungen

Wenn ein Teilnehmer gegen die Nutzungsbedingungen von LiquidFeedback in einer Weise verstößt, die mit Sperrung sanktioniert ist, sperren die Administratoren den entsprechenden Account ohne Löschung zugehöriger Daten. Die Sperrung kann von der Bundesgeschäftsführung wieder aufgehoben werden.

Prozesse Abgleich Mitgliederverwaltung und LiquidFeedback-System

Für den Betrieb des Systems ist es erforderlich, dass eine Verknüpfung zwischen dem von der Mitgliederverwaltung geführten Mitglied und dem im LiquidFeedback-System angelegten Teilnehmerkonto hergestellt wird, damit:

nur Mitglieder der Partei ein Teilnehmerkonto erlangen können;
im Falle des Endes der Parteimitgliedschaft oder des vorübergehenden Verlustes des Stimmrechts das Teilnehmerkonto gesperrt werden kann;
im Falle der Wiedererlangung des Stimmrechts das Konto auch wieder entsperrt werden kann;
die ordnungsgemässe Erteilung von Zugangsberechtigungen nachträglich überprüft werden kann;
im Falle von Rechtsverletzungen durch einen Teilnehmer dieser ermittelt werden kann.

Das LiquidFeedback-Teilnehmerkonto wird erst nach Bestätigung der LiquidFeedback-Nutzungsbedingungen durch den Nutzer aktiviert und mit einem Einladungsschlüssel verknüpft, den der Nutzer bei der Registrierung vorlegen muss.

Die Auflösung des gewählten Pseudonyms bei Benutzung des Systems kann von der Geschäftsführung über die Mitgliederverwaltung aufgelöst werden. Die Auflösung eines Pseudonyms kann nur durch die Geschäftsführung erfolgen. Die Zusammenarbeit der beteiligten Stellen wird durch die folgenden Prozesse beschrieben.

Prozess Neues Mitglied

Die Mitgliederverwaltung teilt dem LiquidFeedback-System eine Identifikation und die E-Mail-Adresse und die Landesorganisation für den anzulegenden Account mit.
Das LiquidFeedback-System erzeugt einen Einladungsschlüssel und versendet die Einladung.

Dieser Vorgang läuft automatisch, es erfolgt keine manuelle Protokollierung.

Prozess Statusänderung

Dieser Prozess findet für die Statusänderungen „Verlust der Stimmberechtigung“, „Wiedererlangung der Stimmberechtigung“, „Ende der Teilnahme/Parteiaustritt“ und „Wechsel der Landesorganisation“ jeweils getrennt Anwendung.

Die Mitgliederverwaltung teilt dem LiquidFeedback-System direkt die Statusänderungen mit.
Das LiquidFeedback-System führt die Statusänderung durch.

Dieser Vorgang läuft automatisch, es erfolgt keine manuelle Protokollierung.

Prozess Auflösung der Pseudonymität

Dieser Prozess beschreibt die begründete Auflösung der Identität eines Benutzers. Dieser Prozess wird durch die Bundesgeschäftsführung:

aufgrund Verfügung eines ordentlichen Gerichts der Republik Österreich; oder
aufgrund Hilfeersuchens einer berechtigten Stelle der Republik Österreich; oder
durch Beschluss des zuständigen Schiedsgerichts aufgrund parteischädigenden Verhaltens im Sinne der Satzung; oder
durch Beschluss der Bundesgeschäftsführung zur Abwehr von Schaden für die Partei, zur Verhinderung erheblicher Straftaten und bei begründetem Verdacht, dass ein Teilnehmer gleichzeitig mehrere Teilnehmer-Accounts hat oder kontrolliert (Sockenpuppen), eingeleitet.

Sofern der Forderung der den Prozess einleitenden Stelle nicht nachgekommen wird, ist dies unter Angabe der Gründe schriftlich mitzuteilen.

Die Bundesgeschäftsführung berichtet nach Abschluss des Prozesses öffentlich in anonymisierter Form über den Vorgang.

Prozess Umschlüsselung

Dieser Prozess findet Anwendung, wenn Einladungsschlüssel zu Benutzerkonten nicht berechtigten Personen bekannt geworden sind.

Der betroffene Account wird gesperrt und die E-Mail-Adresse des Nutzers durch die Administratoren auf die von der Bundesgeschäftsführung genannte E-Mail-Adresse korrigiert.
Danach erhält das Mitglied entsprechend dem Prozess Neues Mitglied einen neuen Einladungscode. Dem Mitglied wird im Zuge dieses Prozesses eine neue Einladung zugesandt.

Sofern ein erheblicher Teil von Zuordnungen nicht berechtigten Personen bekannt geworden sind, wird dieser Prozess auf alle Schlüsselpaare angewendet.

Prozess Teilnehmerkreisprüfung

Um zu überprüfen, ob der Teilnehmerkreis tatsächlich den laut der Mitgliederverwaltung berechtigten Mitgliedern entspricht, wird in unregelmäßigen Abständen folgendes Verfahren durchgeführt:

Die Administratoren erstellen eine Liste der stimmberechtigten Accounts inklusive der Zuordnung der Landesorganisation.
Diese wird der Bundesgeschäftsführung übermittelt.
Die Bundesgeschäftsführung prüft, ob die in dieser Liste vermerkte Stimmberechtigung tatsächlich den eigenen Daten entspricht.

Die Liste der stimmberechtigten Accounts ist der Bundesgeschäftsführung auch über die Datenbank-Dumps verfügbar.

Prozess Einladungsschlüssel verloren

Ist ein Einladungsschlüssel verloren gegangen, meldet sich das Mitglied bei den Administratoren. Die Administratoren senden dann einen neuen Einladungsschlüssel an die im System gespeicherte E-Mail-Adresse.

Dieser Prozess kann von den Administratoren auch eigenständig eingeleitet werden.

Prozess Validierung einer Abstimmung

Dieser Prozess kann durch die Bundesgeschäftsordnung für abgeschlossene Abstimmungen binnen einer Woche nach Ende der Abstimmung gestartet werden, sofern diese zu einem verbindlichen Beschluss führen bzw. geführt haben. Die Ankündigung einer solchen Validierung kann bereits vor Ende der Abstimmung erfolgen. Dieser Prozess kann online (beispielsweise per Mail) oder offline (beispielsweise bei einer Generalversammlung) durchgeführt werden.

Die Bundesgeschäftsführung teilt den direkten Teilnehmern und jenen, die durch Delegation an der Abstimmung teilgenommen haben, mit, dass eine Validierung einer Abstimmung durchgeführt wird.
Die Mitglieder antworten der Bundesgeschäftsführung per E-Mail, dass sie ihre direkte oder delegierte Teilnahme sowie ihren Stimmzettel validiert haben.
Der Prozess ist abgeschlossen, sobald alle Mitglieder ihre direkte oder delegierte Teilnahme sowie ihren Stimmzettel validiert haben.
Alle Mitglieder, die nach einem Monat nicht geantwortet haben, erhalten eine Erinnerung. Ob diese auf anderem Kommunikationsweg als die erste Anfrage erfolgt, obliegt der Entscheidung der Bundesgeschäftsführung. Außerdem werden die LiquidFeedback-Pseudonyme dieser Mitglieder veröffentlicht. Die Bundesgeschäftsführung schließt gleichzeitig den Prozess ab, indem sie eine Empfehlung an die Mitglieder abgibt, ob aufgrund dieser Unregelmäßigkeit die Abstimmung zu beanstanden ist oder nicht. (Zehn Mitglieder können eine Abstimmung unter Angabe technischer oder formaler Gründe bei der Bundesgeschäftsführung binnen zwei Monaten nach Ende der Abstimmungsphase beanstanden und dadurch aufheben.)

LiquidFeedback-System

Softwarekomponenten

Lfd. Nr.	Datum Inbetriebnahme	Komponente	Bezugsquelle	Sicherheitsmeldungen	Zweck	Datum Außerbetriebsetzung
1	11.07.2012	Debian GNU/Linux Basisinstallation	http://www.debian.org/	http://www.debian.org/security/	Basisbetriebssystem für den Systembetrieb	—
2	11.07.2012	Postgresql Datenbankserver	Debian-Paket	http://www.debian.org/security/ http://www.postgresql.org/support/security	Datenbankdienst zur Verwendung durch den LiquidFeedback-Core	—
3	11.07.2012	Lighttpd Webserver	http://www.lighttpd.net/	http://www.lighttpd.net/	Bereitstellung des LiquidFeedback-Frontends für Benutzer	—
4	11.07.2012	exim4 Mail-Transfer-Agent	http://www.exim.org/	http://www.exim.org/	Bereitstellung der LiquidFeedback-Mails für Benutzer	—
5	12.07.2012	LiquidFeedback-Core 2.0.11 inkl. Modifikationen für die Piratenpartei Österreichs	http://www.public-software-group.org/liquid_feedback_core bzw. https://github.com/PPOE/liquid_ppat_core	http://www.public-software-group.org/liquid_feedback_core bzw. https://github.com/PPOE/liquid_ppat_core	Bereitstellung des LiquidFeedback-Core-Systems	—
6	12.07.2012	LiquidFeedback-Frontend 2.0 inkl. Modifikationen für die Piratenpartei Österreichs	http://www.public-software-group.org/liquid_feedback_frontend bzw. https://github.com/PPOE/liquid_ppat_frontend	http://www.public-software-group.org/liquid_feedback_frontend bzw. https://github.com/PPOE/liquid_ppat_frontend	Bereitstellung des LiquidFeedback-Frontends für Benutzer	—
7	01.09.2012	LiquidFeedback-API	http://www.public-software-group.org/mercurial/lfapi	http://www.public-software-group.org/mercurial/lfapi	Bereitstellung der LiquidFeedback-API für Benutzer	—

Bestands- und Nutzungsdaten

Kategorie „Öffentlich“

Daten dieser Kategorie werden jedem übermittelt, der diese abfragt. Folgende Daten gehören zu dieser Kategorie:

Initiativtexte (Antragstexte mit allen Revisionen);
verschiedene Nutzungsdaten im Zusammenhang mit Initiativen (Zeitpunkt der Erstellung, Aktualisierung des Entwurfs, Zurückziehen der Initiative);
Anregungstexte;
Zeitpunkt der Erstellung einer Anregung.

Kategorie „Teilnehmer-Öffentlich“

Daten dieser Kategorie werden nur an angemeldete Teilnehmer des Systems übermittelt. Folgende Daten gehören zu dieser Kategorie:

numerische Benutzer-ID;
Zeitpunkt der Profilerstellung;
Zeitpunkte von Sperrungen und Reaktivierungen des Accounts;
Benutzername;
Historie des Benutzernamens;
Daten des Benutzerprofils;
Avatar und Bild des Benutzerprofils;
gespeicherte Kontakte, die als veröffentlicht markiert sind;
Mitgliedschaft in Themenbereichen;
Interesse an Themen;
Auto-Ablehnen und früher/später-abstimmen-Wunsch;
erteilte und empfangene Delegationen;
Unterstützerstimmen mit Delegationsstruktur;
Initiatoreigenschaft (bei noch nicht angenommenen Einladungen als Initiator nur für einen selbst und die Initiatoren);
Anregungsautoreneigenschaft;
Version des zuletzt gesichteten Entwurfstextes;
Bewertungsstimmen zu Anregungen (mit Delegationsstruktur);
Stimmabgaben bei Abstimmungen mit Delegationsstruktur.

Kategorie „Nicht-Öffentlich“

Daten dieser Kategorie werden nur an den Teilnehmer übermittelt, dem sie zugeordnet sind. Folgende Daten gehören zu dieser Kategorie:

Einladungsschlüssel;
Loginname;
Passwort;
im System hinterlegte E-Mail-Adresse;
Abstimmungsdaten während der Abstimmungsphase;
gespeicherte, aber nicht veröffentlichte Kontakte;
gespeicherte Zeitachsenfilter;
andere nicht-öffentliche Benutzereinstellungen (z. B. Anzeigeoptionen);
der persönliche API-Schlüssel, falls er erzeugt wurde.

Zugriffsberechtigung „Teilnehmer“

Das Verzeichnis der Zugriffsberechtigung „Teilnehmer“ wird durch die Mitgliederverwaltung als nicht-öffentliches Verzeichnis innerhalb der Mitgliederverwaltungssoftware geführt.

Ein Abgleich erfolgt automatisch durch Synchronisationsskripte.

Zugriffsberechtigung „Administrator LiquidFeedback-System“

Lfd. Nr.	Berechtigter	Datum Erteilung	Erteilt durch	Datum Entzug	Entzogen durch
1	lava	11.07.2012	-	-	-
2	verr	27.07.2012	-	-	-
3	Vilinthril (nur Frontend)	09.01.2013	-	-	-

Arbeitsdokumente

Logbuch: Datenbankeingriffe

kompletter Reset der Datenbank, Starten des Skripts zum Datenbankabgleich --Lava 18:09, 24. Jul. 2012 (CEST)
Änderung von globalem Lock auf Unit-Locks (vorerst mit Backup über admin_comment):

UPDATE member SET admin_comment = 'locked' WHERE locked = true;
UPDATE member SET locked = false;

--Lava 11:34, 11. Aug. 2012 (CEST)

Rücksetzen von User 52 auf Anfrage: UPDATE member SET active = false,activated = null,last_activity = null,password = null WHERE id = 52; --Lava 16:35, 11. Aug. 2012 (CEST)
erneutes Hinzufügen des globalen Locks (anstatt der admin_comments):

UPDATE member SET locked = true WHERE admin_comment = 'locked';
UPDATE member SET admin_comment = '';

--Lava 23:00, 11. Aug. 2012 (CEST)

Löschen eines Mitglieds (ausgetreten, nicht aktiv) --Lava 14:24, 13. Aug. 2012 (CEST)
per Default all notifications UPDATE member SET notify_level = 'all' WHERE notify_level IS NULL; --Lava 14:53, 20. Aug. 2012 (CEST)
Reset eines Mitglieds nach Bekanntwerden des Einladungscodes --Lava 21:40, 25. Aug. 2012 (CEST)
Reset der notifications für einen Nutzer wegen einer Flut an Mail-Bounces UPDATE member SET notify_level = NULL WHERE id = ...; --Lava 21:53, 25. Aug. 2012 (CEST)
vacuumdb -afv --Lava 12:02, 30. Aug. 2012 (CEST)
- Nachdem vacuum nicht fertig durchführbar war, wurde ein Datenbankdump angelegt. --Lava 13:52, 30. Aug. 2012 (CEST)
- Mit TRUNCATE direct_population_snapshot; wurde die Problem-Tabelle geleert. Dabei wurden ca. 16 GB Platz frei (die Tabelle enthält eigentlich nur 21250 Datensätze und ist eigentlich < 500 KB). --Lava 13:52, 30. Aug. 2012 (CEST)
- Mit psql -f table.sql wurde der Datenbankdump von genau dieser Tabelle wiederhergestellt. --Lava 13:52, 30. Aug. 2012 (CEST)
Löschen von 27 Accounts, die nie aktiviert wurden, deren zugehörige Mitglieder mittlerweile jedoch gesperrt sind: DELETE FROM member WHERE locked = true and active = false; --Lava 14:48, 1. Sep. 2012 (CEST)
Löschen von 849 Stimmzetteln, die durch einen Bug in LQFB 2.1.0 und 2.1.1 potenziell falsch registriert worden sind: DELETE FROM vote WHERE (issue_id,member_id) IN (SELECT issue_id,member_id FROM vote LEFT JOIN issue ON vote.issue_id = issue.id WHERE state = 'voting' AND (issue_id,member_id) NOT IN (SELECT issue_id,member_id FROM vote LEFT JOIN issue ON vote.issue_id = issue.id WHERE state = 'voting' AND grade != 0) GROUP BY issue_id,member_id); sowie Löschen der dazugehörigen „bereits abgestimmt“-Flags: DELETE FROM direct_voter WHERE (issue_id,member_id) NOT IN (SELECT issue_id,member_id FROM vote);
Verschieben der Gliederung Graz in Themenbereich Graz: UPDATE issue SET area_id = 35 WHERE id IN (1139,1065,1124,1113,1064,1043,948,947,1049,1066,1159,1041,961,915,1060,934,935,774,1063,1048,987,1062); --Lava 20:55, 24. Feb. 2013 (CET)
Löschen von 10 ehemaligen Mitgliedern, die keine Aktionen im System getätigt haben: DELETE FROM member WHERE id IN (284,83,86,46,291,95,171,217,6,221); --Lava 11:31, 12. Mär. 2013 (CET)
Rücksetzen eines Themas, welches fälschlicherweise bereits in der „Eingefroren“-Phase war: UPDATE issue SET state = 'admission', half_frozen = NULL, accepted = NULL WHERE id = 1304; --Lava (Diskussion) 20:39, 12. Apr. 2013 (CEST)
Löschen von 92 ehemaligen Mitgliedern, die keine Aktionen im System getätigt haben: DELETE FROM member WHERE not active AND locked AND activated ISNULL; --Lava (Diskussion) 14:45, 6. Jun. 2013 (CEST)
Löschen des Admin Comments bei einem Mitglied: UPDATE member SET admin_comment = WHERE id = 154; --Lava (Diskussion) 15:04, 6. Jun. 2013 (CEST)
Löschen von einem ehemaligen Mitglied, welches keine Aktionen im System getätigt hat: DELETE FROM member WHERE id = 236; --Lava (Diskussion) 15:04, 6. Jun. 2013 (CEST)
Ein Mitglied wurde fälschlicherweise gelöscht, der alte Account gesperrt. Nach der erneuten Freischaltung wurde automatisch ein neuer Account angelegt. Dieser neue Account wurde gelöscht: DELETE FROM member WHERE id = 689; und der alte Account mit der richtigen Identifikation versehen: UPDATE member SET identification = '<geheim>' WHERE id = 189;. --Lava (Diskussion) 16:03, 14. Aug. 2013 (CEST)
Ein Mitglied hat Anträge versehentlich falsch eingebracht: BEGIN; ALTER TABLE direct_supporter_snapshot DISABLE TRIGGER ALL; UPDATE initiative SET issue_id = 1707 WHERE id IN (4021,4022,4023,4024,4025); ALTER TABLE direct_supporter_snapshot ENABLE TRIGGER ALL; COMMIT; --Lava (Diskussion) 15:06, 30. Okt. 2013 (CET)
- Bevor wir das als Feature einbauen, gäb's allerdings noch ein paar Sachen zu klären:
- INSERT INTO interest (issue_id,member_id) (SELECT 1707,member_id FROM interest WHERE issue_id = 1709 AND member_id NOT IN (SELECT member_id FROM interest WHERE issue_id = 1707)); funktioniert zwar, ist aber unsauber.
- UPDATE supporter SET issue_id = 1707 WHERE issue_id = 1709 AND initiative_id != 3852; auch noch nötig.
- Schauen, ob das mit alten Snapshots besser geht – wobei da auch Probleme entstehen dürften, d. h. verschieben besser nicht? --Lava (Diskussion) 15:19, 30. Okt. 2013 (CET)
Beschluss [1] umsetzen: INSERT INTO membership (area_id,member_id) SELECT A.id AS area_id,M.id AS member_id FROM member M LEFT JOIN privilege P ON P.member_id = M.id LEFT JOIN area A ON A.unit_id = P.unit_id LEFT JOIN membership MS ON MS.member_id = M.id AND MS.area_id = A.id WHERE not locked AND MS ISNULL AND M.id IN (SELECT M.id FROM member M LEFT JOIN membership MS ON M.id = MS.member_id WHERE MS ISNULL); --Lava (Diskussion) 11:25, 10. Jan. 2014 (CET)

Installations-Logbuch

Installation ist nach http://dev.liquidfeedback.org/trac/lf/wiki/installation erfolgt. Das Paket exim4-base musste zuvor installiert werden.

Locales wurden auf en_US.UTF-8 konfiguriert.

Der Notifications Loop wird unter dem User www-data mit folgendem Skript ausgeführt: https://lqfb.piratenpartei.at/static/lf_notification_loop.txt

Für den Datenbank Dump wird (per Cronjob) das lf_export-Skript aufgerufen.

Die Datei myconfig.lua sieht wie folgt aus: https://lqfb.piratenpartei.at/static/myconfig.lua.txt

Stimmrecht Statistik

Unter http://lqfb.piratenpartei.at/static/hourly.php wird stündlich (per cron job) die Anzahl der Stimmberechtigten protokolliert.

Die Skripte dazu sind hier hinterlegt:

Generieren der Statistik:

/opt/liquid_feedback_core/lf_voting_right_stats
https://lqfb.piratenpartei.at/static/lf_voting_right_stats.txt

Anzeigen der Statistik:

/opt/liquid_feedback_frontend/static/hourly.php
https://lqfb.piratenpartei.at/static/hourly.php.txt

Footer generieren:

/opt/liquid_feedback_core/config_footer.sh
https://lqfb.piratenpartei.at/static/config_footer.sh.txt

Datenschutzerklärung

Anzeigen der DSE:

/opt/liquid_feedback_frontend/static/privacy.php
https://lqfb.piratenpartei.at/static/privacy.php.txt