[eol]

Ça m'a l'air mieux

Code :

curl -I http://127.0.0.1/test.txt
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/plain; charset=utf-8
Date: Fri, 15 May 2020 10:13:15 GMT
ETag: 26538-1589487121-665031
Server: OpenBSD httpd
Transfer-Encoding: chunked

Je n'avais pas pensé à lancer ldd sur le binaire ni à lire le Makefile, bien vu.

---

Code :

curl -I --compressed http://127.0.0.1/test.txt
HTTP/1.1 200 OK
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/plain; charset=utf-8
Date: Fri, 15 May 2020 10:21:06 GMT
ETag: 26537-1589487138-260915
Server: OpenBSD httpd
Transfer-Encoding: gzip
Transfer-Encoding: chunked

Mieux pour montrer que la requête vers un .txt sert effectivement un .gz

---

httpd montre :

Code :

default 127.0.0.1 - - [15/May/2020:12:21:06 +0200] "HEAD /test.txt HTTP/1.1" 200 0
server default, client 2 (1 active), 127.0.0.1:37770 -> 127.0.0.1, buffer event error

mais je n'ose pas affirmer que ça a quoi que ce soit à voir avec sbw.

[solene]

j'ai aussi l'erreur 500, en lançant ktrace sur slowcgi j'obtiens ça

Code :

23757 slowcgi  NAMI  "/cgi-bin/sbw.cgi"
23757 slowcgi  ARGS  
        [0] = "/cgi-bin/sbw.cgi"
23757 sbw.cgi  NAMI  "/usr/libexec/ld.so"
18596 slowcgi  PSIG  SIGCHLD caught handler=0xc0ad0d5e890 mask=0<>
18596 slowcgi  RET   kevent -1 errno 4 Interrupted system call

on dirait que cbw.cgi s'arrête de manière impromptue lorsqu'il est appelé via slowcgi. Si je le lance à la main avec le bon environnement il fonctionne par contre.

edit : bon, j'ai fait des progrès... en regardant les libs nécessaires pour sbw.cgi et en copiant ces dernières dans le chroot, sbw.cgi ne meurt pas tout de suite lancé via slowcgi.

Code :

t400# ldd /var/www/cgi-bin/sbw.cgi                
/var/www/cgi-bin/sbw.cgi:
        Start            End              Type  Open Ref GrpRef Name
        00000901e38a8000 00000901e38ae000 exe   1    0   0      /var/www/cgi-bin/sbw.cgi
        000009045c259000 000009045c34c000 rlib  0    1   0      /usr/lib/libc.so.96.0
        000009041d16d000 000009041d16d000 ld.so 0    1   0      /usr/libexec/ld.so
t400#

Lancé à la main, il fait une erreur d'unveil.

Code :

t400# env realroot=/var/www/htdocs/ PATH_INFO=/index.html chroot /var/www/ /cgi-bin/sbw.cgi  
sbw.cgi: unveil: No such file or directory

la sortie de slowcgi confirme ça

Code :

13612 sbw.cgi  RET   kbind 0
13612 sbw.cgi  CALL  kbind(0x7f7fffff0088,24,0xc1c4e3f6d9358e64)
13612 sbw.cgi  RET   kbind 0
13612 sbw.cgi  CALL  unveil(0x7f7fffff0d47,0xf45e67dfea2)
13612 sbw.cgi  STRU  flags="r"
13612 sbw.cgi  NAMI  "/var/www/htdocs/"
13612 sbw.cgi  RET   unveil -1 errno 2 No such file or directory

je crois que j'ai du mettre un chemin absolu pour le realroot

edit 2 : en mettant /htdocs/ et pas /var/www/htdocs/ ça marche. J'ai du copier /usr/lib/libc.so.96.0 et /usr/libexec/ld.so dans le chroot pour que ça marche

edit 3 : vérifié avec Firefox, le chargement du index.html de mon blog, transféré 133,25 ko pour un total de 426,64 ko dans le contenu réel.

[prx]

solene, reessaie depuis que j'ai ajouté l'option "-static" pour la compilation (je rappelle que je débute en C, je n'y avais pas pensé).

Et en effet, tu vas avoir un souci avec unveil, le chemin dans "realroot" est relatif au chroot d'httpd, à savoir /var/www (mais tu le sais).

[solene]

solene, reessaie depuis que j'ai ajouté l'option "-static" pour la compilation (je rappelle que je débute en C, je n'y avais pas pensé).

Et en effet, tu vas avoir un souci avec unveil, le chemin dans "realroot" est relatif au chroot d'httpd, à savoir /var/www (mais tu le sais).

avec -static et sans les libs dans le chroot ça fonctionne

[prx]

Oui, c'est le but : ne pas avoir à copier des libs.

[solene]

Oui, c'est le but : ne pas avoir à copier des libs.

t'as plus qu'à mettre à jour ton site pour expliquer qu'il faut copier les libs alors

[PengouinBSD]

ouah, ça avance, ça avance.
Merci à tous deux d'avoir aidé ! :p

@prx, bon, je vais dl ton nouveau "morceau", et faire le nécessaire selon tes indications

sinon :

s/garantaif/garantir

C'est dans quelle langue "garantaif" ?! :p

----

Bon, en effet, ça semble plus stable :p
Merci.

Proposition d'ajout :
- entête "Last-modified:", calculée à partir de la date de modification du fichier
- la gestion de "deflate", pour laquelle tu peux envoyer le contenu gzip, car gzip connaît ce format de compression
- la gestion de brotli, sans modification du fichier de config

[eol]

Oui, c'est le but : ne pas avoir à copier des libs.

t'as plus qu'à mettre à jour ton site pour expliquer qu'il faut copier les libs alors

Avec "-static" ajouté dans le Makefile,
ce n'est plus nécessaire.

Code :

# ldd /var/www/cgi-bin/sbw.cgi
/var/www/cgi-bin/sbw.cgi:
    Start            End              Type  Open Ref GrpRef Name
    00000c0bd72a5000 00000c0bd72ca000 dlib  1    0   0      /var/www/cgi-bin/sbw.cgi

Il n'y a plus de référence à quoi que ce soit en dehors du chroot.

[solene]

Oui, c'est le but : ne pas avoir à copier des libs.

t'as plus qu'à mettre à jour ton site pour expliquer qu'il faut copier les libs alors

Avec "-static" ajouté dans le Makefile,
ce n'est plus nécessaire.

Code :

# ldd /var/www/cgi-bin/sbw.cgi
/var/www/cgi-bin/sbw.cgi:
    Start            End              Type  Open Ref GrpRef Name
    00000c0bd72a5000 00000c0bd72ca000 dlib  1    0  0      /var/www/cgi-bin/sbw.cgi

Il n'y a plus de référence à quoi que ce soit en dehors du chroot.

aussi mais peut être que prx voulait pas de -static ?

[eol]

Je n'avais pas envisagé cette possibilité.

Dans le cas présent quel serait l'inconvénient de "-static" comparé au fait de devoir
trouver et copier les bibliothèques à la main ? À part sur un système où l'espace disque
est restreint et embarquer une copie des bibliothèques dans chaque éxécutable serait
perçu comme un gaspillage d'espace disque, je ne vois que des avantages à "-static"
pour construire des binaires destinés à un chroot (surtout quand ils sont peu nombreux).

[prx]

Mais si j'en voulais du static ! c'est plus pertinent de n'avoir qu'un binaire à copier pour garder le chroot propre.

Garantaif, c'est très courant, non ?
Je suis effaré de ce que je laisse traîner... Merci.

Concernant tes propositions, je vais voir si l'entête Last-update est pertinent en plus de l'Etag(je ne crois pas).

Pour deflate je ne suis pas sûr que ça soit la même chose comme format de compression. Je vais creuser là aussi.

Pour brotli c'est non, impossible à ma connaissance de compresser en brotli avec une openbsd de base. De plus, si un admin veut proposer ce format, il y a fort à parier que ce soit pour toute sa machine, il n'aura même pas besoin de compiler 2 binaires (l'un pour gzip l'autre pour brotli).

À vrai dire, j'envisageais plus de proposer un patch pour httpd que d'apporter d'autres fonctionnalités. (si j''en suis capable)...

[PengouinBSD]

De ce que j'ai lu, "Last-Modified" est plus pertinent que "ETag".

Si je te parle de deflate, penses-tu vraiment que je n'ai pas vérifié

Concernant brotli, c'est toi, qui voit, mais là, encore, je n'aurais pas la même approche !
Tu n'as pas besoin d'avoir la lib brotli installée, pour pouvoir diffuser du contenu .br (ou .gz) et encore heureux.

Pour le patch pour httpd, "bienvenue" :p

[eol]

je vais voir si l'entête Last-update est pertinent en plus de l'Etag(je ne crois pas).

Ça dépend pour quel usage.
Si je veux savoir si dcraw a été mis à jour, les en-têtes le permettent
et pour ça l'etag, dont je suis de toute façon incapable de tirer la moindre information
me sera moins utile que le last-modified

Code :

curl -I https://www.dechifro.org/dcraw/dcraw.c |grep -E '^(etag|last-modified)'
last-modified: Fri, 01 Jun 2018 21:20:44 GMT
etag: "32614ab-540dc-56d9b281e8300"