foodsharing Entwickler Blog

Neuer Server für foodsharing

Fri, 07 Oct 2022 13:00:00 +0000

Serverumzug die Zweite

Über 3 Jahre ist es nun her, dass wir das letzte mal auf einen neuen Server (damals der Server dragonfruit) umgezogen sind. Seit dem ist foodsharing immer weiter gewachsen und mehr und mehr Menschen nutzen die Plattform. Das sorgt auch für einen erhöhten Bedarf an Ressourcen.

Also haben wir wieder Kontakt zu unserem Server-Sponsor Manitu aufgenommen. Die Antwort auf unsere Anfrage hätte nicht besser sein können – Manitu hat einen gebrauchten Server für uns, der unsere Anforderungen erfüllt und stellt ihn uns kostenfrei zur Verfügung. Lediglich um die Beschaffung von neuen NVMe SSDs haben wir uns selbst gekümmern. Kostenpunkt: 222€ finanziert aus Spenden. Wer dazu beitragen will kann gerne auch Spenden: spenden.foodsharing.de.

Nachdem wir in einigen E-Mails alle Details geklärt hatten, hat Manitu die Server-Hardware für uns hergerichtet. An dieser Stelle noch mal ein großes Dankeschön an das Team von Manitu für den hervorragenden Support.

Am 1.10. haben wir dann nach einiger Vorbereitung den Umzug der Plattform vollzogen. Im Folgenden die ganze Geschichte noch mal etwas ausführlicher.

Planung

Bereits im Vorfeld haben wir überlegt, was wir alles ändern wollen mit dem neuen Server. Beim Betriebssystem sind wir bei debian geblieben, allerdings nun mit der aktuellsten Version bullseye. Die wohl größte Änderung ist, dass wir als Dateisystem nun zfs nutzen. zfs wurde insbesondere für Server entwickelt und bietet deutlich mehr Funktionen als klassische Dateisysteme. Durch den Wechsel mussten noch einige Änderungen z.B. an der Datenbank Konfiguration vorgenommen werden. Des weiteren haben wir für die Zertifikate von certbot auf acme.sh gewechselt und haben die Berechtigung der einzelnen Anwendungen weiter eingeschränkt, um den Schaden im Falle einer Sicherheitslücke weiter zu beschränken.

Der neue Server ist da

Nachdem manitu uns den Server vorbereitet hat, war natürlich die Frage nach dem Namen. Eine Umfrage ergab “onion”. Nun ging es an die Installaton. Dafür haben wir ein Live Debian genutzt und das eigentliche OS mit debootstrap installiert. Bei der Einrichtung des zfs Dateisystems sind wir überwiegend der Anleitung von OpenZFS gefolgt. Das neue System war also schnell da. Dadurch, dass wir schon sehr lange unsere Infrastruktur mit ansible verwalten war es auch sehr einfach eine foodsharing Instanz und alle weiteren Programme die benötigt werden zum laufen zu bekommen. Das Problem ist nur, wie kommen die Daten vom alten Server auf den neuen.

Die Umzugsvorbereitungen

Beim letzten Umzug wurde das kopieren der Daten und Datenbank noch händisch erledigt. Diesmal wollten wir es automatisieren. Also haben wir ein ansible playbook gebaut, dass die beiden Server auf den Umzug vorbereitet, den Code, die Zertifikate, die Daten und die Datenbank kopiert. Es funktioniert auch auf anhieb, also fast fertig.

Problem: Die Datenbank und die Daten müssen in einem konsistenten Zustand kopiert werden. D.h. sie können nur Kopiert werden, wenn die Seite aktuell nicht benutzt wird. Soweit so gut – bei unserer Datenbank die ~60GB groß ist dauert das knapp 2 Stunden. Natürlich schade, wenn die Seite so lange nicht erreichbar ist, deshalb haben wir noch ein mal nach Optimierungsmöglichkeiten gesucht. Unser Datenbankadmin hat noch mal etwas aufgeräumt und z.B. Alte Quiz Sessions gelöscht. Wir Admins haben noch etwas an der Datenbankkonfiguration geschraubt um die Datenbank möglichst schnell kopieren zu können. Mit folgendem Befehl konnten wir die Datenbank letzendlich am schnellsten auf den neuen Server übertragen. Ein Hoch auf Unix Pipes, die es ermöglichen in einem Befehl die Daten direkt in die neue Datenbank einpflegen und auf dem Dateisystem zur Sicherheit ablegen:

ssh root@dragonfruit.foodsharing.network "mysqldump --add-drop-table --add-locks --skip-comments --single-transaction --quick fsprod" | tee fsprod_migration.sql | mysql fsprod

Das Migrationsscript war also vorbereitet, mehrfach getestet, fehlt noch ein Termin für den Umzug. Die Auslastung des Servers zeigt, dass - abgesehen von Mitten in der Nacht – Samstag und Sonntag Vormittag die Nutzung der Seite am geringsten ist. Also haben wir uns für den morgen des 1.10.22 für den Umzug entschieden.

Der Umzug

Samstag morgen der 1.10. Ich war vor meinem Wecker wach. Also pünktlich um 07:46:23 das Migrationsscript angeworfen. Alles wird eingerichtet und installiert.

08:03:06 kommt die Meldung: „We are now going to migrate.“ Kurz noch mal alles Prüfen und los gehts – foodsharing ist erstmal nicht erreichbar und die Datenbank wird umgezogen. Die Zwischenzeit habe ich genutzt um die DNS-Records anzupassen (die Kollegen in Österreich und der Schweiz haben das auch gemacht), und die Anpassungen an unserer CI/CD-Pipeline vorzunehmen. Nach knapp 32 Minuten war die Datenbank umgezogen und um 8:40 war alles auf dem neuen Server vorbereitet. Was noch Fehlte: der neue Code aus der CI/CD-Pipline. Um 10:52:57 waren dann alles abgeschlossen und foodsharing war wieder erreichbar. An Feierabend war aber so früh noch nicht zu denken. Ein paar Dinge mussten noch angepasst werden – so haben wir z.B. neue Zertifikate für die verschiedenen Seiten ausgerollt, das Backup musste angepasst werden und noch weitere Kleinigkeiten.

Die erwarteten unerwarteten Probleme

Selten läuft alles Reibungslos. Bereits Ende März hatten wir durch ein Update von MariaDB Probleme mit dem Chatserver. Bei unseren Tests auf dem neuen Server trat das Problem nicht auf – jetzt wo wir live waren plötzlich schon. Wir hatten also ein akutes Problem. Wir hätten zurück auf den alten Server gekonnt, aber eigentlich musste das Problem irgendwann gefunden und gelöst werden. Also schnell unsere Entwickler zur Hilfe gerufen. Die Stelle mit dem Problem war bereits bekannt. Die Funktion fetchAllByCriteria is gibt ein leeres Array zurück, wenn die Anfrage zu groß ist. Warum? 🤯

Nach ein paar Tests konnte das Prolem schnell weiter eingegrenzt werden. Aber eine Lösung musste her. Durch das manuelle erstellen der Query, wie die Daten Abfragt konnte das Problem behoben werden.

Abschluss

Trotz der Probleme sind wir froh auf den neuen Server umgezogen zu sein. Die Auslastung ist nicht mehr durchgängig am Anschlag und die Ladezeit der Seite hat sich wieder verbessert. Wer sich das anschauen möchte kann das hier tun. Außerdem haben wir auch erstmal wieder Platz die hochgeladenen Daten und die wachsende Datenbank zu speichern. An dieser stelle noch ein mal Danke an manitu, die es uns möglich machen eine große Seite wie foodsharing kostenlos zu betreiben. Den bisherigen Server wollen wir in Zukunft für die foodsharing Cloud und andere Dienste nutzen.

Zukunftsplanung unserer Plattform foodsharing.de

Fri, 12 Aug 2022 23:25:00 +0000

Gut organisiert Lebensmittel retten und gemeinsam die Zukunft organisieren – dafür brauchen wir jetzt euch!

Damit unsere gemeinsame Plattform, welche die Basis für eure Lebensmittelrettungen ist, weiterleben kann, brauchen wir euch und eure Erfahrungen.

Doch bevor wir dazu kommen, was wir von euch erwarten, möchten wir euch unsere Herausforderungen kurz darstellen.

Unsere Herausforderungen:

Jeder Entwickler hat seine Präferenz, was er zum Beispiel gut kann oder was er gern entwickelt. (Diejenigen, die aktiv coden, sind gerade ausschließlich Männer. All genders welcome!) Der eine baut gern Schnittstellen, der andere entwickelt gern die Kern-Funktionen (das sogenannte Backend) und wieder andere gestalten gern die Benutzeroberflächen (das Frontend). Wir möchten euch dabei kurz unsere Hürden darstellen:

Der aktuelle Code der Plattform gibt diese Aufteilung nicht her. Das bedeutet, dass ich in der Arbeit im Code oft viel gleichzeitig im Blick behalten muss. Der Code ist recht alt und eine Dokumentation ist bisher nur an den neueren Stellen vorhanden. Alte und neue Technologien paaren sich und sind bunt gemischt. Die Herausforderung ist es also auch, ein gemeinsames Konzept zu gestalten.

Des Weiteren werden an uns über viele unterschiedliche Kanäle (Produkt-Team, IT-Support (Helpdesk), Slack, Persönliche Nachrichten) Verbesserungsvorschläge oder neue Funktionsvorschläge übermittelt. Manches davon wurde umgesetzt und alle waren glücklich – bis neue Foodsaver, Betriebsverantwortliche und Botschafter kamen, die es genau umgekehrt haben wollten. Uns ist dabei aufgefallen, dass vieles in der Produkt AG nicht zu Ende diskutiert wird und wir Entwickler wissen nicht, was genau die Anforderung ist.

Wir haben uns ein paar Verbesserungsvorschläge überlegt und möchten mit mehr Struktur bei der Entwicklung vorgehen.

Neue Ausrichtung - unser Zukunftsplan:

Wir müssen erst unsere Altlasten loswerden, bevor wir neue größere Funktionen einbauen. Das ist vergleichbar mit einem Haus: Aktuell sind das Fundament und das Dach marode. Es tropft an allen möglichen Stellen in unserem Foodsharing-Haus. Habt also bitte etwas Geduld, wenn ihr neue Ideen einbringt. Wir entwickeln vorerst keine neuen Funktionen mehr, bevor das Dach repariert ist. Ideen, die an uns herangetragen werden, sind nicht verloren.

Unser aktuell höchst priorisiertes Ziel ist, für alle Funktionen eine Schnittstelle (REST API) zu bauen. Wenn das passiert ist, kann die Benutzeroberfläche Seite für Seite (also das Frontend) relativ schnell umgebaut werden.

Wir erstellen sogenannte „Slack Fokus Kanäle“ für einzelne Themen, um unsere Arbeit übersichtlich kommunizieren zu können.

Was wir uns von euch allen wünschen:

Wir wünschen uns mehr Foodsaver, Betriebsverantwortliche und Botschafter, die Slack nutzen und uns Feedback geben.

Unsere Kommunikation findet nämlich hauptsächlich per Chat beim Instant-Messenger-Dienst Slack statt. Im Grunde ist Slack sowas ähnliches wie „Microsoft Teams“ und ermöglicht uns, Themen in Threads zu besprechen, Screenshots/Dateien hochzuladen und per Volltext suchen zu können. Und so könnt ihr euch Slack einrichten: https://slackin.yunity.org

Wir wünschen uns eine sachliche und wertschätzende Kommunikation. Das sollte eigentlich selbstverständlich sein. Immer wieder hören wir u.a. Dinge wie „das ist aber doof, das geht doch nicht so”. Bitte begründet sachlich, warum die Funktion für euch so nicht passt. Sagt uns bitte, warum ihr die Funktion nicht nutzen könnt - was genau wollt ihr machen? Nur so können wir gemeinsam eine Lösung erarbeiten. Etwa einmal die Woche gibt es eine Telefonkonferenz der Entwickelnden, je nach Bedarf. Das ist auch eine Gelegenheit, direkt über ein Anliegen zu sprechen.

Wir wünschen uns eine engere Zusammenarbeit mit der Produkt-AG. Das ist insbesondere dafür wichtig, um passende Umfragen erstellen zu können und informierter zu sein, was ihr Foodsaver tatsächlich benötigt. Nur so können wir auch ein Gesamtkonzept erarbeiten, in dem alle Anforderungen erfasst sind.

Wir wünschen uns, dass weitere Entwickelnde ins Team kommen, da wir, ebenso wie Ihr Lebensmittelretter, die Foodsharing- Plattform ehrenamtlich entwickeln. Ihr seid herzlich willkommen! Mehr Informationen dazu gibt es unter dem Link: https://devdocs.foodsharing.network/it-tasks.html

Vielen Dank!

Es sind stets Personen männlichen und weiblichen Geschlechts gleichermaßen gemeint; aus Gründen der einfacheren Lesbarkeit wird im Folgenden nur die männliche Form verwendet.

Hackweekend Januar 2022

Tue, 16 Nov 2021 19:00:00 +0000

Es ist Zeit für die nächste foodsharing Hackweek!

Es ist Zeit für das nächste foodsharing Hackweekend!

Aufgrund der Corona-Maßnahmen werden wir sie online durchführen.

Wann - 14. Januar bis 16. Januar 2022

Wo - Online: BigBlueButton (ohne Anmeldung möglich), Slack.

Wir werden diskutieren, programmieren, gegenseitig Vorträge anbieten, und foodsharing gemeinsam besser machen.

Man kann auch für ein paar Stunden dabei sein, es lohnt sich unabhängig von den eigenen technischen Vorkenntnissen. Das hackweekend ist sowohl für Unterstützer*innen als auch für Entwickler*innen.

Sei dabei!

Matthias and Tilmann in einer früheren Hackweek

Hackweeks sind der Motor im foodsharing development: In den Programmierzeiten, die wir über die letzten Jahre hatten, haben wir es geschafft, foodsharing Open Source zu machen, Sicherheitslücken zu schließen, neue Features zu implementieren, coole neue Frameworks einzubauen und mehr. Über die letzten Hackweek(end)s wurde hier im Devblog berichtet.

Wir schaffen es auch ohne alle an einem Ort zu sein, ein Teamgefühl zu entwickeln und einander zu unterstützen. Wir haben eine ganze Woche und nehmen uns die Zeit, um uns kennenzulernen, uns über Gott und die Welt zu unterhalten, Spiele zu spielen …

Was noch mega wichtig ist, ist dass Hackweekends nicht nur für Programmierer und Nerds sind, sondern dass es soooo viele Themen gibt, über die es zu diskutieren gilt! Und wir wünschen uns mehr Kommunikation zwischen den Entwickler*innen und der Community von foodsharing. Du könntest auch kommen und den produktiven Vibe nutzen, um an einem anderen foodsharing Projekt zu arbeiten. Wir fänden das super!

Lasst uns gemeinsam den Code verbessern und bereichern!

Lasst uns gemeinsam den Code verbessern und bereichern!

Diesmal wird alles selbstorganisiert ablaufen, deshalb findest du hier ein Pad, das wir alle zusammen mit Inhalten füllen. Trag dich gern mit ein: https://pad.kanthaus.online/foodsharing-hackweekend_2021# (Dort gibt es später auch einen Zeitplan, welche Themen wann gemeinsam besprochen werden sollen.)

Ein weiterer Kommunikationskanal ist der #foodsharing-hackweek Channel auf https://slackin.yunity.org/ - also komm gern auch dort hin!

Bis zur Hackweek!

Hackweekend Herbst 2020 Rückblick

Mon, 14 Sep 2020 13:00:00 +0000

Blogpost über das Hackweekend im Herbst 2020 - ein Rückblick

[Christian-W] Es fing an mit einer lockeren Runde. Es haben sich eine muntere Truppe von 6 Entwickler*innen zusammengefunden, die sich ein Wochenende Zeit nehmen. Gegen 18 Uhr fand die Planung der Sessions statt. Spontan wurde sich entschlossen noch eine Sentry Session am gleichen Abend anzuschließen. Für Samstag stehen als Tagesordnungspunkte:

1) Stand der Programmierung eines Wahltools
2) Anschauen von Merge Requests und
3) Audit Protokollierung von Betriebsfunktionen auf dem Programm.

[Chris] Wir haben einige Zeit angeregt über geplante neue Funktionen unterhalten, darunter ein System für Abstimmungen und das Protokollieren einiger Aktionen in Betrieben.

Außerdem wurde natürlich einiges an Code geschrieben und besprochen. Eine neue Funktion ist dabei direkt herausgekommen: im Forum kann nun nach dem Titel von Themen gesucht werden.

Wenn ihr euch dafür interessiert bzw. generell dabei mithelfen wollt, neue Funktionen auszuprobieren, bevor sie für alle verfügbar sind: macht gern beim Beta-Testen mit!

Dafür gibt es unter https://gitlab.com/foodsharing-dev/foodsharing-beta-testing/-/wikis/how-to/Erste%20Schritte eine ausführliche Anleitung mit vielen Bildern. Oder ihr meldet euch einfach bei der AG Beta Testing. :)

[Jonathan] Wir haben uns zu zehnt ausgetauscht, wie ein neues Meldesystem funktionieren könnte und was technisch nötig wäre.

Dann gab es noch einen Gesprächsgang zum “Foodsharing Freundeskreis” über Finanzierungsmöglichkeiten im Ehrenamt. Ich bin ganz beeindruckt, wie viele dieses Wochenende am Code gebastelt und an der sozialen Struktur unserer Arbeit überlegt wurde!

Wenn du mitmachen magst, findest du uns unter: slackin.yunity.org im Kanal #foodsharing-dev

Was in der letzten Zeit geschah... Hotfix, neue Teamliste, Internationalisierung

Wed, 01 Jul 2020 10:00:00 +0000

Hotfix

Mitte Juni gab es einen Hotfix. Dabei wurden mehrere Probleme behoben, die teilweise beim letzten Release mit reinkamen oder schon länger bestanden und immer dringlicher wurden. Da wir ein relativ hohes E-Mail-Aufkommen im Vergleich zu der uns möglichen Sendefrequenz haben, dauert es immer eine Weile, bis E-Mails ankommen. Dadurch gab es recht viele Supportanfragen, dass E-Mails zu vergessenen Passwörtern, zur Änderung von E-Mail-Adressen und zur Registrierung nicht ankämen. Diese haben nun eine höhere Priorität, sodass diese nun schneller als andere E-Mail-Benachrichtigungen ankommen.

Wenn eine E-Mail von foodsharing nicht zugestellt werden kann, kommt die zugehörige Adresse auf die Bounce Liste. An E-Mail-Adressen auf dieser Liste werden keine Mails mehr versandt. Seit dem Hotfix wird nun eine Warnung auf dem Profil angezeigt, wenn dies so ist, mit einer Erklärung, wie das geändert werden kann. Es gibt auch beim Support jetzt einen Artikel, in dem das ganze noch mal genauer erläutert ist.

Es kam zu einem Bug, wo das bei der Registrierung angegebene Geschlecht falsch abgespeichert wurde. Dieser ist nun behoben.

Neue Teamliste

In den Betrieben ist eine neue Teamliste in Arbeit. Diese wurde in Vue.js neuimplementiert. Damit ist die Liste nun deutlich mobile-freundlicher. Zuvor war es so, dass es beim Klicken auf eine Person in der Liste eine direkte Weiterleitung gab, sodass die Nummer gewählt wurde. Wollte man die anderen Menüoptionen nutzen, musste man erst zurück zum Browser.

Desweiteren sind nun die Betriebsverantwortlichen immer oben in der Liste, selbst wenn sie eine Schlafmütze aufhaben. Damit sind diese deutlich schneller in der Liste auffindbar. Außerdem wird nicht mehr farblich markiert, ob eine Person Botschafter:in ist oder war, für das vorher die Markierung die selbe war. Außerdem können solche Kennzeichnung Hierarchien verstärken, obwohl diese im Kontext der Abholungen keine Rolle spielen sollten.

Internationalisierung

Es gibt die ersten Übersetzungen ins Englische!

Bislang gab es ein selbstgebautes System, welches Texte in die Webseite einband. Durch Anpassung an Standards wird es für neue Entwickler nun einfacher, sich einzufinden, und es ist weniger Aufwand, einen Umschaltbutton für andere Sprachen einzurichten.

Technisch bedeutet dies, dass unser Projekt weiter an die Symfonystandardstruktur angepasst wurde. Das beinhaltet eine Sitzungsvariable, die die aktuelle Sprache speichert, und die von Symfony vorgegebene Dateibenennung. Dadurch brauchen wir nun keine eigenen Übersetzunghelfer und -validierer mehr, sondern können direkt Symfony nutzen. Stück für Stück werden weiterhin die alten Übersetzungen angepasst.

Hackweek Frühling 2020 Rückblick

Fri, 22 May 2020 12:00:00 +0000

Blogpost über die Hackweek Mai 2020 - ein Rückblick

[Felix] Vor der Hackweek war ich unsicher, ob ich mich beteilige und habe mich daher leider nicht an der Vorbereitung beteiligt. Diese Vorbereitung lief erst rech schleppend an, aber in der Zeit kurz vor der Hackweek füllte sich das Programm mit Themen und initiierten Sessions. Für mich als Immer-noch-Neuling haben diese die Möglichkeit gegeben, zuzuhören, Fragen zu stellen und damit zu lernen.

[Kristijan] Die Hackweek ist für mich ein freudiges Ereignis um viele der aktiven Namen auch mal live zu erleben. Corona hat dies leider erschwert. Umso erfreulicher war es, das es eine “online Hackweek” gab. Sessions wurden in Videokonferenzen abgehalten, so konnte sich zumindest mal gesehen werden und haben wesentlich zu einem Gruppengefühl und einem “wir” beigetragen. Es entstand eine schön produktive Atmosphäre und es war wertvoll Feedback und neue Ideen für Umsetzungen zu erhalten. Es gab auch lustige Sessions zu eigentlich ernsten Themen, die damit aufgelockert wurden.

[Caluera] In der Hackweek haben wir richtig viel erledigt bekommen, gerade auch Sachen, die sonst im Alltag eher untergehen. Wir haben viel auch über Strukturen gesprochen und Planungen gemacht, wie wir mit manchen Themen umgehen werden.

[moffer] Die Hackweek hat einiges vorangebracht, für mich vor allem auch soziale Aspekte: Mit einigen Leuten quasi live reden, mit denen man sonst nur über Gitlab oder Slack zu tun hat. Auch fand ich die gesamte Stimmung positiv. Es wurde reichlich diskutiert, wodurch zum Hacken gar nicht so viel Zeit blieb - bei mir war leider durch private Gründe die Zeit auch recht begrenzt. Ich kann mir jedoch vorstellen, dass so ein Onlineformat auch öfters stattfinden kann, da sich der Orga-Aufwand (und evtl finanzieller Aufwand) in Grenzen hält. Ich würde das begrüßen.

[Chris] Besonders begeistert hat mich das Gemeinschafts-Gefühl trotz der räumlichen Entfernung :) Insgesamt viele spannende Einblicke in ganz unterschiedliche Bereiche, produktive Diskussionen und ein am Nutzer orientierter Austausch, dazu eine flexible Organisation mit mehr Struktur genau da, wo es nötig war - ich würde mich über eine baldige Wiederholung definitiv freuen und hoffe auf viele auch neue Gesichter.
Also, ihr Leser da draußen: Schaut einfach beim nächsten Mal unverbindlich rein, bei einigen Sessions vorbei und bringt euch vielleicht direkt ein. Hackweeks sind nämlich eine super Gelegenheit, das Team und die Arbeitsweise kennenzulernen - auch und insbesondere dann, wenn ihr nicht selbst mit programmiert!

Hackweek Frühling 2020

Mon, 20 Apr 2020 16:00:00 +0000

Es ist Zeit für die nächste foodsharing Hackweek!

Aufgrund der Corona-Maßnahmen werden wir sie online durchführen.

Wann - 25. April bis 3. Mai 2020

Wo - Online: Jitsi, Slack, Mumble, …

Wir werden diskutieren, programmieren, gegenseitig Vorträge anbieten, und foodsharing gemeinsam besser machen.

Man kann auch für ein paar Stunden dabei sein, es lohnt sich unabhängig von den eigenen technischen Vorkenntnissen. Die hackweek ist sowohl für Unterstützer*innen als auch für Entwickler*innen.

Sei dabei!

Matthias and Tilmann in einer früheren Hackweek

Hackweeks sind der Motor im foodsharing development: In den Hackweeks, die wir über die letzten Jahre hatten, haben wir es geschafft foodsharing Open Source zu machen, Sicherheitslücken zu schließen, neue Features zu implementieren, coole neue Frameworks einzubauen und mehr. Über die letzten Hackweeks wurde hier im Devblog berichtet.

Es ist außerdem toll mal zusammenzukommen! An foodsharing zu arbeiten ist meistens eine recht einsame Angelegenheit, aber wir schaffen es auch ohne alle an einem Ort zu sein, ein Teamgefühl zu entwickeln und einander zu unterstützen. Wir haben eine ganze Woche und nehmen uns die Zeit, um uns kennenzulernen, uns über Gott und die Welt zu unterhalten, Spiele zu spielen…

Was noch mega wichtig ist, ist dass Hackweeks nicht nur für Programmierer und Nerds sind, sondern dass es soooo viele Themen gibt, über die es zu diskutieren gilt! Und wir wünschen uns mehr Kommunikation zwischen den Entwickler*innen und der Community von foodsharing. Du könntest auch kommen und den produktiven Vibe nutzen, um an einem anderen foodsharing Projekt zu arbeiten. Wir fänden das super!

Lasst uns gemeinsam den Code verbessern und bereichern!

Einige grundlegende Details

Verpass nicht die Sitzungen zu Themen wie “Burnout-Prävention”, “Was passiert, wenn foodsharing ausfällt”, “die lokale foodsharing Umgebung für absolute Anfänger”, “Roadmap der nativen Apps”, “Aktuelle Forschung zur Mensch-Lebensmittel-Interaktion” und viele andere. (Wir haben sogar eine Pen&Paper-Runde geplant).

Diesmal wird alles selbstorganisiert ablaufen, deshalb findest du hier ein Pad, das wir alle zusammen mit Inhalten füllen. Trag dich gern mit ein: https://codi.kanthaus.online/foodsharing-hackweek?view (Dort gibt es auch einen Zeitplan, welche Themen wann gemeinsam besprochen werden sollen.)

Ein weiterer Kommunikationskanal ist der #foodsharing-hackweek Channel auf https://slackin.yunity.org/ - also komm gern auch dort hin!

Bis zur Hackweek!

Programmieren im Pott

Fri, 17 Apr 2020 03:10:00 +0000

Am 15.02.2020 haben sich einige aus der foodsharing IT in Bochum getroffen, um an der foodsharing Webseite weiterzuarbeiten. Hier sind Berichte von einem Teil der Anwesenden:

Caluera: Um die Veranstaltung bekannt zu machen, habe ich einen NRW weiten Termin auf der foodsharing Webseite erstellt, damit vielleicht auch die Leute mitmachen, die bisher noch nicht an der foodsharing Programmierung mitgemacht haben. Darüber haben sich auch ein paar Interessierte gefunden, bei denen es meist leider zeitlich nicht geklappt hat. Außerdem habe ich mich an die Social Media AG gewandt, die einen Aufruf für unser Treffen auf Twitter veröffentlicht hat. Wir haben uns beim Hackerspace das Labor in Bochum getroffen. Ich bin dafür zu deren Plenum gegangen und hab nachgefragt, ob wir deren Raum nutzen dürfen. Der Raum ist mit Tischen, Steckdosen und Internet ideal für solche Treffen. Die Resonanz war sehr positiv und es war auch schnell abgesprochen, wer für uns aufschließen kann. Eine Veranstaltung auf deren Webseite war auch am selben Abend noch erstellt. Es hat sich auch noch eine Person aus dem Labor zum Mitmachen gefunden!

Fridtjof: Diese neue Person war dann wohl ich! Da das Projekt für mich neu war, habe ich mich hauptsächlich erstmal vertraut mit dem Code gemacht. Hierbei ein großes Lob an die Einrichtung der Development-Umgebung - die hat reibungslos geklappt und im Nu hatte ich meine eigene Foodsharing-Instanz zum basteln. Seit dem Hackathon sind meinerseits schließlich auch schon ein paar MRs fertig geworden :)

ctwx: Angekommen im Hackerspace gleich ein paar alte Gesichter sowie mehre neue gesehen. Wir sind gleich zur Sache gekommen und alle haben ihre Laptops rausgeholt und angefangen zu hacken. Es wurde einzeln gehackt, im Pair Programming und alle haben sich gegenseitig geholfen. Ich war erstaunt, wie viel an dem Tag umgesetzt wurde. Das Treffen war ein großer Erfolg. :)

christian-w (Slack) und chriswalg (gitlab) (aus der Region Ludwigsburg / Stuttgart): Habe am Freitag Mittag etwas früher die Arbeit verlassen und bin mit dem Zug nach Duisburg. Dort konnte ich dankenswerterweise bei Lea in der WG im Dachboden, der komplett offen ist, übernachten. Lea und ich haben uns dann noch länger am Abend über foodsharing und deren Programmierung angeregt unterhalten. Am Samstag fuhren wir dann gemeinsam gegen 13 Uhr mit dem Zug nach Bochum zum Hackspace, da die Veranstaltung um 14 Uhr beginnen sollte. Kevin, der erst kürzlich zum Projekt dazu gestoßen ist und dankenswerterweise https://gitlab.com/foodsharing-dev/foodsharing/-/issues/705 behoben hat, kam ohne Laptop. Habe ihn dann nach kurzer Zeit gefragt, ob er sich mal etwas anschauen kann. Es ging um die Javascript Date Library date-fns, die wir auf die aktuelle Version 2.9.0 aktualisieren wollten, da wir bis dato noch mit einer Version < 2.0 gearbeitet hatten. Peter hatte schon große Vorarbeit geleitet, ich habe den Branch auf dem aktuell Stand gehalten (git rebase master) und noch Anpassungen für das neue Registrierungsformular eingebaut. Es gab allerdings noch einen Fehler, den Kevin nach langem suchen gefunden hat. Danach hat Kevin noch einen Fehler in der Erstellung von Visitenkarten behoben, damit der Bezirksname oder die Adresse, wenn diese zu lang sind, umgebrochen werden und auf die Visitenkarte drauf passen. Zwischendurch hat sich Kevin immer wieder entschuldigt, dass er mein Laptop benutzt. Beide Verbesserungen wurde dann am nächsten Tag auf die beta-Seite gemerged.

Zwischenstand der Android App

Sun, 01 Sep 2019 10:00:00 +0000

Projektziel

Wir hatten uns überlegt, dass wir eine App brauchen, um die Handhabbarkeit von Essenskörben für alle Benutzer*innen von www.foodsharing.de zu verbessern. Langfristig sollen auf diese Basis alle foodsaver-Funktionen aufgebaut werden, ohne die Webseite zu ersetzen. Vorteile einer Smartphone-App sind die vorhandenen “Sensoren” wie Kamera, GPS und Ortung. Dem gegenüber nachrangig und doch im Blick ist die Entwicklung der Apple (iOS) App.

So sieht der Chat derzeit aus

Projektverlauf

Das Projekt begann vor einem Jahr mit starker Unterstützung von Nick Sellen. Richtig Fahrt aufgenommen hat es dann erst im Oktober 2018, als ein weiterer Programmierer dazugekommen ist. Die gegenseitige Motivation trug Früchte. Die Chat-Funktion entwickelte sich zum gut funktionierenden Kern der App. Zur Hackweek im Februar gab Nick die App in die Hände des Teams. Dazu gehören Alex, David, Janosch, Lukas, Diego, Simon, WUUUGI, und ich. Wir bauten die bereits angedachten Funktionen weiter und veröffentlichten am 20.04.2019 eine “Public Beta” (öffentlichen Testversion) im **“Google Play Store”.

Am 16.08.2019, also zum foodsharing Festival, erreichte der Downloadzähler den 10.000ten Download (auf unterschiedliche Geräteaccounts). Ein kleines aber sehr aktives Team werkelt nun täglich an Verbesserungen: Von Projektbeginn bis heute wurden 516 Änderungen (commits) gemacht.

Der ersten veröffentlichten Beta Version 0.1.0 vom April 2019 sind bis dato vier weitere Versionen gefolgt, so dass wir im August bei Version 0.4.0 angekommen sind. Bisher haben wir einen Update Zyklus von etwa 45 Tagen, wobei wir kürzere Zyklen anpeilen.

Aktuell gibt es ca. 85 Installationen am Tag, der Kreis der Nutzer wächst also schnell. Dabei haben wir auf ausdrückliche Werbung innerhalb der Community bisher verzichtet, um die Supportanfragen gering zu halten. (Wer im Support helfen möchte, findet unten unsere Kontaktdaten.) Aktuell wird etwa alle 3 Tage intern eine neue Version einer internen “foodsharing Beta” App veröffentlicht. Dafür sind nach einer Anfrage über die genannten Links noch ca. 80 “Testplätze” frei. In Zusammenarbeit in einer Slack Chat Gruppe wird hier sogenannten “Testaufrufen” gefolgt, um die Tester auf Detailänderungen hinzuweisen und Hand in Hand zu arbeiten.

Aufruf zur Unterstützung

Vielleicht bist ja du, werte lesende Person, ein begeisterter Nutzer der App oder sogar eine Programmiererin; ein lernfähiger Mensch mit etwas Zeit und dem Willen, dich einzubringen. Vielleicht hast du sogar Lust, bei der Apple (iOS) App Entwicklung zu unterstützen? Dann schau doch mal in unseren Aufruf zur Mitarbeit und melde dich bei uns (zum Beispiel per Mail: it@foodsharing.network). Wir freuen uns auf dich.

Serverumzug

Sat, 08 Jun 2019 10:00:00 +0000

Den Beginn des Pfingstwochenendes haben sich Chandi und ich ausgesucht, um uns allen die Freude an der Benutzung der foodsharing-Plattform zurückzuholen: Wir ziehen auf einen schnelleren Server um. Die Geschichte dazu möchte ich euch an dieser Stelle erzählen. Dieser Beitrag entsteht während des Umzugs - einerseits in Prokrastinationspausen, andererseits in Zwangspausen, während ich auf irgendetwas warten muss :-)

Was viele vielleicht nicht wissen, ist, dass der Kern der foodsharing-Entwickler die Plattform nur sehr sporadisch nutzt. So kam es vor zwei Wochen, dass ich mal wieder auf foodsharing.de gegangen bin, um nachzuschauen, ob ein Bug dort bereits vorhanden war und ich mich dabei ziemlich genervt davon gefühlt habe, dass die Plattform extrem langsam ist. Wir wussten eigentlich schon, dass wir so langsam ziemlich am Limit unseres Servers sind, aber es selbst zu spüren, ist nochmal was anderes.

Kurzerhand habe ich mich daraufhin freundlich und zurückhaltend an unseren Server-Sponsor Manitu gewendet und nachgefragt, ob wir - u. U. auch mit Zuzahlung einer kleinen Summe - einen schnelleren Server bekommen können, da sich unsere Nutzerzahlen aber auch die Komplexität unserer Anwendung stetig weiterentwickeln.

Die Antwort kam nach wenigen Stunden vom Chef persönlich: Sehr gerne wird foodsharing weiter unterstützt. Ein Mitarbeiter schaut zeitnah mal, was sie uns aus dem Reste-Pool anbieten können. Meine Freude - und auch die im weiteren Team, mit dem ich die Nachricht schnell geteilt habe - war groß. Zwar wussten wir, dass wir mit Manitu als inhabergeführtem Unternehmen “Von Menschen für Menschen” einen guten Partner an der Hand haben, aber es ist wundervoll, auch nach so vielen Jahren weiterhin so eine Unterstützung und positive Kommunikation zu erfahren.

Los gehts: Planung

Nach kurzer Zeit ist geklärt, dass wir den Server in der Woche um den 5. Juni gestellt bekommen. Chandi - selbst Administrator von mehreren Servern für Projekte im ähnlichen Kontext - bietet mir seine Erfahrung und Unterstützung an, den Umzug vorzubereiten und durchzuführen. Wir tauschen uns ein wenig über Ideen und Wünsche an das neue System aus und erstellen einen Plan:

Umzugsplan im CodiMD Pad, Stand Samstag, 12:00 Uhr. Wir hinken ein kleines bisschen hinterher.

Der wichtigste gemeinsame Wunsch von uns ist, eine reproduzierbare Konfiguration des Servers zu haben. Ein typisches Problem einzeln administrierter Server ist, dass über die Zeit immer wieder Menschen etwas an der Konfiguration ändern und es von außen schlecht nachvollziehbar ist, was genau eigentlich mit welchen Einstellungen läuft. Bei uns ist das Problem noch stärker: Für viele Entwickler ist die exakte Konfiguration einer Systemkomponente immer mal wieder interessant, eventuell möchte ein*e Entwickler*in diese sogar ändern. Serverzugriff ist immer mit Zugriff auf sensible Daten verbunden: Den haben bei uns nur sehr wenige Personen.

Eine Lösung dafür ist es, die Konfiguration des Servers komplett in Skripte auszulagern, welche dann dort lediglich ausgeführt werden, jedoch immer nur an zentraler Stelle verändert werden. Die Lösung, für die wir uns entscheiden, ist das Tool Ansible. Es ermöglicht nicht nur die Ausführung von Skripten sondern erlaubt die Beschreibung des Zustands einer Installation. Änderungen können dadurch leichter eingearbeitet werden. Zudem haben wir mit diesem Tool schon einige Erfahrung gesammelt.

Das Ziel: Die Konfiguration nahezu vollständig mit Ansible umzusetzen, sodass manuelle Eingaben am Server nahezu unnötig sind.

Die Ansible-Konfiguration könnt ihr euch im dragonfruit-ansible Git-Repository anschauen und habt damit die Möglichkeit nachzuvollziehen, wie der foodsharing-Server exakt eingerichtet ist. Zudem kann jeder Mensch auch hier Verbesserungen beitragen bzw. vorschlagen. Das Ausführen der Änderungen auf unserem Server obliegt jedoch den Menschen mit entsprechendem Zugriff. Das sind im Moment Nick und ich.

Nun aber: Server einrichten

Nach einigen Stunden Planung haben wir den Donnerstag und Freitag damit verbracht, die Konfiguration des bestehenden Servers in das Ansible-Repository zu übertragen. Da wir gleichzeitig auch einige Software-Pakete updaten, gehört immer wieder dazu, die Konfiguration nachzuvollziehen und anzupassen. Bis Freitagabend haben wir zusammen etwa 30 Stunden investiert.

Bevor es nun ans eingemachte geht soll der Server noch einmal frisch installiert werden. Ein Klick im Manitu Web-Interface erlaubt die frische Installation verschiedener Linux-Distributionen. Wir entscheiden uns für Debian Stretch, die aktuelle, stabile Version des bekanntesten, häufig für Server genutzten Linux.

Und dann passiert… nichts. Der Server startet nicht automatisch neu, installiert sich nicht neu.

Leider ist es schon Freitag, 21:30 Uhr, als ich das bemerke. Der Manitu-Support wird jetzt wohl schon im Wochenende sein. Die Vermutung liegt nahe, dass das Management-Interface nicht richtig angeschlossen ist und der Server nicht auf dieser Ebene ferngewartet werden kann.

Ich denke daran, dass wir theoretisch eine eigene Möglichkeit zur Fernwartung haben: Es handelt sich um professionelle Server-Hardware, welche über IPMI verfügt. Diese Schnittstelle ist quasi ein kleiner Computer im Computer, der unabhängig über das Internet erreicht werden kann und den Server ein/ausschalten kann, eine Remote-Konsole zur Verfügung stellt und sogar Tastatur-, Maus-, und Bildschirmweiterleitung bereitstellen kann. Glücklicherweise habe ich am Tag vorher vom Support IPMI schon freischalten lassen. Aus Sicherheitsgründen ist der Zugriff durch eine Firewall geschützt. Wir können nur über einen anderen unserer Server - carrot, der Server für Cloud und Wiki - darauf zugreifen.

Mir ist die Zeit etwas im Nacken: Wir benötigen etwa 8 Stunden, um alle Profil- und Essenskorbbilder vom alten Server auf den neuen umzuziehen. Dies soll in der Nacht vor dem Umzug geschehen, damit am Samstag nurnoch ein paar neue Bilder übertragen werden und die Ausfallzeit idealerweise auf wenige Stunden reduziert werden kann. Leider ist es inzwischen 22 Uhr.

Während ich mich über IPMI einlese und schonmal einen Neustart des Servers darüber auslösen kann, schreibe ich trotzdem dem Manitu-Support und frage mal höflich, ob da eventuell das Reset-Interface hängt und gehe schon davon aus, dass vorm Dienstag - wir bedenken: Montag ist Pfingsten - nichts mehr passieren wird.

Nebenbei bemerke ich, dass der Server die Neuinstallation angefangen hat. Toll! Leider ist die Freude kurz: Nach weiteren 20 Minuten sehe ich, dass die Neuinstallation mit einem Fehler abgebrochen ist. Ich liebe Fehlermeldungen, leider wird hier keine angezeigt und lediglich auf den Support verwiesen :-(. Ich versuche, die Bildschirmweiterleitung (“KVM”) mittels IPMI zu verwenden, um dort Rückschlüsse auf den Fehler zu bekommen. Das Tool IPMIView funktioniert leider nur so mäßig, da ich es über X-Forwarding benutzen muss. Nach einigen Minuten der Benutzung einer Suchmaschine meiner Wahl finde ich heraus, dass ich die KVM-Weiterleitung auch über einen SSH-Tunnel von Port 5900 auf meinem Rechner lokal ausführen kann und ein Unterprogramm von IPMIView direkt ausführen kann. Der Befehl:

java -Djava.library.path=. -jar iKVM.jar 127.0.0.1 $USER $PASSWORD null 5900 623 2 0

verschafft mir wirklich ein Bild:

IPMIView KVM Weiterleitung über SSH Tunnel, nachgestellt am Samstagmorgen

In der Zwischenzeit bemerke ich, dass der Manitu-Support mir geantwortet hat. Um 23:36 Uhr an einem Freitagabend habe ich eine Antwort auf eine normale, kostenfreie Supportanfrage bekommen! Ich bin begeistert. Der Mitarbeiter liefert mir zwei entscheidende Hinweise:

Leider kann er zu dieser Zeit nicht am Server nachschauen. Ich müsste eine kostenpflichtige Remote-Hand buchen, um das Reset-Interface sofort zu testen. Andernfalls erfolgt es am Dienstag.
Sein System zeigt, warum die Neuinstallation fehlgeschlagen ist: Anscheinend hat sich das Installationsskript beim Partitionieren der SSDs verschluckt. Ich bekomme den Rat, diese manuell zu löschen und es erneut zu probieren.

Ich habe überhaupt nicht mit einer so raschen Antwort gerechnet und finde es total gerechtfertigt, dass das eigentliche Problem nicht sofort gelöst werden kann. Der zweite Hinweis wirkt: Nach einem Secure Erase der SSDs läuft die Neuinstallation erfolgreich durch.

Inzwischen ist es Samstag. Um 00:30 Uhr logge ich mich in den frisch installierten Server ein, starte die Konfiguration mittels des bis dahin relativ weit fortgeschrittenen Ansible-Projekts und habe nach wenigen Sekunden einen fast fertig eingerichteten foodsharing-Server. Wunderbar :-)

Ich hatte zwischenzeitlich schonmal im Team kommuniziert, dass es gerade Probleme gibt, die uns zu einer Terminverschiebung zwingen könnten. Das darf ich nun also guten Gewissens durchstreichen:

Thread im #foodsharing-dev Slack

Ich starte den Synchronisierungsvorgang der Bilder vom alten Server zum neuen, deaktiviere die Backups auf dem alten Server weil die sonst zuviel IO-Kapazität gezogen hätten und das Kopieren ewig dauern würde und gehe gegen 1:30 Uhr einigermaßen entspannt und zufrieden schlafen.

Weiter geht’s

Samstag um 09:00 gehts mit Kaffee und nach einem netten Frühstück weiter. Glücklicherweise ist der Kopiervorgang schon fertig, auch wenn es zwischendurch so aussah, als könnte der länger dauern. Ein Blick in die Zugriffsstatistiken offenbart, dass nicht weniger los ist als an sonstigen Samstagen. Unsere Ankündigung der Auszeit wird also offenbar nicht so ernst genommen :-).

Ruck zuck ist es 13 Uhr - obwohl “eigentlich alles fertig ist”, verbringe ich den ganzen Tag mit kleineren Anpassungen:

Chandi überarbeitet das Letsencrypt Setup nochmal etwas
Ich richte das E-Mail-System ein und stolpere dabei darüber, dass ich das Paket libsasl2-modules installieren muss, damit unser Mailserver sich an einem anderen anmelden kann, ohne eine nicht ganz hilfreiche Fehlermeldung zu liefern
Gegen 15 Uhr bemerke ich, dass die E-Mail-Anhänge für eingehende E-Mails in das interne E-Mail-System nicht mit synchronisiert - und nebenbei auch nie gebackupt - worden. Naja, ab jetzt schon :-)
Kurze Zeit später stoße ich alle DNS Änderungen an und nehme die Seite das erste mal auf dem neuen Server in Betrieb. Es läuft gut. Ich entscheide mich aber, den Wartungsmodus noch einige Zeit aktiv zu lassen, um alle Komponenten ausführlich zu testen. Für Menschen, die nginx-Konfigurationen lesen können, finden sich im Ansible-Repository alle Hinweise, wie foodsharing.de trotz Wartungsmodus benutzt werden kann. Bitte nicht ohne Absprache nachmachen (sondern lieber dem Entwickler-Team beitreten!)
Den Rest des Abends schlage ich mich noch mit der Einrichtung von PHPMyAdmin zur Datenbankadministration (bäh, keine aktuelle APT-Paketquelle), munin und telegraf zum Monitoring herum.

Die eigentliche Inbetriebnahme - rm /var/www/{production,beta}/current/maintenance_mode_on - verläuft sehr unspektakulär. Es funktioniert einfach und die Seite fühlt sich auch nach wenigen Minuten, trotz einiger Seitenaufrufe pro Sekunde, noch sehr viel schneller als früher an.

Zwischenfazit

Alles dauert wie immer länger als geplant
Donnerstag nachmittag richtig anfangen war gerade so rechtzeitig
Der Serverumzug hat um die 100 Personenstunden im Entwicklerteam gebunden (“Marktwert” also um die 7000 Euro), dennoch wurden nur ungefähr 2 Liter Kaffee konsumiert (und ich wäre mit 2 Tassen weniger vermutlich produktiver gewesen…)
Ansible macht alles langwieriger, zahlt sich aber hoffentlich irgendwann aus
Es macht Spaß zu sehen, dass alles zügiger geworden ist

Am Sonntag um 09:00 Uhr starte ich das Backup erneut, weil es in der Nacht nicht erfolgreich durchgelaufen ist (menschliches Versagen…). In der Vergangenheit hieß Backup am Anfang des Monats immer, dass foodsharing für 1-2 Tage sehr langsam war. Jetzt ist 10:55 Uhr, das Backup ist gerade fertig und foodsharing rannte nebenbei so schnell wie nie :-)

Unser Performance-Monitoring für die Startseite (vollständige Antwort auf den ersten HTTP Request “/”) verbessert sich von ~70-180 ms auf ~17-40 ms, während die CPU-Last an einem Sonntag morgen von ~30-40 % auf ~7-15 % gefallen ist. Die Antwortzeit der Festplatten (Average IO wait) fällt von durchschnittlich ~70-150 ms auf etwa 2 ms (yay, SSDs :-) ), während gleichzeitig die Auslastung von 30-70 % auf unter 10 % fällt.

Wat isn dat jetzt fürne Kiste?

Alter Server, banana.foodsharing.de
- AMD Phenom(tm) II X4 955 Processor (4 x 3.2 GHz, ~2010)
- 8 GB Ram
- 2x 1 TB 7200rpm HDD als RAID1 (effektiv ~200 IOPS read, ~75 IOPS write)
- Debian 8, jessie (+ einige aktuelle Pakete)
Neuer Server, dragonfruit.foodsharing.de
- AMD Opteron(TM) Processor 6272 (16 x 1.4-2.4 GHz, ~2011)
- 32 GB Ram (ECC)
- 4x 240 GB SSD als RAID10 (effektiv ~30000 IOPS read, ~12000 IOPS write)
- Debian 9, stretch (+ viele aktuelle Pakete)

Lust, dabei zu sein?

Hat dich dieser Beitrag angefixt, auch Teil eines ehrenamtlich arbeitenden Teams mit diversesten Aufgaben und dem Interesse, einfach mal neue Dinge ausprobieren zu können, zu werden?
Hier findest du unsere Devdocs, mit einem Teil der Aufgaben, bei denen wir noch nach Unterstützung suchen.
Melde dich gerne per Mail bei it@foodsharing.network oder im #foodsharing-dev Kanal auf dem yunity Slack! Du wirst herzlich empfangen werden :-)