Einloggen
[c] [meta] [fefe]

/meta/ – Diskussionen über Dietchan


Antwort erstellen

(≤ 4)



[Zurück]

  • [l] Quellcodeklebrig? Frickelfelix Wed, 02 Jan 2019 23:05:00 GMT Nr. 5853 Geschlossen
    PNG 623×714 235.4k
    Schraubt hier jemand außer Zuse am DC-Quelltext?

    Die Projektziele haben mir gefallen und obwohl Portabilität nicht mit aufgeführt wird und ausdrücklich Linux gefordert, habe ich mal versucht, es auf meinem LSD zum laufen zu bekommen. Auf die namensgebende Diäten-Libc kann man verzichten, libowfat und Abhängigkeiten sind als Paket vorhanden.

    Kleinere Unterschiede , wie dass
    * sich include- und lib-Pfade unterscheiden,
    * BSD-gcc alt ist und z.B. -mmititage-rop nicht unterstützt,
    * einige Bibos in BSD nicht existieren, oder dass
    * Funktionsprototypen für malloc und alloca nicht in eigenen Header-Dateien liegen,

    lassen sich trivial lösen. Gestoppt habe ich jetzt, bei fallocate (z.B. db.c:398). Vielleicht kann man es einfach ein #ifdef _GNU_SOURCE eingefassen, aber was war hier die Absicht des Verfassers?

    Was hält Felix von einem Klebefaden für Quellcodefrickler? Wenn man auf Gitgud schaut, könnte das Projekt Aufmerksamkeit und Zuarbeiter gebrauchen (issues == mergereqs == 0).
  • [l] Frickel- Felix Wed, 02 Jan 2019 23:12:22 GMT Nr. 5854 SÄGE
    Es hätte heißen sollen
    >wühlt hier sonst jemand in den Eingeweiden von...
    dann passt die Katze auch dazu.

    Bin ansonsten schwer von der bereites erledigten Arbeit begeistert. Bitte empfangt mein kameradschaftliches Tele-Schulterklopfen.
  • [l] Zuse ## Admin Wed, 02 Jan 2019 23:25:32 GMT Nr. 5855
    Ich finde es auf jeden Fall kühl, wenn andere daran mitfrickeln. Danke schon mal für deine Erkenntnisse.

    Das fallocate ist da, weil die Datei per mmap in den Speicher gemappt wird. Ohne fallocate gäbe es dann beim Zugriff einen Bus-Error. Die gleiche Funktionalität müsste doch aber auch unter BSD möglich sein?

    In db.c könnte man eh ein paar Sachen verbessern. Z.B. wird die Datei im Moment zwei mal ein den Speicher gemappt, wobei die eine Kopie nur zum Zurückschreiben der Daten auf die Platte dient. Das ist eigentlich unnötig, da könnte man auch einfach write(), seek() und Co. verwenden.

    Außerdem hat sich herausgestellt, dass fsync auf dem Raspberry Pi sehr langsam ist (das Syncen der Datenbank braucht so ungefähr eine Sekunde und in dieser Zeit können keine Requests bearbeitet werden). Man könnte das vielleicht in einem Hintergrundthread oder so erledigen.

    Habe den Faden mal angepinnt.
  • [l] Frickel- Felix Thu, 03 Jan 2019 13:31:00 GMT Nr. 5874
    Du wirst deine Gründe dafür haben, aber dass es zwei db_init-Prototypen gab, war für mich eine Stolperfalle. fallocate(2) ist erstmal rausgeflogen, es kompiliert und ich bin beim genannten Bus-Problem.

    >gleiche Funktionalität unter BSD
    Gibt es bestimmt. Zumindest kann man auch ohne fallocate mit mmap in Dateien schreiben. Ich habe mal versucht, das Problem mit einem einfachen Programm nachzubauen:
    #include <unistd.h>
    #include <fcntl.h>
    #include <sys/mman.h>
    #include <string.h>
    
    int main(void)
    {
            int fd = open("test_file", O_RDWR | O_CREAT, (mode_t)0600);
            const char *text = "hello";
            size_t textsize = strlen(text) + 1;
            lseek(fd, textsize-1, SEEK_SET);
            /*write(fd, "", 1);*/
            char *map = mmap(0, textsize, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
            memcpy(map, text, strlen(text));
            msync(map, textsize, MS_SYNC);
            munmap(map, textsize);
            close(fd);
            return 0;
    }
    

    fallocate wäre hier write. Wenn es auskommentiert ist, kommt es zum Fehler.
  • [l] Bonus-Frickel- Felix Thu, 03 Jan 2019 14:06:46 GMT Nr. 5875
    Da ich bei mir die mitgelieferten Fefe-Libs ignorieren kann (da BSD-Clib vorhanden und libowfat vorinstalliert), fuhrwerke ich direkt in dietchan/src/dietchan/src rum und da ist mir cmake nach einer Weile auf den Senkel gegangen, weil man nach vielen kleineren Änderungen immer das Makefile neu generieren musste. Meine Variante ist sicher nicht perfekt, aber reicht zum kompilieren:
    CC=gcc
    CFLAGS=-I/usr/local/include -pedantic -std=c99 -O0 -ggdb
    OBJS=arc4random.o bans.o bbcode.o captcha.o context.o db.o db_hashmap.o \
        dietchan.o export.o http.o import.o ip.o job.o mime_types.o \
        params.o permissions.o persistence.o print.o session.o \
        tpl.o upload_job.o util.o
    POBJS=pages/banned.o pages/board.o pages/dashboard.o pages/edit_board.o pages/edit_user.o pages/login.o pages/mod.o pages/post.o pages/static.o pages/thread.o 
    dietchan: $(OBJS) $(POBJS)
            $(CC) -o dietchan -L/usr/local/lib -lowfat $(OBJS) $(POBJS:S/pages\///g)
    
    clean:
            rm -f $(OBJS) $(POBJS:S/pages\///g) dietchan
    

    Hab's auch mit clang geprüft. Kompiliert und die Fehlermeldungen sind dieselben :)

    Auch: rsync benutzt fallocate (--preallocate), allerdings optional.

    Wa alles, beste Grüße
  • [l] Zuse ## Admin Thu, 03 Jan 2019 16:53:35 GMT Nr. 5876
    >>5874
    >Du wirst deine Gründe dafür haben, aber dass es zwei db_init-Prototypen gab
    Hmm, nein, eigentlich nicht. Weiß selber nicht mehr, warum das so ist. Vielleicht war es mal irgendwas zum debuggen, was ich danach nur unvollständig wieder entfernt habe.

    Bezüglich CMake: Zum Entwickeln am besten in src/dietchan wechseln und dort bauen. So habe ich es immer gemacht. Die ExternalProjekt-Funktion von CMake scheint irgendwie etwas verkäfert zu sein. Ich wollte aber etwas haben, was man einfach runterladen und kompilieren kann. Mit dietlibc ist das alles etwas schwierig.
  • [l] Felix Sat, 05 Jan 2019 22:13:28 GMT Nr. 5936
    PNG 512×512 16.6k
    >Mit dietlibc ist das alles etwas schwierig.
    Elaboriere "das alles". Gibt's kein 'make install' oder tut es einfach nicht das Richtige?

    Ich versuche es immer noch zum laufen zu bekommen. Ich schreibe wie im Beispiel gleich nach dem Öffnen in die neue Datei und der Bus-Error ist verschwunden. Jetzt ist ein neuer in db_hashmap_init und wieder mit byte_zero().
  • [l] Zuse ## Admin Sun, 06 Jan 2019 04:11:51 GMT Nr. 5938
    >>5936
    Du brauchst nicht nur dietlibc, sondern auch die richtige Version. Zum Zeitpunkt der Veröffentlichung war das die Trunk-Version und nun die 0.34, weil in der damals aktuellen Version 0.33 noch einige Sachen nicht implementiert waren (z.B. SHA-Hashes und die Race-Condition-freie Version von realpath()). Außerdem muss libowfat dann auch gegen dietlibc gelinkt sein. Das ist alles nicht unbedingt gegeben, wenn man aus einem Repository installiert. Dependencies zu installieren ist sowieso immer mühsam. Ich wollte die Einstiegshürde so gering wie möglich halten. Man sollte es einfach runterladen können und einen Befehl ausführen können, um es zu kompilieren.

    >Ich versuche es immer noch zum laufen zu bekommen. Ich schreibe wie im Beispiel gleich nach dem Öffnen in die neue Datei und der Bus-Error ist verschwunden. Jetzt ist ein neuer in db_hashmap_init und wieder mit byte_zero().
    Versuch mal, die Datei gleich am Anfang auf eine größere Größe zu initialisieren. Die Datei wächst nämlich dynamisch, während sie gefüllt wird. Ich glaube, es ist aber offiziell undefiniertes Verhalten, wie mmap sich verhält, wenn man über das Dateiende hinausmappt (wusste ich zu dem Zeitpunkt aber auch nicht). Beispiel: Sagen wir mal du mappst 10 MB, aber deine Datei ist nur 2 MB groß. POSIX gibt dir die Garantie, dass du auf die ersten 2 MB zugreifen kannst. Wenn jetzt aber die Datei auf 4 MB wächst, dann ist nach POSIX nicht garantiert, dass du auf mehr als die ersten 2 MB zugreifen kannst, obwohl die 4 MB noch in den gemappten 10 MB sind. Unter Linux funktioniert es aber. Vielleicht geht das unter BSD nicht.

    Lösung könnte sein, nach dem Vergrößern der Datei mmap erneut aufzurufen, mit MAP_FIXED als Flag. Dummerweise gibt es aber wiederum keine Garantie, dass MAP_FIXED auch beachtet wird. Aber solange sich die gemappte Größe nicht ändert, sehe ich keinen Grund, warum ein Betriebssystem das Flag nicht beachten sollte.

    Ich würde es erst mal zum Testen damit probieren, die Datei gleich zu Anfang auf eine größere Größe zu initialisieren, z.B. auf 10 MB. Das sollte reichen (die db von dietchan.org ist aktuell 2.1 MB groß).
  • [l] Zuse ## Admin Sun, 06 Jan 2019 09:57:57 GMT Nr. 5939
    Ich habe mal ein paar der angesprochenen Dinge geändert. Probier mal die neue Version.

    Falls hier demnächst etwas kaputt geht, wisst ihr woran es lag.
  • [l] Zuse ## Admin Sun, 13 Jan 2019 16:44:48 GMT Nr. 6155
    Bist du inzwischen weitergekommen?
  • [l] Frickel- Felix Mon, 14 Jan 2019 18:41:12 GMT Nr. 6183
    JPG 600×600 102.6k
    Leider noch nicht.

    Gerade ist daheim das Internet futsch, was die Freizeitprojekte etwas ausbremst.
  • [l] Frickel- Felix Sun, 20 Jan 2019 10:16:41 GMT Nr. 6344
    Wenn ich das richtig sehe, dann hast du die Bibliotheken aus dem Projekt entfernt. Hier ein Ansatz für dietchan/Makefile, um die aktuellen Bibliotheken herunterzuladen, verifizieren und zu entpacken:
    FETCH=curl -O
    VERIFY=gpg --verify
    LFVER=0.32
    LFURI=http://www.fefe.de/libowfat/
    DLVER=0.34
    DLURI=http://www.fefe.de/dietlibc/
    
    libs: libowfat-$(LFVER) dietlibc-$(DLVER)
    
    libowfat-$(LFVER): libowfat-$(LFVER).tar.xz libowfat-$(LFVER).tar.xz.sig
    	$(VERIFY) libowfat-$(LFVER).tar.xz.sig
    	xzcat libowfat-$(LFVER).tar.xz | tar xf -
    
    dietlibc-$(DLVER): dietlibc-$(DLVER).tar.xz dietlibc-$(DLVER).tar.xz.sig
    	$(VERIFY) dietlibc-$(DLVER).tar.xz.sig
    	xzcat dietlibc-$(DLVER).tar.xz | tar xf -
    
    libowfat-$(LFVER).tar.xz:
    	$(FETCH) $(LFURI)$@
    
    libowfat-$(LFVER).tar.xz.sig:
    	$(FETCH) $(LFURI)$@
    
    dietlibc-$(DLVER).tar.xz:
    	$(FETCH) $(DLURI)$@
    
    dietlibc-$(DLVER).tar.xz.sig:
    	$(FETCH) $(DLURI)$@
    

    Zum Verifizieren braucht man natürlich den Schlüssel (von Fefes Seite holen oder mit gpg --search-key A534A9C6 suchen und importieren).
    Kann es sein, dass GPG bei nicht erfolgreicher Verifizierung trotzdem null zurückgibt? Auch würde ich gerne die letzten vier Regeln in eine zusammenfassen, komme aber gerade nicht drauf wie.
  • [l] Frickel- Felix Fri, 01 Mar 2019 20:45:53 GMT Nr. 8024
    Ich habe jetzt eine BSD- und eine Linux-Installation und bin soweit ohne CMake klargekommen. Makefile aus >>5875 funktioniert mit einigen Anpassungen. Ich beschreibe den Vorgang im nächsten Pfosten. Hier noch einige Anregungen:

    1. Erste Meldung: "Listening on 127.0.0.1:4000 (try /c)" ist klickbar und deutet gleich auf's Standardbrett
    2. dietchan startet eine unschöne Endlosschleife, wenn captcha im Ordner fehlt (generate_captchas ist bei mir deshalb auskommentiert).
    3. Es wäre schon, wenn der Quelltext wirklich in /src zu finden wäre. captcha kann meinetwegen fliegen. Es ist ein eigenständiges Projekt und man kopiert nur die fertige Datei zu herüber.
  • [l] Frickel- Felix Fri, 01 Mar 2019 20:48:10 GMT Nr. 8025
    Dietchan zu kompilieren ist nicht schwierig. Ohne Vorkenntnisse sollte man nach 10-15 Minuten mit dem Hacken anfangen können. Ich habe das hier mal etwas ausführlicher beschrieben:

    1. DIETLIBC

    Lade dir die aktuelle Version (zur Zeit 0.34) von http://www.fefe.de/dietlibc .

    Falls du ihn noch nicht hast, solltest du auch seinen PGP-Schlüssel A534A9C6 laden. Das geht entweder über die Seite selbst (https://dl.fefe.de/felix@fefe.de.asc, du musst ihn noch mit "gpg --import" einlesen) oder mit dem Befehl "gpg --search-key 0xA534A9C6". Kannst du den Schlüssel dann in der Ausgabe von "gpg -k Fefe" finden, kannst du ebenso mit "gpg --verify dietlibc-0.34.tar.xz" die Echtheit des Pakets prüfen.

    Hat GPG nichts zu beanstanden, entpackst du das Archiv, wechselst in das neue Verzeichnis und führst "make" aus. Wenn du hier einen Fehler bekommst, dann hast du vermutlich die Kernel-Header nicht installiert. Ist alles glatt gelaufen, dann schaust du in den Ordner bin-x86 oder bin-x86_64 und wirst dort eine Datei mit dem Namen diet finden. Mit ihrer Hilfe können wir ohne großer Friemelei Dateien mit der dietlibc kompilieren, indem wir einfach das Wort diet vor den gcc-Befehl schreiben.

    Du solltest wissen, wie du auf deinem System diese Datei in deinen Suchpfad kopieren kannst. Tue dies! Nur falls du dies nicht weißt, probier es mit folgendem:
    1. Lege dir ein Verzeichnis ~/bin an.
    2. Starte eine Shell und schreibe PATH=$PATH:~/bin .
    3. Kopiere die diet-Datei nach ~/bin .
    4. Probiere testweise im entpackten Archiv folgendes: "diet -v gcc t.c"
    Dietlibc schreibt einige Warnungen, die uns jetzt nicht interessieren. Schau, ob eine Datei t entstanden ist und ob sie läuft.

    Gut! Du hast jetzt diet in deinem Suchpfad und kannst theoretisch allerhand Dateien mit der Dietlibc kompilieren und auf diese Weise viel kleinere ausführbare Datei erzeugen.

    2. LIBOWFAT

    Sehr einfach: Herunterladen, Verifizieren, Entpacken und make ausführen. Wenn du im letzten Schritt alles richtig gemacht hast, dann wird diet im Suchpfad erkannt und genutzt.

    3. DIETCHAN

    Besorg dir den Kot, indem du das Git-Repositorium klonierst:
    git clone https://gitgud.io/zuse/dietchan.git
    Der eigentliche Quellkot liegt im Unterverzeichnis dietchan/src. Wir machen es uns jetzt sehr einfach und kopieren das Verzeichnis libowfat-0.32/libowfat und die Datei libowfat.a ins dietchan-Verzeichnis. Dann gehst du in das src-Verzeichnis und das "make" sollte ohne Probleme durchlaufen und eine Datei dietchan erzeugen. Wenn du diese ausführst, kannst du in deinem Brausierer die Adresse "127.0.0.1:4000/c" öffnen et voila!

    Du siehst, es ist nicht schwierig. Vielleicht konntest du Einiges überspringen, weil du es schon kennst. Du kannst jetzt jedenfalls alles.jpg im Quelltext verändern. Versuche zum Beispiel mal die Seitenunterschrift ("Proudly made...") zu ändern und pfostiere dein Ergebnis hier.
  • [l] Frickel- Felix Fri, 01 Mar 2019 20:52:14 GMT Nr. 8026
    Der Vollständigkeit halber, die veränderte Make-Datei:
    CC=diet gcc
    CFLAGS=-I.. -pedantic -std=c99 -O0 -ggdb
    OBJS=arc4random.o bans.o bbcode.o captcha.o context.o db.o db_hashmap.o \
        dietchan.o export.o http.o import.o ip.o job.o mime_types.o \
        params.o permissions.o persistence.o print.o session.o \
        tpl.o upload_job.o util.o
    POBJS=pages/banned.o pages/board.o pages/dashboard.o pages/edit_board.o pages/edit_user.o pages/login.o pages/mod.o pages/post.o pages/static.o pages/thread.o 
    dietchan: $(OBJS) $(POBJS)
    	$(CC) -o dietchan $(OBJS) $(POBJS) -L.. -lowfat
    
    clean:
    	rm -f $(OBJS) $(POBJS) dietchan
    


    Es ist jetzt an die einfacheren Gegebenheiten angepasst und berücksichtigt, dass die Pfade nicht von POBJS nicht angepasst werden müssen.

    Nochmal zum letzten Pfosten: Stimmt der Git-Pfad so?
  • [l] Zuse ## Admin Sat, 02 Mar 2019 19:48:02 GMT Nr. 8038
    >>8024
    >1. Erste Meldung: "Listening on 127.0.0.1:4000 (try /c)" ist klickbar und deutet gleich auf's Standardbrett
    Ist ein guter Vorschlag, werde ich wohl umsetzen.
    >2. dietchan startet eine unschöne Endlosschleife, wenn captcha im Ordner fehlt (generate_captchas ist bei mir deshalb auskommentiert).
    Eine Endlos-Schleife ist es nicht, aber es ist etwas spammig, das gebe ich zu. Wäre besser, wenn die Captchas erst generiert würden, wenn sie wirklich gebraucht werden.
    >3. Es wäre schon, wenn der Quelltext wirklich in /src zu finden wäre.
    Hmm, die Logik ist, dass sich in dem Ordner die Quellen zu den Teilkomponenten befinden. Normalerweise sind dies: dietlibc, libowfat, dietchan selbst und das captcha. Da du dietlibc und libowfat aber manuell kompiliert hast, ist das vielleicht bei dir etwas irritierend.

    Danke auf jeden Fall für deine Ausführungen :-) Hast du etwas bestimmtes mit der Software vor?
  • [l] Felix Tue, 05 Mar 2019 17:56:39 GMT Nr. 8087
    >>8038
    Stimmt der Git-Pfad so? Bin mit Git noch nicht ganz warm.

    >Hast du etwas bestimmtes mit der Software vor?
    Ja, C-Praxis bekommen. Vielleicht hast du bei Linux schon von den Kernel-Putzen gehört.

  • [l] Zuse ## Admin Wed, 06 Mar 2019 16:54:39 GMT Nr. 8148
    >>8087
    >Stimmt der Git-Pfad so? Bin mit Git noch nicht ganz warm.
    Sollte stimmen. Wenn es funktioniert, dann stimmt es auch.
  • [l] Frickelfelix Fri, 29 Mar 2019 21:32:32 GMT Nr. 9101
    diff --git a/src/dietchan/src/dietchan.c b/src/dietchan/src/dietchan.c
    index 46727cc..68ad8d2 100644
    --- a/src/dietchan/src/dietchan.c
    +++ b/src/dietchan/src/dietchan.c
    @@ -246,7 +246,7 @@ int handle_write_events(int limit)
     		if (!ctx) {
     			io_dontwantwrite(s);
     			io_close(s);
    -			printf("Warning: cookie is null\n");
    +			buffer_putsflush(buffer_2, "Warning: cookie is null\n");
     			continue;
     		}
     		context_flush(ctx);
    @@ -258,8 +258,11 @@ void add_listener(struct ip ip, uint16 port)
     {
     	char buf[256];
     	buf[fmt_ip(buf,&ip)] = '\0';
    -	fprintf(stderr, "Creating listener on port %d for address %s\n", (int)port, buf);
    -
    +	buffer_puts(buffer_2, "Creating listener (try http://");
    +	buffer_puts(buffer_2, buf);
    +	buffer_puts(buffer_2, ":");
    +	buffer_putulong(buffer_2, (unsigned long)port);
    +	buffer_putsflush(buffer_2, "/c for the default board).\n");
     	struct listener *listener = listeners + listener_count;
     	listener->ip = ip;
    

  • [l] Zuse ## Admin Sat, 30 Mar 2019 00:54:43 GMT Nr. 9103
    >>9101
    Danke, ist drin.
  • [l] Felix Wed, 24 Apr 2019 12:54:18 GMT Nr. 10061
    GIF 600×400 104.5k
    Kannst du für einen guten NichtInformatiker etwas zu deiner Datenbank sagen?

    Verstehe das so, dass sie dynamisch Speicher alloziert und zwar eimerweise :> Funktion eines Journals ist schon von Dateisystemen her bekannt. Die persistence.h verstehe ich so, dass praktisch alle Anfragen an die Datenbank dort gebündelt sind. Serialisierung fällt flach, weil die Datenstruktur auf der Platte dank mmap dieselbe wie im Speicher ist.

    Gibt es ein Vorbild?
  • [l] Zuse ## Admin Thu, 25 Apr 2019 03:41:18 GMT Nr. 10078
    >>10061
    Du hast es erfasst. Die Datenbank ist sozusagen ein Dump des Speicherabbildes.

    >Gibt es ein Vorbild?
    Das Design war ein bisschen von BerkeleyDB inspiriert. Ich weiß aber nicht viel über BerkeleyDB, habe es auch nie benutzt.
  • [l] Felix Mon, 29 Apr 2019 23:13:01 GMT Nr. 10176
    Kurze Frage: Kann es sein, dass der Quelltext
    https://gitgud.io/zuse/dietchan/blob/master/src/dietchan/src/db.c#L568-582
    niemals ausgeführt wird, weil die Schleife darüber immer entweder zu success oder fail springt?
  • [l] Zuse ## Admin Tue, 30 Apr 2019 10:20:45 GMT Nr. 10185
    >>10176
    Gut aufgepasst, der Code machte auf jeden Fall keinen Sinn.

    Eigentlich müssen die Seiten sowieso nur nach einem Crash neu gemappt werden (im laufenden Betrieb wächst die Datenbank sonst einfach in den anonym gemappten Bereich hinein), dann aber immer, unabhängig davon, ob sich die Größe geändert hat. Ich habe das mal behoben. Ich habe den Code länger nicht mehr angeschaut, aber glaube es stimmt so.

    Es sind eh im Hintergrund Änderungen am Journal im Gange, ist aber alles noch experimentell.

    Vielen Dank für den Hinweis!
  • [l] Frickel- Felix Sat, 01 Jun 2019 12:15:39 GMT Nr. 11247
    Hai, Konni!

    Hab mal wieder gebaut und mit dem aktuellen Kot läuft die Kiste auch auf BSD.

    diff --git a/src/dietchan/src/config.h b/src/dietchan/src/config.h
    index 9f64c30..4c3af42 100644
    --- a/src/dietchan/src/config.h
    +++ b/src/dietchan/src/config.h
    @@ -75,5 +75,6 @@
     #define MAX_GET_PARAM_LENGTH           2048
     #define MAX_POST_PARAM_LENGTH         16384
     #define MAX_MULTIPART_BOUNDARY_LENGTH   128
    +#define NEED_CAPTCHA                      0
     
     #endif // CONFIG_H
    diff --git a/src/dietchan/src/dietchan.c b/src/dietchan/src/dietchan.c
    index 65be601..64ce7ed 100644
    --- a/src/dietchan/src/dietchan.c
    +++ b/src/dietchan/src/dietchan.c
    @@ -380,7 +380,7 @@ int main(int argc, char* argv[])
     	mkdir(DOC_ROOT "/uploads", 0755);
     	mkdir(DOC_ROOT "/captchas", 0755);
     	// Start generating captchas
    -	generate_captchas();
    +	if (NEED_CAPTCHA) generate_captchas();
     
     	// Main loop
     	while (1) {
    

    Eigentlich sollte das nur auskommentiert werden, aber wir haben ja schon eine config.h.

    diff --git a/src/dietchan/src/http.c b/src/dietchan/src/http.c
    index c141d33..f82f55f 100644
    --- a/src/dietchan/src/http.c
    +++ b/src/dietchan/src/http.c
    @@ -1,6 +1,8 @@
     #include "http.h"
     
    +#ifdef __GLIBC__
     #include <alloca.h>
    +#endif
     #include <string.h>
     #include <stdlib.h>
     #include <ctype.h>
    

    Anscheinend ist alloca.h GLIBC-spezifisch und ich habe überlegt, wie man das umsetzen kann. Wörksformi(tm), aber jetzt fange ich an, den Kot mit ifdefs zu verschandeln. Ich habe mal gelesen, dass das schöner geht, kann mich aber nicht daran erinnern wie.

    diff --git a/src/dietchan/src/import.c b/src/dietchan/src/import.c
    index eab0a6f..a0ca7a2 100644
    --- a/src/dietchan/src/import.c
    +++ b/src/dietchan/src/import.c
    @@ -1,6 +1,5 @@
     #include "import.h"
     
    -#include <malloc.h>
     #include <unistd.h>
     #include <ctype.h>
     #include <stdio.h>
    

    Einbinden von malloc.h ist angeblich auch auf Linux mittlerweile unerwünscht, also habe ich es einfach ausgelassen.

    diff --git a/src/dietchan/src/pages/post.c b/src/dietchan/src/pages/post.c
    index 2971796..16acadc 100644
    --- a/src/dietchan/src/pages/post.c
    +++ b/src/dietchan/src/pages/post.c
    @@ -1,9 +1,8 @@
    -#define _BSD_SOURCE 1
    +#define _BSD_SOURCE 1
     #define _GNU_SOURCE 1
     #define _XOPEN_SOURCE 1
     #include "post.h"
     
    -#include "malloc.h"
     #include <stdio.h>
     #include <sys/socket.h>
     #include <sys/stat.h>
    

    In post.c hat sich ein BOMЖ verirrt, an dem sich gcc verschluckt.

    Das "malloc.h" habe ich aus demselben Grund ausgelassen, warum ist es hier allerdings in ""?

    diff --git a/src/dietchan/src/util.c b/src/dietchan/src/util.c
    index 3802858..b6c78ab 100644
    --- a/src/dietchan/src/util.c
    +++ b/src/dietchan/src/util.c
    @@ -1,11 +1,15 @@
     #include "util.h"
     
     #include <ctype.h>
    +#ifdef __GLIBC__
     #include <alloca.h>
    +#endif
     #include <libowfat/str.h>
     #include <libowfat/fmt.h>
     #include <libowfat/scan.h>
    +#ifndef arc4random
     #include "arc4random.h"
    +#endif
     
     size_t byte_str(const char *haystack, size_t haystack_length, const char *needle)
     {
    

    Keine Ahnung, ob das so funktioniert. In BSD wird arc4random in der stdlib.h definiert, also sollte er die eigene Definition nicht einbinden.
  • [l] Zuse ## Admin Sat, 01 Jun 2019 22:51:18 GMT Nr. 11254
    >>11247
    Danke erstmal. Sieht soweit gut aus, das mit den Captchas könnte aber Probleme geben, wenn man sie zur Laufzeit aktiviert und NEED_CAPTCHAS nicht gesetzt ist. Ich denke, die richtige Lösung wäre, dass die Captchas generiert werden, wenn sie zum ersten mal aktiviert werden.
  • [l] Zuse ## Admin Fri, 14 Jun 2019 04:18:25 GMT Nr. 11668
    Kurzes Update, ich habe erstmal diese Header-Sachen da gefixt. Es hat sich außerdem rausgestellt, dass auch dietlibc mittlerweile eine arc4random-Implementierung mitliefert, sodass ich den Kot komplett entfernen konnte. Das ist immer erfreulich.
  • [l] Felix Wed, 04 Sep 2019 20:03:49 GMT Nr. 14529
    Bugreport (vom Kopierscript, nicht Dietchan): https://dietchan.org/fefe/14493

    Fefe hat im HTML-Quelltext den Link mit <a href=" begonnen, aber vor der URL einen Zeilenumbruch eingefügt. Damit taucht auf DC unten in der URL zusätzlich vorher https://blog.fefe.de auf. Ist nur was kosmetisches, aber ich dachte ich zeig mal drauf.
  • [l] Zuse ## Admin Wed, 04 Sep 2019 23:17:28 GMT Nr. 14535
    >>14529
    Danke für den Hinweis. Sollte jetzt behoben sein.
  • [l] Zuse ## Admin Fri, 13 Sep 2019 00:12:45 GMT Nr. 14737
    PDF geht übrigens wieder. War kaputt, weil etliche Distros PDF-Unterstützung in ImageMagick (aus guten Gründen) abgestellt haben, nachdem es gefühlt jede Woche einen neuen Exploit gab. Dietchan nutzt jetzt stattdessen Poppler, was etwas besser zu sein scheint.
  • [l] Felix Mon, 06 Jan 2020 10:13:50 GMT Nr. 20563
    Bilder laden nicht:
    >curl -I https://dietchan.org/uploads/1568333565001s.png
    HTTP/2 500
    Bilder hochladen geht nicht:
    >Error
    >
    >Unsupported mime type: cannot open `./www/uploads/.tmp9548370890' (No such file or directory)
    >fefehefe.png
  • [l] Zuse ## Admin Tue, 07 Jan 2020 01:39:23 GMT Nr. 20573
    Es werden wohl irgendwo Dateideskriptoren geleckt. Muss noch genauer untersucht werden.
  • [l] Zuse ## Admin Fri, 10 Jan 2020 21:31:08 GMT Nr. 20722 SÄGE
    >>20573
    Die Ursache scheint gefunden. Manche Klienten schließen die Verbindung, bevor sie überhaupt anfangen, Daten zu senden (ich habe IPv6-Fail-Fast im Verdacht). In diesem Fall wurde der Socket und der zugehörige Kontext nicht freigegeben. Das sollte nun nicht mehr auftreten.
  • [l] Felix Sat, 11 Jan 2020 15:41:26 GMT Nr. 20752 SÄGE
    >>20722
    Gute Arbeit, Konrad.
    Du hattest gewissermaßen das gegenteilige Problem von Fefe, der Sockets vorzeitig weggeschmissen hat, bevor alle Ereignisse (und der OpenSSL-Fehlerstapel) für diese abgearbeitet waren.
    https://blog.fefe.de/?ts=a90aedbb
    https://blog.fefe.de/?ts=a900fc5d
  • [l] Ey, lass mal auditieren Felix Thu, 23 Apr 2020 14:40:16 GMT Nr. 27689
    GIF 474×308 78.0k
    Kann es sein, dass es noch keine „Letsaudits“ gibt, wo jemand echten, im Einsatz befindlichen Kot erklärt. Die sogenannten Live Coding Sessions kommen dem bisher am nächsten, aber ich will kein Schulbeispiel, sondern echte Programmierpraxis.

    Der Vollständigkeit halber hier ein paar Suchbegriffe, die ich versucht habe und was ich gefunden habe:

    letsaudit -> nada
    source code audit -> Erklärvideo
    audit session -> Scientology
    debug session -> Mikroelektronik, Android


    Auch: Was hielte die Administration von einem ebensolchen Premiere-Audit? Rundfunk über datensparsames Telnet, Erklärung und dumme Fragen vom Publikum per Mumble. Optional für die Nachwelt eine ttyrec-Aufnahme nebst Audio-Aufzeichnung. Soweit meine Idee, um sich von den anderen Brettern mit ihren lahmen Radios abzugrenzen :)
  • [l] Zuse ## Admin Thu, 23 Apr 2020 18:58:39 GMT Nr. 27698
    >>27689
    Wenn du das machen willst, nur zu. Was genau erwartest du von der Administration? Würde aber vorher erst mal schauen, ob genug Felixe Interesse daran haben. Eventuell das ganze auch noch mal zusätzlich woanders bewerben.
  • [l] Felix Fri, 24 Apr 2020 06:00:13 GMT Nr. 27721
    >>27689
    >Kann es sein, dass es noch keine „Letsaudits“ gibt, wo jemand echten, im Einsatz befindlichen Kot erklärt.
    Schwebt dir sowas vor? https://www.youtube.com/watch?v=K5ql20pM99o
    >Sean Barrett - very high-level analysis of System Shock 1 source code release

    Sean Barrett ist der Typ, der die stb_nothings-Bibliotheken geschrieben hat: https://github.com/nothings/stb
  • [l] Felix Thu, 30 Apr 2020 00:07:58 GMT Nr. 28046
    >>27698
    Hmmm, mir schwob eigentlich eine sehr leichtgewichtige Lösung vor. Die erste Idee war, dass jeder als Login-Shell einfach `cat /dev/tty$OP` bekommt, aber das zeigt viele Probleme. Vielleicht ist es ja auch irgendmöglich den stdout von einer Shell mit drei Zeilen dietlib-C zu duplizieren, aber erstmal habe ich versucht, dass mit fertigen Programmen zu bauen. Jetzt ist die Idee, ein telnetd mit Login felix@ und jedes neue Terminal startet `tmux attach-session -r`, also read-only. Es gibt auch jemanden, der das schon einmal gemacht hat[1]. Der Patch dort ist vielleicht auch schon im Distri-tmux drin (außer man hat Debian :^) latürnich) und man muss es nicht nochmal neu aus den Quellen bauen (ist aber auch nur eine Sache von Sekunden). Der Rest ist Mumble einzurichten = geschenkt.
    Ich will das jedenfalls mal in den kommenden Tagen auf meinen heimischen Servieren prüfen.

    > Was genau erwartest du von der Administration?
    Idealerweise natürlich das zu hostieren. Andererseits könnt Ihr auch meine Angst, nacktgemacht zu werden, besänftigen. Ich habe schon selbst hostiert, aber bei Bilderbrettern weiß ich noch nicht, welche Sachen auf mich zukämen. Mit anonymen Hosten habe ich mich auch noch nicht beschäftigt. Dann bräuchte man nur einen Elfenjüngling zu platzieren.

    Auf jeden Fall braucht es einen, der etwas über seinen Code erzählen möchte. Da es hier um Dietchan geht, sollte natürlich ein (der) Entwickler sich dafür eine Stunde freinehmen können.

    >>27721
    Das trifft die Idee schon ziemlich genau. Ich hätte natürlich lieber jemand, der *seinen* Code beschreibt und das dann auch besser erklären kann. Gerade als Sean diese Anekdote erzählt hat, dass der Programmierer für die Physik-Logik auch einen Physiker-Hintergrund hatte und daher ziemlich Fortran-typischen Code schrieb, hätte ich wirklich gerne mehr erfahren.

    Aber gut, dass du Spiele erwähnst. Die Spiele von id sind ja auch größtenteils quelloffen und John (oder John) könnte gerne mal ein wenig mehr darüber erzählen. Ich habe das mal vor einer Weile versucht und habe entweder die Entwickler gefunden, wie sie über allgemeine Dinge sprachen (Wie man anfängt, Spiele zu entwickeln, welche Rolle straffe Unternehmensführung dabei spielt usw.) oder irgendwelche Anderen, die Teile des Codes auseinandergenommen haben. Dass Leute ihren eigenen Code erklären scheint wirklich noch eine Nische zu sein.

    1: https://brianmckenna.org/blog/guest_tmux
  • [l] Felix Thu, 30 Apr 2020 09:44:58 GMT Nr. 28084
    >>28046
    > Ich habe schon selbst hostiert, aber bei Bilderbrettern weiß ich noch nicht, welche Sachen auf mich zukämen.
    Kinderpornobilder. Jede Menge Kinderpornobilder, wahlweise durhc Trolle oder durch Leute, die dein Bilderbrett zum Tauschen von Kipo benutzen wollen. Und Bilder von ISIS-Hinrichtungen, Nazipropaganda, Goatse etc.
  • [l] Zuse ## Admin Thu, 30 Apr 2020 17:56:24 GMT Nr. 28135
    >Idealerweise natürlich das zu hostieren. Andererseits könnt Ihr auch meine Angst, nacktgemacht zu werden, besänftigen. Ich habe schon selbst hostiert, aber bei Bilderbrettern weiß ich noch nicht, welche Sachen auf mich zukämen. Mit anonymen Hosten habe ich mich auch noch nicht beschäftigt. Dann bräuchte man nur einen Elfenjüngling zu platzieren.
    Kommt natürlich darauf an, wie viel Wert du auf Anonymität legst. Nacktmachung erfolgt vor allem über DNS. Da würde es reichen, einen Anbieter mit Whois-Guard zu nehmen (z.B. njal.la). Eine Domäne braucht man für den Anfang aber nicht unbedingt. Einfach bei beliebigem Wolkenhostierer einen Servierer mieten und dann die IP verlinken. Das sollte reichen, solange du nichts illegales vorhast. Dietchan könnte ggf. auch eine Subdomäne bereitstellen oder als Stellvertreter agieren.

    >Da es hier um Dietchan geht, sollte natürlich ein (der) Entwickler sich dafür eine Stunde freinehmen können.
    Danke, aber darauf habe ich ehrlich gesagt nicht wirklich Lust. Ich hoffe, das hält niemanden davon ab.

    >>28084
    >Kinderpornobilder. Jede Menge Kinderpornobilder, wahlweise durhc Trolle oder durch Leute, die dein Bilderbrett zum Tauschen von Kipo benutzen wollen. Und Bilder von ISIS-Hinrichtungen, Nazipropaganda, Goatse etc.
    Es war weniger schlimm als erwartet. Bisher kam es hier zum Glück nicht zu solchen Problemen. Das ist wohl der Vorteil, wenn man eine kleine Nische bedient.
  • [l] N00bfelix Fri, 22 May 2020 14:31:24 GMT Nr. 29146
    Schlechter Informatikerfelix hat sich mal dietchan gezogen und komplifiziert aber das Ding leitet nicht weiter wenn man nur Domäne:Port eingibt. Man muss /c mit angeben. Wo kann Felix das einstellen? Drinbevor muddu Kot ändern. Es kommt:
    >404
    >Das Brett wurde nicht gefunden :(.
  • [l] Zuse ## Admin Fri, 22 May 2020 22:22:43 GMT Nr. 29162
    >>29146
    Tatsächlich ist diese Funktion bisher in Dietchan nicht implementiert. Der Grund ist, dass Dietchan eigentlich dafür konzipiert ist, hinter einem Reverse Proxy (z.B. nginx) betrieben zu werden. Wenn man schon den Reverse Proxy konfiguriert, dann kann man auch leicht noch eine Umleitung dort einrichten. Es könnte aber auch sein, dass man gar keine Umleitung möchte, sondern auf der Startseite lieber etwas anderes anzeigen möchte, z.B eine Übersichtsseite, Neuigkeiten usw. Da lässt Dietchan dir alle Freiheiten.

    Eine einfache Konfiguration für nginx mit Umleitung könnte so aussehen:

    events {
        worker_connections  4096;
    }
    
    http {
        gzip  on;
    
        upstream dietchan {
            server 127.0.0.1:4000;
        }
        
        server {
            listen       80;
            listen       [::]:80;
    
            # Statt localhost deine Domäne angeben
            server_name  localhost;
    
            # Umleitung 
            location = / {
                return 301 /c/;
            }
    
            # Reverse-Proxy
            location / {
                proxy_request_buffering off;
                proxy_buffering off;
                proxy_http_version 1.1;
                client_max_body_size 0;
            
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            
                proxy_pass http://dietchan;
            }
        }
    }
    

  • [l] Felix Fri, 22 May 2020 23:33:32 GMT Nr. 29163
    >>29162
    Es wäre einfach so im LAN als unkonventionelle Halde gedacht gewesen. Das Ding läuft schnell so schnell auf einem Himbeerkuchen. Dann ist es halt so.
    Danke auch sonst, ist ein interessantes Projekt.
  • [l] Felix Thu, 18 Jun 2020 10:47:46 GMT Nr. 30368
    Fehler:
    >>/fefe/30361
    >E&amp;Y hat Wirecard das Testat verweigert
  • [l] Felix Thu, 18 Jun 2020 16:42:49 GMT Nr. 30426
    >>30368
    Ist ein HTML-Kompetenztest.


[Zurück]
[c] [meta] [fefe]