Utiliser une API perso avec / à côté de yunohost

LaBaude · July 23, 2020, 9:34am

Bon bah j’ai copié collé tous les paramètres du lein en modifiant par more_set_headers puis j’ai fais un sudo service ngnix reload
Et ça m’a cassé le serveur …
j’ai eu ça comme réponse :

Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.

ensuite j’ai donc fait le systemctl status

● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2020-07-23 11:16:44 CEST; 34s ago
Docs: man:nginx(8)
Process: 582 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)

Du coup j’ai redémarrer pour voir, ça n’a rien fait.

j’ai tenté avec les add_header plutôt et ça n’a pas mieux fonctionné.

Donc j’ai supprimé ce que j’avais fait et tout est rentré dans l’ordre.
A noter que j’avais plus accès à la webadmin, seul le ssh fonctionnait.

C’est dommage parce que ça avait l’air vraiment bien …

Pour ce qui est des requêtes j’ai OPTIONS, POST, GET et DELETE. Mais bon ça je me débrouillerai quand ça marchera

tituspijean · July 23, 2020, 9:54am

Pardon ! J’ai un peu trop présumé que tu savais ce que tu faisais. ^^’

Il faut que tu ajoutes le code en bas juste avant la dernière accolade fermante du fichier:

    # Include SSOWAT user panel.
    include conf.d/yunohost_panel.conf.inc;
#COPIE LE CODE ICI
}

Ce code:

#
# Wide-open CORS config for nginx
#
     if ($request_method = 'OPTIONS') {
        more_set_headers 'Access-Control-Allow-Origin: *';
        more_set_headers 'Access-Control-Allow-Methods: GET, POST, OPTIONS';
        #
        # Custom headers and headers various browsers *should* be OK with but aren't
        #
        more_set_headers 'Access-Control-Allow-Headers: DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
        #
        # Tell client that this pre-flight info is valid for 20 days
        #
        more_set_headers 'Access-Control-Max-Age: 1728000';
        more_set_headers 'Content-Type: text/plain; charset=utf-8';
        more_set_headers 'Content-Length: 0';
        return 204;
     }
     if ($request_method = 'POST') {
        more_set_headers 'Access-Control-Allow-Origin: *';
        more_set_headers 'Access-Control-Allow-Methods: GET, POST, OPTIONS';
        more_set_headers 'Access-Control-Allow-Headers: DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
        more_set_headers 'Access-Control-Expose-Headers: Content-Length,Content-Range';
     }
     if ($request_method = 'GET') {
        more_set_headers 'Access-Control-Allow-Origin: *';
        more_set_headers 'Access-Control-Allow-Methods: GET, POST, OPTIONS';
        more_set_headers 'Access-Control-Allow-Headers: DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
        more_set_headers 'Access-Control-Expose-Headers: Content-Length,Content-Range';
     }

LaBaude · July 23, 2020, 10:12am

Bah c’est ce que j’ai fait
Je vais re tenter au cas où …

edit : c’est bien dans le fichier : /etc/nginx/conf.d/labaudesrv.duckdns.org.d/my_webapp.conf qu’il faut ajouter ça ?

re edit : je me rend compte que j’avais peut-être ajouté une accolade en trop justement. Cette fois ci le reload de ngnix à l’air ok … je vais faire des tests et je reviens

LaBaude · July 23, 2020, 10:40am

Bon alors effectivement le problème semble réglé. Merci bcp !!

J’ai un nouveau problème maintenant c’est que quelque soit la requête que je fais la réponse c’est : 404 not found

La seule qui me renvoie quelque chose c’est si j’ouvre mon navigateur à la racine de my_webapp. (mondomaine/pvapp : l’url que je lui ai attribué). Mais après quand je cherche mes routes qui sont dans api/v1/token et donc l’url devrait etre : mondomaine/pvapp/api/v1/nomderoute par exemple y’a plus rien

tituspijean · July 23, 2020, 11:50am

Cela veut dire que tu n’as pas de dossier public/api/..., tu confirmes ?
Pour pouvoir t’aider il va falloir que tu montres le contenu de public, ainsi que ton ancienne configuration Apache ou Nginx, celle avant de migrer vers my_webapp.

Par exemple pour l’app Flarum (qui utilise aussi une API pour servir un forum), tout passe par le index.php. Du coup dans le fichier de conf de nginx on a quelque chose comme try_files $uri $uri/ /index.php?$query_string; (tu peux tenter déjà ça, mais c’est vraiment du pifomètre, mieux vaut voir ton ancien fichier de config).

LaBaude · July 23, 2020, 1:04pm

Merci !

Effectivement pas de dossier public/api/…

Dans mon dossier public, y’a que un index.php qui appel mon bootstrap en fait. Donc oui tout est sensé passer par lui.

Mon architecture d’API est faite sur celle expliqué ici : https://odan.github.io/2019/11/05/slim4-tutorial.html

Et voici la config nginx de la doc du framwork de l’API : https://www.slimframework.com/docs/v4/start/web-servers.html#nginx-configuration

Je vais t’envoyer le repo de l’API en mp directement.

Je vais voir pour le conf de nginx

LaBaude · July 23, 2020, 1:38pm

Bon j’ai essayé la config nginx que tu m’as proposé et ça ne fonctionne pas.
J’ai tenté d’adapter avec la config de la doc, ça ne fonctionne pas non plus. ($is_args$args).
ni toute la ligne

try_files $uri /index.php$is_args$args;

Aucun rapport mais je vois aussi dans mon fichier conf cette ligne :

fastcgi_pass unix:/var/run/php/php7.0-fpm-my_webapp.sock;

Est ce qu’il faudrait pas passer à php7.4 ici aussi ?

tituspijean · July 23, 2020, 2:21pm

Oups, oui ! Corrige ça, déjà, et voyons ce que ça donne.

LaBaude · July 23, 2020, 2:41pm

Alors maintenant sur ma page mondomaine/pvapp/ donc la racine j’ai un 502 Bad Gateway

Normalement c’est silm qui me renvoie un 404 (mais sur cette page c’est noramle parce qu’il n’y a pas de route paramétré )

tituspijean · July 23, 2020, 2:51pm

Edit: on a oublié une modif dans /etc/php/7.4/fpm/pool.d/my_webapp.conf. Tu y as une ligne listen = /var/run/php/php7.X-fpm-my_webapp.sock où il faut modifier le 7.X vers 7.4.

Peux-tu vérifier le statut de php7.4-fpm ?

sudo service php7.4-fpm status

et si il est arrêté :

sudo systemctl restart php7.4-fpm
# en cas d'erreur
journalctl -xe

LaBaude · July 23, 2020, 2:58pm

Alors php 7.4 fonctionne bien.

Cependant pas d’amélioration après les dernières modifications

tituspijean · July 23, 2020, 3:56pm

Relance le service si tu as fait une modif : sudo systemctl restart php7.4-fpm

LaBaude · July 23, 2020, 4:30pm

Ha oui j’avais reload nginx mais pas ce service.

Bon plus de problème de 502 bad gateway par contre y’a toujours les 404 not found …

tituspijean · July 23, 2020, 4:55pm

Je dirais que c’est parce que nginx ne sait pas aller chercher tes fichiers dans ../config/.
Pour confirmer ça, peux-tu vérifier ses logs ? C’est dans /var/log/nginx/labaudesrv.duckdns.org/pvapp-error.log

LaBaude · July 23, 2020, 5:10pm

Alors le chemin que tu me donnes existe pas,

Donc j’ai ouvert le labaudesev.duckdns.org-error.log

et la dernière ligne c’est :

2020/07/23 19:03:28 [error] 10208#10208: *3161 open() "/var/www/my_webapp/www/public/api/v1/tokens" failed (2: No such file or directory), client: 88.120.120.131, server: labaudesrv.duckdns.org, request: "POST /pvapp/api/v1/tokens HTTP/1.1", host: "labaudesrv.duckdns.org"

Ce que je trouve étonnant c’est que normalement c’est PHP qui est sensé aller chercher les fichiers dans config directement. Est ce que ce serait pas parce qu’il arrive pas à récup le index.php dans le dossier public ? c’est une hypothèse …

LaBaude · July 25, 2020, 10:11am

Bon @tituspijean j’ai essayé plein de choses en adaptant à la config de https://www.slimframework.com/docs/v4/start/web-servers.html#nginx-configuration

Mais rien ne fonctionne… J’avoue que là je ne sais plus quoi faire…
Voici tout mon fichier de conf nginx :

rewrite ^/pvapp$ /pvapp/ permanent;
location /pvapp/ {

    # Path to source
    alias /var/www/my_webapp/www/public/;

    # Force usage of https
    if ($scheme = http) {
        rewrite ^ https://$server_name$request_uri? permanent;
     }

    # Default indexes and catch-all
    index index.html index.php;
    try_files $uri $uri/ /pvapp/index.php?$args;

    # Prevent useless logs
    location = /pvapp/favicon.ico {
        log_not_found off;
        access_log off;
    }
    location = /pvapp/robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    # Deny access to hidden files and directories
    location ~ ^/pvapp/(.+/|)\.(?!well-known\/) {
        deny all;
    }

    # Execute and serve PHP files
    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        fastcgi_pass unix:/var/run/php/php7.4-fpm-my_webapp.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param REMOTE_USER $remote_user;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param SCRIPT_FILENAME $request_filename;
    }

    # Include SSOWAT user panel.
    include conf.d/yunohost_panel.conf.inc;
    
    #
    # Wide-open CORS config for nginx
    #
         if ($request_method = 'OPTIONS') {
            more_set_headers 'Access-Control-Allow-Origin: *';
            more_set_headers 'Access-Control-Allow-Methods: GET, POST, OPTIONS';
            #
            # Custom headers and headers various browsers *should* be OK with but aren't
            #
            more_set_headers 'Access-Control-Allow-Headers: DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
            #
            # Tell client that this pre-flight info is valid for 20 days
            #
            more_set_headers 'Access-Control-Max-Age: 1728000';
            more_set_headers 'Content-Type: text/plain; charset=utf-8';
            more_set_headers 'Content-Length: 0';
            return 204;
         }
         if ($request_method = 'POST') {
            more_set_headers 'Access-Control-Allow-Origin: *';
            more_set_headers 'Access-Control-Allow-Methods: GET, POST, OPTIONS';
            more_set_headers 'Access-Control-Allow-Headers: DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
            more_set_headers 'Access-Control-Expose-Headers: Content-Length,Content-Range';
         }
         if ($request_method = 'GET') {
            more_set_headers 'Access-Control-Allow-Origin: *';
            more_set_headers 'Access-Control-Allow-Methods: GET, POST, OPTIONS';
            more_set_headers 'Access-Control-Allow-Headers: DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
            more_set_headers 'Access-Control-Expose-Headers: Content-Length,Content-Range';
         }
}

Peut-être que tu pourras y voir un défaut de config.
Quelque soit ce que j’ai pu essayé de changer j’ai invariablement la même erreur qui me dit “no such file or directory”…

tituspijean · July 25, 2020, 10:43am

Pareil de mon côté, je ne vois pas où est le problème.

J’ai testé en revenant aux fondamentaux, en exécutant la commande sudo -u my_webapp php -S 0.0.0.0:8085 -t public/ comme tu l’avais mentionné avant (0.0.0.0 pour y accéder depuis n’importe quelle machine)… et ça ne marche pas.

LaBaude · July 25, 2020, 11:04am

Zut …

Par contre je viens de faire les maj de mon serveur et :

Le fichier YAML de métadonnées associé aux logs est corrompu : '/var/log/yunohost/categories/operation/20200720-222754-app_install-my_webapp.yml'
Erreur : Fichier YAML corrompu en lecture depuis /var/log/yunohost/categories/operation/20200720-222754-app_install-my_webapp.yml (raison : while scanning an alias
in "", line 11, column 27:
YNH_APP_ARG_PASSWORD: ''**********''
^
expected alphabetic or numeric character, but found '*'
in "", line 11, column 28:
YNH_APP_ARG_PASSWORD: ''**********''
^)

tituspijean · July 25, 2020, 11:24am

J’ai tout repris à zéro. Je pense que le problème vient de la configuration de ton API.

# Installons l'app
# (demander la création d'une BDD)
yunohost app install my_webapp

# Préparons les dossiers
cd /var/www/my_webapp
# Préparons le dossier pour Composer
mkdir .composer
chown my_webapp:my_webapp .composer
sudo su my_webapp -s /bin/bash
rm -rf www
git clone $TonRepo www
cd www
mkdir tmp
# Installons Composer
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === 'e5325b19b381bfd88ce90a5ddb7823406b2a38cff6bb704b0acc289a09c8128d4a8ce2bbafcd1fcbdc38666422fe2806') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
# Installons les dépendances
php composer.phar install

# Dans /var/www/my_webapp/db_access.txt
# se trouve le mot de passe de la BDD. Copions-le.
# Le nom de la BDD et l'utilisateur sont "my_webapp"
# Modifier les infos qui vont bien dans le fichier suivant
nano /var/www/my_webapp/www/config/settings.php

# Quittons l'utilisateur my_webapp
exit
# Modifions la config de nginx pour faire un alias dans public:
sudo nano /etc/nginx/conf.d/$Domaine.d/my_webapp.conf
# la ligne 5 devient
# alias /var/www/my_webapp/www/public/;
sudo service nginx reload

Ici j’ai testé via la webapp, et ça ne marche toujours pas.
Alors testons avec le serveur web intégré. Dans un autre terminal:

# Ouvrons le port côté YunoHost
sudo yunohost firewall allow TCP 8085
# Lançons le serveur
php -S 0.0.0.0:8085 -t public/

Ouvre le site dans ton navigateur (http://T.O.N.IP:8085/api/…). Échec aussi. Je pense que le problème vient de la configuration de ton API. Y a-t-il moyen de la rendre plus verbeuse, et lui faire dire quelle route donne l’erreur 404 par exemple ?

Modif 21h30: coquille à la ligne du chown
Modif lendemain 12h30: coquille à la ligne du firewall

LaBaude · July 25, 2020, 4:32pm

Merci pour le mal que tu te donnes en tout cas !

Alors non je peux pas vraiment la rendre plus verbeuse, enfin noramlement elle l’est mais j’ai vraiment l’impression que nginx bypass complètement l’API. Je dis ça parce que si je me contente d’appeler mondomaine/pvapp, tout fonctionne bien. Dans le sens ou j’ai bien un retour d’erreur :

Mais ça c’est complètement normal puisqu’il n’y a pas de route / qui soit paramétré.
On voit d’ailleurs qu’il y a des test, test1, test2, test3 en haut. J’ai placé des var_dumb(‘test’) dans mes fichiers et ça fonctionne, ça passe bien par l’index, le bootstrap et le fichier route.

Donc le problème semble venir du fait que nginx cherche un fichier en interprétant l’url comme une route réelle alors qu’en fait elle est fictive et que c’est le système d’autoloader de composer et l’url rewriting de apache qui font le boulot…

Donc je me suis dis que peut-être que le problème viens de l’autoloader et que il serait judicieux de le re configurer.

Donc je tente d’installer composer (parce que pour l’instant j’avais fait sans, en balançant mes fichiers via filezilla en FTP) .

Et là après un composer install j’ai ça :

Donc je me demande pourquoi est-ce qu’on est toujours en php 7.0 ?? surtout qu’il me faut vraiment du php 7.2+ au minimum. Et je me demande si ça n’a pas un effet sur l’autoloading, en tous cas c’est requis.

En passant j’ai les fichier .htaccess de apache qui sont toujours là, je vais les supprimer au cas où, mais ça devrait pas changer grand chose…

Edit : je précise que j’ai pas créer d’utilisateur my_webapp pour installer composer, j’ai fait à partir de mkdir tmp

Edit 2 : Dans la web admin dans services je n’ai pas php7.4fpm. Mais en ssh avec sudo service php7.4-fpm status j’ai bien un running