Ce guide apporte des précisions importantes concernant le lancement et l'exécution de scripts en ligne de commande (SSH) sur différents types d'hébergements Infomaniak.

Exécution de scripts via SSH et gestion des ressources

Contrairement aux scripts exécutés via un navigateur web, il n'y a généralement pas de limite de temps (timeout) stricte pour les commandes lancées en SSH. Votre script peut donc théoriquement tourner aussi longtemps que nécessaire.

Temps d'exécution et persistance

Si votre session SSH se ferme (perte de connexion internet ou fermeture du terminal), le script en cours sera immédiatement interrompu.

Pour éviter cela lors de tâches longues, il est recommandé d'exécuter vos scripts en arrière-plan ou dans le cas d'un VPS d'utiliser des outils de multiplexage de terminal (comme screen, tmux ou l'utilitaire nohup). Cela permet au processus de continuer son travail même après votre déconnexion.

Limites de ressources (RAM et CPU)

Si le temps n'est pas limité, les ressources matérielles le sont.

L'exécution de vos scripts reste soumise aux capacités de la machine et à sa configuration :

• Mémoire (RAM) : si un processus consomme plus de mémoire que la limite autorisée (par exemple, la limite memory_limit de PHP ou la RAM physique disponible), il sera tué par le système pour préserver la stabilité du serveur.
• Processeur (CPU) : un usage abusif du processeur sur une longue durée peut entraîner un bridage ou une interruption du processus.

Ce guide explique comment restaurer un snapshot de VPS Cloud Infomaniak.

Restaurer un snapshot

Pour cela:

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné.
3. Cliquez sur Snapshot dans le menu latéral gauche.
4. Cliquez sur le menu d'action ⋮ à droite de l'objet concerné dans le tableau qui s'affiche.
5. Cliquez sur Restaurer:
   
6. Cliquez sur le bouton bleu pour démarrer la restauration du snapshot.
7. Un e-mail est envoyé lorsque le snapshot est restauré.

Restaurer le disque du système d'exploitation

La restauration du volume système comme dans l'exemple ci-dessus est une opération irréversible. Le disque du système d'exploitation sera remplacé par le snapshot et le serveur se retrouvera dans l'état exact de la date de la sauvegarde.

Les données stockées sur le volume des données (vdb) ne sont pas affectées par cette opération.

Restaurer le disque des données (vdb)

Deux modes de restauration de données sont possibles :

1. Mode “Lecture seule”

Si la taille du snapshot diffère de la taille du volume, seul ce mode lecture seule est disponible.

Cette option permet de monter l'image du snapshot de données, ce qui permet d'accéder en lecture seule aux données de la sauvegarde.

À titre d'information, voici des commandes utiles pour exploiter votre sauvegarde :

• Pour accéder au volume de données principal : mount /dev/vdb /mnt/.
• Pour monter le volume des données dans un dossier spécifique "backup" : mount -o nouuid -o ro,norecovery /dev/vdc /backup.

Pour savoir quelle lettre utiliser (/dev/vd?), utilisez la commande lsblk:

2. Mode “Restauration”

La restauration du volume des données est une opération irréversible. Le disque des données (vdb) sera remplacé par le snapshot. À la fin de la restauration, il sera nécessaire de remonter le volume des données afin que votre système d'exploitation rafraichisse le contenu.

La procédure et les commandes suivantes sont uniquement fournies à titre indicatif :

1. Assurez-vous que votre volume de données n'est pas monté :
   * umount /mnt (/mnt ou l'emplacement que vous aviez choisi pour accéder à vos données).
2. Remontez le volume de données :
   * mount /dev/(vdb) /mnt

Pour connaître le nom du volume de données attaché à votre serveur, utilisez la commande lsblk (voir ci-dessus).

Ce guide explique comment initialiser votre VPS Cloud / VPS Lite avec Windows lors d'une première connexion.

Initialisation d'un Serveur Cloud avec Windows

Il faut changer le mot de passe de votre utilisateur Windows avant de pouvoir effectuer une connexion via RDP (Remote Desktop Protocol) à votre serveur, sinon une erreur est retournée (indiquant que le mot de passe doit être changé).

Pour cela il faut se connecter en utilisant la console VNC la toute première fois.

Une fois le mot de passe de l'utilisateur changé (via VNC), il sera possible de se connecter sans souci via RDP. Ce protocole est déjà activé sur les images Windows Infomaniak.

Identifiants de connexion

• Nom d'utilisateur:
  • pour Windows 11 Professionnel = Infomaniak
  • pour Windows 10 Professionnel = Infomaniak
  • pour Windows Server = Administrator
• Mot de passe: celui que vous avez choisi lors de la commande du serveur ; en cas d'oubli, veuillez réinitialiser le serveur.
• Adresse IP: celle indiquée dans le tableau de bord de votre serveur.

Se connecter par RDP…

• … sur Windows: le bureau à distance est une fonctionnalité incluse.
• … sur macOS: installez l'app desktop gratuite Windows App (ex-Microsoft Remote Desktop).
• … sur Linux: installez l'app Remmina.

Ce guide explique comment déplacer un site Web existant au sein d'un Hébergement Web Infomaniak sur un autre hébergement Web Infomaniak.

Préambule

• Il n'y a pas beaucoup de solutions clé-en-main pour déplacer un site Web:
  • De façon générale peu d'hébergeurs proposent l'exportation ou l'importation d'un site complet avec ses bases de données.
  • Cela vient notamment du fait qu'il existe une multitude de façon de construire un site et tout autant de langages plutôt incompatibles entre eux.
• Si toutefois le site à transférer est construit avec WordPress, prenez connaissance de cet autre guide illustrant une solution simplifiée.
• Il est également possible de déplacer un hébergement Web complet (lire plus bas).

Solution manuelle: exemple de transfert de site

Pour le faire manuellement, il est nécessaire de:

• récupérer les données Web ainsi que les bases de données associées,
• republier cela sur un site créé sur l'hébergement Web de destination,
• et si le nom de domaine associé est identique, il faudra que le premier site soit effacé ou renommé.

Pour le reste, voici un exemple de marche à suivre :

1. Commandez l'autre hébergement Web / Serveur Cloud si vous ne l'avez pas encore.
2. Créez un «faux site» sur ce nouvel hébergement (par exemple dev.domain.xyz - lire plus bas).
3. Copiez manuellement vos données en FTP et MySQL (export / import).
4. Adaptez votre site si nécessaire (adresse de la base de données, etc.).
5. Une fois que vous êtes satisfait du «nouveau site», supprimer l'ancien.
6. Changez le nom du nouveau site pour lui donner son vrai nom.

Une alternative consiste, au point 2 ci-dessus, de travailler avec l'alias www. que vous pouvez détacher au préalable de votre site actuel. En effet, l'alias www(.domain.xyz) est souvent installé en tant qu'alias de votre site, et il suffit de le détacher, ce qui permet la création d'un site sur l'autre hébergement avec le nom www.domain.xyz (n'oubliez pas, au point 6, d'ajouter votre alias de type "domain.xyz" sans les www à ce nouveau site).

Déplacements d'hébergements Web entiers

Il existe une façon automatisée de déplacer un hébergement Web Infomaniak vers:

• un Serveur Cloud Infomaniak (si l'hébergement est actuellement mutualisé ou si l'hébergement est déjà sur Serveur Cloud)
• une autre Organisation Infomaniak

Un hébergement Starter ne peut être déplacé mais il peut être converti.

Ce guide vous explique comment désactiver (ou réactiver) l'outil de détection de vulnérabilités, une protection gratuite et complémentaire à l'antivirus qui protège automatiquement les Hébergements Web contre les malware et les failles de sécurité.

Désactiver ou réactiver la détection des vulnérabilités

Afin d'accéder à l'hébergement Web pour désactiver (ou réactiver) le service :

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné.
3. Cliquez sur Sécurité dans le menu latéral gauche.
4. Cliquez sur Scan de vulnérabilité dans le menu latéral gauche.
5. Cliquez sur le bouton à bascule (toggle switch) pour désactiver ou activer le scan:
   

Prenez connaissance de cet autre guide si vous recherchez des informations au sujet de l'annulation d'une correction de sécurité.

Ce guide vous explique comment procéder pour appliquer ou annuler un patch, une mise en quarantaine ou un blocage effectué par l'outil de détection de vulnérabilité, la protection gratuite et complémentaire à l'antivirus qui protège automatiquement les Hébergements Web contre les malware et les failles de sécurité.

Préambule

• Sans action de votre part, l'outil corrige automatiquement les vulnérabilités détectées dans un délai de 7 jours.
• Il est fortement déconseillé d'annuler un patch ou une mise en quarantaine à moins d'être sûr de ce que vous faites.

Appliquer ou annuler une correction

Pour cela:

1. Cliquez ici afin d'accéder à la gestion de votre hébergement sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué à l'hébergement concerné:
   
3. Cliquez sur Sécurité ‍ dans le menu latéral gauche.
4. Cliquez sur Scan de vulnérabilité dans le menu latéral gauche:
   
5. Si rien de particulier n'est affiché, cliquez d'abord sur le bouton pour Voir l'historique.
6. S'il existe un historique d'évènement, cliquez sur le menu d'action ⋮ à droite de la vulnérabilité concernée dans le tableau qui s'affiche.
7. Cliquez sur Annuler la correction.
8. Dans certains cas, d'autres actions sont possibles:
   1. Appliquer le patch : corrige immédiatement la vulnérabilité.
   2. Annuler le patch : annule la correction et rétabli le fichier d'origine vulnérable (non recommandé).
   3. Supprimer le fichier : efface définitivement le malware de votre hébergement (peut affecter le fonctionnement de votre site).
   4. Mettre en quarantaine : isole le fichier vulnérable et vous permet de le restaurer en cas de besoin (peut affecter le fonctionnement de votre site).
   5. Annuler la quarantaine : restaure le fichier isolé à son emplacement initial (non recommandé).
   6. Ajouter une exception : permet d'indiquer à l'outil que le fichier vulnérable est sain ; ce dernier ne sera plus analysé.
   7. Supprimer une exception : supprime l'état Autorisé du fichier ; ce dernier sera à nouveau analysé.

Détail des différents états

1. VULNÉRABLE‍‍ : une vulnérabilité a été détectée dans un fichier ; la colonne chemin d'accès vous indique l'emplacement du fichier.
2. RÉSOLU‍‍ : la vulnérabilité a été corrigée par l'outil.
3. AUTORISÉ‍‍ : le fichier vulnérable a été manuellement autorisé ; ce dernier ne sera plus analysé par l'outil.
4. RÉSOLU‍‍ : une correction manuelle extérieure à l'outil a été apportée au fichier (mise à jour CMS, modification du code source, suppression manuelle du fichier, etc.).
5. CORRECTIF ANNULÉ‍‍‍ : la correction de l'outil a été manuellement annulée ; il est possible de réappliquer le patch.

Ce guide explique comment migrer d'un VPS Lite à un VPS Cloud en conservant toutes ses données et sans ne devoir rien reconfigurer de son installation.

Effectuer une migration de VPS Lite à VPS Cloud

Pour démarrer l'opération, accédez au VPS Lite :

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné.
3. Cliquez sur Faire évoluer mon offre:
   
4. Cliquez sur le bouton Mettre à niveau sur la modale qui s'affiche.
5. Terminez la commande pour faire évoluer votre VPS Lite.
6. Patientez pendant la migration, une interruption de service sera ressentie pendant le processus.

Ce guide explique comment spécifier un fichier qui sera chargé avant même la page voulue ou au début de chaque script PHP exécuté sur votre serveur, inclus comme s'il avait été appelé avec la fonction require(), mais plus globalement en utilisant la directive auto_prepend_file de PHP. 

Préambule

• Pour par exemple déclarer les headers d'un site Web, il est possible de faire un fichier headers.php qui contient des fonctions PHP header() et qui soit prepend au début de chaque fichier PHP…
  • … via un fichier .user.ini (propre à un dossier),
  • … ou via la configuration du site du Manager (global) comme expliqué ci-dessous.

Inclure un fichier globalement depuis le Manager

Pour accéder à la gestion du site Web :

1. Cliquez ici afin d'accéder à la gestion de votre site sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au site concerné:
   
3. Cliquez sur Gérer les paramètres avancés:
   
4. Cliquez sur l'onglet PHP / Apache:
   
5. Complétez la ligne concernée en entrant le chemin du fichier à inclure.
6. Cliquez sur le bouton Enregistrer en bas de page:
   

Après avoir défini cette directive, toutes les pages PHP sur votre serveur incluront automatiquement le fichier spécifié avant d'exécuter leur propre code.

Les headers définis dans un fichier .htaccess ne sont valables que pour le contenu non PHP (donc statique).

Infomaniak utilise php-fpm qui reçoit les différents headers via apache fast_cgi. Dans la RFC de cgi_www le header Strict-Transport-Security ne fait pas partie des headers passés via CGI et la documentation Apache le confirme. Prenez connaissance de cette autre RFC.

Ce guide explique comment personnaliser le ou les créneaux durant lesquels Infomaniak pourra effectuer des maintenances pour faire évoluer vos services (nouvelles fonctionnalités, correctifs, etc.).

Préambule

• Cette fonctionnalité est uniquement disponible pour les:
  • Serveurs Cloud
  • VPS Cloud / VPS Lite
  • Jelastic Cloud
• Sans indication de votre part, les maintenances planifiées sont généralement effectuées par Infomaniak entre 22h et 6h du matin.

Modifier la période de maintenances planifiées

Pour cela:

1. Cliquez ici afin d'accéder au service pour lequel vous souhaitez planifier les maintenances sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné.
3. Cliquez sur Maintenances planifiées dans le menu latéral gauche ou sur la page centrale selon le service concerné (ci-dessous Jelastic):
   
   • Même principe pour un VPS:
     
4. Cliquez sur les boutons pour définir, en bleu, un créneau d'intervention préféré.
5. Validez en cliquant sur le bouton tout en bas:
   

Ce guide détaille la création d'un dépôt GIT aussi bien sur votre Hébergement Web que sur votre Serveur Cloud Infomaniak.

Préambule

• GIT et GITHub sont disponibles par défaut sur les 2 supports susmentionnés.

Création du dépôt GIT

Mise en place, sur le serveur:

• le dépôt GIT est sur /git_depot
• le site se trouve dans le dossier /web/[projet] (dans votre serveur FTP)

Lignes de commande à indiquer:

cd
mkdir git_depot
cd git_depot/
git init --bare [projet].git
cd [projet].git
git update-server-info

Envoi du dépôt local sur le serveur

A faire sur le poste en local:

git init
git remote add origin ssh://user@[xxxxx].ftp.infomaniak.com:/home/clients/[123456789]/git_depot/[projet].git
git status
git add .
git commit -a -m "init"
git push --set-upstream origin master
git push

Clonage du site sur le répertoire du serveur

A faire sur le serveur:

cd
cd web
rm -r [projet]/
git clone /home/clients/[123465789]/git_depot/[projet].git [projet]/

Ce guide explique comment augmenter le volume de stockage de votre VPS Cloud une fois le changement d'offre effectué.

Préambule

• Par défaut, le VPS Cloud est fourni avec deux volumes :
  • 1 volume pour le système d'exploitation de votre choix (/dev/vda).
  • 1 volume pour le stockage de vos données (/dev/vdb), c'est celui-ci qui sera augmenté.
• Attention: selon le système d'exploitation installé, le volume système peut se nommer /dev/sda, /dev/sda1 ou /dev/vda ; idem pour le volume de données /dev/sdb, /dev/sdb2 ou /dev/vdb … Il convient donc de remplacer ces indications par celles correspondant à votre situation.

Commandes SSH pour augmenter le volume de stockage

Si vous choisissez du XFS par exemple, il est nécessaire d'installer les outils appropriés (s'ils ne sont pas déjà présents) :

sudo apt install xfsprogs

Puis d'augmenter le volume avec les commandes SSH suivantes :

sudo xfs_grow /dev/vdb

Et si vous choisissez du EXT4 :

sudo resize2fs /dev/vdb

Étendre le volume après une augmentation du volume de stockage

Deux cas de figures peuvent se présenter une fois que vous avez étendu le volume de stockage de votre serveur sous Linux. Noter qu'aucune donnée n'est supprimée lors de l'augmentation de l'espace via le changement d'offre de votre VPS.

Premier cas de figure

Dans le cas ou tout le volume est utilisé sans partition, il n'est pas nécessaire de faire un resizepart, vu qu'il n'y a pas de partition.

sudo umount /dev/vdb
sudo fsck.ext4 -f /dev/vdb
sudo resize2fs /dev/vdb

Second cas de figure

Dans le cas d'un volume qui contient une partition (/dev/vdb1), il faut commencer par arrêter les processus qui utilise ce volume puis il faut démonter la partition.

sudo umount /dev/vdb1

Il faut ensuite augmenter la taille de la partition avec parted qui dispose de la commande resizepart, ce qui n'est pas le cas de fdisk.

sudo parted /dev/vdb
GNU Parted 3.2
Using /dev/vdb
Welcome to GNU Parted! Type ‘help' to view a list of commands.
(parted) resizepart 1 100%
(parted) quit
sudo fsck.ext4 -f /dev/vdb1
sudo resize2fs /dev/vdb1

Et le volume Système ?

Il n'est pas possible d'agrandir la taille du volume système.

Pour Linux, Infomaniak fournit 20 Go, suffisant pour n'importe quelle distribution Linux. 

Pour Windows, Infomaniak fournit 100 Go sur le disque C, suffisant pour Windows. Les applications doivent être installées sur le lecteur D. Si vous disposez de 50 Go vous pouvez demander 100 Go (contactez le support Infomaniak en précisant un créneau pour l'opération car il y a quelques minutes d'interruption à prévoir).

Ce guide explique comment installer et configurer systemd sur un Serveur Cloud et présente les principales commandes utilisables.

Prérequis

• Suivre le guide d'installation systemd pour Serveur Cloud.
• Consulter la documentation officielle pour prendre connaissance de l'ensemble des possibilités offertes par systemd
• Les fichiers "unit" devront être placés dans : ~/.config/systemd/user/ ( /home/clients/absolute-path-id/.config/systemd/user ) (en remplaçant absolute-path-id visible dans votre Manager) et les permissions doivent être réglées en 0644.
• Le paramètre --user doit être indiqué dans chaque commande.

Principales commandes 

Voici une liste non-exhaustives de commandes utilisables avec systemd.

Forcer systemd à lire à nouveau les unit files et à prendre en compte les modifications:

systemctl --user daemon-reload

Activation d'un service: 

systemctl --user enable --now SERVICENAME.service

Vérification de l'état d'un service:

systemctl --user status SERVICENAME.service

Configuration de Node en tant que service avec systemd

Il sera nécessaire de créer un fichier "Unit" avec l'extension ".service", qu'il faudra enregistrer dans le répertoire:

~/.config/systemd/user/

Il est possible de réutiliser l'exemple ci-après en remplaçant les valeurs commençant par {} :

[Unit]
Description={Le nom du service} # Spécifier ici un nom du service. Celui-ci est obligatoire mais n'a pas d'impact sur le fonctionnement
[Service]
Restart=always
Environment=NODE_VERSION={la version souhaitée} # Spécifier ici la version de Node à utiliser. S'assurer qu'elle soit installée au préalable avec "nvm install {la version souhaitée}"
WorkingDirectory=%h/{repertoire du projet Node} # %h correspond à la racine de l'hébergement
ExecStart=/bin/bash -c "exec $HOME/.nvm/nvm-exec {commande de lancement du script node}" # Cette commande dépend du projet. Par exemple, "npm run start", "npm run serve" ou encore "node server.js" sont courants
[Install]
WantedBy=default.target

Actions supplémentaires avec un fichier Unit

systemctl --user daemon-reload

Démarrer le service (si celui-ci est déjà actif, rien ne se passe):

systemctl --user start [Nom du Unit]

Arrêter le service (si celui-ci n'est pas actif, rien ne se passe):

systemctl --user stop [Nom du Unit]

Redémarrer le service (s'il ne tourne pas, il est lancé):

systemctl --user restart [Nom du Unit]

Obtenir des informations sur le service ; notamment:

• "Active" qui indique si le service tourne et depuis quand
• "CGroup" montre le groupe de processus que gère le service, ça permet de voir les processus actifs, avec leurs arguments et leur ID

En dessous de "CGroup" se trouvent d'éventuels logs (la sortie standard et erreur du processus):

systemctl --user status [Nom du Unit]

Activer le démarrage automatique du service au boot du serveur ; NB: ça ne démarre pas le service:

systemctl --user enable [Nom du Unit]

Désactiver le démarrage automatique du service au boot du serveur ; NB: ça n'arrête pas le service:

systemctl --user disable [Nom du Unit]

Configuration avec les entrées user:

[Unit]
Description="nom service"
[Service]
Restart=always
Environment=NODE_VERSION=16.17
WorkingDirectory=%h/sites/"nom-repertoire-site"/
ExecStart=/bin/bash -c "exec $HOME/.nvm/nvm-exec npm run start"
[Install]
WantedBy=default.target

Ce guide explique comment modifier les variables de l'extension PHP-CLI qui est disponible par défaut sur Serveur Cloud Infomaniak.

Modifier les variables PHP_CLI

Pour accéder aux extensions PHP du Serveur Cloud :

1. Cliquez ici afin d'accéder à la gestion de votre Serveur Cloud sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au Serveur Cloud concerné.
3. Cliquez sur Extensions PHP dans le menu latéral gauche.
4. Cliquez sur le menu d'action ⋮ à droite de PHP-CLI dans le tableau qui s'affiche.
5. Cliquez sur Configurer:
   
6. Modifiez les variables suivantes : allow_url_fopen, allow_url_include, memory_limit, max_execution_time, short_open_tag, allow_local_infile
7. Cliquez sur le bouton bleu Enregistrer.

Ce guide explique comment se connecter à Elasticsearch après l'avoir installé sur Magento depuis un Serveur Cloud Infomaniak.

Prérequis

• Posséder un Serveur Cloud Infomaniak.
• Installer Magento.
• Prendre contact avec le support Infomaniak pour l'installation d'Elasticsearch.

Informations de connexion

Une fois connecté à votre espace Magento, il sera nécessaire d'indiquer les informations suivantes pour démarrer Elasticsearch :

• Hostname :localhost ou 127.0.0.1
• Port :9200
• Préfixe :magento2

Ce guide présente plusieurs exemples d'utilisation de Varnish sur Serveur Cloud Infomaniak.

Préambule

• Consultez ces ressources complémentaires sur le langage de configuration Varnish (VCL) pour maîtriser le traitement des requêtes, le routage et la mise en cache :
  • VCL Tutorial
  • VCL user guide
  • VCL Reference

Configuration de Varnish

Une fois installé, la configuration de Varnish repose sur des règles précises de mise en cache et de purge. Veillez à restreindre l'accès pour éviter que des entités non autorisées puissent vider votre cache.

Voici un exemple de fichier de configuration regroupant les cas d'usage les plus fréquents :

vcl 4.0;

# Default backend configuration
backend default {
    .host = "127.0.0.80";  # Backend IP address
    .port = "80";           # Backend port
}

# Access Control List (ACL) for purge authorization
acl purge {
    "localhost";            # Local access
    "1.2.3.4";              # Trusted home IP
    "42.42.42.0"/24;        # Trusted company range
    ! "42.42.42.7";         # Specific IP exclusion (e.g., problematic user)
}

# Handle incoming requests
sub vcl_recv {
    # Handle PURGE requests
    if (req.method == "PURGE") {
        # Check if client IP is authorized
        if (!client.ip ~ purge) {
            return (synth(405, "IP not authorized for PURGE requests."));
        }
        return (purge);
    }

    # Custom PURGEALL for image directory
    if (req.method == "PURGEALL" && req.url == "/images") {
        if (!client.ip ~ purge) {
            return (synth(405, "IP not authorized for PURGEALL requests."));
        }
        # Invalidate all image-related objects in cache
        ban("req.url ~ \.(jpg|png|gif|svg)$");
        return (synth(200, "Images purged."));
    }

    # Bypass cache for authorized requests (e.g., admin panels)
    if (req.http.Authorization) {
        return (pass);
    }
}

# Handle backend responses before caching
sub vcl_backend_response {
    # Set TTL for images to 1 day
    if (beresp.http.content-type ~ "image") {
        set beresp.ttl = 1d;
    }

    # Respect backend's "uncacheable" instruction
    if (beresp.http.uncacheable) {
        set beresp.uncacheable = true;
    }
}

Purge via l'interface CLI

Dès lors que vos règles sont actives, vous pouvez tester la purge de votre site (ex: "domain.xyz") en utilisant l'outil curl :

# Purge the homepage
$ curl -X PURGE https://domain.xyz/

# Expected Varnish response
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged</title>
</head>
<body>
    <h1>Success 200: Purge completed</h1>
    <p>The page has been successfully purged.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 2</p>
    <hr>
    <p>Varnish Cache Server</p>
</body>
</html>

Pour purger une URL spécifique, modifiez simplement le chemin de la requête :

# Purge a specific file
$ curl -X PURGE https://domain.xyz/some_path/some_file.html

# Expected Varnish response
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged</title>
</head>
<body>
    <h1>Success 200: Purge completed</h1>
    <p>The file has been successfully purged.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 4</p>
    <hr>
    <p>Varnish Cache Server</p>
</body>
</html>

Ou pour déclencher la purge groupée des images définie dans le VCL :

# Execute PURGEALL for images
$ curl -X PURGEALL https://domain.xyz/images

# Expected Varnish response
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged images</title>
</head>
<body>
    <h1>Success 200: Images purged</h1>
    <p>All images have been successfully purged.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 32770</p>
    <hr>
    <p>Varnish Cache Server</p>
</body>
</html>

Purge depuis un CMS (PHP)

La gestion du cache peut aussi se faire dynamiquement via votre backend. Dans la configuration précédente, un contrôle sur l'en-tête Uncacheable a été ajouté. Votre CMS peut envoyer cet en-tête pour forcer Varnish à ne pas stocker une réponse.

Voici comment envoyer une requête de purge programmatique en PHP :

<?php
// Initialize cURL for a specific URL
if ($curl = curl_init("http://127.0.0.1/some_url")) {
    curl_setopt_array($curl, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CUSTOMREQUEST => "PURGE",
        CURLOPT_HTTPHEADER => [
            "Host: {$_SERVER['HTTP_HOST']}" // Match the target host
        ]
    ]);

    curl_exec($curl);
    
    // Check if the purge was successful (HTTP 200)
    if (curl_getinfo($curl, CURLINFO_HTTP_CODE) == 200) {
        echo "Cache purged!";
    }
    curl_close($curl);
}
?>

Ce guide explique comment sauvegarder des données WordPress sur un espace de sauvegarde Swiss Backup, la solution de sauvegarde dans un cloud suisse indépendant.

Préambule

• Si les sauvegardes proposées par Infomaniak ne correspondent pas ou plus à vos besoins en terme de disponibilité ou de sécurité ou site votre site est hébergé ailleurs, vos données pourront être sauvegardées via une connexion S3 Compatible sur les serveurs d'Infomaniak ; vous avez ainsi l'assurance de ne rien perdre.

Installer et configurer l'extension UpdraftPlus

Prérequis

• Posséder un espace Swiss Backup Infomaniak avec un quota d'appareil disponible (minimum 1) pour une sauvegarde iCloud.
• Ajouter 1 appareil de type Cloud pour obtenir les paramètres S3 Compatible.

Ensuite:

1. Ajoutez l'extension WordPress UpdraftPlus qui propose la sauvegarde des données WordPress sur emplacement S3 Compatible.
2. Cliquez sur Réglages puis UpdraftPlus Backups:
   
3. Cliquez sur Settings puis S3-Compatible (Generic):
   
4. Plus bas, renseignez les champs selon les informations propres à votre appareil.
   
5. Voici le type d'informations que vous devez avoir en votre possession et qu'il faut spécifier dans les différents champs pour créer la connexion:
   

Vous pourrez ensuite programmer vos sauvegardes à intervalle régulier.

Télécharger la sauvegarde manuellement

Vos sauvegardes faites via UpdraftPlus - S3 peuvent être récupérées via un client S3 compatible, Cyberduck par exemple.

Restaurer une sauvegarde UpdraftPlus

Prenez connaissance de ce guide officiel en anglais.

Ce guide concerne la création de réseaux privés entre différentes offres d'hébergement Infomaniak comme VPS Cloud / VPS Lite, Public Cloud, NAS Synology, etc.

Créer un VLAN entre VPS

Il n'est pas possible de créer un réseau privé (VLAN) entre VPS Cloud / VPS Lite et d'autres produits, comme NAS Synology par exemple, car ils sont installés sur des réseaux distincts.

Cependant il est possible de créer un VLAN entre minimum 10 VPS Cloud / VPS Lite vous appartenant (contactez le support Infomaniak) cependant un réseau privé dédié ne pourra pas communiquer avec un autre.

Il est recommandé de migrer vers l'offre Public Cloud pour créer de tels réseaux privés entre VM.

Ce guide concerne le swap sur Serveur Cloud.

Swap et mémoire RAM

Il peut y avoir du swap alors que la consommation de RAM est faible. En effet le système peut utiliser le swap à tout moment s'il le juge utile.

Le swap n'est pas un espace mémoire dédié à être utilisé s'il n'y a pas de RAM libre, bien que ce soit souvent son utilisation principale.

Si vous souhaitez en savoir plus, il existe un paramètre "swappiness" qui permet de définir la manière dont le système utilisera le swap. La valeur par défaut est 60 et elle ne peut pas être modifiée.

L'infrastructure Infomaniak ne transmet pas d'instructions de virtualisation aux VPS Cloud / VPS Lite ; il n'est donc pas possible de faire de la virtualisation imbriquée (virtualisation qui s'exécuterait à l'intérieur d'un environnement déjà virtualisé) car cela pose des problèmes notamment lors des migrations en direct.

Vous pouvez néanmoins…

• … créer un instantané (snapshot) du serveur (sauvegarde non automatisée)
• … sauvegarder le serveur sur Swiss Backup (sauvegarde automatisée)