Asustor Web Center ADM 5

T

thebossbibi

Nouveau membre
7 Novembre 2019
21
4
3
Pour ceux qui auraient aussi des problèmes comme moi avec le passage en version 5, voilà la liste des choses à checker :

EZ-ROUTER => eu besoin de désactiver les règles du pare-feu créée au moment de la mise à jour (appelé "migration..."), à partir de là j'ai pu me reconnecter à distance.
BDD => j'utilise mariaDB et il faut aller dessus pour changer le MDP/remettre l'ancien sinon aucune connexion possible.
Apache => le fichier de config a été reset comme à chaque MAJ => suppression de la règle pour faire de la basic-auth PHP => ajout des règles dans le .htaccess pour retrouver le fonctionnement correct.

Il y a surement d'autres choses qui peuvent avoir changé mais pour ma part c'est uniquement ces points là qui ont empêchés le redémarrage auto des services.
Une notice d'info plus conséquente avec des avertissements sur ces points (et non uniquement l'arrêt du support de PHP 7.4) serait la bienvenue et/ou un changelog existant au niveau des apps ASUSTOR
 
Dami1 a dit:
merci
Cliquez pour agrandir...
Avec la MAJ de cette nuit (5.0.0 RIN1), le Serveur Web est de nouveau HS, en allant sur la page par défaut je tombe sur la page d'erreur NGINX (code 502) alors que j'utilise apache et plus possible d'accéder à mes sites sur d'autres ports.
De plus en essayant de debug la config du Web Center je tombe sur des erreurs à la pelle alors que la modification est bien prise en compte, une vrai cata la migration ADM 5

Toutes mes configs sont restés comme avant (apache, php,...) le seul changement visible a été à priori qu'il y a eu des corrections de bugs du Web Center mais pour en ajouter de nouveau à priori

En switchant sur la config NGINX je retrouve la page d'activation réussie du Web Center sur le 443 comme je l'avais avec Apache, une utilisation par défaut de NGINX même avec Apache utilisé ?
Si je n'ai pas de réponse rapide j'essaierai de switcher mes sites sur une config compatible NGINX en attendant
 
Dernière édition:
bonsoir

voici la réponse de mon collègue en Anglais.
il a besoin de davantage d'informations. Vous pouvez aussi ouvrir un ticket auprès de https://member.asustor.com


I’d like to better understand a few of the points you mentioned so I can verify whether these are already known issues or something new that we need to investigate further:

1. Regarding the EZ-Router issue – could it be related to the previous bug where the firewall whitelist rules were re-enabled automatically after being disabled once?
Or is it a different issue entirely? I'd really appreciate it if you could clarify the behavior you observed.

2 For the MariaDB part, could you kindly elaborate on the problem you faced? I’d like to better understand why the password needed to be changed or restored,
and whether this behavior was triggered by the ADM upgrade itself.

3. For the Apache configuration reset, if possible, could you please share the relevant parts of your previous config file or
.htaccess rules before and after the upgrade? That would really help us pinpoint what’s missing or what was changed unexpectedly.

I completely agree that we can and should do a better job communicating these kinds of changes in our changelogs and upgrade notices
— not just the PHP 7.4 deprecation. We'll definitely take your suggestion into account moving forward.
 
Dami1 a dit:
bonsoir

voici la réponse de mon collègue en Anglais.
il a besoin de davantage d'informations. Vous pouvez aussi ouvrir un ticket auprès de https://member.asustor.com


I’d like to better understand a few of the points you mentioned so I can verify whether these are already known issues or something new that we need to investigate further:

1. Regarding the EZ-Router issue – could it be related to the previous bug where the firewall whitelist rules were re-enabled automatically after being disabled once?
Or is it a different issue entirely? I'd really appreciate it if you could clarify the behavior you observed.

2 For the MariaDB part, could you kindly elaborate on the problem you faced? I’d like to better understand why the password needed to be changed or restored,
and whether this behavior was triggered by the ADM upgrade itself.

3. For the Apache configuration reset, if possible, could you please share the relevant parts of your previous config file or
.htaccess rules before and after the upgrade? That would really help us pinpoint what’s missing or what was changed unexpectedly.

I completely agree that we can and should do a better job communicating these kinds of changes in our changelogs and upgrade notices
— not just the PHP 7.4 deprecation. We'll definitely take your suggestion into account moving forward.
Cliquez pour agrandir...
Le problème est complètement différent cette fois.
J'ai réussi à récupérer l'accès à phpMyAdmin en redémarrant le NAS qui a du reboot Apache mais pour mes sites qui sont en virtualHost sur des ports différents de 443 (et même le 443 je n'ai plus rien maintenant) je tombe après moins de 5 secondes d'attente sur une page "la connexion a échoué" sans rien trouver en terme de log ou autre, comme si le NAS ne répondait même pas.

Aucun souci avec le pare feu à priori cette fois, que je le désactive ou non ça ne change rien et je n'ai pas eu de soucis pour me connecter sur l'interface du NAS après la MAJ.

J'avais dans l'idée de tenter un downgrade pour repasser sur la version précédente qui marchait mais je ne peux pas le faire seul ou selon ce que j'ai vu faut que je vienne bidouiller le fichier de conf global pour lui faire penser qu'il est sur une ancienne version et accepte le downgrade. (ce qui a été du au fait que la MAJ auto des version ADM a été réactivé en passant en version 5).


Sinon pour répondre aux demandes :
1) Une règle du pare-feu (que je n'ai pas réussi à trouver puisque aucun blocage régional ne posait problème en théorie), pouvait être du aux DNS asustor non atteignable car compris dans la règle je pense.
2) Pour MariaDB, il était inactif (ou dans un état bloqué) tant que je n'était pas allé dessus pour suivre les instructions indiquées après MAJ.
3) Il est possible que le fichier que je vienne modifier étant le fichier de conf de base de Apache et non un fichier annexe, ce soit là mon erreur, dans ce cas il faudrait un moyen d'ajouter des règles de manière plus "clean" et qui serait enregistré à part et réappliqué après une MAJ (pareil pour la conf PHP)
la seule règle de Apache que j'avais eu besoin de toucher avant le passage sur ADM 5 était d'autoriser une taille de body infinie puisque j'upload de très gros fichier (ce qui n'est pas commun), mais ce qui m'avait du coup dérangé a été que le module ou règle qui gère la basic-auth via la variable $_SERVER ne soient plus actif.

Merci pour ta réactivité et en espérant trouver une solution (de moi-même ou avec de l'aide).
 
Dami1 a dit:
bonsoir

voici la réponse de mon collègue en Anglais.
il a besoin de davantage d'informations. Vous pouvez aussi ouvrir un ticket auprès de https://member.asustor.com


I’d like to better understand a few of the points you mentioned so I can verify whether these are already known issues or something new that we need to investigate further:

1. Regarding the EZ-Router issue – could it be related to the previous bug where the firewall whitelist rules were re-enabled automatically after being disabled once?
Or is it a different issue entirely? I'd really appreciate it if you could clarify the behavior you observed.

2 For the MariaDB part, could you kindly elaborate on the problem you faced? I’d like to better understand why the password needed to be changed or restored,
and whether this behavior was triggered by the ADM upgrade itself.

3. For the Apache configuration reset, if possible, could you please share the relevant parts of your previous config file or
.htaccess rules before and after the upgrade? That would really help us pinpoint what’s missing or what was changed unexpectedly.

I completely agree that we can and should do a better job communicating these kinds of changes in our changelogs and upgrade notices
— not just the PHP 7.4 deprecation. We'll definitely take your suggestion into account moving forward.
Cliquez pour agrandir...
Pour faire suite, j'ai réussi à tout redémarrer correctement en désinstallant complètement apache et nginx et les réinstallant, il y a surement eu un problème dans la MAJ 5.0.0 RIN1 qui a foiré une config de l'un des deux (j'attendais la fin d'une sauvegarde complète avant de faire une action)
 
  • J'aime
Réactions: Asmodée
Vous devez vous connecter ou vous enregistrer pour répondre ici.
Haut Bas