Se passer d'Apache

Bonjour, pour le moment je ne vais pas migrer mes sites sur Yunohost mais prévois de le faire.

J’ai bien noté qu’il ne faut pas installer Apache sous risque de casser Yuno. Bien… Mais ça fait tellement de temps que je tourne sous Apache que je “m’inquiète” un peu.

Auriez-vous quelques pistes de lecture sur cette problématique de changement ; Apache > Nginx, je fais du Wordpress principalement.

Merci à vous.

Bonjour,
je pense que la solution est plutôt de migrer tes sites WP vers Yunohost sans trop te préoccuper de la configuration de Nginx dans un premier temps.
Il y a beaucoup de publications, dont celle-ci, par hasard : http://www.planet-libre.org/index.php?post_id=21568

1 Like

Pendant 20 ans j’ai utilisé Apache et je redoutait vraiment le passage à autre chose… en fait la migration vers Nginx c’est assez simple, et avec Yunohost c’est que du bonheur… le seul truc c’est d’abandonner mentalement toute les bidouilles à base de .htaccess et donc lire un peu de doc pour savoir comment faire la même chose avec Nginx…

Dans le cas particulier de Wordpress il faut juste faire gaffe aux plugins de cache qui en général sont calibrés pour Apache, mais je pense que l’on peut s’en passer en activant opcache dans PHP, si c’est pas le cas par défaut dans Yunohost (?)

Sauf si tu as des besoins tres precis, dans YunoHost tu ne devrais pas avoir besoin de toucher a la conf nginx toi-meme, a moins d’avoir des besoins tres precis

  • Soit tu installes une app deja packagee (e.g. Wordpress) et l’app fera le taf …
  • soit tu veux deployer un site web custom, et pour ca tu peux utiliser l’app my_webapp qui installera aussi le morceau de conf nginx qui va bien (il te reste ensuite a mettre tes fichiers dans le /var/www/ qui va bien, comme explique dans le README de l’app)

Le problème avec my_webapp, c’est qu’il faut (parfois) faire des modifications dans Nginx. J’ai installé Moodle il y a un an, et il a fallu faire quelques modifs (je ne sais plus lesquelles) et activer le mode barracuda de MySQL.
Aussi, actuellement, il faudrait offrir la possibilité d’utiliser PHP 7.2 car de nombreuses solutions WEB (comme Typo 3) le réclament dans les versions les plus récentes.
Enfin, j’ai eu des surprises avec MyWebapp (suppression des instances lors de mise-à-jour de Yunohost - dont un site en prod ! Heureusement que je sauvegarde, mais ça fait chier sur le coup…) Et aussi, les mises à jour de https://zwiicms.com/ ne permettent plus de se logguer en tant qu’utilisateur (cela a déjà fait l’objet d’un billet ici).

Certes, m’enfin la tu rentres typiquement dans “des besoins tres precis”, à savoir tu veux utiliser my_webapp pour installer un CMS non packagé pour YunoHost … L’app my_webapp est typiquement prévue pour héberger un petit site soit en pur HTML/CSS, soit avec du PHP/Mysql si besoin. Tu peux bricoler pour installer un CMS custom avec, mais la vraie solution c’est de packager pour de vrai ce CMS dans une app.

Par contre si il y a des bug dans l’app (dans la mise à jour comme tu le cites) alors il faut rapporter le bug et trouver des gens pour travailler dessus. Mais il faut se méfier de ne pas conclure “ça marche pas donc je vais reconfigurer la roue moi-même sur mon serveur”. Ça marche sur le court terme et pour soi-même, mais c’est pas l’esprit de YunoHost.

Certes… J’ai essayé de rendre fonctionnel l’utilisation de la nouvelle version de Typo 3, mais sans succès.
A bon entendeur, si quelqu’un est intéressé par le CMS Typo 3…

Pour ma part je n’ai que des wordpress (mono et multisite et woocommerce), mais évidemment comme ils tournes depuis longtemps maintenant, il y a forcément un certain nombre de plugins et effectivement quelques confs qui nécessitaient des modifs de .httacess.

Il faut que je test la façon de faire avec Yuno ;

1- je déploie un WP packagé Yuno de base ; import BDD puis je tente d’importer l’export d’un de mes WPress perso : les fichiers…

2 - soit la méthode décrite plus haut plus haut, my_webapp

Y a juste le soucis des liens internes de WP et des rewrite rules… et du problème de changement de domaine. Je me fais un schéma…

Mais je pense que la 1 est préférable. Je vais tester, vous dirai

Bonjour à toutes et tous,

Je suis toujours dans la phase pré-migration de mes WPress… J’ai quelques questions propres à Yunohost, pour étendre encore ma représentation mentale du sytème ;

Je me suis rendu dans /etc/nginx/sites-available histoire de découvrir une conf nginx vs apache, et pour l’instant c’est vide. Alors je me demandais comment sont servies les pages de YunoHost ? , l’admin ?

  • Histoire d’optimiser les ressources de ma petite instance OVH-Cloud,

    top - 11:07:01 up 1 day, 20:05, 1 user, load average: 0.00, 0.00, 0.00
    Tasks: 104 total, 1 running, 103 sleeping, 0 stopped, 0 zombie
    %Cpu(s): 0.3 us, 0.3 sy, 0.0 ni, 99.0 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st
    KiB Mem : 3952592 total, 1603140 free, 311052 used, 2038400 buff/cache
    KiB Swap: 0 total, 0 free, 0 used. 3338224 avail Mem

Si j’en crois ce petit rapport HTOP, juste debian+yuno ; 4 go c’est chô !

je souhaitais me libérer également de PhpMyAdmin pour par exemple Adminer qui m’a l’air bien light et optimisé pour MariaDB, mais je ne le trouve pas dans la liste des apps section /Application/installer
Je peux tout de même l’installer ?

  • pour procéder à la migration, j’ai créé chez mon registar une entrée A > ip_instance > Yunohost (sousdom.domaine.com). Mais une fois la migration effectuée j’aimerais donc faire diriger mon domaine principal vers Yuno. J’ai vu qu’on pouvait changer la conf du domaine principal dans Yuno après l’installation, mais à quoi dois-je faire gaffe ?

A ce propos, merci pour le lien vers la conférence de Stéphane Bortzmeyer, m’en suis injecté une bonne heure et demi d’un bloc, ça m’a bien dédramatisé les noms de domaines / DNS.

merci à vous

C’est dans /etc/nginx/conf.d/DOMAIN.conf et /etc/nginx/conf.d/DOMAIN.d/*.conf

Yunohost (avec debian) ça tourne sur 512Mo (même 256Mo je pense).

Là tu as 4Go de RAM donc tu as pas mal de mise en cache (2G), mais ça n’affecte pas ton système. Après faut tout de même vérifier que y a pas le parefeu éteint où ce genre de chose…

Le paquet d’application yunohost pour adminer est actuellement noté niveau 1 par l’outils de test de Yunohost. Tu peux l’installer mais c’est pas idéal car la mise à jour ne fonctionne probablement pas pour l’instant.

Pour bénéficier de toutes les fonctionnalités il faut suivre la config proposé dans la Web Admin → Domain → TONDOMAINE → Configuration DNS

[quote=“kameleon1er, post:9, topic:7969”] J’ai vu qu’on pouvait changer la conf du domaine principal dans Yuno après l’installation, mais à quoi dois-je faire gaffe ?
[/quote]
Ca se fait plutôt bien. Attention tout de même à 2 points:

  • si tu souhaites changer l’url d’une app, il faut que l’app supporte la fonctionalité de changement d’URL (ce n’est pas le cas de toutes).
  • pour le mail, il y a un bug liés aux multidomaines, je sais plus trop le détail

Merci ljf

Le paquet d’application yunohost pour adminer est actuellement noté niveau 1 par l’outils de test de Yunohost. Tu peux l’installer mais c’est pas idéal car la mise à jour ne fonctionne probablement pas pour l’instant.

Ok, donc mieux vaut que je reste sur PhpMyadmin pour le moment.

Au sujet des /apps justement, je m’embrouille un peu…

Quand ttu parles de "mise-à-jour " tu parles j’imagine à Yunohost ? Mais justement pour les apps installées disons hors /apps officielles, qu’est-ce qu’il se passe ? Ca casse le serveur ? Ca casse juste l’app ?

Et que ce passe-t-il aussi pour des paquets côté debian ? Genre “apt-get install htop” par exemple (oui je sais, suis un fou, j’aime les gros softs bien lourds)

Ca fragilise la cohérence des updates / upgrades Yuno ?

Ce que je tente de comprendre c’est qu’est-ce qui est purement Système et qu’est-ce qui est purement Yuno et l’intrication entre les 2. Et en cas d’upgragde de Yuno par exemple, qu’est-ce qu’il “écraserait” le cas échéant.

J’ai bien regardé le graph : Vue d’ensemble de l’écosystème YunoHost mais tout n’est pas encore très clair dans mon esprit.

Par exemple qui a accès à quoi côté visiteurs ?

Si je comprend bien, certaines applications, comme wordpress par exemple sont normalement accessibles au public, mais d’autres sont restreintes au “barrage” du SSO ? Comme les mails par exemple, pour en bénéficier sur mon domaine, un utilisateur doit être préalablement créé si j’ai bien tout compris.

Est-ce que cette “disponibilité” public / Yuno_Users-enregistrés est au choix libre de l’admin, ou est-ce que c’est imposé par certains critères ?

Merci par avance

Oui. Typiquement, quand tu installes une app comme Wordpress (ou d’autre) tu peux choisir si l’application est publique (et donc accessible sans etre logguee) ou restreinte a certains utilisateurs (sachant qu’il est possible de configurer plus finement les permissions par utilisateurs dans la configuration de l’app une fois installee)

Salut Aleks, ok, merci.

Enfin, pas tout à fait finalement :slight_smile:

J’ai installé kanboard par exemple, dans l’admin o m’indique :

Gestion des droits d’accès. Utilisateurs autorisés : Tous les utilisateurs y ont accès.

or si je me rend à l’adresse publique : https://services.domaine.com/kanboard

J’ai droit à un beau :

[https://services.domaine.com/yunohost/sso/?r=aHR0cHM6Ly9zZXJ2aWNlcy5kZW1vY3Jhc2l0ZS5jb20va2FuYm9hcmQv

Veuillez vous identifier pour accéder à cette page]

J’ai loupé quelque chose ? ou kanboard est un mauvais exemple et demande de la conf supplémentaire ?

Peut être un soucis avec kanboard, tu as essayé avec un / à la fin de l’url ?

La notion d’app officiel va disparaître, car de nombreuses apps communautaires sont de bonnes qualités. Les apps niveau 7 et 8 sont des apps qui passent les tests automatiques. A partir de niveau 3 ça passe la mise à jour (mais c’est moins bien intégré backup absent ou absence de liaison ldap/sso).

Plus d’info sur: https://dash.yunohost.org/appci/branch/stable

Tu peux installer la plupart des paquets à la main. Quelques paquets sont proscrits (genre apache2), il faut vérifier que apt ne demande pas de supprime run autre paquet yunohost ou noté ynh-XXXX.
Il est fortement déconseillé d’ajouter un repo tiers car ça peut vraiment casser yunohost.

On peut distinguer l’upgrade des paquet apt de l’upgrade des apps. La commande de mise à jour yunohost te permet d’ailleurs de choisir, et on est plusieurs à choisir le moment opportun pour mettre à jour une app alors que perso pour les paquets je suis en automatique la plupart du temps(avec unattended_upgrade).

NB: il y aussi la notion de migration, yunohost parfois va vouloir migrer des éléments du système, si c’est des changements mineurs ce sera automatique, si c’est des changement qui ont des conséquences dans l’usage il faut valider le disclaimer à la main et tu peux choisir le moment de la faire.
ANB2: si tu modifies des confs gérées par yunohost à la main,les confs modifiées seront à mettre à jour manuellement en cas de nouvelles version. Il y aura un warning lors de la mise à jour. Et si tu casses tout, il y a un mécanisme de regénération de configuration.

Mon conseil: essaies sur une VM

A mon avis, ça signifie “tous les utilisateur connectés y ont accès”

Lorsque tu as installé Kanboard, est-ce que tu as dis oui ou non à la question “Est-ce que c’est une app publique” ?

That means all users connected to YunoHost will have kanboard into their user panel.
As the app is private, if you asked for, only users who are connected to YunoHost can access it.
This option allow you to restrain this access only to some of your users instead of all.

Salut Aleks,

Effectivement, lors de l’installation, je pense que j’ai choisi “privé” pensant qu’il serait possible de modifier ce choix ensuite après configuration.

Ce n’est pas possible ?

Nope, ce n’est pas possible malheureusement (peut-etre dans le futur, mais pas en l’etat)