Nginx 'invalid number of arguments in "allow" directive' after upgrading

Support
,
1

My YunoHost server

Hardware: Old laptop (hp 840 G1)
YunoHost version: yunohost version : 11.2.8.2 (stable)
I have access to my server : Through SSH
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no
If yes, please explain:

Description of my issue

I updated yunohost through the update system in the webadmin without issue apparently, but when I tried to upgrade my apps next, it failed to upgrade the first one (namely calibreweb) and uninstalled it instead. because I’m slow, I then tried to upgrade another app (docuwiki) and faced exactly the same issue :

 nginx.service: Failed to parse PID from file /run/nginx.pid: Invalid argument

I then ran a diagnosis and found out the following issue :

nginx: [emerg] invalid number of arguments in "allow" directive in /etc/nginx/conf.d/yunohost_api.conf.inc:11

here is the line 11 to 13 of that file :

     allow ;
      
    deny all;

unfortunately this prevent Nginx to restart. I commented out the allow to make it work, but of course, now, trying to reach the webadmin only give a 403 error

I think that something went wrong during the yunohost upgrade and a script ment to fill the gap after the allow failed or something…

since I assume that commenting out the deny line and adding allow all; is probably stupid, I’m wondering what I should put there to fix the access to the webadmin (I’m not on the same local network) ?

FR

J’ai mis à jour yunohost depuis la fonction “mise à jour” de l’interface web d’administration sans problèmes apparent, mais quand j’ai voulu mettre à jour les applications qui le nécessitaient, la mise à jour de la première (calibreweb) a échoué et l’application a été désinstallée. parce que je suis un peu obtus, j’ai ensuite essayé de mettre à jour une autre application (docuwiki) et rencontré le même problème :

 nginx.service: Failed to parse PID from file /run/nginx.pid: Invalid argument

j’ai lancé un diagnostic et trouvé cette erreur :

nginx: [emerg] invalid number of arguments in "allow" directive in /etc/nginx/conf.d/yunohost_api.conf.inc:11

voici le contenu des lignes 11 à 13 de ce fichier :

     allow ;
      
    deny all;

malheureusement, cette erreur empèche Nginx de redémarrer. J’ai commenté la ligne allow pour que ça fonctionne, mais évidemment, maintenant, l’interface wb d’administration n’est plus accessible et renvoie une erreur 403.
Je pense que quelque chose a foiré pendant la mise à jour de yunohost et qu’un script sensé remplir le vide après allow dans ce fichier n’a pas fonctionné.
Puisque que je suppose que commenter la ligne deny et ajouter allow all; est probablement stupide, je me demande ce que je devrais mettre après ce allow pour restaurer l’accès à l’interface d’administration (je ne suis pas sur le même réseau local que le serveur) ?

2

Sounds like somehow at some point you enabled the “limit access to webadmin to a list of IP” but the list of IP is empty …

3

that was my understanding, though I don’t know how I would have enabled that without my knowing, and that doesn’t seems to explain the app failing to update and being removed, that’s why I assumed something went wrong during the upgrade…

4

I removed the comment on the allow line in /etc/nginx/conf.d/yunohost_api.conf.inc and launched

yunohost settings set security.webadmin.allowlist.enabled -v False
Info : Saving the new configuration...
Succès ! Config updated as expected

but it did’nt changed anything in /etc/nginx/conf.d/yunohost_api.conf.inc, the argumentless allow was still there.
after commenting that line again, I’m able to go to the webadmin login page but there is an error popup:

 Error: "403"

Action: "GET" /yunohost/api/installed?locale=en

after closing the popup, I tried to log in but it doesn’t work.

5

I just found out that these allow and deny lines are not supposed to be there anyway if the webadmin is opened to the world (that would have been great to find that in the documentation instead of an unrelated forum post) so I also commented the deny all;, that fixed my main issue as I have access to the webdamin again.

I’m still puzzled about what happened, though, and I’m afraid it’ll happen again (especially the “remove the app instead of updating it” part), so I’ll be glad if anyone has some insight about that !

6

It’s hard to investigate exactly what happened without the corresponding logs for the upgrade attempts of the two apps

7

sorry about that, here are the logs from the system upgrade with a warning about nginx (not an error) :
https://paste.yunohost.org/raw/dexipuwiyo

2023-12-10 16:21:56,076: WARNING - unable to retrieve string to translate with key 'nginx: [emerg] invalid number of arguments in "allow" directive in /etc/nginx/conf.d/yunohost_api.conf.inc:11' for default locale 'locales/en.json' file (don't panic this is just a warning)
2023-12-10 16:21:56,077: WARNING - unable to retrieve string to translate with key 'nginx: configuration file /etc/nginx/nginx.conf test failed' for default locale 'locales/en.json' file (don't panic this is just a warning)
[...]
2023-12-10 16:22:06,226: SUCCESS - System upgraded

and here are the logs about the upgrade of calibreweb a few minutes later with an error caused by nginx being unable to reload or restart because of that same warning :
https://paste.yunohost.org/raw/akayirigec

2023-12-10 16:25:32,109: WARNING - déc. 10 16:25:30 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
2023-12-10 16:25:32,110: WARNING - déc. 10 16:25:30 systemd[1]: Reload failed for A high performance web server and a reverse proxy server.
2023-12-10 16:25:33,605: ERROR - Could not upgrade calibreweb: An error occurred inside the app upgrade script
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.