aussi sur https://bricoles.du-libre.org/serveur_maison
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é.
L'installation héberge tout un tas de service pour plusieurs associations, je prévois:
Dans l'idéal 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
============⇒»»>lalal
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 vmbr2 192.168.9.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:
ALLOW_FROM="127.0.0.1,192.168.5.0/24,192.168.3.0/24" DENY_FROM="all" 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 à déclarer sur le node/PVE,IPFire et chaque Yunohost DNS_du_FAI,DNS_BOX,1.1.1.1?
127,0.0.1 ; 192.168.1.1 ; 91.121.61.147 pour moi
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