This guide provides important details regarding the launch and execution of command-line scripts (SSH) on various types of Infomaniak hosting.

Executing scripts via SSH and managing resources

Unlike scripts executed via a web browser, there is generally no strict time limit (timeout) for commands launched via SSH. Your script can therefore theoretically run as long as necessary.

Execution time and persistence

If your SSH session closes (loss of internet connection or terminal closure), the running script will be immediately interrupted.

To avoid this during long tasks, it is recommended to run your scripts in the background or, in the case of a VPS, use terminal multiplexing tools (such as screen, tmux, or the nohup utility). This allows the process to continue its work even after you disconnect.

Resource limits (RAM and CPU)

If time is not limited, hardware resources are.

The execution of your scripts remains subject to the capabilities of the machine and its configuration:

• Memory (RAM): if a process consumes more memory than the allowed limit (for example, the memory_limit of PHP or the available physical RAM), it will be killed by the system to preserve the stability of the server.
• Processor (CPU): excessive use of the processor over a long period can result in throttling or interruption of the process.

This guide explains how to restore a snapshot of VPS Cloud Infomaniak.

Restore a snapshot

To do this:

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 Snapshot in the left sidebar menu.
4. Click on the action menu ⋮ to the right of the object concerned in the table that appears.
5. Click on Restore:
   
6. Click on the blue button to start restoring the snapshot.
7. An email is sent when the snapshot is restored.

Restore the operating system disk

Restoring the system volume as in the example above is an irreversible operation. The operating system disk will be replaced by the snapshot and the server will be in the exact state of the backup date.

The data stored on the data volume (vdb) is not affected by this operation.

Restore the data disk (vdb)

Two data restoration modes are possible:

1. “Read-only” mode

If the size of the snapshot differs from the size of the volume, only this read-only mode is available.

This option allows you to mount the data snapshot image, which allows read-only access to the backup data.

For information, here are useful commands to exploit your backup:

• To access the main data volume: mount /dev/vdb /mnt/.
• To mount the data volume in a specific folder "backup": mount -o nouuid -o ro,norecovery /dev/vdc /backup.

To know which letter to use (/dev/vd?), use the command lsblk:

2. “Restore” mode

Restoring the data volume is an irreversible operation. The data disk (vdb) will be replaced by the snapshot. At the end of the restoration, it will be necessary to remount the data volume so that your operating system refreshes the content.

The following procedure and commands are provided for informational purposes only:

1. Make sure your data volume is not mounted:
   * umount /mnt (/mnt or the location you chose to access your data).
2. Remount the data volume:
   * mount /dev/(vdb) /mnt

To find out the name of the data volume attached to your server, use the command lsblk (see above).

This guide explains how to initialize your VPS Cloud / VPS Lite with Windows upon first connection.

Initializing a Cloud Server with Windows

You need to change the password of your Windows user before you can connect via RDP (Remote Desktop Protocol) to your server; otherwise, an error is returned (indicating that the password must be changed).

To do this, you need to connect using the VNC console the very first time.

Once the user password has been changed (via VNC), it will be possible to connect without issue via RDP. This protocol is already enabled on Infomaniak Windows images.

Login credentials

• Username:
  • for Windows 11 Professional = Infomaniak
  • for Windows 10 Professional = Infomaniak
  • for Windows Server = Administrator
• Password: the one you chose when ordering the server; if forgotten, please reset the server.
• IP address: the one indicated in your server's dashboard.

Connect via RDP…

• … on Windows: Remote Desktop is a built-in feature.
• … on macOS: install the free desktop app Windows App (formerly Microsoft Remote Desktop).
• … on Linux: install the app Remmina.

This guide explains how to move an existing website within an Infomaniak Web Hosting service to another Infomaniak Web Hosting service.

Introduction

• There are not many ready-made solutions for moving a website:
  • In general, few hosting providers offer the export or import of an entire website with its databases.
  • This is mainly due to the fact that there are many ways to build a website and just as many languages, which are often incompatible with each other.
• If the website to be transferred is built with WordPress, please refer to this other guide, which illustrates a simplified solution.
• It is also possible to move an entire Web Hosting service (see below).

Manual solution: example of website transfer

To do this manually, it is necessary to:

• retrieve the website data as well as the associated databases,
• republish this on a website created on the destination Web Hosting service,
• and if the associated domain name is the same, the first website must be deleted or renamed.

For the rest, here is an example of the steps to follow:

1. Order the other Web Hosting / Cloud Server if you don't already have it.
2. Create a "dummy website" on this new hosting (for example, dev.domain.xyz - see below).
3. Manually copy your data via FTP and MySQL (export / import).
4. Adapt your site if necessary (database address, etc.).
5. Once you are satisfied with the "new site", delete the old one.
6. Change the name of the new site to give it its actual name.

Alternatively, in step 2 above, you can work with the www. alias which you can detach beforehand from your current site. Indeed, the www alias (.domain.xyz) is often installed as an alias of your site, and you simply need to detach it, which allows you to create a site on the other hosting with the name www.domain.xyz (remember, in step 6, to add your alias of the type "domain.xyz" without the www to this new site).

Moving entire Web Hosting accounts

There is an automated way to move an Infomaniak Web Hosting account to:

• an Infomaniak Cloud Server (if the hosting is currently shared or if the hosting is already on a Cloud Server)
• another Infomaniak Organization

A Starter hosting account cannot be moved but it can be converted.

This guide explains how to disable (or re-enable) the vulnerability detection tool, a free and complementary antivirus protection that automatically protects Web Hostings against malware and security vulnerabilities.

Disable or re-enable vulnerability detection

To access the web hosting to disable (or re-enable) the service:

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 Security in the left sidebar.
4. Click on Vulnerability Scan in the left sidebar.
5. Click on the toggle switch to disable or enable the scan:
   

Refer to this other guide if you are looking for information about canceling a security fix.

This guide explains how to apply or cancel a patch, quarantine, or block implemented by the vulnerability detection tool, the free and complementary protection to the antivirus that automatically protects your Web Hosting against malware and security vulnerabilities.

Introduction

• Without any action on your part, the tool automatically corrects detected vulnerabilities within 7 days.
• It is strongly recommended not to cancel a patch or quarantine unless you are sure of what you are doing.

Apply or cancel a correction

To do this:

1. Click here to access the management of your hosting on the Infomaniak Manager (need help?).
2. Click directly on the name assigned to the hosting in question:
   
3. Click on Security ‍ in the left-hand menu.
4. Click on Vulnerability Scan in the left-hand menu:
   
5. If nothing specific is displayed, first click on the button to View History.
6. If there is an event history, click on the action menu ⋮ to the right of the vulnerability in question in the table that appears.
7. Click on Cancel the fix.
8. In some cases, other actions are possible:
   1. Apply the patch: immediately fixes the vulnerability.
   2. Cancel the patch: cancels the fix and restores the original vulnerable file (not recommended).
   3. Delete the file: permanently removes the malware from your hosting (may affect the operation of your site).
   4. Quarantine: isolates the vulnerable file and allows you to restore it if necessary (may affect the operation of your site).
   5. Cancel quarantine: restores the isolated file to its original location (not recommended).
   6. Add an exception: allows you to indicate to the tool that the vulnerable file is safe; it will no longer be analyzed.
   7. Remove an exception: removes the Allowed status from the file; it will be analyzed again.

Details of the different statuses

1. VULNERABLE: a vulnerability has been detected in a file; the path column indicates the location of the file.
2. RESOLVED: the vulnerability has been fixed by the tool.
3. ALLOWED: the vulnerable file has been manually allowed; it will no longer be analyzed by the tool.
4. RESOLVED: a manual fix outside the tool has been applied to the file (CMS update, source code modification, manual file deletion, etc.).
5. PATCH ROLLBACK‍ : the patch application was manually rolled back; it is possible to reapply the patch.

This guide explains how to migrate from a VPS Lite to a VPS Cloud while preserving all your data and without having to reconfigure your setup.

Introduction

• The server's IP address is retained, as are all data on the disk.
• It is not possible to undo this change or revert to the previous state.
• It is not possible to switch from a Cloud VPS to a Lite VPS.

Migrating from a Lite VPS to a Cloud VPS

To start the process, access your VPS Lite:

1. Click here to access the management interface for your VPS in the Infomaniak Manager (need help?).
2. Click directly on the name assigned to the VPS in question:
   
3. Click on Upgrade my plan:
   
4. Click on the Upgrade button in the pop-up window.
5. Complete the order to upgrade your VPS Lite.
6. Please wait during the migration; there will be a service interruption during the process.

This guide explains how to specify a file that will be loaded before the desired page or at the beginning of each PHP script executed on your server, included as if it had been called with the function require(), but more globally using the PHP directive auto_prepend_file.

Preamble

• For example, to declare the headers of a website, you can create a file headers.php that contains PHP header() functions and that is prepended at the beginning of each PHP file…
  • … via a .user.ini file (specific to a folder),
  • … or via the site configuration in the Manager (global) as explained below.

Include a file globally from the Manager

To access the website management:

1. Click here to access the management of your site on the Infomaniak Manager (need help?).
2. Click directly on the name assigned to the site concerned:
   
3. Click on Manage advanced settings:
   
4. Click on the PHP / Apache tab:
   
5. Complete the relevant line by entering the path of the file to include.
6. Click on the Save button at the bottom of the page:
   

After defining this directive, all PHP pages on your server will automatically include the specified file before executing their own code.

The headers defined in a .htaccess file are only valid for non-PHP (i.e., static) content.

Infomaniak uses php-fpm which receives the different headers via apache fast_cgi. In the RFC of cgi_www the header Strict-Transport-Security is not part of the headers passed via CGI and the Apache documentation confirms this. Refer to this other RFC.

This guide explains how to customize the time slot(s) during which Infomaniak can perform maintenance to update your services (new features, fixes, etc.).

Preamble

• This feature is only available for:
  • Cloud Servers
  • Cloud VPS / Lite VPS
  • Jelastic Cloud
• Without any indication from you, scheduled maintenance is usually performed by Infomaniak between 10 PM and 6 AM.

Modify the scheduled maintenance period

To do this:

1. Click here to access the service for which you want to schedule maintenance on the Infomaniak Manager (need help?).
2. Click directly on the name assigned to the product concerned.
3. Click on Scheduled Maintenance in the left sidebar or on the central page depending on the service concerned (below Jelastic):
   
   • Same principle for a VPS:
     
4. Click the buttons to define, in blue, a preferred intervention slot.
5. Validate by clicking the button at the bottom:
   

This guide details how to create a GIT repository on both your Web Hosting and your Cloud Server with Infomaniak.

Introduction

• GIT and GitHub are available by default on both of the aforementioned platforms.

Creating the GIT repository

Setup on the server:

• The GIT repository is located at /git_depot
• The website is located in the /web/[project] folder (on your FTP server)

Commands to enter:

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

Sending the local repository to the server

To be done on the local machine:

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

Cloning the website to the server directory

To be done on the server:

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

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

Preamble

• By default, the VPS Cloud 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 can occur once you have extended the storage volume of your Linux server. Note that no data is deleted when increasing the space via the offer change of your VPS.

First scenario

In the case where the entire volume is used without partitioning, it is not necessary to do 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, which is not the case with 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 increase 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 modifications:

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

Below '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

• Consult these additional resources on the Varnish Configuration Language (VCL) to master request processing, routing, and caching:
  • VCL Tutorial
  • VCL user guide
  • VCL Reference

Varnish Configuration

Once installed, Varnish configuration is based on precise caching and purging rules. Make sure to restrict access to prevent unauthorized entities from clearing your cache.

Here is an example of a configuration file that includes the most common use cases:

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 the CLI interface

Once your rules are active, you can test the purge of your site (e.g., "domain.xyz") using the curl tool:

# 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>

To purge a specific URL, simply modify the request path:

# 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>

Or to trigger the grouped purge of images defined in the 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 from a CMS (PHP)

Cache management can also be done dynamically via your backend. In the previous configuration, control over the Uncacheable header has been added. Your CMS can send this header to force Varnish not to store a response.

Here is how to send a programmatic purge request in 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);
}
?>

This guide explains how to save WordPress data to a backup space on Swiss Backup, the independent Swiss cloud backup solution.

Preamble

• If the backups offered by Infomaniak do not meet or no longer meet your availability or security needs, or if your site is hosted elsewhere, your data can be backed up via an S3 Compatible connection on Infomaniak's servers; this ensures that you do not lose anything.

Install and configure the UpdraftPlus extension

Prerequisites

• Have a Swiss Backup space from Infomaniak with available device quota (minimum 1) for an iCloud backup.
• Add 1 device of type Cloud to obtain the S3 Compatible parameters.

Next:

1. Add the WordPress extension UpdraftPlus which offers backup of WordPress data to S3 Compatible location.
2. Click on Settings then UpdraftPlus Backups:
   
3. Click on Settings then S3-Compatible (Generic):
   
4. Further down, fill in the fields according to the information specific to your device.
   
5. Here is the type of information you should have in your possession and that you need to specify in the different fields to create the connection:
   

You can then schedule your backups at regular intervals.

Download the backup manually

Your backups made via UpdraftPlus - S3 can be retrieved via an S3 compatible client, Cyberduck for example.

Restore an UpdraftPlus backup

Refer to this official guide in English.

This guide covers 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 recommended to migrate to the Public Cloud offering to create such private networks between VMs.

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)