Accéder à l'environnement de développement local ServBay sur le réseau local (LAN)
Pour les petites équipes de développement ou les développeurs individuels qui ont besoin de tester sur plusieurs appareils, il est courant et important de pouvoir accéder à un environnement de développement local ServBay hébergé sur un autre membre ou appareil via le réseau local (LAN). ServBay est conçu pour permettre l'accès à la plupart de ses services principaux sur le LAN, mais certains services nécessitent une configuration supplémentaire afin de garantir leur sécurité et leur disponibilité.
Ce guide détaille comment configurer et accéder aux sites web et services de base de données de ServBay via le réseau local.
Prérequis
Avant d'essayer d'accéder aux services ServBay à partir du réseau local, veuillez vous assurer des conditions suivantes :
- Connexion réseau : L’ordinateur qui fournit les services ServBay (appelé ci-après « hôte ») et l’ordinateur qui accède au service (« client ») sont sur le même réseau local.
- Adresse IP de l’hôte : Connaissez l'adresse IP privée de l'hôte sur le réseau local. Cette information se trouve dans les réglages réseau de l’hôte.
- Configuration du pare-feu : Si l’hôte a un pare-feu activé, veillez à autoriser les connexions externes sur les ports essentiels utilisés par ServBay (par exemple, HTTP en 80, HTTPS en 443, MySQL en 3306, PostgreSQL en 5432, Redis en 6379, etc.). En fonction des services à exposer, ouvrez les ports correspondants dans le pare-feu et configurez des listes de contrôle d’accès (ACL) pour limiter la plage d’adresses IP autorisées (si nécessaire).
Sites web
Les sites standards configurés via ServBay écoutent généralement, par défaut, sur toutes les interfaces réseaux de l’hôte (c’est-à-dire 0.0.0.0
ou *
), ce qui permet naturellement aux autres appareils du LAN d’y accéder. ServBay utilise Caddy ou Nginx comme serveur web, dont la configuration par défaut va souvent dans ce sens.
Cependant, pour accéder à ces sites via leur nom de domaine depuis un navigateur sur un appareil client, il faut configurer la résolution DNS du nom de domaine sur cet appareil. Par ailleurs, si vos sites locaux utilisent un certificat SSL généré par ServBay (ce qui est fortement recommandé), l’utilisateur doit également installer le certificat racine de ServBay pour éviter les avertissements du navigateur.
Voici un exemple de configuration :
- Adresse IP LAN de l’hôte :
10.0.0.3
- Nom de domaine du site ServBay :
servbay.demo
- Racine du site :
/Applications/ServBay/www/servbay.demo
Configuration de la résolution de nom de domaine (DNS)
L’ordinateur client doit connaître l’équivalence entre le nom de domaine servbay.demo
et l’adresse IP de l’hôte 10.0.0.3
. Voici deux méthodes classiques :
Modifier le fichier Hosts du client : La méthode la plus simple et directe, adaptée à un petit nombre de clients.
- Repérez le fichier Hosts sur l’ordinateur client :
- macOS/Linux :
/etc/hosts
- Windows :
C:\Windows\System32\drivers\etc\hosts
- macOS/Linux :
- Ouvrez ce fichier en mode administrateur, puis ajoutez à la fin :
10.0.0.3 servbay.demo
1 - Enregistrez le fichier. Désormais, toute requête vers
servbay.demo
pointera vers10.0.0.3
depuis ce client.
- Repérez le fichier Hosts sur l’ordinateur client :
Configurer le serveur DNS du LAN : Si votre réseau local dispose d’un serveur DNS (fonctionnalité DNS du routeur ou d'un service dédié), vous pouvez ajouter un enregistrement A pour
servbay.demo
, pointant vers l’adresse LAN de l’hôte10.0.0.3
. Ainsi, tous les appareils du LAN utilisant ce DNS résoudront ce domaine correctement.
Distribution et installation du certificat CA ServBay (SSL)
ServBay propose une puissante infrastructure PKI pour l’environnement de développement local, y compris un certificat racine CA ServBay permettant de signer les certificats SSL des sites locaux. Pour accéder à ces sites HTTPS, il est nécessaire que l’ordinateur client fasse confiance à la CA ServBay afin d’éviter les alertes de sécurité du navigateur.
Vous devrez donc exporter le certificat racine user CA de ServBay, le distribuer aux utilisateurs du réseau, puis les guider dans l'installation et la confiance de ce certificat sous leur système ou navigateur.
Pour les procédures détaillées d’export et d’installation des certificats, référez-vous à la documentation ServBay, chapitre gestion des certificats SSL, notamment les parties sur l’export des certificats et l’installation dans l’OS/navigateur.
Bases de données
ServBay prend en charge plusieurs services de bases de données, comme MySQL, MariaDB, PostgreSQL, MongoDB, ainsi que des bases en mémoire comme Redis et Memcached. Chaque service gère différemment ses paramètres d’écoute réseau et ses mécanismes de permissions.
MySQL / MariaDB
Par défaut, les services MySQL et MariaDB de ServBay écoutent sur toutes les interfaces réseau (0.0.0.0
), ce qui autorise les connexions du réseau local.
Cependant, MySQL/MariaDB applique une vérification stricte des droits d’utilisateur. Même si l’accès réseau est ouvert, l’utilisateur doit disposer d’un identifiant et d’un mot de passe autorisant la connexion à partir de l’adresse IP utilisée.
En général, l’utilisateur root
n’est autorisé qu’à se connecter depuis 127.0.0.1
ou localhost
. Pour accorder un accès LAN, créez un utilisateur dédié ou modifiez les droits d'un utilisateur existant pour permettre la connexion depuis une IP spécifique du LAN ou depuis n'importe quelle adresse (%
).
Exemple pour créer un utilisateur servbay-demo
autorisé depuis n’importe quelle IP du LAN (%
), et lui donner tous les droits sur une base de données :
sql
-- Supposons que vous soyez connecté avec un utilisateur root ou équivalent
CREATE USER 'servbay-demo'@'%' IDENTIFIED BY 'your_strong_password';
GRANT ALL PRIVILEGES ON `your_database_name`.* TO 'servbay-demo'@'%';
FLUSH PRIVILEGES;
1
2
3
4
2
3
4
Remplacez 'your_strong_password'
et your_database_name
selon vos besoins.
Attention : Autoriser un utilisateur à se connecter depuis toutes adresses (%
) avec de larges privilèges est risqué. Sur un réseau non isolé ou en production, il est conseillé de restreindre l’accès à certaines IP de confiance (ex : 'servbay-demo'@'10.0.0.5'
) ou d’utiliser un VPN pour plus de sécurité.
ServBay permet de réinitialiser le mot de passe root MySQL/MariaDB et de gérer les droits utilisateurs, soit via cette option, soit via des outils clients.
Redis
Dans ServBay, Redis est généralement configuré pour écouter uniquement sur l’adresse de bouclage locale (127.0.0.1
), empêchant tout accès direct depuis le LAN par défaut — pour des raisons de sécurité, car par défaut Redis n’impose pas de mot de passe.
Pour autoriser l’accès LAN à Redis, il vous faudra modifier le fichier de configuration redis.conf
.
Deux méthodes existent :
1. Via l’interface graphique de ServBay
- Ouvrez ServBay, dans le menu de gauche, rendez-vous sur
Bases de données
>Redis
- Dans le panneau de configuration, cochez
Require Password
, puis saisissez un mot de passe fort - Cliquez sur
Enregistrer
2. Modification manuelle du fichier redis.conf
(non recommandée)
- Repérez le chemin du fichier
redis.conf
de Redis dans ServBay (généralement dans/Applications/ServBay/etc/redis/redis.conf
). - Ouvrez ce fichier avec un éditeur de texte.
- Trouvez la ligne :
bind 127.0.0.1
- Modifiez-la en :
bind 0.0.0.0
ou commentez-la (# bind 127.0.0.1
) pour permettre l’écoute sur toutes les interfaces réseau. - [Critique] Localisez la ligne
requirepass
(elle peut être commentée). Décommentez-la et définissez un mot de passe solide :À ne jamais faire : ouvrir Redis au réseau sans mot de passe ! Cela expose à des risques critiques.requirepass your_very_strong_redis_password
1 - Enregistrez
redis.conf
. - Redémarrez le service Redis via ServBay pour appliquer les changements.
Vous pouvez alors accéder à Redis via l’IP LAN de l’hôte et le mot de passe configuré.
PostgreSQL
Dans ServBay, PostgreSQL écoute également par défaut uniquement sur 127.0.0.1
, bloquant donc les accès réseau local par défaut.
Pour autoriser l’accès LAN, il vous faudra modifier deux fichiers de configuration clés : postgresql.conf
et pg_hba.conf
.
Identifiez les chemins de ces fichiers dans ServBay (en général,
/Applications/ServBay/etc/postgresql/postgresql.conf
et/Applications/ServBay/etc/postgresql/pg_hba.conf
).Modification de
postgresql.conf
:- Ouvrez
postgresql.conf
dans un éditeur. - Repérez la ligne
listen_addresses
(peut être commentée). - Décommentez-la et remplacez la valeur par
'*'
pour activer l’écoute sur toutes les interfaces :listen_addresses = '*'
1 - Enregistrez le fichier.
- Ouvrez
Modification de
pg_hba.conf
:- Ouvrez
pg_hba.conf
. Ce fichier contrôle quels hôtes, bases et utilisateurs peuvent se connecter et via quelle méthode d'authentification. - Ajoutez une ligne permettant l’accès depuis le segment LAN (exemple : autoriser le sous-réseau
10.0.0.0/24
à se connecter avec mot de passe) :# TYPE DATABASE USER ADDRESS METHOD host all all 10.0.0.0/24 md5
1
2TYPE
:host
= connexion via TCP/IP.DATABASE
:all
pour toutes bases de données, ou un nom spécifique.USER
:all
pour tous les utilisateurs, ou un nom précis.ADDRESS
:10.0.0.0/24
autorise la plage10.0.0.1
à10.0.0.254
. Sinon, ciblez une IP ou évitez0.0.0.0/0
sauf protection par pare-feu.METHOD
:md5
exige l’authentification par mot de passe MD5 (recommandé). Éviteztrust
(pas de mot de passe, jamais à distance) etpassword
(mot de passe en clair, risqué).
- Enregistrez le fichier.
- Ouvrez
Redémarrez PostgreSQL depuis ServBay pour activer la configuration.
Les clients pourront alors se connecter à PostgreSQL via l’IP de l’hôte LAN, un utilisateur et un mot de passe valides.
La gestion et la réinitialisation du mot de passe root
(postgres) de PostgreSQL sont aussi supportées par ServBay.
Memcached
Memcached est un système de cache mémoire distribué haute performance au design minimaliste, qui n'intègre aucune authentification ni autorisation native.
Il est donc fortement déconseillé d’exposer Memcached directement sur le réseau local ou un réseau public, sauf si vous disposez d'autres protections réseau : limitez l’accès à des sous-réseaux internes de confiance et filtrez strictement avec un pare-feu.
Vous pouvez configurer l’écoute de Memcached sur une IP LAN dans ServBay, mais soyez conscient du danger : par défaut, il n’y a aucune protection par mot de passe. Pour modifier cette adresse d’écoute, la procédure est similaire à Redis (via édition de la configuration), mais il n’y a aucune authentification.
Conseils de sécurité
Rendre l’environnement de développement local accessible sur le réseau facilite grandement la collaboration et les tests multi-appareils, mais cela augmente aussi la surface d’exposition aux risques. Suivez impérativement ces recommandations :
- Pare-feu : Utilisez toujours un pare-feu pour limiter les ports ouverts de l’hôte ServBay. N’autorisez que le trafic en provenance d’IP LAN de confiance.
- Mots de passe forts : Affectez des mots de passe robustes pour les bases de données (MySQL/MariaDB/PostgreSQL) et Redis. Changez-les régulièrement.
- Principe du moindre privilège : N’accordez aux utilisateurs de base de données que les droits strictement nécessaires. Ne vous connectez jamais à distance en tant que
root
oupostgres
sauf nécessité. - Sécurité Memcached : Encore une fois, puisque Memcached n’a aucune sécurité intégrée, évitez de l’exposer sur le LAN. Utilisez si besoin un tunnel SSH ou un accès réseau restreint.
- Mises à jour système : Maintenez votre OS hôte et ServBay à jour avec les derniers correctifs de sécurité.
En appliquant ces bonnes pratiques, vous pourrez partager et accéder plus sereinement et efficacement à votre environnement ServBay sur le réseau local.