1. Mon adresse ip n'est pas détectée par le script d'installation
2. Le login admin n'est pas détecté par le script d'installation
3. La capacité du disque n'est pas détecté par le script d'installation
4. Je n'arrive plus à atteindre mon serveur alors qu'il fonctionne bien
5. Suis-je obligé d'utiliser la version 14.04 d'Ubuntu Server ?
6. L'empreinte MD5 de l'archive ne correspond pas à celle indiquée sur la page du projet
7. Je ne sais pas où se trouve physiquement mon serveur qui est hébergé chez un fournisseur, comment faire à l'installation ?
8. Je ne peux pas modifier certains paramètres du compte administrateur principal à partir de l'interface de gestion utilisateur
9. Je n'arrive pas à utiliser **sync** en mode sécurisé https, pourquoi ?
10. Peut-on installer KerHost sur un réseau local sans nom de domaine ?
11. Peut-on tester KerHost en le virtualisant ?
12. Existe-t-il une image pré-installée de farmserv pour Raspberry pi ?
13. Je souhaiterai intégrer le projet farmserv, comment faire ?
14. Pourquoi NextCloud n'est pas présent dans les SPI ?
15. Pourquoi mon serveur est injoignable depuis internet en auto-hébergement ?
16. Puis-je tester la version de développement ?
17. Je n'arrive pas à accéder à l'interface admin de KerHost, mon identifiant admin est rejeté

Le script d'installation détecte l'adresse ip en utilisant la commande bash suivante:
hostname -I
Cette commande se base pour un serveur standard. Il se peut que cette commande ne renvoie rien (pour plusieurs raisons). Dans ce cas là, il vous suffit d'indiquer l'adresse ip manuellement (que de toute façon vous devez connaître !). Il existe sûrement une commande bash plus aboutie… je ne la connais pas.

Si le script d'installation ne détecte pas correctement le login admin, c'est sûrement que vous avez plusieurs comptes unix déjà créés et que le script ne sait pas lequel choisir. Les pré-requis indiquent une installation fraîchement installée avec juste un compte admin de créé. Supprimer les comptes pour ne garder que le compte admin et relancez l'installation.

Tout comme l'adresse ip, la capacité du disque peut ne pas être détectée correctement pour plusieurs raisons. La commande bash qui récupère cette valeur est la suivante :
`df -B G | awk '/root/ {print $2}'` pour un Raspberry Pi
`df -B G /dev/$disk | awk '/sda/ {print $2}'` pour un serveur normal
Elle cherche par défaut la partition principale /dev/sda2. Si la capacité du disque n'est pas proposée, alors vous pouvez toujours l'indiquer vous même.

Tout marchait bien, et hop, plus rien ! Vous vous êtes probablement fait bannir par fail2ban suite à une mauvaise manip (authentification échouée à plusieurs reprises sur un service par exemple…). Pour un utilisateur, il suffit qu'il contacte l'administrateur par mail pour demander le déblocage, ou alors attendre que le temps de bannissement imparti soit passé (24h par défaut), ou alors se connecter à partir d'une autre adresse IP. Pour l'administrateur, ça se complique !!! Si le bannissement ne s'applique pas au filtre fail2ban-ssh, alors celui-ci peut se connecter en SSH sur le serveur et débloquer son adresse IP avec la commande suivante :
iptables -D filtre -s adresse_ip -j DROP en remplaçant filtre par le filtre qui a bloqué l'adresse ip (pour le connaître il suffit de lire la table d'iptables avec la commande iptables -L) et adresse_ip par l'adresse ip bloquée. Une autre possibilité est de redémarrer fail2ban par un service fail2ban restart, mais cette option va réinitialiser le firewall et dé-bannir toutes adresses ip bloquées. Si l'administrateur ne peut pas contacter le serveur en ssh et qu'il n'a plus accès à l'interface d'administration, alors il lui faudra disposer d'une autre adresse ip pour contacter à nouveau le serveur !
D'où l'importance que l'administrateur ajoute son adresse ip fixe tout de suite après l'installation de façon à toujours disposer d'un point d'entrée sur le serveur.

Oui, vous devez impérativement utiliser la version prescrite dans les pré-requis. Il y a souvent de trop grandes différences dans les fichiers de configuration d'une version à une autre de Debian, ce qui causerait des erreurs à répétition du script d'installation. En revanche, les versions intermédiaires de mises à jour peuvent être utilisées sans aucun problème comme :

• Debian 10.1
• Debian 10.2
• Debian 10.8
• …

Si c'est le cas, l'installeur refusera de continuer par mesure de sécurité. Il est fort probable que vous essayez une installation de KerHost qui ne fait pas partie de install.kerhost.fr. La vérification md5 du script d'installation n'est pas infaillible et ce dernier peut aisément être modifié par n'importe qui pour contourner cette vérification. C'est pour cela qu'il est très important pour que la vérification md5 soit fiable que vous vous assuriez bien que :

• la commande d'installation wget -O - https://install.kerhost.fr | bash qui va chercher le script d'installation pointe bien sur le sous domaine install.kerhost.fr
• que la page web de vérification du code md5 soit bien https://install.kerhost.fr/md5.html.

C'est ce couple qui vous garantit la fiabilité de l'installation, et rien d'autre !

Dans le cas ou vous n'utiliseriez pas de certificats Let'sEncryt, le script d'installation vous demande où se situe géographiquement votre serveur pour la création des certificats de sécurités auto-signés. Si votre hébergeur ne vous fournit pas cette information, ce n'est pas grave. Mettez ce que vous voulez. Ceci n'a pas vraiment d'importance étant donné que les certificats ne sont pas déclarés officiellement auprès d'un organisme agréé. En revanche si vous décidez de les faire certifier, alors il sera impératif de connaître la géolocalisation de votre serveur.

C'est normal. Le compte administrateur principal ne peut pas à partir de l'interface de gestion utilisateur :

• modifier son profil
• modifier ses services web
• gérer ses services web

C'est expliqué dans le guide utilisateur. Si vous n'utilisez pas Let'sEncrypt, vous devez d’abord visiter cette page https://sync.votre_domaine/ pour faire accepter à vos navigateurs Firefox le certificat de sécurité auto-signé. Sinon sync refusera de marcher.

Oui, c'est possible, en utilisatnt un nom de domaine bidon, par exemple pour une utilisation sur un réseau local ou tout simplement pour tester KerHost. Vous n'êtes pas obligé d'installer un serveur DNS comme bind, il est inclus en cas d'une installation pour un auto-hébergement. Soit vous utilisez comme DNS votre serveur, soit vous modifiez votre fichier hosts. Vous procédez d’abord à une installation normale en choisissant un nom de domaine, et ensuite pour atteindre le serveur, vous modifiez votre fichier /etc/hosts (linux/macosx) ou C:\WINDOWS\system32\drivers\etc\hosts (windows) en ajoutant ceci :

• adresse_ip_du_serveur nom_de_domaine
• adresse_ip_du_serveur mail.nom_de_domaine
• adresse_ip_du_serveur smtp.nom_de_domaine
• adresse_ip_du_serveur imap.nom_de_domaine
• adresse_ip_du_serveur lists.nom_de_domaine
• adresse_ip_du_serveur ftp.nom_de_domaine
• adresse_ip_du_serveur blog.nom_de_domaine
• adresse_ip_du_serveur partage.nom_de_domaine
• adresse_ip_du_serveur rss.nom_de_domaine
• adresse_ip_du_serveur statsperso.nom_de_domaine
• adresse_ip_du_serveur statserver.nom_de_domaine
• adresse_ip_du_serveur statservice.nom_de_domaine
• adresse_ip_du_serveur php.nom_de_domaine
• adresse_ip_du_serveur sync.nom_de_domaine
• adresse_ip_du_serveur ntp.nom_de_domaine
• adresse_ip_du_serveur recherche.nom_de_domaine
• adresse_ip_du_serveur formulaire.nom_de_domaine
• adresse_ip_du_serveur wiki.nom_de_domaine
• adresse_ip_du_serveur proxy.nom_de_domaine
• adresse_ip_du_serveur vpn.nom_de_domaine
• adresse_ip_du_serveur webadmin.nom_de_domaine
• adresse_ip_du_serveur git.nom_de_domaine
• adresse_ip_du_serveur terminal.nom_de_domaine
• adresse_ip_du_serveur doc.nom_de_domaine
• adresse_ip_du_serveur calc.nom_de_domaine
• adresse_ip_du_serveur drop.nom_de_domaine
• adresse_ip_du_serveur memo.nom_de_domaine
• adresse_ip_du_serveur link.nom_de_domaine
• adresse_ip_du_serveur conversation.nom_de_domaine
• adresse_ip_du_serveur mta-sts.nom_de_domaine
• adresse_ip_du_serveur autoconfig.nom_de_domaine

En remplaçant adresse_ip_du_serveur par l'adresse ip du serveur et nom_de_domaine par un nom de domaine bidon. Et le tour est joué.

Oui il est tout a fait possible de virtualiser KerHost. Personnellement je fais mes tests sur des maquettes virtualisées sous VirtualBox (32 et 64bit), et en modifiant mon fichier hosts comme expliqué ci-dessus.

Non, hélas, pas pour le moment, mais c'est prévu pour la prochaine version. C'est que ça prend du temps à développer tout ça, et je suis tout seul.

Vous avez des connaissances en développement ? Vous avez pleins de propositions d'amélioration (ainsi que les solutions) ? Parfait ! Faites moi signe, je suis preneur !

Tout simplement parce que NextCloud à tendance à être lourd pour le système tant on peut y ajouter des applications. Il est proposé comme service (et c'est déjà pas mal !) mais pas disponible pour les sites web perso. Après, il peut être ajouter sans problème.

Avez-vous pensé à configurer la DMZ de votre box ? En auto-hébergement, il est impératif que votre box serve de passerelle entre votre serveur et internet.

Oui, il existe une version de développement. Vous la trouverez içi : https://install.kerhost.fr/dev/ Pour lancer une installation sur la version de développement, il suffit de taper :
wget -O - https://install.kerhost.fr/dev/kerhost | bash
Attention ! C'est la version de développement en cours et elle peut changer à tout moment. Référez-vous à la page de mise à jour pour connaître le détail des nouveautés. N'utilisez pas cette version pour de la production.

Vous essayez probablement de vous connecter avec votre compte utilisateur. La double authentification ce fait à partir d'un identifiant supplémentaire différent.