Base de connaissances

Ce guide explique comment déplacer un site  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:
  • 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 des hébergements & sites sur votre Manager Infomaniak (❓: aide).
2. Cliquez sur le nom de 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. 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 des hébergements & sites sur votre Manager Infomaniak (❓: aide).
2. Cliquez sur le nom de 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.

Préambule

• L'adresse IP du serveur est conservée, ainsi que toutes les données du disque.
• Il n'est pas possible d'annuler ce changement ou de revenir en arrière.
• Passer d'un VPS Cloud à un VPS Lite n'est pas possible.

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 VPS sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au VPS 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, 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 :

1. Cliquez ici afin d'accéder à la gestion des hébergements & sites sur votre Manager Infomaniak (❓: aide).
2. Cliquez sur le nom du 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.
• Contacter 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 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)

Ce guide explique comment bénéficier de nouvelles versions de PHP, MySQL et de nombreux autres paquets en faisant migrer un Serveur Cloud sur une nouvelle infrastructure Infomaniak.

Préambule

• La migration est gratuite et se déroule en 3 étapes:
  1. Infomaniak met à disposition un Serveur Cloud dernière génération ayant les mêmes caractéristiques que l'actuel, au même tarif et même durée d'engagement.
  2. Vous disposez d'un mois pour déplacer vos hébergements sur le nouveau Serveur Cloud mis à disposition (lire ci-dessous).
  3. Lorsque vos hébergements sont déplacés sur le nouveau serveur, résiliez l'ancien Serveur Cloud.
• Les accès FTP et bases de données ne changent pas.
• Seules changent au niveau des hébergements les versions supportées de PHP et MariaDB, ainsi que les adresses IPv4 et IPv6 du serveur.
• Les noms d'hôtes (hostnames) ne changent pas et sont automatiquement mis à jour pour pointer sur les nouvelles adresses IP.
• Lors de cette opération, les statistiques sont réinitialisées.

Procédure de migration

En migrant vos données sur la nouvelle infrastructure Cloud, vous augmentez la performance et la fiabilité de vos sites qui accéderont aux dernières technologies:

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 le bouton bleu dans l'encadré "Faire évoluer votre Serveur Cloud" (ou sur Gérer):
   

Infomaniak ne fournit pas d'accès root sur Serveur Cloud.

En revanche, un accès root est possible sur:

• VPS Cloud / VPS Lite
• Jelastic Cloud
• Public Cloud

Ce guide explique comment modifier la configuration de stockage d'un VPS Cloud / VPS Lite Infomaniak.

Préambule

• Il est nécessaire d'étendre le volume après une augmentation du volume de stockage.
• Les modifications de configuration (CPU/RAM) ou de stockage rendent le service indisponible pendant environ 20 minutes.

Modifier la taille de stockage sur VPS Cloud / VPS Lite

Pour accéder au VPS Cloud / VPS Lite :

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez sur le menu d'action ⋮ à droite de l'objet concerné dans le tableau qui s'affiche.
3. Cliquez sur Modifier l'offre:
   
4. Effectuez les ajustements souhaités parmi les propositions du shop et terminez la procédure en bas: