en fr nl de
À propos Contact Charte Actualités
all2all

Hébergement web

Questions sur Apache, le transfert de fichiers, les permissions, CGI, .htaccess, les statistiques et l’accès shell.

Questions

Quels programmes de transfert de fichiers puis-je utiliser ?

Choisissez de préférence un programme qui prend en charge les transferts chiffrés, surtout SFTP. FTP reste disponible principalement pour la compatibilité avec d’anciens usages.

Recommandations courantes :

  • FileZilla : le classique universel sur Windows, macOS et Linux ; pratique pour les transferts simples par glisser-déposer. Téléchargez-le depuis le site officiel du projet, pas depuis des miroirs tiers.
  • WinSCP : très apprécié sous Windows, notamment pour SFTP, les scripts, l’automatisation et la synchronisation.
  • Cyberduck : interface claire sur macOS et Windows ; utile pour des transferts occasionnels et certains flux avec stockage en nuage.
  • Transmit : client macOS soigné et rapide, apprécié dans les flux professionnels, mais payant et uniquement macOS.
  • rsync : outil en ligne de commande très robuste pour les sauvegardes, migrations et synchronisations incrémentales.

Dans le support hosting, on rencontre surtout FileZilla, WinSCP et Cyberduck. Pour les migrations plus importantes ou les synchronisations répétées, rsync, scp et sftp en ligne de commande sont souvent plus fiables qu’un transfert manuel.

Les comptes d’hébergement all2all incluent l’accès shell ; au besoin, les fichiers peuvent donc aussi être manipulés directement sur le serveur.

Comment configurer mon client de transfert ?

Utilisez les identifiants reçus lors de l’activation du compte hosting.

Paramètres habituels :

  • nom du serveur : le nom de serveur indiqué pour votre hébergement
  • utilisateur : votre nom d’utilisateur all2all
  • mot de passe : le mot de passe du compte
  • protocole : SFTP recommandé ; SCP pour la ligne de commande ou l’automatisation ; FTP uniquement pour compatibilité ancienne

SFTP et SCP passent par SSH/OpenSSH, généralement sur le port 22. FTP classique passe par le service FTP, souvent ProFTPD, généralement sur le port 21 plus les ports passifs.

Avec FTP, le programme arrive souvent directement dans le répertoire utilisateur. Avec SFTP ou SCP, il peut être nécessaire d’entrer manuellement dans le répertoire d’hébergement, normalement situé sous /var/www/htdocs/username.

Utilisez le nom du serveur plutôt que le nom de domaine si le DNS est encore en propagation ou si le domaine ne pointe pas encore vers le bon serveur.

Les fichiers du site doivent être placés dans public/. Si votre client ouvre le répertoire utilisateur, entrez d’abord dans public/ avant de transférer les fichiers.

Autres méthodes possibles : accès shell, rsync et gestionnaire de fichiers Virtualmin.

Pourquoi ai-je une erreur FTP 530 ou trop de connexions simultanées ?

Cela signifie souvent que le serveur refuse des connexions supplémentaires venant du même client.

Causes fréquentes :

  • trop de transferts parallèles
  • anciennes sessions pas fermées correctement
  • tentatives de reconnexion répétées
  • connexions passives bloquées

Réduisez le nombre maximal de connexions simultanées dans les réglages du programme. Une valeur de 2 ou 3 suffit généralement.

Si le problème persiste, déconnectez-vous complètement, attendez quelques secondes, puis reconnectez-vous. Redémarrer le client peut aussi fermer des sessions restées suspendues.

Pour les erreurs du type 425 unable to build data connection, vérifiez le mode passif, le pare-feu et les connexions bloquées.

Quand c’est possible, utilisez SFTP. Cela évite beaucoup de problèmes classiques liés à FTP.

Comment envoyer par courriel les données d’un formulaire web ?

L’ancien service partagé CGI FormMail n’est plus recommandé.

Les formulaires devraient normalement être gérés par l’application du site elle-même, par exemple avec :

  • un script PHP bien configuré
  • une extension de formulaire WordPress
  • un envoi SMTP authentifié

Le SMTP authentifié, avec une vraie adresse d’expédition du domaine, améliore la délivrabilité et réduit les risques d’abus. Il fonctionne aussi mieux avec SPF, DKIM et DMARC.

Un traitement personnalisé reste possible avec l’accès shell et les environnements de script standards.

Où se trouvent sendmail et Perl ?

Certains anciens scripts demandent encore des chemins système explicites.

Chemins habituels :

  • sendmail : /usr/sbin/sendmail
  • Perl : /usr/bin/perl

Un en-tête Perl typique est :

#!/usr/bin/perl

/usr/sbin/sendmail pointe vers l’agent de transport mail local, généralement via la compatibilité Postfix. Certains anciens logiciels mentionnent aussi /usr/lib/sendmail.

Les applications modernes utilisent plutôt leurs propres bibliothèques mail ou du SMTP authentifié au lieu d’appels directs à sendmail.

Comment régler correctement les permissions de fichiers ?

Les permissions indiquent qui peut lire, écrire ou exécuter un fichier. Elles peuvent être modifiées par SFTP/FTP, via shell avec chmod, ou dans le gestionnaire de fichiers Virtualmin.

Valeurs habituelles :

  • fichiers ordinaires : 644
  • répertoires : 755
  • scripts CGI ou shell exécutables : 755
  • fichiers de configuration sensibles : souvent 600

Utilisez les permissions minimales nécessaires. Évitez 777, qui donne un accès en écriture à tout le monde et crée un risque sérieux.

Ne modifiez pas manuellement les permissions de répertoires système comme cgi-bin/ sans raison technique précise.

Comment configurer Apache avec des fichiers .htaccess ?

Un fichier .htaccess applique des directives Apache dans un répertoire du site.

Usages fréquents :

  • redirections et réécriture d’URL
  • forcer HTTPS
  • protection par mot de passe
  • types MIME
  • comportement des fichiers d’index

Placez le fichier dans public/ ou dans un sous-répertoire. Les règles s’appliquent depuis cet endroit vers les sous-dossiers.

Sur les hébergements all2all actuels, .htaccess est normalement activé par défaut.

Si Apache retourne 500 Internal Server Error après une modification, renommez temporairement le fichier ou annulez la dernière directive. La cause la plus courante est une syntaxe invalide. Vérifiez aussi le journal d’erreurs Apache : il contient souvent la directive, le chemin ou l’erreur de syntaxe précise.

D’autres exemples se trouvent dans la section Documentation. Contactez le support si vous avez besoin d’une règle particulière et n’êtes pas sûr qu’elle soit autorisée.

Comment protéger un répertoire par mot de passe avec Apache ?

L’authentification Apache permet de protéger un répertoire par nom d’utilisateur et mot de passe.

Elle demande généralement :

  • un fichier .htaccess dans le répertoire protégé
  • un fichier de mots de passe contenant les utilisateurs autorisés

Virtualmin propose aussi une interface pour les répertoires protégés. Elle permet de créer le domaine d’authentification, définir les chemins et gérer les utilisateurs sans éditer les fichiers à la main.

Utilisez cette méthode pour des zones privées temporaires, pages de test, téléchargements restreints ou documents internes.

Pour des sites modernes avec comptes utilisateurs, une authentification au niveau de l’application est souvent préférable : utilisateurs WordPress, système de login PHP ou module d’authentification du framework.

Comment accéder aux statistiques du site ?

Les statistiques web sont disponibles via Virtualmin. Selon l’hébergement, Webalizer et AWStats peuvent être disponibles.

Dans de nombreux cas, elles sont aussi accessibles à l’adresse :

  • https://votre-domaine.example/stats/

Une authentification peut être demandée.

Webalizer donne un aperçu compact. AWStats fournit souvent plus de détails, par exemple les navigateurs, robots, téléchargements et comparaisons mensuelles.

Indicateurs utiles :

  • Visits : sessions de visite
  • Pages : pages réellement vues
  • Hits : toutes les requêtes de fichiers, y compris images et scripts
  • Bandwidth : volume de données transféré

Les hits sont souvent beaucoup plus nombreux que les visites, car chaque page charge images, CSS, JavaScript et polices. Les visites et pages reflètent mieux l’activité réelle.

Comment activer le versioning et l’accès shell ?

Les comptes hosting actuels incluent l’accès shell par défaut. Cela permet SSH, SFTP, SCP et la maintenance en ligne de commande.

Pour les déploiements versionnés, Git est l’outil habituel. Subversion (SVN) reste possible lorsque des flux existants en dépendent.

L’accès shell est utile pour :

  • gérer directement les fichiers
  • exécuter des scripts
  • consulter les journaux
  • faire un checkout de dépôt
  • effectuer des tâches de maintenance

Quand c’est utile, créez des utilisateurs dédiés pour des tâches séparées : déploiement, application, maintenance. Cela améliore la traçabilité et limite les modifications accidentelles.

Pour une intégration côté serveur ou un support dépôt, contactez le support avec le domaine, l’outil souhaité et le flux de travail attendu.

Pouvons-nous aider lorsqu’un site web est piraté ?

Oui, mais il faut distinguer la responsabilité serveur de la responsabilité du site. all2all gère la plateforme d’hébergement, le système d’exploitation, le mail et l’infrastructure serveur. Le site web, le CMS, les plugins, les thèmes et les applications installés restent sous la responsabilité du propriétaire du site ou de son webmaster.

La plupart des hébergeurs mutualisés suspendent simplement les sites compromis lorsqu’ils envoient du spam, hébergent du malware, redirigent les visiteurs ou surchargent le serveur. Chez all2all, nous essayons généralement d’aller plus loin : protéger d’abord l’infrastructure, puis aider la personne responsable à comprendre ce qui s’est passé et quelles options existent.

Le déroulement habituel :

  1. détection de spam, phishing, malware, fichiers suspects, redirections, charge élevée ou signalement abuse
  2. mise en mode protégé si nécessaire, par exemple désactivation de scripts vulnérables ou limitation de l’accès web
  3. contact avec le webmaster ou responsable du site
  4. escalade vers l’adresse de contact du site, puis le contact du compte, puis les anciennes adresses de contact si nécessaire
  5. remédiation par le client, son webmaster, un spécialiste tiers, ou par all2all si nous avons de la disponibilité

Le client peut nettoyer le site lui-même. S’il a besoin d’aide, nous pouvons recommander un webmaster ou, si notre planning le permet, établir une estimation pour une intervention all2all. Un nettoyage WordPress compromis prend souvent environ 2 à 3 heures à 60 EUR/heure, selon l’état du site, des plugins, des sauvegardes et des journaux.

Pour les premiers gestes techniques, voir aussi : Mon site WordPress semble piraté ou redirige : que faire ?

Si utile, nous pouvons créer une archive forensic et une première évaluation : fichiers suspects, journaux pertinents, adresses IP impliquées, horaires, redirections, cron jobs ou code injecté. Cela peut servir pour un rapport interne, une assurance ou une déclaration officielle.

Une déclaration formelle n’est généralement pas nécessaire pour une simple défiguration de site ou un site de test compromis sans données personnelles, fraude, extorsion ou impact plus large. Elle devient importante si des données personnelles ont pu être consultées ou modifiées, en cas de fraude, usurpation d’identité, extorsion, phishing contre des tiers ou obligation légale de notifier une fuite de données. En Belgique, certaines violations de données personnelles doivent être notifiées à l’Autorité de protection des données dans les 72 heures. Les incidents de cybersécurité peuvent aussi être signalés via Safeonweb/CCB, et les infractions pénales à la police.

Mon site WordPress semble piraté ou redirige : que faire ?

Contactez d’abord support@all2all.org.

Évitez d’écraser les traces avant de comprendre la situation. Ne réinstallez pas à l’aveugle, ne supprimez pas de fichiers suspects et ne restaurez pas une sauvegarde avant une première évaluation minimale. Nous pouvons aider à faire une évaluation forensic et créer une archive de l’état affecté. Cela peut être utile pour documenter l’incident auprès d’une assurance, en interne ou auprès des autorités.

Signes fréquents : redirections inattendues, administrateurs inconnus, règles .htaccess modifiées, fichiers PHP étranges, cron jobs suspects ou anciens plugins appelant des scripts externes.

Premiers gestes recommandés :

  • contacter le support avec le domaine et une brève description des symptômes
  • conserver l’état actuel jusqu’à la création d’une archive
  • changer les mots de passe administrateur WordPress après l’archive ou quand on vous le conseille
  • nettoyer le site compromis, puis mettre à jour WordPress core, thèmes et plugins
  • supprimer les plugins et thèmes inutilisés
  • vérifier .htaccess, wp-config.php et les fichiers PHP récemment modifiés
  • restaurer une sauvegarde propre si nécessaire

Une déclaration n’est généralement pas nécessaire pour un simple site de test compromis, sans données personnelles, fraude, usurpation ou impact large. Documentez néanmoins ce qui s’est passé et les mesures prises.

Une notification peut devenir nécessaire si des données personnelles ont pu être consultées, copiées ou modifiées. En Belgique, certaines violations de données doivent être notifiées à l’Autorité de protection des données dans les 72 heures : https://www.autoriteprotectiondonnees.be/.

En cas de fraude, extorsion, usurpation d’identité, perte financière ou menace criminelle, contactez la police. Les organisations belges peuvent aussi signaler un incident au Centre pour la Cybersécurité Belgique via https://notif.safeonweb.be/. Les messages de phishing suspects peuvent être transférés à suspect@safeonweb.be ou verdacht@safeonweb.be selon le contexte.

Si le site envoie du spam, héberge du malware ou redirige les visiteurs, nous pouvons désactiver temporairement les scripts concernés pour protéger le serveur et les autres utilisateurs.

Pourquoi mon certificat Let’s Encrypt ne se renouvelle-t-il pas ?

Le renouvellement exige que le domaine pointe vers le bon serveur et que le chemin de validation HTTP soit accessible.

Causes fréquentes :

  • DNS pointant encore vers un autre serveur
  • redirections bloquant /.well-known/acme-challenge/
  • règles .htaccess trop restrictives
  • alias de virtual host manquant, par exemple www
  • un ou plusieurs alias inclus dans le certificat ne sont plus actifs ou ne pointent plus vers le serveur
  • permissions incorrectes
  • ancienne configuration Apache ou Virtualmin

C’est particulièrement important lorsqu’un site possède plusieurs noms de domaine ou alias. Vérifiez que chaque nom inclus dans le certificat est encore actif, renouvelé et résout vers le serveur d’hébergement. Un seul nom hors service peut bloquer tout le renouvellement Let’s Encrypt, même si le domaine principal est correct.

Si l’alias doit rester actif, renouvelez le nom et corrigez son DNS, ou excluez-le de la configuration Let’s Encrypt dans Virtualmin. Si l’alias n’est plus nécessaire, supprimez l’alias domaine via Virtualmin ; il sera alors retiré des futures demandes de certificat.

Si le renouvellement échoue encore, contactez le support avec le domaine et le message d’erreur exact. Nous pouvons vérifier Apache, Virtualmin et le chemin de validation ACME.

Mon site ne fonctionne plus après migration : que vérifier ?

Les problèmes de migration viennent souvent du DNS, des paramètres de base de données, d’une différence de version PHP ou de chemins qui pointent encore vers l’ancien hébergement.

Vérifiez d’abord :

  • le DNS pointe vers le serveur all2all prévu
  • les fichiers du site sont dans public/
  • le nom de base de données, l’utilisateur, le mot de passe et l’hôte sont corrects
  • WordPress wp-config.php pointe vers la nouvelle base de données, avec les bons identifiants, et non vers l’ancienne
  • les anciens chemins absolus ou URL codées en dur ont été adaptés
  • la version PHP est compatible avec l’application
  • .htaccess ne contient pas d’anciennes redirections ou règles de réécriture

Pendant la migration, gardez un accès temporaire disponible, par exemple votresite.all2all.org, jusqu’à ce que les pages, formulaires, médias et zones de connexion aient été testés.

Pourquoi mon espace d’hébergement est-il plein ?

L’espace hosting est souvent rempli par des sauvegardes locales, caches, journaux, médias uploadés, anciennes archives ou copies de migration.

Vérifiez les plus gros répertoires via shell, SFTP ou Virtualmin. Les plugins de sauvegarde WordPress sont une cause fréquente lorsqu’ils stockent des sauvegardes complètes répétées dans le même compte.

Supprimez les archives obsolètes et placez les sauvegardes hors de l’espace hosting quand c’est possible. Si le projet a réellement besoin de plus d’espace, contactez le support pour revoir la formule ou le quota.

Commander