This guide explains how to increase the storage volume of your Cloud VPS once the change of offer has been made.

Preamble

• By default, the Cloud VPS is provided with two volumes:
  • 1 volume for the operating system of your choice (/dev/vda).
  • 1 volume for storing your data (/dev/vdb), this is the one that will be increased.
• Warning: depending on the installed operating system, the system volume may be named /dev/sda, /dev/sda1 or /dev/vda; the same applies to the data volume /dev/sdb, /dev/sdb2 or /dev/vdb … It is therefore necessary to replace these indications with those corresponding to your situation.

SSH commands to increase the storage volume

If you choose XFS, for example, it is necessary to install the appropriate tools (if they are not already present):

sudo apt install xfsprogs

Then increase the volume with the following SSH commands:

sudo xfs_grow /dev/vdb

And if you choose EXT4:

sudo resize2fs /dev/vdb

Extend the volume after increasing the storage volume

Two scenarios may arise once you have extended the storage volume of your Linux server. Note that no data is deleted when increasing the space via the change of offer of your VPS.

First scenario

In the case where the entire volume is used without partitioning, it is not necessary to perform a resizepart, since there is no partition.

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

Second scenario

In the case of a volume that contains a partition (/dev/vdb1), you must first stop the processes that use this volume, then you must unmount the partition.

sudo umount /dev/vdb1

You must then increase the size of the partition with parted, which has the resizepart command, unlike 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

And the System Volume?

It is not possible to enlarge the size of the system volume.

For Linux, Infomaniak provides 20 Go, sufficient for any Linux distribution.

For Windows, Infomaniak provides 100 GB on the C drive, which is sufficient for Windows. Applications should be installed on the D drive. If you have 50 GB, you can request 100 GB (contact Infomaniak support specifying a time slot for the operation as there will be a few minutes of interruption to expect).

This guide explains how to install and configure systemd on a Cloud Server and presents the main commands that can be used.

Prerequisites

• Follow the installation guide for systemd on Cloud Server.
• Consult the official documentation to learn about all the possibilities offered by systemd.
• The "unit" files must be placed in: ~/.config/systemd/user/ ( /home/clients/absolute-path-id/.config/systemd/user ) (replacing absolute-path-id visible in your Manager) and the permissions must be set to 0644.
• The --user parameter must be specified in each command.

Main commands

Here is a non-exhaustive list of commands that can be used with systemd.

Force systemd to reload the unit files and take into account the changes:

systemctl --user daemon-reload

Activate a service:

systemctl --user enable --now SERVICENAME.service

Check the status of a service:

systemctl --user status SERVICENAME.service

Configuration of Node as a service with systemd

It will be necessary to create a "Unit" file with the ".service" extension, which must be saved in the directory:

~/.config/systemd/user/

It is possible to reuse the example below by replacing the values starting with {} :

[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

Additional actions with a Unit file

systemctl --user daemon-reload

Start the service (if it is already active, nothing happens):

systemctl --user start [Nom du Unit]

Stop the service (if it is not active, nothing happens):

systemctl --user stop [Nom du Unit]

Restart the service (if it is not running, it is started):

systemctl --user restart [Nom du Unit]

Get information about the service; in particular:

• "Active" which indicates whether the service is running and for how long
• "CGroup" shows the process group that the service manages, this allows you to see the active processes, with their arguments and their ID

Under 'CGroup' are any logs (the standard output and error of the process):

systemctl --user status [Nom du Unit]

Enable automatic service startup on server boot; NB: this does not start the service:

systemctl --user enable [Nom du Unit]

Disable automatic service startup on server boot; NB: this does not stop the service:

systemctl --user disable [Nom du Unit]

Configuration with user entries:

[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

This guide explains how to modify the PHP-CLI extension variables that are available by default on Infomaniak Cloud Server.

Modify PHP_CLI variables

To access the PHP extensions of the Cloud Server:

1. Click here to access the management of your Cloud Server on the Infomaniak Manager (need help?).
2. Click directly on the name assigned to the Cloud Server concerned.
3. Click on PHP Extensions in the left sidebar.
4. Click on the action menu ⋮ to the right of PHP-CLI in the displayed table.
5. Click on Configure:
   
6. Modify the following variables: allow_url_fopen, allow_url_include, memory_limit, max_execution_time, short_open_tag, allow_local_infile
7. Click on the blue Save button.

This guide explains how to connect to Elasticsearch after installing it on Magento from an Infomaniak Cloud Server.

Prerequisites

• Have an Infomaniak Cloud Server.
• Install Magento.
• Contact Infomaniak support for the installation of Elasticsearch.

Connection Information

Once connected to your Magento space, you will need to provide the following information to start Elasticsearch:

• Hostname :localhost or 127.0.0.1
• Port :9200
• Prefix :magento2

This guide presents several examples of using Varnish on Infomaniak Cloud Server.

Preamble

• For additional help contact a partner or launch a free call for tenders — also discover the role of the host.
• Become familiar with these other guides regarding the Varnish configuration language (VCL) to control request processing, routing, caching, and several other aspects:
  • VCL Tutorial
  • VCL user guide
  • VCL Reference

Varnish Configuration

After installation, configuring Varnish includes important rules for caching and purging. Be careful not to accidentally allow unwanted IP addresses.

Here is what a basic configuration file might look like with a few common cases and different actions/rules in a single example:

vcl 4.0;
# Configuration du backend par défaut
backend default {
    .host = "127.0.0.80";  # Adresse IP du backend
    .port = "80";           # Port du backend
}
# Définition d'une liste de contrôle d'accès (ACL) pour les IPs autorisées à purger le cache
acl purge {
    "localhost";            # IP locale
    "1.2.3.4";              # IP de votre domicile
    "42.42.42.0"/24;        # Plage d'IP publique de votre entreprise
    ! "42.42.42.7";         # Exclusion d'une IP spécifique (ex : un collègue gênant)
}
# Traitement des requêtes à leur réception par Varnish
sub vcl_recv {
    # Autoriser les requêtes de purge
    if (req.method == "PURGE") {
        # Vérification si l'IP du client est autorisée à purger
        if (!client.ip ~ purge) {  # 'purge' fait référence à l'ACL définie plus haut
            # Retourne une page d'erreur si l'IP n'est pas autorisée
            return (synth(405, "Cette IP n'est pas autorisée à envoyer des requêtes PURGE."));
        }
        # Si l'IP est autorisée, purger le cache pour cette requête
        return (purge);
    }
    # Autoriser la purge de toutes les images via une requête PURGEALL
    if (req.method == "PURGEALL" && req.url == "/images") {
        if (!client.ip ~ purge) {
            return (synth(405, "Cette IP n'est pas autorisée à envoyer des requêtes PURGE."));
        }
        # Invalider tous les objets en cache correspondant à des images
        ban("req.url ~ \.(jpg|png|gif|svg)$");
        return (synth(200, "Images purgées."));
    }
    # Ne pas mettre en cache les pages avec une autorisation (header Authorization)
    if (req.http.Authorization) {
        # Passer la requête directement au backend sans la mettre en cache
        return (pass);
    }
}
# Traitement de la réponse du backend avant de la renvoyer au client
sub vcl_backend_response {
    # Mise en cache des images pour une durée de 1 jour
    if (beresp.http.content-type ~ "image") {
        set beresp.ttl = 1d;
    }
    # Si le backend indique que la réponse ne doit pas être mise en cache, respecter cette consigne
    if (beresp.http.uncacheable) {
        set beresp.uncacheable = true;
    }
}

Purge from the CLI interface

From there, the rules stated in the configuration above work on all requests, so if the configured site is "domain.xyz", you can simply use the CLI tool "curl" and do the following:

# Envoyer une requête PURGE pour purger la page d'accueil de "domain.xyz"
$ curl -X PURGE https://domain.xyz/
# Réponse renvoyée par le serveur Varnish
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged</title>
</head>
<body>
    <h1>Erreur 200 : Purge effectuée</h1>
    <p>La page a été purgée avec succès.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 2</p>
    <hr>
    <p>Serveur de cache Varnish</p>
</body>
</html>

And there, the homepage has been purged. Or to purge another URL, just point the request to the latter:

# Envoyer une requête PURGE pour purger un fichier spécifique à "domain.xyz"
$ curl -X PURGE https://domain.xyz/some_path/some_file.html
# Réponse renvoyée par le serveur Varnish
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged</title>
</head>
<body>
    <h1>Erreur 200 : Purge effectuée</h1>
    <p>Le fichier a été purgé avec succès.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 4</p>
    <hr>
    <p>Serveur de cache Varnish</p>
</body>
</html>

Or, as indicated in the VCL configuration, purge all images:

# Envoyer une requête PURGEALL pour purger toutes les images dans "domain.xyz"
$ curl -X PURGEALL https://domain.xyz/images
# Réponse renvoyée par le serveur Varnish
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged images</title>
</head>
<body>
    <h1>Erreur 200 : Images purgées</h1>
    <p>Toutes les images ont été purgées avec succès.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 32770</p>
    <hr>
    <p>Serveur de cache Varnish</p>
</body>
</html>

Purge from a CMS

It is a bit more difficult to illustrate this case because there are many ways to manage caching from a backend. In the configuration example above, control over the "Uncacheable" header is added, which disables caching. With this option, any CMS could simply set this header on the response to disable caching of this request, for example.

From any PHP code and with the configuration above, you can simply send an HTTP request and use this snippet to perform a PURGE of the cache:

<?php
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']}"
        ]
    ]);
    curl_exec($curl);
    if (curl_getinfo($curl, CURLINFO_HTTP_CODE) == 200) {
        echo "Cache purged!";
    }
    curl_close($curl);
}
?>

This guide provides instructions to synchronize kDrive with a VPS (or vice versa) via the WebDAV protocol found in the rClone application.

✘ UNAVAILABLE‍ with
kSuite free / kSuite Standard
my kSuite / my kSuite+ (ik.me, etik.com, ikmail.com) 

Prerequisites

• Have a VPS.
• Know your kDrive identifier (kDrive ID).

Synchronize kDrive and VPS via rClone

This operation allows you to retrieve in real-time the files and folders from kDrive and to read, create, or modify these files from your VPS while ensuring they are synchronized again on the kDrive server. An rClone mount point can be created with a folder on your VPS to manipulate these kDrive files.

Refer to the rClone documentation if you are looking for information about the available options:

1. Example of rClone command:

   • rclone mount kdrive:/My_kDrive_Folder_Path /home/ubuntu/Target_Folder_Path --vfs-cache-mode full --vfs-cache-max-age 24h --vfs-cache-max-size 10G --cache-dir /home/ubuntu/rclone/cache --daemon --allow-other --dir-cache-time 1h --log-file /home/ubuntu/rclone/rclone.log --log-level INFO

   • The --daemon attribute of this command allows you to run the synchronization as a background task because without it, this sync stops at each VPS disconnection…
2. Example of rClone configuration file:

   • [kdrive]
     type = webdav
     url = https://xx.connect.kdrive.infomaniak.com/xx
     vendor = other
     user = ***
     pass = ***

   • Server address: https://IDkDrive.connect.kdrive.infomaniak.com (see prerequisites above)
   • Username: email address to log in to your Infomaniak account
   • Password: create an application password for this specific use.

This guide concerns the creation of private networks between different Infomaniak hosting offers such as VPS Cloud / VPS Lite, Public Cloud, NAS Synology, etc.

Create a VLAN between VPS

It is not possible to create a private network (VLAN) between VPS Cloud / VPS Lite and other products, such as NAS Synology for example, as they are installed on separate networks.

However, it is possible to create a VLAN between a minimum of 10 VPS Cloud / VPS Lite that belong to you (contact Infomaniak support) however a dedicated private network will not be able to communicate with another.

It is recommended to migrate to the Public Cloud offer to create such private networks between VM.

This guide concerns swap on Managed Cloud Server.

Swap and RAM memory

There can be swap even when RAM usage is low. Indeed, the system can use swap at any time if it deems it useful.

Swap is not a dedicated memory space to be used if there is no free RAM, although this is often its main use.

If you want to know more, there is a "swappiness" parameter that allows you to define how the system will use the swap. The default value is 60 and it cannot be modified.

Infomaniak's infrastructure does not pass virtualization instructions to Cloud VPS / Lite VPS; it is therefore not possible to perform nested virtualization (virtualization that would run within an already virtualized environment) as this causes issues, particularly during live migrations.

However, you can…

• … create a server snapshot (non-automated backup)
• … backup the server on Swiss Backup (automated backup)

This guide explains how to benefit from new versions of PHP, MySQL, and many other packages by migrating a Cloud Server to new Infomaniak infrastructure.

Migration procedure

By migrating your data to the new Cloud infrastructure, you increase the performance and reliability of your sites, which will have access to the latest technologies:

1. Click here to access the management of your product on the Infomaniak Manager (need help?).
2. Click directly on the name assigned to the product concerned.
3. Click the blue button in the box "Upgrade your Cloud Server" (or Manage):
   

The migration is free and takes place in 3 steps:

1. Infomaniak provides a state-of-the-art Cloud Server with the same characteristics as the current one, at the same price and same commitment period.
2. You have one month to move your hosting to the new Cloud Server provided (see below).
3. Once your hosting is moved to the new server, cancel the old Cloud Server.

Regarding step 2...

When moving hosting from one Cloud Server to another:

• FTP access and databases do not change.
• Only the supported versions of PHP and MariaDB, as well as the server's IPv4 and IPv6 addresses, change at the hosting level.
• Hostnames (hostnames) do not change and are automatically updated to point to the new IP addresses.

Infomaniak does not provide root access on Managed Cloud Server.

However, root access is possible on:

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

This guide explains how to modify the configuration of a VPS Cloud / VPS Lite.

Modify storage size on VPS Cloud / VPS Lite

To access the VPS Cloud / VPS Lite:

1. Click here to access the management of your product on the Infomaniak Manager (need help?).
2. Click on the action menu ⋮ to the right of the object concerned in the table that appears.
3. Click on Modify the offer:
   
4. Make the desired adjustments from the shop's proposals and complete the procedure at the bottom:
   
5. It is necessary to extend the volume after an increase in storage volume.

It is not possible to order and obtain more IP addresses on a VPS Cloud / VPS Lite.

The possible alternatives would be to use…

• … a Public Cloud hosting (it is possible to add as many IP addresses as desired),
• … the Newsletter tool according to your needs.

This guide explains how to allow certain incoming and/or outgoing ports in the firewall (firewall or firewall) of a VPS Cloud / VPS Lite server.

Access the management tool

To manage the VPS Cloud / VPS Lite firewall:

1. Click here to access the management of your product on the Infomaniak Manager (need help?).
2. Click directly on the name assigned to the product concerned.
3. Click on Firewall in the left sidebar:
   

Rule to allow ping on VPS Cloud / VPS Lite

To add a rule to the firewall:

1. Click the blue button to Add a rule.
2. Click on Manual selection.
3. Select ICMP:
   
4. Validate at the bottom of the page.

Open the outgoing port 25 globally

The outgoing port 25 (SMTP Mail port) is blocked by default. It is recommended to use an authenticated mail sending solution. To open this port, contact Infomaniak support and justify your request.

Infomaniak does not offer virtual disk encryption on VPS Cloud / VPS Lite but provides a block device that you can format and encrypt if you wish.

This guide helps you diagnose and resolve the error "Your connection is not private" (or NET::ERR_CERT_AUTHORITY_INVALID). This security alert can affect both visitors to a site and its administrators.

Preamble

• This alert is a protection mechanism of your browser. It indicates that a secure connection could not be established with the server for one of the following reasons:
  • The site does not have an SSL/TLS security certificate.
  • The installed certificate is expired or misconfigured.
  • The connection between your device and the server is intercepted or disrupted.
• Warning: On a site showing this error, the data you enter (passwords, card numbers) are not encrypted and can be intercepted by third parties.

Solutions for visitors

If you encounter this error on a site you do not manage, the problem may sometimes come from your own configuration. Here are the points to check:

• Check the time on your device: If your computer or smartphone is not at the correct date/time, the certificate validation will systematically fail.
• Test in private browsing: If the error disappears, clear the cache and cookies of your browser.
• Check your network: Avoid public Wi-Fi networks that may force their own login portals.
• Antivirus and Firewall: Some security software analyze HTTPS connections and can cause false positives.

Solutions for Infomaniak site owners

If you are the site administrator, you must ensure that your SSL certificate is active and valid to cover all of your domain names.

1. Is the SSL certificate installed?

If your site is still in HTTP, you need to generate a certificate (free via Let's Encrypt or paid). Learn about the certificates available at Infomaniak.

Important: If you have added aliases (secondary domain names) to your site after installing SSL, you must update the certificate to include them.

2. Check validity and expiration

At Infomaniak, certificates are renewed automatically, but a technical issue may sometimes occur. To check the status of your certificate:

1. Click here to access the management of your certificates in the Manager (need help?).
2. Check the status and expiration date in the dashboard:
   

3. Force HTTPS and fix the "Mixed Content"

If your certificate is valid but the error persists (or the padlock is not green), it is possible that your site is still loading elements (images, scripts) in HTTP. To fix this, refer to this other guide.