Installation fraîche VBox, pas de login?

Un autre problème maintenant:
Un bandeau jaune avec le message “undefined”, et qui indique une page 404 pour Nginx.

Et comment régler le problème de certificat?

Il faudrait explorer Firefox, d’après leur doc, on peut toujours accepter un certificat auto signé sur la version 45.
Mais j’y ai été confronté il y a quelques jours.

Quand à ce “undefined”, c’est pour le moins laconique…

Je ne suis pas présentement sur un Firefox desktop, donc je ne peux pas te dire précisément.
Mais il faut en général ajouter une exception en précisant qu’on comprends les risques

On se comprend que pour de l’auto-hébergement, on ne peut pas espérer du public qu’ils acceptent manuellement un certificat potentiellement louche pour accéder au site…

Donc comment résout-on ça¿

Je te proposais ça pour une solution à court terme, pour accéder à ton instance fraîchement installée.
Pour une solution plus pérenne, il te faut un vrai certificat.
Un topic sur ce forum explique l’usage de lets encrypt, qui te permettra d’avoir un vrai certificat. Mais je n’ai pas encore testé.

Tu peux également te tourner vers StartSSL, qui fourni des certificats gratuits. La doc explique comment installer un certificat signé.

Hmm bon, et pour ce “undefined”, qui renvoie sur une page 404? Car l’interface présentée n’a rien à voir avec ce qui est montré dans la doc

“undefined” le problème c’est que s’est pas très parlant comme erreur…

Mieux vaut traiter les problèmes un à un.
Pour le certificat autosigné, avec la dernière version de firefox, c’est devenu un vrai casse tête… Je trouve ça vraiment pas malin d’ailleurs…

Rend-toi dans Préférences/Avancé/Afficher les certificats
Et clique sur Ajouter une exception...
Là tu pourras rentrer l’adresse de ton site et y accéder correctement.

A partir de là, tu pourras configurer ton instance Yunohost et t’occuper après de mettre en place un nouveau certificat en suivant ces infos.
Pour installer un certificat via lets encrypt:

Sinon pour installer un certificat plus “conventionnel”:
https://yunohost.org/#/certificate_fr

Bon, ça bloque dès la première instruction: je ne peux pas rentrer en root avec le mot de passe défini à l’installation. Est-ce qu’il y en a un par défaut?

Le mot de passe root devrait-être yunohost

Non. “Permission denied”, après m’avoir demandé d’accepter l’empreinte envoyée par le serveur, puisque mon ordinateur ne la connaissait pas.

Non à quoi?
Tu essaye d’accéder en root à quoi exactement?

  • L’interface d’administration de Yunohost?
  • La connexion au serveur sur un écran branché sur celui-ci?
  • Une connexion ssh?
  • Un sudo?
  • Un su root?

Tu suis quel tutoriel?

Celui visant à installer un certificat “officiel” avec let’s encrypt

Il faut préfixer ces commandes de sudo, c’est pas indiqué dans le tuto à ce que je vois.
Ce sont des commandes nécessitant les droits d’administration.

sudo ssh root@yunohost.maison ???

ok, pour moi la première commande est apt-get update. Et cette commande là, il faut la préfixée de sudo.

Si tu essayes de te connecter en ssh, à première vue d’après la doc.
https://yunohost.org/#/ssh_fr
Il faut se connecter avec l’user admin, et non root.

Aussi, il est important que tu me décrives exactement tes problématiques pour que je puisse te répondre au mieux. Sinon, c’est délicat.
Pour plus de simplicité, éventuellement, je suis sur le salon de discutions de Yunohost (accessible en bas de droite de la page d’accueil de Yunohost.)

Alors pour la question du certificat, étant donné que c’est une installation uniquement destinée à une machine virtuelle, je ne me vois pas en demander une officielle auprès d’un organisme quelconque, particulièrement si je dois leur laisser des informations personnelles. Ça me semble un peu contradictoire avec l’objectif de Yunohost, qui est de garder les informations chez soi. D’un autre côté, possible que je ne comprenne pas complètement comment fonctionnent ces fameux certifs.

La connexion a fonctionné avec ssh admin@yunohost.local, bizarre en soi puisque j’ai nommé le mien v-yunohost (toutes mes machines virtuelles ont ce V devant".
Il y a toujours ce “undefined” dans l’interface Web, à laquelle j’ai accédé en utilisant un vieux Safari qui ne sert plus que sur le réseau interne, faut de sécurité suffisante.

Donc j’en suis avec Let’s encrypt, étape 2:
nommé letsencrypt.conf, via nano /etc/nginx/conf.d/votreDomaine.tld.d/letsencrypt.conf
Ce qui donnerait, dans mon cas:
nano /etc/nginx/conf.d/v-yunohost.maison.d/letsencrypt.conf
si je comprends?

Suivi de:

{
    unprotected_urls : [
        "v-yunohost.local/.well-known/acme-challenge"
    ]
}

Sauf que pour le courriel, ça se corse
email = some_admin_user@votreDomaine.tld
Mon installation Yunohost ne comportera pas de serveur courriel dans un premier temps, puisque les messages provenant d’une plage d’IP dynamiques sont rejetés par les filtres des correspondants dans l’immense majorité des cas. Mon FAI bloque le port 25, comme d’habitude, en raison du nombre de machines infectées.

Comme tu le disais, un problème à la fois.

Par la suite, ça donnerait bien:
$ export DOMAINS="-d v-yunohost.local"

Ou est-ce que j’ai complètement faux et il me faut une adresse officielle avec un TLD pour pouvoir administrer convenablement YunoHost?

Yunohost.local ressemble à un alias dans un fichier hosts. Mais je ne trouve rien là dessus et je n’ai pas ça chez moi.
Tu n’aurais pas ajouté ça à ton hosts pour passer avec l’IP locale?

Ton nom de domaine au final c’est quoi? J’ai du mal à croire que ce soit v-yunohost.maison étant donné le tarif de cette extension!

Dés lors, le fichier /etc/ssowat/conf.json.persistent devrait contenir ton nom de domaine réel.

Concernant le mail, le serveur mail est installé et configuré d’office avec Yunohost. Donc tu peux utiliser un mail générique si tu le souhaites. Tel que root@domain.tld, admin@domain.tld, webmaster@domain.tld ou postmaster@domain.tld.

Il y a un point là que je ne comprend pas.
Tu m’as parlé d’un accès public en début de ce topic. Un accès public implique nécessairement un nom de domaine enregistré dans un DNS. Sinon ton serveur ne peut pas être joignable!
Si tu destines ton serveur à un usage limité à ton réseau local, il est inutile de te battre avec un certificat officiel, autant rester en auto-signé.

Tout dépend de la portée que tu souhaites donner à ton serveur.

Tout dépend de la portée que tu souhaites donner à ton serveur.

Compte tenu de la faiblesse de nos connexions Internet et le bruit généré par un disque dur, pas grand chose pour le moment. J’héberge personnellement un petit serveur WebDAV pour Zotero, un serveur d’impression CUPS (qui pose problème à Windows et un Mac, d’ailleurs), une boîte de téléchargements pour moi et quelques amis dotés d’une connexion trop limitée pour ce faire. Je ne sais pas trop quoi mettre d’autre qui serait 1- pas forcément rejeté d’un destinataire éventuel 2- facilement remplaçable en cas de panne de disque dur ou de coupure d’électricité ou d’incendie, inondation, etc. 3- ne demandant pas un entretien constant.

Les services essentiels comme le courriel, calendrier, web sont chez un hébergeur bien connu qui s’occupe des mises à jour, sauvegardes et gestions des pannes, et dispose d’une bande passante suffisante. Je suis bien conscient que ça laisse des traces, ça me préoccupe, mais moins que la dépense pour remettre sur pied un éventuel serveur perso qui aurait calé.

L’accès de Yunohost en machine virtuelle n’est évidemment pas public, mais le but est de simuler le plus possible ce qui arriverait, le cas échéant. Pour le moment, j’accède à certaines machines à distance avec une adresse No-IP. Peut-on faire des certificats sur des noms de domaine renvoyant à des IP dynamiques?

D’ailleurs, si le serveur devait résider chez moi, je l’administrerai à partir de son nom sur le LAN, non de son adresse publique, ni de son IP interne, pour la simple raison que je ne peux me souvenir de l’adresse wifi ET câblée d’une quinzaine de périphériques partageant le réseau.

Pour ça, son nom actuel de v-yunohost.local est valide uniquement sur le LAN. Mais ce hostname ne devrait jamais apparaître dans le fichier HOSTS! Je voudrais que tous mes serveurs utilisent, je crois, Zeroconf pour annoncer leur nom sur le LAN, pas de modifier manuellement le nom dans HOSTS sur tous les ordis connectés.

La documentation de Yunohost détaille l’installation, l’assistant a été simplifié pour les neuneus de mon genre, mais omet un point essentiel: il faut avoir loué le nom de domaine avant toute tentative d’installation, et si possible avoir créé le certificat!

Ok, donc si je comprend bien, tu cherches à reproduire ce que pourrait être un serveur autohébergé public avec une machine virtuelle pour voir la faisabilité de l’ensemble.

Sur les 3 points que tu cites, seul le second reste un problème très concret avec Yunohost à mon avis. Bien que les services hébergés ne soient pas non plus vitaux.
Reste la possibilité de déporter l’hébergement chez un hébergeur privé, tel qu’OVH par exemple, pour réduire les risques de pannes.

Quoi qu’il en soit, il n’est pas nécessaire de disposer de son propre nom de domaine pour utiliser convenablement Yunohost. Il suffit de choisir “Je n’ai pas de nom de domaine …” pour obtenir un nom de domaine en nohost.me ou noho.st.
A partir de là, il est possible d’y associer un certificat signé par une autorité.

Ok, donc si je comprend bien, tu cherches à reproduire ce que
pourrait être un serveur autohébergé public avec une machine virtuelle
pour voir la faisabilité de l’ensemble.

Tout à fait!

Bien que les services hébergés ne soient pas non plus vitaux.

Courriel et calendriers qui ne fonctionneraient pas signifierait perte de tous les contrats de travail, RDV importants, etc. C’est donc vital pour mes besoins. Moins le Web, mais là se pose un pb de bande passante.

Puisque le pb de certificat est au moins réglé en théorie, d’où vient cette erreur “Undefined” dans l’interface Web? Il n’y a pas de détails ni de code d’erreur.

Où apparaît cette erreur? Quelle page tentes-tu d’afficher?
As-tu regardé le log d’erreur d’nginx?