Installation fraîche VBox, pas de login?

Support
21

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.

22

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

23

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.

Tout dépend des besoins. Ne pas avoir de calendrier ni de courriel signifierait des pertes financières importantes pour moi.

Est-il vraiment nécessaire de souscrire obligatoirement un domaine public, même en nohost.me, pour un usage purement virtuel? Autrement dit, le certificat est-ils absolument nécessaire pour effectuer la simulation convenablement?

Est-ce que ce serait la cause de cette erreur affichée dans l’interface web?

24

Il faut bien dissocier tout ça.

Le nom de domaine public est nécessaire uniquement si tu souhaites accéder à la machine depuis l’extérieur de chez toi. Ou si tu souhaites que d’autres personnes y accède depuis l’extérieur.
Le cas contraire, le choix de ton domaine est arbitraire. J’utilise personnellement un nom de domaine pour mes essais qui n’est connu par aucun dns public.
Yunohost fonctionne aussi bien avec un domaine public qu’avec un domaine limité au réseau local.

Le certificat est indépendant de tout cela. Tu as de toute manière un certificat, auto-signé par défaut.
Si tu souhaites que ton serveur soit accessible de l’extérieur, le certificat signé par une autorité certifiée n’est pas indispensable, c’est uniquement un confort pour les utilisateurs qui n’auront pas à subir un message anxiogène.
Encore une fois, Yunohost fonctionne aussi bien avec un certificat auto-signé qu’avec un certificat “officiel”. En revanche, certaines applications peuvent ne pas fonctionner correctement avec un certificat auto-signé, mais le message d’erreur te l’indique en général.

Pour ce qui est de ton erreur “undefined”, il commencer par savoir où et quand se produit l’erreur.

25

Alors dans l’ordre:
Dans Firefox, bien que j’ai ajouté le certificat correspondant à l’IP numérique sur le LAN, il refuse toujours la connexion avec l’erreur SEC_ERROR_REUSED_ISSUER_AND_SERIAL.

Problème: le hostname n’est pas résolu, seule l’IP numérique fonctionne.

Dans un vieux Safari,

Captura de pantalla 2016-03-13 a las 18.55.52.png938×72 12.5 KB
, ce message d’erreur apparaît sur fond jaune. En cliquant sur le lien “Lire davantage”, je tombe sur une page 404.

En ce qui concerne le log d’erreur de nginx, je trouve:

/var/log/nginx/error.log
2016/03/12 07:24:55 [crit] 2476#0: *18 SSL_do_handshake() failed (SSL: error:1408A0D7:SSL routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL handshaking, client: 192.168.1.20, server: 0.0.0.0:443 2016/03/12 07:28:17 [error] 2476#0: *19 open() "/usr/share/yunohost/admin//undefined" failed (2: No such file or directory), client: 192.168.1.20, server: , request: "GET /yunohost/admin/undefined HTTP/1.1", host: "192.168.1.23", referrer: "https://192.168.1.23/yunohost/admin/" 2016/03/12 07:28:28 [crit] 2476#0: *20 SSL_do_handshake() failed (SSL: error:1408A0D7:SSL routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL handshaking, client: 192.168.1.20, server: 0.0.0.0:443 2016/03/13 23:45:42 [crit] 2475#0: *59 SSL_do_handshake() failed (SSL: error:1408A0D7:SSL routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL handshaking, client: 192.168.1.20, server: 0.0.0.0:443 2016/03/13 23:49:55 [error] 2475#0: *63 open() "/usr/share/yunohost/admin//undefined" failed (2: No such file or directory), client: 192.168.1.20, server: , request: "GET /yunohost/admin/undefined HTTP/1.1", host: "192.168.1.23", referrer: "https://192.168.1.23/yunohost/admin/" 2016/03/13 23:50:45 [crit] 2475#0: *64 SSL_do_handshake() failed (SSL: error:1408A0D7:SSL routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL handshaking, client: 192.168.1.20, server: 0.0.0.0:443 2016/03/13 23:50:45 [crit] 2475#0: *67 SSL_do_handshake() failed (SSL: error:1408A0D7:SSL routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL handshaking, client: 192.168.1.20, server: 0.0.0.0:443 2016/03/13 23:51:32 [crit] 2475#0: *91 SSL_do_handshake() failed (SSL: error:1408A0D7:SSL routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL handshaking, client: 192.168.1.20, server: 0.0.0.0:443

Ton nom de domaine est-il du type de ceux finissant en .local?

26

SEC_ERROR_REUSED_ISSUER_AND_SERIAL
ainsi que
SSL_do_handshake() failed (SSL: error:1408A0D7:SSL routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL handshaking

sont la même erreur, firefox refuse le certificat car il considère que 2 certificats différents utilises le même numéro de série.
Je te conseille dés lors de supprimer les certificats enregistrés dans firefox pour ton serveur afin de repartir sur des bases saines.

Concernant ton erreur “undefined”, utilises-tu une application nommée complitly? (C’est une app qui traduit tes recherches web et complète le texte pour tes recherches.)

Mon domaine de test est mon domaine normal auquel j’ai adjoint -test avant le .fr. Tout simplement. Mais ça pourrait être n’importe quoi, à partir du moment où il y a 1 point.

27

Toujours un échec avec Firefox: j’ai retiré les certificats liés à cette machine virtuelle YunoHost, redémarré la machine virtuelle puis rajouté manuellement l’IP à exempter de contrôle.
Je ne peux y accéder avec son hostname v-yunohost.local, par contre il répond sur yunohost.local.

Cette fois, je peux y accéder de Firefox, mais on dirait que le hostname n’est pas annoncé régulièrement sur le réseau.

Comment régler ça?

Une nouvelle ribambelle d’erreurs apparaît:

Captura de pantalla 2016-03-13 a las 20.23.12.png939×194 29.6 KB

Je pensais qu’il s’agissait d’une offre de mises à jour, mais apparemment non.

Donc je comprends avoir une machine très vulnérable, mais aucune solution qui ne soit clairement proposée?

L’autre erreur a disparu après le redémarrage, et pour répondre à la question, je n’ai pour le moment aucune application installée, mais le service bind9 n’a pas démarré.

Et le log correspondant:
Mar 14 01:18:31 yunohost ntpd[2526]: Listen normally on 2 lo 127.0.0.1 UDP 123 Mar 14 01:18:31 yunohost ntpd[2526]: Listen normally on 3 eth0 192.168.1.23 UDP 123 Mar 14 01:18:31 yunohost ntpd[2526]: Listen normally on 4 eth0 fe80::a00:27ff:fec1:894e UDP 123 Mar 14 01:18:31 yunohost ntpd[2526]: Listen normally on 5 lo ::1 UDP 123 Mar 14 01:18:31 yunohost ntpd[2526]: peers refreshed Mar 14 01:18:31 yunohost ntpd[2526]: Listening on routing socket on fd #22 for interface updates Mar 14 01:18:33 yunohost /etc/mysql/debian-start[2624]: Upgrading MySQL tables if necessary. Mar 14 01:18:35 yunohost nslcd[2699]: version 0.8.10 starting Mar 14 01:18:35 yunohost nslcd[2699]: accepting connections Mar 14 01:18:38 yunohost dbus[1987]: [system] Activating service name='org.freedesktop.UDisks' (using servicehelper) Mar 14 01:18:38 yunohost dbus[1987]: [system] Successfully activated service 'org.freedesktop.UDisks' Mar 14 01:18:38 yunohost dbus[1987]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper) Mar 14 01:18:38 yunohost dbus[1987]: [system] Activating service name='org.freedesktop.ConsoleKit' (using servicehelper) Mar 14 01:18:38 yunohost polkitd[3019]: started daemon version 0.105 using authority implementationlocal’ version 0.105' Mar 14 01:18:38 yunohost dbus[1987]: [system] Successfully activated service 'org.freedesktop.PolicyKit1' Mar 14 01:18:39 yunohost dbus[1987]: [system] Successfully activated service 'org.freedesktop.ConsoleKit' Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: Looking for 'mysql' as: /usr/bin/mysql Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: Running 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/var/run/mysqld/mysqld.sock' '--host=localhost' '--socket=/var/run/mysqld/mysqld.sock' '--host=localhost' '--socket=/var/run/mysqld/mysqld.sock' Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: Running 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/var/run/mysqld/mysqld.sock' '--host=localhost' '--socket=/var/run/mysqld/mysqld.sock' '--host=localhost' '--socket=/var/run/mysqld/mysqld.sock' Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.columns_priv OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.db OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.event OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.func OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.general_log OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.help_category OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.help_keyword OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.help_relation OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.help_topic OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.host OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.ndb_binlog_index OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.plugin OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.proc OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.procs_priv OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.proxies_priv OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.servers OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.slow_log OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.tables_priv OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.time_zone OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.time_zone_leap_second OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.time_zone_name OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.time_zone_transition OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.time_zone_transition_type OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: mysql.user OK Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: Running 'mysql_fix_privilege_tables'... Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: ERROR 1436 (HY000) at line 1151: Thread stack overrun: 8672 bytes used of a 131072 byte stack, and 128000 bytes needed. Use 'mysqld --thread_stack=#' to specify a bigger stack. Mar 14 01:18:47 yunohost /etc/mysql/debian-start[2633]: FATAL ERROR: Upgrade failed Mar 14 01:18:47 yunohost /etc/mysql/debian-start[3275]: Checking for insecure root accounts. Mar 14 01:18:47 yunohost /etc/mysql/debian-start[3281]: Triggering myisam-recover for all MyISAM tables

28

Pour t’assurer que ton nom de domaine soit résolu, il est plus sûr de le fixer dans le fichier hosts. Afin que ton navigateur trouve l’IP correspondante en interrogeant les DNS.
https://yunohost.org/#/dns_local_network_fr

Ta machine n’est pas vulnérable, c’est juste une informations sur les failles qui ont été récemment découvertes. Si ton système est à jour, ces failles ont été corrigées.

Par contre, sur une machine Yunohost quasi vierge, le service bind9 démarre. Tu peux éventuellement regardé pourquoi il est arrêté. Mais je ne sais pas si il est véritablement utile si ton serveur ne fait pas office de serveur DNS sur ton réseau.

29

J’ai toujours associé ça à de la triche, qui ne ferait que gêner la résolution d’éventuels problèmes de réseau puisqu’on ne saurait pas qui est à blâmer, un fichier HOSTS non mis à jour, ou un véritable problème de DNS. D’après ma compréhension de la chose, sans “antisèche” sous forme de modification manuelle du HOSTS, une mauvaise résolution de l’adresse interne montrerait sans équivoque que le serveur DNS, ou son cache local, ne fonctionne pas.

Concernant le problème du “hairpinning”, je crois que mon routeur le prend, sous le nom de LAN Lopback:

Captura de pantalla 2016-03-15 a las 16.31.53.png964×447 63.4 KB

Ça a toujours été mal expliqué, mais d’après ce que j’ai saisi, ça permet, entre autres, d’accéder à un serveur sur son propre LAN même en tapant son adresse publique (dans mon cas, ça sert pour le serveur WebDAV, qui doit être accessible sans changer la configuration, du LAN comme d’Internet)

Par contre pour le DNS, la page de configuration du routeur n’est pas vraiment claire, et mentionne:

DNS Server Configuration
Select DNS Server Interface from available WAN interfaces OR enter static DNS server IP addresses for the system. In ATM mode, if only a single PVC with IPoA or static IPoE protocol is configured, Static DNS server IP addresses must be entered.

DNS Server Interfaces can have multiple WAN interfaces served as system dns servers but only one will be used according to the priority with the first being the higest and the last one the lowest priority if the WAN interface is connected. Priority order can be changed by removing all and adding them back in again.

Ce qui n’empêche pas le routeur d’avoir correctement reçu les deux adresses DNS de mon ISP. Je me suis dit que c’était une bonne chose et permettrait une résolution plus rapide des adresses sans surcharger le processeur du routeur, déjà abondamment sollicité si j’en crois les très brèves coupures de wifi qu’il montre à l’occasion lors de traffic particulièrement intense.

D’ailleurs je ne comprends pas pourquoi bind9 s’est arrêté, je ne compte pas avoir plus d’un DNS sur le LAN, c’est une source d’ennuis. Le log dépasse mes compétences :frowning:

30

Je dois bien avouer que j’ai parfois un peu du mal à te suivre :confused:

Le fichier HOSTS fait partie intégrante de la résolution dns. Il est interrogé au même titre que n’importe quel autre dns.
Sauf cas exceptionnel (j’en connais aucun qui le fasse), ton routeur ne s’occupe pas de la résolution dns. Il se contente d’envoyer les demandes de résolution dns au serveur indiqué dans sa configuration.
Qui peut être:

  • Ton propre serveur (en cache dns ou en véritable résolveur dns en lien direct avec les serveurs racines)
  • Le DNS de ton FAI.
  • Le DNS d’un autre FAI
  • D’autres DNS, google ou open-dns par exemple.
    La seule exception à cela, que je connaisse, c’est l’équivalent d’un hosts sur le routeur. Mais ça se limite à quelques nom de domaine que tu renseignes.

MAIS, dans le cas de ta machine virtuelle avec un nom de domaine “non officiel”, aucun dns public (FAI, google, etc), ne connaît la correspondance entre ton nom de domaine et ton ip. Donc, aucun dns public ne peut répondre à ta requête quand tu tentes d’obtenir l’ip de v-yunohost.maison, v-yunohost.local ou yunohost.local.

Donc, pour résoudre ça, il faut renseigner un dns quelque part. Tu ne peux pas le faire sur les dns public, il faut le faire sur le tiens. Moi je fais ça sur mon serveur, qui est le dns contacté par mon routeur.
Si tu peux le faire sur ton routeur, c’est mieux car tout ton réseau en profitera, sinon il faut le faire sur le fichier hosts de chaque machine.
Ce n’est pas de la “triche” dans ce cas, c’est simplement une entrée dans un dns auquel tu as accès, car il en faut au moins un.

Par contre je me perd dans tes domaines et tes hostnames!
Le hostname est le nom de la machine, ma machine de test s’appelle yunohost. C’est le nom qui va s’afficher sur les partages réseaux, sur le routeur lorsque la machine est connectée, etc.

Le nom de domaine est par contre crudelis-test.fr, c’est l’adresse par laquelle je me connecte aux serveurs hébergés sur la machine. C’est cette adresse là que je donne au dns pour obtenir l’ip. C’est cette adresse qui pourrait être accessible publiquement, et surtout c’est cette adresse qui nous intéresse!

31

En effet, le modem-routeur se charge de la résolution DNS, et a pris celui de mon FAI, pour une question de rapidité de routage.
Cependant, d’après le peu que je sais, le protocole surnommé “Bonjour” “annonce” la machine sur le réseau local et se chargerait aussi de la résolution des noms de domaine locaux. C’est censé être automatique, sans passer par la modification manuelle du HOSTS sur chacune des machines, et seul YunoHost pose problème avec la résolution.

Sur toutes mes machines, le nom de domaine local se trouve être le même que le hostname, assorti du suffixe .local. Ma machine actuelle s’appelle silver, nom affiché, et peut être atteinte d’un ordinateur quelconque en entrant l’adresse silver.local.

Je voudrais que YunoHost fasse la même chose sous le nom de v-yunohost.local (hostname: v-yunohost, celui qui s’affiche sur les machines)

32

Ok, je commence à mieux comprendre ta recherche.

Il s’agit de Zeroconf, Bonjour est son implémentation Apple.
Il est question dés lors de nom de domaine automatiquement tiré de ton hostname en y lui concaténant .local

Zeroconf n’est pas installé ni configuré sur debian. Ça reste à vérifier tout de même car je n’ai pas d’accès ssh d’où je suis pour le faire.
Mais je serais très surpris de trouver ça sur un système serveur !
C’est le paquet ‘libnss-mdns’ qui devrait t’intéresser.

Tu trouveras d’avantage d’infos ici
https://wiki.debian.org/ZeroConf

Quand à savoir si nginx répond à un nom de domaine géré par zeroconf, je ne sais pas…

Edit: Par contre, l’usage de Zeroconf n’est pas du tout compatible avec l’idée de créer un “vrai” serveur auto hébergé. Zeroconf limite l’usage à ton réseau privé uniquement.