[boring-nginx] You screw up
PixiBixi opened this issue · 62 comments
Hello,
It seems you fucked up your image :)
2017/08/07 19:36:55 [alert] 11#11: worker process 12 exited on signal 9
2017/08/07 19:36:55 [alert] 11#11: worker process 14 exited on signal 9
2017/08/07 19:36:55 [alert] 11#11: worker process 15 exited on signal 9
2017/08/07 19:36:55 [alert] 11#11: worker process 13 exited on signal 9
2017/08/07 21:49:57 [crit] 11#11: *2240 SSL_do_handshake() failed (SSL: error:100000f0:SSL routines:OPENSSL_internal:UNSUPPORTED_PROTOCOL) while SSL handshaking, client: x, server: 0.0.0.0:4430
2017/08/07 23:17:42 [crit] 12#12: *2247 SSL_do_handshake() failed (SSL: error:100000f0:SSL routines:OPENSSL_internal:UNSUPPORTED_PROTOCOL) while SSL handshaking, client: x, server: 0.0.0.0:4430
2017/08/08 00:11:39 [crit] 9#9: *2252 SSL_do_handshake() failed (SSL: error:100000f0:SSL routines:OPENSSL_internal:UNSUPPORTED_PROTOCOL) while SSL handshaking, client: x, server: 0.0.0.0:4430
2017/08/08 00:11:40 [crit] 11#11: *2253 SSL_do_handshake() failed (SSL: error:100000f0:SSL routines:OPENSSL_internal:UNSUPPORTED_PROTOCOL) while SSL handshaking, client: x, server: 0.0.0.0:4430
2017/08/08 00:11:42 [crit] 12#12: *2254 SSL_do_handshake() failed (SSL: error:100000f0:SSL routines:OPENSSL_internal:UNSUPPORTED_PROTOCOL) while SSL handshaking, client: x, server: 0.0.0.0:4430
Comme je ne l'utilise pas c'est dur de tester tous les changements...
Je crois que c'était dû au TLSv1.3 dans ssl_params, je l'ai retiré, merci de confirmer.
C'est bien ça en ffet ! Merci ;)
EDIT: J'ai rien dis, toujours le problème..
Super. Après je doute de l'utilité de bidouiller Boring pour faire marcher TLS 1.3, je ne sais pas s'ils ont mis à jour la draft, or les browser ne supportent que la draft 18.
Je remets un commentaire pour dire que c'est toujours pas bon, je sais pas si tu as vu :P
Bon on va faire ça autrement en virant le support des drafts de TLS 1.3. Si ça marche, bah ça sera supporté quand TLS 1.3 sera finalisé.
Ca roule
Dis moi quand l'image est push sur le hub que je check :P
https://hub.docker.com/r/wonderfall/boring-nginx/builds/
C'est en train de build, je te dis quand c'est bon.
Aussi si jamais ça marche, j'aimerais bien un petit Qualys SSL pour vérifier les paramètres et 2-3 bricoles, thanks.
Pas de problème, je te fais ça si ça marche! (TLS Imhiril ça te convient ?)
Envoie moi un mail sur mon mail MonDedie par contre, je le poste pas en public ^^
Oui j'ai ton mail je pense. Pour les tests oui Imirhil convient aussi.
Je dois avouer que je n'ai pas d'autres idées si ça ne marche toujours pas. 🤔
Non mais moi j'ai pas le tient justement, envoie le moi sur mon mail :D
(En tout cas, ça vient de ton update de hier, ça marchait avant ;) )
Oué bon ok, fait pas le malin ! :3
C'est leeeent le build
Toujours pas bon, tu veux pas cancel ton commit de hier pour cette image ? D:
Ben le problème c'est que si je cancel l'image reste bloquée sur une vieille version d'nginx, en plus l'image buildait plus avant... Donc c'était nécessaire.
Mais c'est toujours SSL routines:OPENSSL_internal:UNSUPPORTED_PROTOCOL ?
J'ai même plus de logs là.... (nginx se lance pas je pense)
Je pourrais avoir les logs de build de l'image ?
Essaie de passer sur la dernière version de nginx/alpine mais juste ça, sans rien concernant le TLS 1.3 ni autre modification
Les logs de build sont toujours sur le hub : https://hub.docker.com/r/wonderfall/boring-nginx/builds/bqst6mfe8njcjaxrws2jxbd/
Ensuite je n'avais rien touché pour TLS 1.3 à part merge une PR qui changeait les noms de fichiers et l'ajout dans ssl_params que j'ai viré. Le reste est sensé fonctionner et ce sont des modifs que j'utilise dans ma version d'nginx actuelle.
Comment ça nginx se lance pas ? Il doit forcément y a voir un truc, une ligne ? Le conteneur plante (si oui c'est que c'est bien nginx) ?
Le conteneur plante mais aucune ligne de log quelque part ^^" (Donc je pense que ça essaie de lancer nginx, il se lance pas,)
Mais pourtant le conteneur était lancé avant, avec la modif TLS 1.3 en plus. 😨
Euh lancé non, il plantait instantanément (Regarde : http://i.imgur.com/jMqFBCc.png)
Ah bah j'ai viré TLS 1.3 pour rien du coup, j'ai ce genre d'erreurs aussi souvent dans mes logs, sûrement des bots ou autre merde du genre. 🤔
Bon là c'est un autre problème qui défie toute logique.
Défie toute logique non... Ca a planté quand tu as commit la MAJ, donc bon, ça me semble plutôt évident ^^"
Non mais c'est pas aussi simple que "j'ai commit donc ça plante", dans ce que j'ai commit y a rien de très fou, ça a l'air différent parce que j'ai un peu restructuré mais y a très peu d'autres modifs qui pourraient être en cause (et celles-ci je les utilise actuellement en production...).
Je vais faire des tests chez moi, mais pour l'instant je recommande de rester sur une ancienne version.
Ba oui pas le choix du coup :D
Perso j'aurais quand même essayé de reverse les modifications voir si ça marche ^^"
Ben à la limite je vais essayer (sans commit) les anciens flags pour la compil', mais si ça change rien, alors vraiment je n'ai aucune idée et ça doit être un soucis bien plus profond style une incompatibilité entre Boring et nginx.
Ca roule, on test une dernière fois avec les anciens flags :P
Avec les nouveaux flags, quand je lance nginx, ça ne plante pas...
Sûr que tu n'as rien ni dans docker logs -f ni dans error.log ?
oui
Pas moyen de me filer un accès portainer pour ce conteneur ?
non, tu me dis ce que tu veux voir
Si tu lances un conteneur vierge avec run -ti --rm, et qu'une fois dedans tu lances nginx, se passe quoi ?
J'ai même pas accès au container ^^"
docker run -ti --rm wonderfall/boring-nginx
docker run -ti --rm wonderfall/boring-nginx sh
Et dedans lance nginx ou run.sh
Ah ba oui jsuis con ><"
Illegal instruction (core dumped)
Ca pue ce putain de kernel OVH de merde...
Ah oui merde... Perso je suis la dernière version du kernel compilée à la main. :/
Là je sais pas trop quoi faire...
Je réactive TLS 1.3 du coup vu que c'est pas lié, si tu ne veux pas changer de kernel, je regarderai si c'est un flag qui fait ça ou bien le code source d'un truc.
Ouep, désolé de la perte de temps...
Je vais virer ce kernel OVH de merde
août 08 17:56:41 x kernel: traps: nginx[18001] trap invalid opcode ip:ac274cf911b sp:74ee5a9d0240 error:0 in nginx[ac274cc4000+349000]
août 08 17:56:41 x kernel: grsec: Illegal instruction occurred at 00000ac274cf911b
in /usr/sbin/nginx[nginx:18001] uid/euid:0/0 gid/egid:0/0, parent /bin/busybox[sh:17933] uid/euid:0/0 gid/egid:0/0
Ca vient bien de ton commit quand même :P
grsec est devenu une bouse payante donc OVH va virer ça de toute façon.
Pour l'erreur ça doit sûrement être un flag, comme dit.
Tu as moyen de compiler chez toi sans que je commit puis attendre le Hub ? Histoire qu'on trouve le flag qui passe pas, je le retire si ça va pas.
model name : Intel(R) Atom(TM) CPU N2800 @ 1.86GHz
Donc non xD
Rofl bon attends je vais faire un Dockerfile express
Pour aller plus vite je vais push dessus : https://hub.docker.com/r/wonderfall/bxt-nginx/
Je build à la main depuis mon serveur une version avec les anciens flags, quand c'est push tu peux tester
EDIT : c'est bon !
Trop fort ça marche \o/
D'accord donc forcément ça venait des flags du coup. Maintenant pour optimiser le truc j'aimerais juste trouver le vrai fautif. Je vais push une nouvelle version avec entre autres l'utilisation de jemalloc pour les paramètres de link
Ca roule, tu me dis ça ! :)
Nouvelle version push, un hybride entre les anciens et les nouveaux flags.
Toujours ok chef ! :P
Je pense qu'on va rester sur cet hybride, le reste est trop agressif.
Cool ! Tu me dis quand tu as push vers la vraie image :D
Il y a juste le flag TCP Fastopen que tu n'as pas testé mais je pense que ça ne pose pas de soucis.
IMO ça venait de Ofast qui est vraiment trop agressif au point d'hérisser les cheveux de grsec.
Je lance la build
C'est build, tu peux tester
Si tu peux m'envoyer un résultat de Qualys ça serait cool !
Mais WTF ça marche pas là, ça doit bien venir de Fastopen :(
J'ai viré Fastopen, rebuild en cours...
C'est juste chiant que tout le monde soit privé de TCP FO juste à cause de toi. :P
Euh à cause de moi... et tous les utilisateurs de GRSec :')
Et vérifie fastopen, il permet pas forcément un gain de perfs ;)
Comme dit plus haut, Grsec a changé de modèle donc bientôt plus aucun particulier ne l'utilisera...
Et je me suis renseigné, TCP FO permet de réduire la latence, et j'ai comparé, je le sens.
Ca dépend, m'enfin bref ;)
Et juste pour te dire, fastopen faut aussi l'activer sur nginx hein :D (https://www.masv.io/enabling-tcp-fast-open-nginx-centos-7/)
Non mais je sais, je suis pas con. :)
fastopen=256 une seule fois dans la directive listen.
Peut-être que ça dépend, mais moi je le sens sur mes sites.
Parce que je l'ai dit, il faut le mettre une seule fois. C'est un paramètre que nginx ne prend que sur un seul vhost et qui s'appliquera à tous les vhosts. Si tu le mets sur plusieurs vhosts, nginx va chialer. Déjà essayé, c'est pour ça que je dis ça...
Ah ok, comment tu vas l'appliquer alors ? ^^
L'utilisateur a juste à éditer un fichier à la main (le vhost avec le listen par défaut), tout est dans un volume, c'est transparent. Donc par défaut ce n'est pas activé, mais si besoin, on peut l'activer. Enfin maintenant on peut plus avec l'image. :P
ahah :D
J'espère que ça va enfin marcher
Yop, c'est bon pour la build !
Vu, c'est ENFIN bon pour moi aussi \o/
PS: Si tu as pas vu, je t'ai mail un rapport TLS Imhiril
Je peux enfin fermer du coup :P