Ou le nouveau serveur maison.
Je remplace quelques années d'empilage de services et de serveurs, plusieurs machines qui se chargent des messageries, sites, ressources, organisations etc pour ma famille et quelques associations par une seule nouvelle machine!
Un T-BAO R3 Pro Mini PC, AMD Ryzen 7 5700U 8 Cores 4.3GHz, 16GB DDR4 RAM 512GB SSD, HDMI+DP+Type-C Triple 4K Display, WiFi 6 Bluetooth 5.2, 2*USB3.0 2*USB2.0 2*2.5G RJ45 Ports 1*3.5mm Audio Jack, Dual-fan Cooling. Qui ressemble à un grille pain.
Cela va me permettre de passer des bons 80W du tout à moins de 20W, gagner de la place et me faciliter la maintenance, sans compter le gros gain de rapidité. Un saut véritable dans le temps, je n'utilisais que de la récup… ici c'est plutôt de l'investissement pour 10ans. L'installation est surdimentionnée pour des services de bases mais je n'aurais plus de reflexion sur le temps d'attente de nextcloud et nous sommes maintenant deux à tester pas mal de trucs, ces ressources seront un confort anti-stress non négligeable.
La partie humaine fait aussi partie de l'approche écolo…
Pour un bon début , plutot qu'un Raspberry pi 5 + carte pour SSD + SSD , ou une récupération de PC de bureau, bien plus rapide et consommant autant voir moins de 10W il y a sur le marcher aussi des T-BAO N100 250Go/8Go pour 130€. Pour un auto-hebergement plus simple voir juste un Yunohost, c'est peut être une bonne idée.
L'installation héberge tout un tas de service pour plusieurs associations, je prévois:
Dans l'idéal ,plus tard, ce serveur pourra fonctionner sur un panneau solaire avec une simple adsl ou une liaison 4G pour être autonome à la campagne et participer à une émancipation technique plus grande d'autres personnes ou groupes…
Je participe en parallèle à une démarche un peu similaire mais peut être moins radicale sur un projet nommé Hentoù (le chemin en Breton) avec Bretagne Transition dans le pays de l'Aven… et je maintient un petit atelier sur le sujet : https://minyhack.kerminy.org/ressources:serveur_ovh_hentou
Ici, je n'utilise pas les services d'un hébergeur (OVH) en me chargeant moi-même de cela. Ce qui simplifie la structure et surtout rend l'installation bien plus aisée à maintenir. J'accède à tout depuis l'arrivée de la box (fibre pour moi), disques, USB, réseau etc
Ce qui m'oblige aussi à sécuriser, câbles, sauvegardes, alimentation, accès , mais ce n'est pas plus mal.
le schéma des réseaux
en prévision , un réseau orange/DMZ sur 192.168.5.0 … non utiliser pour le moment
#/dev/sda2: UUID="03aaf4ae-b616-46ad-9ae9-1a6d448d20ce" /mnt/DD4T2 ext4 defaults 0 1 #/dev/sda3: UUID="e1e0930c-13f7-411d-9f8a-e020d6f32a55" /mnt/DD4T3 ext4 defaults 0 1 #/dev/sda1: UUID="397a7984-4043-4c10-8717-4a326684068e" /mnt/DD4T1 ext4 defaults 0 1
cf tteck pour proxmox , ajustage des dépots à partir de la console du node prox, tout est validé, reboot…
bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/misc/post-pve-install.sh)"
/etc/networks/interfaces
auto lo iface lo inet loopback iface eno1 inet manual iface enp3s0 inet manual auto vmbr0 iface vmbr0 inet static address 192.168.1.2/24 gateway 192.168.1.1 bridge-ports eno1 bridge-stp off bridge-fd 0 #WAN iface wlp4s0 inet manual auto vmbr1 iface vmbr1 inet static address 192.168.5.1/24 bridge-ports none bridge-stp off bridge-fd 0 #LAN1 DMZ auto vmbr2 iface vmbr2 inet static address 192.168.3.1/24 bridge-ports enp3s0 bridge-stp off bridge-fd 0 #LAN2
On fera pointer la box sur le firewall, transfert de port 80,443,… sur 192.168.2.254
qui a son tour délivrera http;https au site par le reverseproxymanager 192.168.2.253
Pour donner accès à l'administration ciblée, certaine VM/LXC par ex
apt install sudo # création de l'utilisateur useradd -m USERNAME # mot de passe passwd USERNAME # ajout dans le groupe sudo gpasswd -a USERNAME sudo # ssh mkdir /home/USERNAME/.ssh touch /home/USERNAME/.ssh/authorized_keys chmod 600 /home/USERNAME/.ssh/authorized_keys chown USERNAME:USERNAME /home/USERNAME/.ssh/authorized_keys # Placer ensuite le contenu de vos clés publiques SSH dans ce fichier # ou avec: sur mon pc linux ssh-keygen -t rsa ssh-copy-id -i ~/.ssh/id_rsa.pub user@ip ssh 'user@ip ' # fonctionne
pour n'accéder qu'a travers le réseau local , ssh ou tailscale:
Création du fichier de configuration pour restreindre l'accès à l'interface Web de Proxmox, on autorise seulement ce qui vient vmbr2 192.168.3.xx ou une entrée locale 127.0.0.1 . Mais on garde le port 8006
vi /etc/default/pveproxy
Insérer le contenu suivant:
DENY_FROM="all" ALLOW_FROM="127.0.0.1,192.168.3.0/24" POLICY="allow"
Relancer le service
sudo service pveproxy restart
On change le port du ssh vers un port non standard genre 7422 .
On fera le transfert de port dans IPFire pour passer.
Faire la modification du fichier /etc/ssh/sshd_config , vi ou nano pour invalider l'accès root et ouvrir le ssh sur un autre port que le 22, pour nous 7422
vi /etc/ssh/sshd_config # vi ou autre éditeur nano ? # Modifier ensuite les lignes suivantes du fichier Port 7422 PermitRootLogin no
Relancer ensuite le service SSH qui sera maintenant accessible avec notre utilisateur : USERNAME
service ssh restart
ou mieux un reboot de Proxmox complet pour voir si tout est bon… penser qu'au cas ou on a plus le ssh en directe sur ce nouveau port:…
ssh -p7422 USERNAMEt@domaine.xx -L 8006:127.0.0.1:8006
cad un ssh port 7422 passe à travers vmbr0/vmbr1 sur IPFire (regle iptable du Proxmox) qui fait un tunnel vers le Proxmox (regle de transfert de port de ce firewall) ou avec tailscale
ssh USERNAME@domaine.xxtailsscale -L 8006:192.168.5.1:8006
cad ssh a travers tailscale vers la machine domaine.xxtailscale qui fait le tunnel sur l'interface web du Proxmox
https://localhost:8006 # pour firefox et l'accès au PVE
Tout doit entrer sur le firewall…
Après tests, IPFire semble le plus simple à mettre en place… suivre ses documention d'install
https://downloads.ipfire.org/releases/ipfire-2.x/2.27-core182/ipfire-2.27-core182-x86_64.iso
Pour l’installation:
Le réseau GREEN/Vert est la vmbr2 ip=192.168.3.254/24 avec un DHCP actif Le réseau RED/rouge est la vmbr0 ip=192.168.1.3/24 gateway 192.168.1.1 Orange vmbr1 192.168.5.254/24
On y accede 192.168.3.254:444 en etant sur le LAN
On pourrait y accèder ensuite avec un tunnel ssh: (root ou l'utilisateur admin principal, sur le port 444 d'IPFIre)
ssh root@37.187.XX.XX -L 8445:192.168.3.254:444 https://localhost:8445 # firefox
On y fera la création de règles de transfert de ports:
Faire une sauvegarde de cette machine et la récupérer pour la re-déposer sur une nouvelle installation…
Le reverse-proxy permet la déclaration des certificats Let'sEncrypt, des noms de domaines de nos machines;services (et future) pour ventiler les renvois http;https sur le réseau interne orange (192.168.5.0/24 vmbr1)
Doc: https://nginxproxymanager.com/guide/
Installation de https://tteck.github.io/Proxmox/, on installe une LXC avec Nginx Proxy Manager
Dans une console sur le node
bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/ct/nginxproxymanager.sh)"
Choisir vmbr2, une ip fixe 192.168.3.253/24 gateway 192.168.3.254
le premier accès sera sur 192.168.2.253:81
Email: admin@example.com
Password: changeme
Mais si on est à l'extérieur (sur le net)
ssh -p7422 root@domaine.xx -L 8081:192.168.3.253:81 ou avec tailscale ssh root@hdomaine.xxtailsscale -L 8081:192.168.3.253:81 https://localhost:8081 # pour firefox
ajout de python3-certbot-dns-ovh
oublié par le paramétrage de la LXC? en tout cas faire:
yarn cache clean # ? pas sur derniere version pkg clean nvm cache clear
pour ne pas avoir d'utilisateur root
adduser USERNAME # valider et donner un pass (qu'on sauvegarde!!) (penser keepass) usermod -aG sudo USERNAME
Faire une sauvegarde de cette machine et la récupérer pour la re-déposer sur une nouvelle installation…
En résumé du coté des noms de domaine
les DNS sont gérés par la pihole (192.168.3.13).
Pihole permet d'adresser en local les machines de notre réseaux, plutot que de partir vers le DNS du FAI puis de revenir avec une ip généraliste, les requêtes obtiennent une ip 192.168.3.xx sans sortir de notre zone. Plus rapide,pratique,sécure…
Après expériencessss je suis revenu à utiliser pour le partage des données en local une simple Alpine en LXC privilégiée avec un serveur NFS (et Samba)
Ce qui est très pratique , il suffit d'ajouter dans les fstab des machines devant accéder
192.168.3.XX:/MEDIAS /MEDIAS nfs defaults,user,exec 0 0
Mais qui demande à ce que les LXC soient en privilégiées pour ouvrir les options dans le PVE NFS,CIFS
Et donc tout mes fichiers multimedias sont gérés par une Yunohost avec les application Jellyfin,Prowlarr/Radarr/Sonarr/Readarr/Transmission …
Les données sont sur un disque séparé, je ne sauvegarde que les répertoires de données personnelle, pas ce qui vient de la pêche torrent.
J'installe un Yunohost pour rendre le groupe un peu plus autonome et pouvoir faire un éventuel transfert
Sur la console du PVE
bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/ct/yunohost.sh)"
se connecter sur l'ip donnée avec le navigateur pour terminer l'installation
Une fois que la post-installation est terminée et que tout marche en root sur ce LXC, ajout d'un php 8.2
sudo apt install lsb-release apt-transport-https ca-certificates software-properties-common -y sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg sudo sh -c 'echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list' sudo apt update sudo apt install php8.2
ynh1.domaine.xx, sera l'accès général, peut être prévoir un⋅e admin par groupe?
Dans chaque YNH on installera les applications sans se soucier des certificats puisque il sont gérés par ReverseProxyManager.
On ne chargera pas non plus YNH de mettre à jour le DNS *.mondomaine.truc ! mais seulement les domaines du groupe
Chaque YNH, groupe, se chargera de la gestion de ses propres utilisateurs⋅trices, des accès aux différents services.
Si il est besoin de port particulier,il faudra les ajouter aux regles du Proxmox et à IPFire. Par exemple prévoir le routage des messageries/mail MX et autres
d'un site/appli dans un des Yunohost par ex
En local un accès navigateur https://truc.mondomaine me demande de valider l'absence de certificat, ce qui me semble normal puisque j’accède directement hors internet, donc auto-signé. Depuis l'extérieur pas de pb nginxproxymanager signe pour lui.
Yunohost fonctionne à merveille, j'installe pour chaque site dokuwiki,my_webapp-code html hugo),spip,bludit , etc.
Bludit est un bon CMS simple sans base de donnée, qui donne la main rapidement au futur admin de la machine et des sites, il ne prend que 40Mo dans le répertoire, on peut l'installer autant de fois qu'on veut, soit en sous domaine soit plus simplement en sous répertoire.
J'ai eu la surprise de voir le disque alloué a la LXC revereproxymanager fondre …les log dans /data/logs prenant tout l'espace.. et provocant des bugs dans toutes les transactions genre NS_ERROR_NET_PARTIAL_TRANSFERT dans les navigateurs, ceux-ci ne recevant que des bouts de page.
La solution est
Mon disque utilise 1.8Go
Je vais faire une alerte de disque presque plein …
cat <<EOF | pct enter 101 | tail +2 | sed s/%//g | awk '{ if($5 > 90) print "Alert "$0;}' | mail -s "Alerte disque presque plein 101" moi@blabla.org df EOF
ou pour tous les lxc
#!/bin/bash set -x rm /tmp/mailgep # test espace disque restant for idlxc in ` pct list | awk 'NR == 1 {next} {print $1 }' ` do cat <<EOF | pct enter $idlxc | tail +2 | sed s/%//g | awk '{ if($5 > 40) { print "Alert "$0 } ;}' >> /tmp/mailgep df EOF done if [ -s /tmp/mailgep ]; then cat /tmp/mailgep | mail -s "Alerte disque" moi@moimoi.org fi exit 0
a mettre dans le cron (cron -e) genre 0 23 * * * pour tous les soir 23h…
j'utilise imapsync sur la maéine cible pour récupérer mes boites et ses répertoires.
imapsync --host1 192.168.3.10 --user1 "gentiuser" --password1 "Coollepass" --ssl1 \ --host2 localhost --user2 "gentiuser" --password2 "Coollepass" --ssl2 \ --subscribeall
marche nickel …
Cela serait peut-être envisageable , la box filtre déjà un peu, et Yunohost,Nethserver(mail) sont bâtis pour un certain niveau de sécurité qu'on pourrait juger suffisant de façon indépendant ?