Guides

IPv6 Configuration On Linux

We offer free, fully routed /64 IPv6 per cloud server. We do not support automatic (SLAAC) or dynamic (DHCPv6) IPv6 assignment for the time being. If you use our pre-built images and enable IPv6 during the initial deployment of your cloud server, it will be automatically configured via cloud-init (Linux) or cloudbase-init (Windows). If you install your OS using a custom ISO or enable IPv6 after the server has been created, you will need to configure it manually. You can find necessary details to configure your IPv6 prefix in the Public IPv6 tab under the Network section. Ubuntu 18.04, 20.04 / Debian 10, 11 1. Create a new netplan file for the IPv6 config e.g. /etc/netplan/90-ipv6.yml. Replace 2401:a4a0:2:a3::/64 with your unique IPv6. network: ethernets: eth0: addresses: - 2401:a4a0:2:a3::/64 gateway6: fe80::1 version: 2 1. Enable the new config: sudo netplan apply 2. Confirm IPv6 is configured: ip -6 a Ubuntu 22.04+ / Debian 12+ 1. Create a new netplan file for the IPv6 config e.g. /etc/netplan/90-ipv6.yml. Replace 2401:a4a0:2:a3::/64 with your unique IPv6. network: ethernets: eth0: addresses: - 2401:a4a0:2:a3::/64 routes: - to: default via: fe80::1 version: 2 1. Enable the new config: sudo netplan apply 2. Confirm IPv6 is configured: ip -6 a RHEL (CentOS, AlmaLinux) 7-8 1. Append the IPv6 configuration to the existing configuration file in /etc/sysconfig/network-scripts/ifcfg-eth0 without removing the current settings, as shown below. Replace 2401:a4a0:2:a3::/64 with your assigned unique IPv6 block. IPV6ADDR=2401:a4a0:2:a3::/64 IPV6INIT=yes IPV6_DEFAULTGW=fe80::1%eth0 1. Restart the network service: sudo systemctl restart network 2. Confirm IPv6 is configured: ip -6 a RHEL (CentOS, AlmaLinux) 9 1. Run the following command to add the IPv6 configuration to the interface. Replace 2401:a4a0:2:a3::/64 with your assigned unique IPv6 block. nmcli connection modify eth0 \ ipv6.addresses 2401:a4a0:2:a3::/64 \ ipv6.gateway fe80::1 \ ipv6.method manual \ ipv6.may-fail yes 1. Enable the new configuration: nmcli connection up eth0 2. Confirm IPv6 is configured: ip -6 a

How to Disable Secure Boot

If you need to disable Secure Boot, use the Console in the panel to access your server and initiate a reboot. When the boot screen appears as shown below, press the Esc key to enter the BIOS: The UEFI setting screen will be like this: Enter Device Manager, then enter Secure Boot Configuration: Use arrow keys to move to Attempt Secure Boot option and press Space key to deselect Secure Boot: Back to the main UEFI settings screen and choose Reset to reboot the VM.

How to Configure Reverse DNS

Reverse DNS (rDNS), also known as a PTR record, links an IP address to a domain name, typically a subdomain. This process works in the opposite direction of regular (forward) DNS, where a domain name is connected to an IP address. For example, if you set the reverse DNS for IP 123.123.123.123 to mail.example.com: - When you query the IP address of mail.example.com using a command like DIG, you'll receive the IP 123.123.123.123. - Conversely, performing a reverse DNS lookup on 123.123.123.123 will return mail.example.com. Reverse DNS is often used to verify the source of an email, adding an extra layer of security. Many email servers are configured to reject or flag messages as spam if the sending IP does not have a valid reverse DNS record. How to Configure Reverse DNS To configure the reverse DNS, log in to the Onidel Cloud Control Panel, navigate to the service that has the IP you want to configure and click on Reverse DNS tab: You can view the list of IPs associated with the server that have PTR records configured in the Reverse DNS Records table. To add a new Reverse DNS record or update an existing one, input the IP address concerned and enter the domain and click Add/Update Reverse DNS. Adding a new record will also delete any invalid PTR record has the same domain. When you add or update a record, our system immediately checks if the A Record points to the specified IP address. If the A record is changed after reverse DNS has been set, our system may remove the reverse DNS for that address.

Change Your Preferred Currency

Due to technical limitations, changing the currency after it has been selected is not supported. However, you can create a new team with your preferred currency and updated billing details. Create a new team with new currency Navigate to Team Management > New Team. Fill in team name and description, then untick Use default team's billing information In the Billing Information section, you can choose your desired currency. Click Create Team to finish creating a new team. Make the new team primary team On the Team Management page, find the team you want to set as your default. Click the three dots icon next to it, then select Make Primary Team. From now on, your new primary team will be selected by default when you log in. You can switch teams anytime using the dropdown menu in the top-left corner of the dashboard.

Converting VM IPs to Reserved IPs

Reserved IPs allow you to retain specific IP addresses even after terminating a VM, so you can reassign them to other VMs later. Pricing - IPv4: $3/month (billed hourly) - IPv6: $1/month (billed hourly) How to Convert an Existing IP 1. Navigate to your VM's management page 2. Go to Network → Public Network 3. In the Public Network tab, locate your VM's primary IP 4. Click the conversion button to convert it to a Reserved IP Managing Reserved IPs After conversion, your IP appears in the Reserved IPs section where you can: - Assign it to any VM in your account - Retain it even after terminating the original VM - Reassign it to new or existing VMs as needed Reserved IPs remain in your account until you explicitly release them, ensuring you never lose important IP addresses when managing your infrastructure.

Disable or Change Windows Server Account Lockout

When attempting to connect to your Windows Server via Remote Desktop, you may encounter this security error: "As a security precaution, the user account has been locked out because there were too many logon attempts or password change attempts. Wait a while before trying again, or contact your system administrator or technical support." This occurs when Windows Server's default security policy temporarily locks accounts after multiple failed login attempts, preventing unauthorised access attempts while potentially blocking legitimate users. Understanding Account Lockout Policies Windows Server implements account lockout policies as a security measure against brute-force attacks. The system tracks failed login attempts and temporarily disables accounts that exceed the configured threshold. These policies include: - Account lockout threshold: Number of failed attempts before lockout - Account lockout duration: How long the account remains locked - Reset account lockout counter after: Time before the failed attempt counter resets Solution: Modify Account Lockout Settings Access Local Security Policy 1. Use Onidel Console feature to access to the Windows. 2. Click the Start button or press the Windows key 3. Type secpol.msc or search for Local Security Policy 4. Run the application as Administrator Navigate to Account Lockout Settings 1. In the Local Security Policy window, expand Account Policies in the left panel 2. Select Account Lockout Policy 3. You'll see three configurable settings in the right panel Configure the Settings Option 1: Disable Account Lockout (Less Secure) - Double-click Account lockout threshold - Set the value to 0 (zero) - Click OK to apply - This completely disables account lockouts, allowing unlimited login attempts Option 2: Adjust Lockout Parameters (Recommended) - Account lockout threshold: Set to a reasonable number (e.g., 5-10 attempts) - Account lockout duration: Configure in minutes (e.g., 30 minutes) - Set to 0 for manual unlock only by administrator - Set to a specific value for automatic unlock after that duration - Reset account lockout counter after: Set the time window for counting attempts (e.g., 30 minutes) Apply Changes After modifying the settings: 1. Click OK to save each setting 2. Close the Local Security Policy window 3. Changes take effect immediately - no restart required Security Considerations While disabling or reducing account lockout restrictions improves accessibility, consider these security implications: - Disabling lockouts (threshold = 0) removes protection against brute-force attacks - Short lockout durations may not sufficiently deter automated attacks - High thresholds reduce security but minimise accidental lockouts For production servers, we recommend: - Maintain a threshold of 5-10 attempts - Set lockout duration to 15-30 minutes - Use complex passwords to reduce the likelihood of successful attacks - Consider implementing additional security layers like IP whitelisting or VPN access

Using your own domain with Onidel Object Storage

This guide walks you through configuring a custom domain to serve content from Onidel Object Storage, enabling you to host static websites or serve files using your own domain name instead of the default Onidel storage URLs. Prerequisites Before starting, ensure you have: - An active Onidel Object Storage service. - A registered domain name that you control - Access to your domain's DNS management panel - A Cloudflare account (recommended for SSL and CDN capabilities) Overview Onidel Object Storage supports static website hosting with custom domains through a straightforward configuration process. By creating a specially-named bucket and configuring DNS records, you can serve your content directly from your own domain with full SSL support through Cloudflare's proxy service. Step 1: Create a Domain-Matched Bucket The first requirement is creating a bucket with a name that exactly matches your intended domain. Creating the Bucket Navigate to your Onidel Object Storage dashboard and create a new bucket. The bucket name must precisely match the domain or subdomain you plan to use. Examples: - For example.com, create a bucket named example.com - For cdn.example.com, create a bucket named cdn.example.com - For assets.mysite.io, create a bucket named assets.mysite.io The bucket name must match the full domain including any subdomains. This naming convention is essential for the routing system to correctly map requests to your bucket. Throughout this tutorial, we use a setup based on the domain mydomain.onidel.com.au. Step 2: Configure Bucket Visibility After creating your bucket, you need to modify its access permissions to allow public access for web hosting. Changing Visibility Settings 1. Access your bucket through the Onidel Object Storage dashboard 2. Navigate to the Settings tab for your bucket 3. Locate the Bucket Visibility in Access & Versioning section 4. Change the setting from Private to Public This modification allows anonymous users to read objects in your bucket, which is necessary for serving website content to visitors. Step 3: Enable Static Website Hosting With your bucket configured for public access, the next step is enabling static website hosting functionality. Activating Website Hosting 1. Navigate to the Website tab for you bucket. 2. Enable the static website hosting option 3. Configure the following settings as needed: a. Index Document: Specify your default page (typically index.html) b. Error Document: Define your custom error page (typically 404.html or error.html) 4. Save your configuration Understanding Your Website Endpoint Once static website hosting is enabled, Onidel Object Storage generates a unique website endpoint for your bucket. This endpoint follows a specific format based on your bucket's region: http://<your-domain>.s3-website.<region>.onidel.cloud Make note of this endpoint URL as you'll need it for DNS configuration in the next step. Step 4: Configure DNS Records The final step involves pointing your domain to the Onidel Object Storage endpoint through DNS configuration. Access your domain's DNS management panel (this might be through your domain registrar, Cloudflare, or another DNS provider) and create a CNAME record pointing to the endpoint from step 3. We recommend using Cloudflare to take advantages of automatic SSL/TLS encryption, CDN caching and DDoS protection: Verifying Your Configuration After completing the setup, verify your configuration: 1. DNS Propagation: Wait 5-15 minutes for DNS changes to propagate 2. Test Access: Navigate to your domain in a web browser 3. SSL Verification: If using Cloudflare proxy, verify HTTPS access works Your custom domain is now configured to serve content from Onidel Object Storage. Visitors accessing your domain will receive files directly from your bucket (with SSL encryption through Cloudflare's proxy if using Cloudflare). If you encounter any issues during setup, please open a support ticket through your dashboard and we'll be happy to assist.

How to mount and use Block Storage

Block Storage is currently supported at 4 locations: - Australia (HDD and SSD NVMe) - Singapore (HDD and SSD NVMe) - Netherlands (SSD NVMe) - USA (SSD NVMe) It works as an addon to your existing VPS. You can easily move the storage between VMs in the same region since Block Storage can be attached and detached at any time. Block Storage behaves just like a regular storage device, on Linux it can be partitioned and mounted with a filesystem. In this tutorial we will buy and mount Block Storage to use as storage for Nextcloud data disk. You may have other use case, but the setup itself should be pretty similar. Creating Block Storage 1. Ensure you have an active VM in the desired location. In the Onidel Cloud Panel, go to Compute > Virtual Machine to see a list of your Virtual Machines. 2. Next, navigate to Storage > Block Storage and click on New Block Storage button. 3. Then you will be asked for storage type and location you want the storage to be created in. The storage type selection should depend on your intended workload, in our case HDD storage should work just fine for storing personal files with Nextcloud. Make sure the location is the same as your VM. It can not be changed once the storage is ordered. 4. Next, pick your desired Billing cycle, Storage name and Disk size and click Deploy Now. The name can be changed later and disk size can be increased (but not decreased) on demand. 5. After paying the generated invoice, you should see the service being active in the list of Block Storages. Attaching Block Storage to the VM 1. By clicking into the newly Block Storage, you can select which VM to mount it to. The dropdown should show all VMs you have running in the same location as your storage block. 2. After selecting the VM you want to attach the storage to, click on Save Changes button and Confirm you want to make changes to this service. 3. The VM instance should now be listed alongside your storage in Block Storages list. 4. After going to Compute > Virtual Machine > (select your VM) > Storage > Disks, you should also see the storage now being attached properly from there. Mounting Block Storage inside the VM 1. Firstly, login into your Virtual Machine using SSH. You will need root privileges to perform most of the tasks listed below. 2. Verify the storage was mounted correctly inside the guest OS. root@vm-sg:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sr0 11:0 1 1024M 0 rom sr1 11:1 1 4M 0 rom vda 254:0 0 20G 0 disk ├─vda1 254:1 0 19.9G 0 part / ├─vda14 254:14 0 3M 0 part └─vda15 254:15 0 124M 0 part /boot/efi vdb 254:16 0 1000G 0 disk Your 1TB block storage drive /dev/vdb should be visible at the bottom. 3. Now you can create partition table and first partition on the drive. We will use fdisk for that - to create GPT partition table, use the g command, then create one large partition with n and write changes to the drive with w. Leave defaults where asked. root@vm-sg:~# fdisk /dev/vdb Welcome to fdisk (util-linux 2.41). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Device does not contain a recognized partition table. Created a new DOS (MBR) disklabel with disk identifier 0x77eca7ed. Command (m for help): g Created a new GPT disklabel (GUID: C54D761B-AD48-4C64-93A2-FA5D78F118AD). Command (m for help): n Partition number (1-128, default 1): First sector (2048-2097151966, default 2048): Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-2097151966, default 2097149951): Created a new partition 1 of type 'Linux filesystem' and of size 1000 GiB. Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks. 4. Next, create a filesystem on the one large partition we just created. Here, we create ext4 filesystem using mkfs.ext4, but you can use other one if you want. root@vm-sg:~# mkfs.ext4 /dev/vdb1 mke2fs 1.47.2 (1-Jan-2025) Discarding device blocks: done Creating filesystem with 262143488 4k blocks and 65536000 inodes Filesystem UUID: 201c4e8d-1d35-48d0-aa8b-97dd893a4795 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848 Allocating group tables: done Writing inode tables: done Creating journal (262144 blocks): done Writing superblocks and filesystem accounting information: done 5. Create mount point for created partition (can be arbitrary directory on your system). root@vm-sg:~# mkdir /mnt/nextcloud-data 6. Note down the PARTUUID value of your partition. root@vm-sg:~# lsblk -o PARTUUID /dev/vdb1 PARTUUID 78ddd192-302a-46b1-95a5-94bf16f99a50 7. Add this entry at the end of /etc/fstab file (replace PARTUUID value with the one you got above and mount point if different one was used): PARTUUID=78ddd192-302a-46b1-95a5-94bf16f99a50 /mnt/nextcloud-data ext4 rw,noatime,errors=remount-ro,x-systemd.growfs 0 2 8. To check if everything was done properly, mount all fstab entries with mount -a and verify the filesystem was mounted: root@vm-sg:~# mount -a mount: (hint) your fstab has been modified, but systemd still uses the old version; use 'systemctl daemon-reload' to reload. root@vm-sg:~# systemctl daemon-reload root@vm-sg:~# df -h /dev/vdb1 Filesystem Size Used Avail Use% Mounted on /dev/vdb1 984G 2.1M 934G 1% /mnt/nextcloud-data After the addition to fstab, the filesystem should be remounted automatically on each boot. Nextcloud specific configuration You can skip this section if not interested. By this point, your storage should be configured properly and ready to use! 1. There are several ways of running Nextcloud but probably the easiest way is to go with Docker and docker compose. 2. You can use this docker compose file and replace the mount points so that the app uses your Storage Block as storage for data: ... image: nextcloud restart: always ports: - 8080:80 depends_on: - redis - db volumes: - /mnt/nextcloud-data:/var/www/html/data - config:/var/www/html/config - apps:/var/www/html/apps ... Remember this setup is only for demonstration purposes. In reality, you need to secure your Nextcloud instance - setup strong passwords and use a reverse proxy to communicate over HTTPS. 3. You may need to change permissions on the storage directory to align with the user Nextcloud is running as (id 33), like mentioned here: root@vm-sg:~# chown -Rv 33:33 /mnt/nextcloud-data/ changed ownership of '/mnt/nextcloud-data/lost+found' from user:user to 33:33 changed ownership of '/mnt/nextcloud-data/' from user:user to 33:33 4. After the initial setup, you Nextcloud should be using your Block Storage drive. Upgrading the Block Storage If you ever run out of capacity on your block storage, you can easily upgrade it from Onidel Cloud panel. 1. Go to Storage > Block Storage > (select your Block Storage) > Upgrade. 2. Then increase the size of your drive using the slider and click the Upgrade button. 3. Confirm the change and pay the generated invoice. 4. Now, going back to the SSH console, you will see the drive changed size to 2TB, however the partition is still only 1TB. root@vm-sg:~# lsblk /dev/vdb vdb 254:16 0 2T 0 disk └─vdb1 254:17 0 1000G 0 part /mnt/nextcloud-data 5. The easiest way to resize partition is to use the growpart command as such: root@vm-sg:~# growpart /dev/vdb 1 CHANGED: partition=1 start=2048 old: size=2097149951 end=2097151966 new: size=4194301919 end=4194303966 6. After this, reboot your VM and the x-systemd.growfs hook we specified in fstab earlier should automatically resize the filesystem as well. Then you will see the new size being available. FAQ Can my Storage Block be moved to another location? No, the Storage Blocks are limited only to one location and can only be used in location they were created in. Can a Storage Block be moved to different VM? Yes. You just need to unmount and detach a Storage Block from your VM and attach, then mount it to another one. This is possible as long as all VMs are in the same location. Is it possible to shrink a Storage Block? No, we do not support shrinking a Storage Block due to high risk of data loss. If you need to shrink a storage block, you will need to create a new, smaller one and migrate your data manually there. Can storage type be changed? No, storage type (HDD vs SSD NVMe) can not be changed after the Storage Block is created. You will need to migrate your data manually. What kind of IO performance to expect? Some quick benchmarks I ran in Singapore using ext4 as a filesystem on mounted storage with yabs.sh (fio) to measure the IO performance: NVMe SSD fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vdb1): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 136.29 MB/s (34.0k) | 1.09 GB/s (17.1k) Write | 136.65 MB/s (34.1k) | 1.10 GB/s (17.2k) Total | 272.94 MB/s (68.2k) | 2.20 GB/s (34.4k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 1.04 GB/s (2.0k) | 1.03 GB/s (1.0k) Write | 1.10 GB/s (2.1k) | 1.10 GB/s (1.0k) Total | 2.14 GB/s (4.1k) | 2.13 GB/s (2.0k) HDD fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vdb1): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 40.03 MB/s (10.0k) | 629.06 MB/s (9.8k) Write | 40.13 MB/s (10.0k) | 632.37 MB/s (9.8k) Total | 80.16 MB/s (20.0k) | 1.26 GB/s (19.7k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 922.29 MB/s (1.8k) | 902.43 MB/s (881) Write | 971.29 MB/s (1.8k) | 962.53 MB/s (939) Total | 1.89 GB/s (3.6k) | 1.86 GB/s (1.8k) Do not take those as a guarantees, the actual results may differ based on storage utilization and other factors in a shared environment.

Custom ISOs

Custom ISO images are fully supported on Onidel Cloud. It enables you to perform installation from your own installation media which can be handy for Uniform deployments, Encrypted Drive installations or just deploying an OS that is not available from our templates. Onidel supports Custom ISOs of size up to 10 GB. Installation from Custom ISO Upload ISO image 1. First, obtain a direct HTTP or HTTPS link to your ISO image. Our panel does not support uploading ISO images directly from your PC, so you will need to prepare a link to the ISO image you want to use. Please note services like Google Drive or Dropbox usually do not support sharing direct links. 2. Login into your Onidel Cloud Account, then go to Orchestration > Custom ISOs. 3. Now paste the direct ISO link into the Remote URL field and click the Upload button. 4. After this, the download of your custom ISO image should start. 5. Once it's finished you will see the custom ISO in the list of available ones below. Deploying a new VM with your Custom ISO 1. If you want to provision a new Virtual Machine using the image you just uploaded, go to Compute > Virtual Machine > Deploy New Server, then in the Software part, select the image from the ISO tab. 2. Next, select your desired specifications and adjust all necessary deployment settings and create the VM as usual by clicking the Deploy Now button. 3. After the VM is created, you can click on the View Console button and install your custom ISO manually. Reinstalling an existing VM into your Custom ISO 1. To reinstall an already provisioned Virtual Machine with your Custom image, you need to mount the custom ISO in the Compute > Virtual Machine > (select your VM) > Storage > ISO images. 2. Now, you should see the custom ISO you have uploaded before. Click Attach on the ISO you want to reinstall from. 3. You will now be asked to confirm whether the Virtual Machine can be reboot (to adjust the boot order and make it boot from your ISO automatically). Click check the checkbox and click the Attach ISO button. 4. After this, the VM will reboot into the ISO your just mounted and you can proceed with manual installation using the VM Console. Troubleshooting If your Virtual Machine did not boot into your Custom ISO despite it being mounted properly, check the Boot Mode selection inside Settings tab of your VM and try changing it to match the boot mode that is supported by your custom ISO.

VM Snapshots

Onidel Cloud supports taking, restoring and downloading snapshots of Virtual Machines. Creating Snapshot of a VM 1. Navigate to Compute > Virtual Machine > (select your VM) > Storage > Snapshots. 2. Click on Create Snapshot button, choose a Name and optional Description of the snapshot. 3. Creating a snapshot usually takes a few minutes depending on the size of the drive. You should see Snapshot In Progress status on the VM. During all this time your VM will stay online but you can't perform any actions on it. 4. After this is finished, you should see the snapshot in the list under Storage > Snapshots. From there, you can Restore, Download or Delete the snapshot. Restoring from a Snapshot 1. Navigate to Compute > Virtual Machine > (VM to restore snapshot on) > Storage > Snapshots. 2. Then, click the Restore button of a selected snapshot. 3. Next you will be asked to confirm whether it's okay for a snapshot to be restored there. Keep in mind, restoring a snapshot will overwrite all existing data of the target VM. 4. After confirming, the VM will start being restored. 5. The process should take a few minutes and after this, the VM will boot from disk restored from snapshot. Deploying new VM from a Snapshot You can also use it as base image when creating a new Virtual Machine. Just go to Compute > Virtual Machine > Deploy New Server, then in the Software part, select your snapshot from the Snapshot tab. In most cases, the new VM will get a different IP address and hostname (as set during deployment). Those are automatically managed by cloud-init on all major Linux distributions. All other configuration and data will be recreated from the snapshot. FAQ Price 2 snapshots per account are free. If you need more, please contact us via ticket. Location Snapshots are tied to a specific location, so a snapshot of a VM in one location can only be restored within the same location, either on the same or different Virtual Machine. Target drive size Snapshots can only be restored to a target with equal or larger drive. Restoring snapshot to a Virtual Machine with a smaller disk is not supported. Retention Snapshots are not removed when destroying a VM they were taken from. If you no longer need a snapshot, you need to delete it separately.

How to set up a WireGuard VPN Server

WireGuard is a modern, fast, and secure VPN protocol. In this tutorial, we will set up a private WireGuard VPN Server running on a Virtual Machine in Onidel Cloud. We will configure the server, enable network routing so your clients can access the internet through the VPN, and configure a client device to connect to it. Prerequisites You will need a running VM with your Linux distribution of choice installed. The specs can be very modest as WireGuard will run well on basically any modern hardware. Hardware Our smallest plan with 1 vCPU, 1 GB RAM and 20 GB SSD should be more than enough to follow this tutorial. Network and Traffic More important factor for VPN server may be the traffic allocation - for a personal VPN however you will most likely not use more than a few hundred gigabytes per month. If you plan to share the VPN with your family and friends, you may consider purchasing additional bandwidth or polling with another VM in the same region. Additionally remember that if you want to host a public VPN, you must follow and enforce Onidel's Terms of Service and Acceptable Usage Policy onto the users. Thus, providing public VPN services is generally discouraged. Connectivity The tutorial assumes your server has both IPv4 and IPv6 connectivity. It's recommended to enable IPv6 on the VM either at purchase time or later by going to (Your VM) > Network > Public Network > Enable IPv6. Install Dependencies To run WireGuard, you need to install the WireGuard kernel module and the userspace tools that allow you to generate keys and manage the VPN interface. You will also need iptables to configure traffic routing. Both of those can be installed in different ways depending on your Linux distribution of choice: Debian/Ubuntu $ apt update && apt upgrade $ apt install wireguard iptables CentOS/RHEL/Alma/Rocky $ dnf install -y epel-release elrepo-release $ dnf update $ dnf install kmod-wireguard wireguard-tools iptables-services Set up IP Forwarding Routing internet traffic via your VPS server requires IPv4 and IPv6 to be forwarded by your OS. You can enable it by setting net.ipv4.ip_forward and net.ipv6.conf.all.forwarding parameters in sysctl. $ nano /etc/sysctl.d/99-wireguard.conf net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1 Those rules will now apply after a reboot, but you can also apply them it immediately with sysctl -p command: $ sysctl -p /etc/sysctl.d/99-wireguard.conf Generate server keys WireGuard utilizes a public and private key pair for cryptography. Let's generate the keys for your server. Navigate to the WireGuard directory and set your umask to 077 so that the generated key files are only readable by the root user: $ cd /etc/wireguard $ umask 077 $ wg genkey | tee server_private_key | wg pubkey > server_public_key You can view the contents of these files using cat server_private_key and cat server_public_key. You will need them in the next step. Create the Wireguard Interface Configuration - Note: While this guide assumes your primary network interface is eth0 (the default on Onidel Cloud VMs), yours might be named differently (e.g. ens3 or enp6s18). Verify your interface name using the ip a command: $ ip a 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 0c:1d:e1:cd:56:32 brd ff:ff:ff:ff:ff:ff inet 104.250.118.103/24 brd 104.250.118.255 scope global eth0 valid_lft forever preferred_lft forever ... If your interface is not eth0, make sure to replace eth0 with your actual interface name in the PostUp and PostDown lines below. Next, create the configuration file for the WireGuard interface (wg0): $ nano /etc/wireguard/wg0.conf Add the following configuration. Be sure to replace <SERVER_PRIVATE_KEY> with the contents of your server_private_key file. [Interface] Address = 10.8.8.1/24, fd88::1/64 ListenPort = 51820 PrivateKey = <SERVER_PRIVATE_KEY> PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i %i -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i %i -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE The PostUp and PostDown commands ensure that traffic from the VPN interface (wg0) is masqueraded as it leaves the server's public interface (eth0), granting internet access to connected clients. Start the WireGuard Server Enable the WireGuard service to start automatically on system boot, and then start it: $ systemctl enable wg-quick@wg0 $ systemctl start wg-quick@wg0 Verify that the interface is up and running: $ wg show interface: wg0 public key: SNYVqnhP7qXO7idORIxBg+gtKcEHtExWOkXGYjDmim0= private key: (hidden) listening port: 51820 Configure the Firewall If you want to configure Firewall for your server, remember to add a traffic rule in the Firewall Group to allow UDP connections on WireGuard ListenPort. In this example, we will add two rules - for both IPv4 and IPv6 traffic. Add a Client To connect a client device (like a phone or laptop), you must generate a separate key pair for it and register its public key on the server. This should ideally be done on a trusted/client device so the server does now have the private key of a client. $ wg genkey | tee clientA_private_key | wg pubkey > clientA_public_key You may need to install WireGuard Userspace tools on the trusted device. Some WireGuard clients also let you generate client keys right from the app. Now, edit your server's WireGuard configuration to recognize this client: $ nano /etc/wireguard/wg0.conf Append the client's peer information at the bottom of the file. Replace <CLIENT_PUBLIC_KEY> with the contents of clientA_public_key (or public key generated by the app). [Peer] PublicKey = <CLIENT_PUBLIC_KEY> AllowedIPs = 10.8.8.2/32, fd88::2/128 Restart the WireGuard interface to apply the changes: $ systemctl restart wg-quick@wg0 Create the Client Configuration File Now, construct the configuration file (client.conf) that you will import into the WireGuard app on your client device. Replace the placeholders with your actual generated keys and your VPS's public IP address (or a domain pointing to it). [Interface] PrivateKey = <CLIENT_PRIVATE_KEY> Address = 10.8.8.2/24, fd88::2/64 DNS = 9.9.9.9, 2620:fe::fe, 1.1.1.1, 2606:4700:4700::1111 [Peer] PublicKey = <SERVER_PUBLIC_KEY> Endpoint = <YOUR_VPS_PUBLIC_ADDRESS>:51820 AllowedIPs = 0.0.0.0/0, ::/0 Setting AllowedIPs = 0.0.0.0/0, ::/0 tells the client to route all of its internet traffic (IPv4 and IPv6) through the VPN. Verify the Connection Once you import client.conf into your device's WireGuard application and connect, go back to your server and run: $ wg show interface: wg0 public key: SNYVqnhP7qXO7idORIxBg+gtKcEHtExWOkXGYjDmim0= private key: (hidden) listening port: 51820 peer: zH3EfBN2E+mXZHd8D4vb9pxihVWRHe+7IRtZDBaBuSs= endpoint: [redacted]:38445 allowed ips: 10.8.8.2/32, fd88::2/128 latest handshake: 6 seconds ago transfer: 11.95 KiB received, 27.34 KiB sent On the client you should be able to access websites with both IPv4 and IPv6: Next Steps Congratulations! You have successfully set up a private WireGuard VPN server on Onidel Cloud VM and connected a client securely. Now, you can add more clients to your server assigning each of them a different internal IP address.

Onidel Object Storage Bucket Policies

Bucket Policies are defined in IAM JSON policy schema format rules which define the actions that can be performed on a bucket under defined conditions. You may want to use them to limit the scope of access to the bucket or control which operations can be performed by users of your application. Since Onidel Object Storage is based on CEPH, it has support for Bucket Policies following the CEPH Object Gateway implementation. This tutorial is to showcase how to set up and verify bucket policies. To follow along, you will need to have a bucket created and s3cmd utility set up to access it. We will use the s3cmd utility to manage active bucket policy, however you may use a different tool, or even create one yourself. Creating a Bucket Policy To define a policy, you first need to create a local policy.json file. Below is an example of how it might look like. { "Version": "2012-10-17", "Statement":[ { "Sid": "AllowPublicRead", "Effect": "Allow", "Principal": "*", "Action":[ "s3:GetObject", "s3:ListBucket" ], "Resource":[ "arn:aws:s3:::cat-pictures", "arn:aws:s3:::cat-pictures/*" ] }, { "Sid": "DenyWriteAndDelete", "Effect": "Deny", "Principal": "*", "Action":[ "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::cat-pictures/*" } ] } This policy assumes your bucket is named cat-pictures. It will make the objects Read Only by disallowing PutObject and DeleteObject actions. GetObject and ListBucket are operations that do not modify the contents of bucket, and the policy explicitly allows those. Checking Active Bucket Policy To see what policy is already defined on your bucket, you may use the s3cmd info command. $ s3cmd info s3://cat-pictures s3://cat-pictures/ (bucket): Location: ap-southeast-1 Payer: BucketOwner Ownership: none Versioning:none Expiration rule: none Block Public Access: none Policy: none CORS: none ACL: 54132dec-5121-4932-8f91-3c2cc2cbea28: FULL_CONTROL Currently no policy is applied to the bucket (Policy: none). Applying Policy To apply the policy we defined a few steps above, navigate to the same folder your policy file is in and execute the s3cmd setpolicy command. $ s3cmd setpolicy policy.json s3://cat-pictures s3://cat-pictures/: Policy updated As you can see, the policy got applied successfully. $ s3cmd info s3://cat-pictures s3://cat-pictures/ (bucket): Location: ap-southeast-1 Payer: BucketOwner Ownership: none Versioning:none Expiration rule: none Block Public Access: none Policy: { "Version": "2012-10-17", "Statement":[ { "Sid": "AllowPublicRead", "Effect": "Allow", "Principal": "*", "Action":[ "s3:GetObject", "s3:ListBucket" ], "Resource":[ "arn:aws:s3:::cat-pictures", "arn:aws:s3:::cat-pictures/*" ] }, { "Sid": "DenyWriteAndDelete", "Effect": "Deny", "Principal": "*", "Action":[ "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::cat-pictures/*" } ] } CORS: none ACL: 54132dec-5121-4932-8f91-3c2cc2cbea28: FULL_CONTROL Verification Now, let's see if the policy we defined works in practice. We will try to upload a new object as well as deleting the existing one: $ s3cmd ls s3://cat-pictures 2026-03-14 15:05 20425 s3://cat-pictures/cat1.jpg 2026-03-14 15:05 57982 s3://cat-pictures/cat2.jpg 2026-03-14 15:05 68630 s3://cat-pictures/cat3.webp 2026-03-14 15:05 32602 s3://cat-pictures/cat4.jpg 2026-03-14 15:05 67608 s3://cat-pictures/cat5.jpg $ s3cmd put cat6.jpg s3://cat-pictures upload: 'cat6.jpg' -> 's3://cat-pictures/cat6.jpg' [1 of 1] 38403 of 38403 100% in 0s 39.31 KB/s done ERROR: S3 error: 403 (AccessDenied) $ s3cmd del s3://cat-pictures/cat5.jpg ERROR: S3 error: 403 (AccessDenied) We got AccessDenied error in both cases, which is expected. However the listing of objects was successful. You can also read an object with s3cmd get, as allowed by policy. $ s3cmd get s3://cat-pictures/cat5.jpg download: 's3://cat-pictures/cat5.jpg' -> './cat5.jpg' [1 of 1] 67608 of 67608 100% in 0s 114.29 KB/s done Removing Policy You may delete existing policy by issuing the s3cmd delpolicy command. $ s3cmd delpolicy s3://cat-pictures s3://cat-pictures/: Policy deleted $ s3cmd info s3://cat-pictures s3://cat-pictures/ (bucket): Location: ap-southeast-1 Payer: BucketOwner Ownership: none Versioning:none Expiration rule: none Block Public Access: none Policy: none CORS: none ACL: 54132dec-5121-4932-8f91-3c2cc2cbea28: FULL_CONTROL Now the policy should not apply anymore, we are able to upload a new object to the bucket and delete existing one. $ s3cmd put cat6.jpg s3://cat-pictures upload: 'cat6.jpg' -> 's3://cat-pictures/cat6.jpg' [1 of 1] 38403 of 38403 100% in 1s 37.41 KB/s done $ s3cmd del s3://cat-pictures/cat5.jpg delete: 's3://cat-pictures/cat5.jpg' $ s3cmd ls s3://cat-pictures 2026-03-14 15:05 20425 s3://cat-pictures/cat1.jpg 2026-03-14 15:05 57982 s3://cat-pictures/cat2.jpg 2026-03-14 15:05 68630 s3://cat-pictures/cat3.webp 2026-03-14 15:05 32602 s3://cat-pictures/cat4.jpg 2026-03-14 23:12 38403 s3://cat-pictures/cat6.jpg Additional Notes Do note that CEPH implementation of Bucket Policies is still somewhat limited, you may find that some of your existing policies will not work with Onidel Cloud Object Storage. If you plan to implement more sophisticated policies, you may want to look at policy examples from the AWS docs.

Debian Installation with Preseed

To simplify Debian Installation from an ISO Image on Onidel Cloud, you may use a preseeded config. note: this tutorial will only work for Debian Linux installed from an ISO What is Preseed Preseed is an automation mechanism used by the Debian Installer that allows you to answer installation prompts in advance. It eliminates most of manual steps required by the plan Debian Installer and helps build more reproducible/custom environments. The Preseed file is a plaintext configuration that provides predefined answers to the questions normally asked during installation such as locale, keyboard layout, disk partitioning, network settings, user accounts, and package selection. These answers map directly to the installer's internal debconf database, which is the system responsible for managing configuration questions. This configuration file can be included in the ISO or loaded from an external HTTP server before the installation phase. You can find an up-to-date list of all debconf options available for your Debian release on this dedicated page. What is cloud-init cloud-init is a first-boot initialization system designed to automatically configure a newly installed or provisioned machine when it starts for the first time. While preseed handles the installation phase, cloud-init operates after the system boots, applying runtime configuration to make the system immediately usable. In our case, cloud-init will pull the configuration from Onidel Cloud and automatically configure the networking, SSH keys and root password. You may specify a Startup Script to perform one-time custom after-install configuration of your own (adding users, hardening the system, etc). While cloud-init is not strictly required when installing an OS manually, it helps a lot with initial system configuration. You can also choose to configure everything yourself with using preseed options or post-installation scripts, however this is outside of scope of this tutorial. Example Preseed File Below is an example preseed configuration file. It will stop at the disk partitioning step and ask you to configure disk layout yourself, from there you may choose to perform an installation with LUKS encrypted partition. It is provided as a base and assumes cloud-init will do post-install steps on first boot. Feel free to change and tweak this configuration to your liking. # Preseed file to install Debian from ISO on Onidel Cloud # Verified to work on Debian 13.4 # keyboard and locale settings d-i debian-installer/locale string en_US.UTF-8 d-i keyboard-configuration/xkb-keymap select us # ipv4 network configuration using DHCP on default interface d-i netcfg/disable_autoconfig boolean false d-i netcfg/choose_interface select auto # choosing default worldwide mirror d-i mirror/country string manual d-i mirror/http/hostname string deb.debian.org d-i mirror/http/directory string /debian d-i mirror/http/proxy string # root account configuration d-i passwd/root-login boolean true # this password should be automatically changed by cloud-init on first boot d-i passwd/root-password password temp_root_password d-i passwd/root-password-again password temp_root_password # do not setup additional user (can be done after install) d-i passwd/make-user boolean false # clock and timezone configuration d-i clock-setup/utc boolean true d-i time/zone string UTC d-i clock-setup/ntp boolean true # partitioning step is left to the you - the installer will ask you for desired disk layout # from there, you may choose to encrypt the drive with LUKS2 supplying the temporary password # highly recommended to change the LUKS password afterwards from inside the installed OS # if you wish this step to be automated as well, you may use partman-auto directives in preseed file # enable non-free and contrib repositories d-i apt-setup/non-free-firmware boolean true d-i apt-setup/non-free boolean true d-i apt-setup/contrib boolean true # installation profile: standard, no gui, with SSH server tasksel tasksel/first multiselect standard, ssh-server # installing necessary packages - you may tweak this if needed d-i pkgsel/include string curl wget nano htop sudo cloud-init systemd-resolved d-i pkgsel/upgrade select full-upgrade popularity-contest popularity-contest/participate boolean false # bootloader configuration d-i grub-installer/only_debian boolean true d-i grub-installer/with_other_os boolean true d-i grub-installer/bootdev string default # important when sev-snp is enabled, the OS will only look for bootloader in generic efi directory grub-installer/force-efi-extra-removable boolean true d-i preseed/late_command string \ mkdir -p /target/etc/cloud/cloud.cfg.d; \ echo 'system_info:' > /target/etc/cloud/cloud.cfg.d/99-network-renderer.cfg; \ echo ' network:' >> /target/etc/cloud/cloud.cfg.d/99-network-renderer.cfg; \ echo ' renderers: ["networkd"]' >> /target/etc/cloud/cloud.cfg.d/99-network-renderer.cfg; \ in-target systemctl enable systemd-networkd; \ in-target systemctl enable systemd-resolved; \ in-target ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf; d-i finish-install/reboot_in_progress note Debian Installation Serve the Preseed file The easiest way to get the custom preseed file (preseed.cfg) into a VM with Debian installer is to serve it over the network (HTTP). That requires you to have an IPv4 address with at least one TCP port available. In this example, we used another Onidel server to host the file temporarily using Python's built in http.server module. It has to be launched from the same directory the preseed.cfg file is in: $ python3 -m http.server Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ... If you don't have a way to host the preseed configuration, you may also embed it into the ISO itself, however that is out of scope of this guide. Boot from Debian ISO As explained in a dedicated Custom ISO guide, you need to first upload the Debian ISO into Onidel Cloud to later boot a VM from it. Navigating to Compute > Virtual Machine > (Your VM) > Settings, you should change the Boot Mode to UEFI. This is optional, but highly recommended. UEFI boot mode is required for enabling SEV-SNP later. The custom install is boot mode specific, so if installed on BIOS it has to be manually converted to UEFI and vice-versa. Next, attach the ISO to your VM. The VM should automatically reboot into the ISO image. You can then open the VM console to set necessary preseed parameters and perform the installation. Specify Preseed Source In the console you will see the GRUB bootloader configuration of Debian installer. To modify kernel boot parameters, press the e key. At the end of the line starting with linux add the following special options: auto=true priority=critical preseed/url=http://[static-server-ip]:[port]/preseed.cfg Remember to replace the server IP and port with ones you serve the preseed config from. Then press Ctrl+x or F10 to boot with those custom parameters. Then the installer will start booting. It will first configure the network, then try to pull the preseed file from preseed/url specified. At some point, you should see the request from the VM coming to your HTTP server. This means the preseed was obtained properly. 192.209.63.14 - - [05/Apr/2026 07:38:04] "GET /preseed.cfg HTTP/1.1" 200 - Installation will pause at the Disk Partitioning stage. This one is left up to you. We recommend you set up encrypted root partition using the installer's built-in partman interface. Partition the Drives Additionally, if you want to configure automatic disk unlocking later, it's encouraged to create a separate unencrypted /boot partition for initramfs and kernel. This is the default behavior of Debian installer when Encrypted LVM is selected. After the drive is selected, the installer will start overwriting the virtual disk with random data. This is primarily meant to wipe data remaining on physical drives and not necessary in cloud environments, so you can safely cancel it. Now, you will be asked for drive encryption password and confirmation. And here is how the desired partition layout may look like. You can choose to Write changes to disk and Continue. From now on, the installation should continue uninterrupted until the end. The system will automatically reboot once it's completed. Detach the ISO After the VM is rebooted, you will likely be met with the GRUB bootloader of the installer again. You can now detach the ISO from Onidel Panel and wait for the VM to boot from the drive. Unlock the drive Right now, when going to the Console again, you should be prompted for drive encryption password. After it's provided, your VM should boot and perform necessary cloud-init setup. Once that's done, you will be able to login into the VM and confirm its custom disk layout. $ ssh [email protected] Linux preseeded 6.12.74+deb13+1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.74-2 (2026-03-08) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@preseeded:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sr0 11:0 1 1024M 0 rom sr1 11:1 1 4M 0 rom vda 254:0 0 20G 0 disk ├─vda1 254:1 0 952M 0 part /boot/efi ├─vda2 254:2 0 953M 0 part /boot └─vda3 254:3 0 18.1G 0 part └─vda3_crypt 253:0 0 18.1G 0 crypt ├─debian--vg-root 253:1 0 17.1G 0 lvm / └─debian--vg-swap_1 253:2 0 1008M 0 lvm [SWAP] Next Steps Change LUKS password Since in theory, actions performed in the VNC window are not encrypted end-to-end, you may want to change the LUKS drive encryption password from inside your VM via SSH using luksChangeKey: root@preseeded:~# cryptsetup luksChangeKey /dev/vda3 Remote Unlocking To not have to go into the VNC window each time you reboot the server, you may consider configuring remote unlocking at initramfs stage using either: - SSH (requires manual connection over end to end encrypted SSH tunnel) - Clevis (fully automatic with a trusted remote server)

Networking at Initramfs Stage

Introduction Initramfs (Initial RAM Filesystem) is a small, temporary root filesystem loaded into RAM memory during the early stages of the Linux boot process. It acts as a bridge between bootloader (GRUB/systemd-boot) and your OS. Initramfs provides the kernel with the essential tools needed to find, unlock and mount the root filesystem. It can also temporarily configure basic networking which enables remote unlocking of the Virtual Machine's drive. note: This is an intermediary tutorial, a prerequisite for Remote Root Disk Unlocking with SSH or Clevis. Configuring static IPv4 address Kernel IP parameter Linux kernel takes an IP parameter which was used historically for configuring kernel in network boot environments with NFS. In modern Linux, the kernel itself ignores it, as it's primarily handled at later early user-space boot stages by initramfs. Handling it in user-space has its own benefits, the networking can be configured using DHCP and even communicate with name servers to resolve external domains on the internet. Here is a general look of IP parameter string and all available options: IP="<client-ip>:(srv-ip):<gw-ip>:<mask>:(hostname):<dev>:<autoconf>:(dns0):(dns1):(ntp0)" - client-ip - IPv4 of your client device (here, of your VPS server) - srv-ip - not needed, should be left blank (historically used for NFS server) - gw-ip - IPv4 of the gateway, since most subnets on Onidel are /24, this is usually IP of your server with .1 as last number (however that isn't always the case) - mask - IP netmask, usually 255.255.255.0 - hostname - optional, can be left blank - dev - network interface for initramfs to configure. This will likely match the interface name inside your VM (eth0, ens18, etc.) - autoconf - should be none for static IP configuration - dns0 - optional, IPv4 of primary DNS server - dns1 - optional, IPv4 of secondary DNS server - ntp0 - optional, IPv4 address of a NTP server for time synchronization To pass the IP parameter, you may choose either of those methods listed below. On Debian based distributions both will work. If your distribution is RedHat/Arch based, it most likely uses dracut instead of initramfs-tools. Providing IP string in bootloader instead should work on practically every distribution. In initramfs-tools Create a custom drop-in file in initramfs-tools configuration directory on your system. It should be placed under /etc/initramfs-tools/conf.d/network. IP="185.232.84.76::185.232.84.1:255.255.255.0::ens18:none" Remember to replace the values with the ones matching your IP address and network configuration. Then regenerate initramfs with the following command. $ update-initramfs -u update-initramfs: Generating /boot/initrd.img-6.12.74+deb13+1-amd64 In GRUB bootloader configuration In /etc/default/grub, change the GRUB_CMD_LINUX line to have the ip parameter defined at the end. GRUB_CMDLINE_LINUX="... ip=185.232.84.76::185.232.84.1:255.255.255.0::ens18:none" Remember to replace the values with the ones matching your IP address and network configuration. Then regenerate GRUB with update-grub command. $ update-grub Generating grub configuration file ... Found linux image: /boot/vmlinuz-6.12.74+deb13+1-amd64 Found initrd image: /boot/initrd.img-6.12.74+deb13+1-amd64 Warning: os-prober will not be executed to detect other bootable partitions. Systems on them will not be added to the GRUB boot configuration. Check GRUB_DISABLE_OS_PROBER documentation entry. Adding boot menu entry for UEFI Firmware Settings ... done *Note: this should also work with *other bootloaders as long as the ip parameter is passed to the kernel. Verification If the IP parameter was added correctly, you should be greeted with the following parameter listing displayed after the network is set up with initramfs. Configuring static IPv6 address Due to lack of support of IPv6 in minimal klibc-utils package bundled in initramfs on Debian based distributions, IPv6 configuration is not officially supported at initramfs stage. This poses a significant challenge especially in IPv6-only environments. While getting IPv6 to work in early-userspace is possible, but it must be performed via a custom initramfs hooks. An example of such hook can be found here.

Importing Disk Image

This tutorial explains how to import a disk image into Onidel Cloud. It also explains how to obtain a full root disk image copy of your current cloud instance to be restored into Onidel VM later. The guide is divided into the following sections: 1. Entering a Live/Recovery Environment: Booting your source server without mounting the root drive. 2. Obtaining the Disk Image: Extracting the raw disk image securely over SSH. 3. Importing the Image: Uploading and restoring the image via the Onidel Cloud Panel. If you already have a raw disk image ready to upload, you can skip directly down to the importing section. Entering Live/Rescue Environment To ensure data integrity and avoid corruption, a root disk should never be copied while the operating system is actively using it. When a system is running, files are constantly shifting, logs are being written, and data is sitting in memory caches. Copying an active disk often results in an inconsistent state, causing corrupted databases or unbootable operating systems. Instead, we will boot the server into a temporary "Live" or rescue environment. A live environment runs entirely from memory (RAM) and leaves your actual root drive completely untouched and unmounted. This allows us to safely read the raw disk bit-by-bit and safely extract a pristine, completely frozen-in-time replica of your drive. Method 1: Using Provider's Rescue Mode Many cloud providers offer a Rescue Mode. We can leverage it to boot into live environment and transfer the image of root disk over SSH. In this example, we showcase how to activate the rescue mode of VirtFusion panel, however the steps should be pretty similar for other panels as well. 1. Check and write down the current VM Boot Mode by going to Options > Settings (BIOS in our case). 2. Create a Rescue Session by going to Options > Rescue then clicking on Create Rescue Session. 3. Once activated, your VM should get rebooted to Rescue environment. 4. You will get an email with temporary login details and instructions on how to connect. 5. After logging in over SSH, you should be dropped into a dedicated rescue shell. root@rescue:~# Method 2: Booting GRML Linux via ISO (Live CD) If your cloud provider does not have a dedicated rescue mode, but allows you to upload and boot custom ISO images, Grml is an good lightweight Linux distribution that runs entirely from RAM. We will use it as a rescue environment to perform disk image dump. 1. Mount the ISO: Download the Grml ISO and attach it to your instance's virtual CD-ROM drive via your provider's control panel. 2. Boot from ISO: Force the server to restart and boot from the ISO. You may need to use the cloud provider's VNC/Web console. In there, you will also see the currently active boot method that you should take a note of. 3. Start the SSH Server: Once booted into Grml (username root, no password by default on physical console), set the temporary password, configure the network and start SSH daemon. $ passwd # set a temporary root password $ grml-network # configure network via TUI (netcardconfig) $ systemctl start ssh Obtaining the Disk Image Once your server has successfully booted into your chosen Live/Rescue environment and you have confirmed SSH network access, you can proceed to create the disk image. First, make sure your Live/Rescue environment has lsblk and zstd compression tools installed. root@rescue:~# apt update && apt install zstd util-linux -y Then, using lsblk find the drive containing the root filesystem of your VM (/dev/vda in our case). Then start the transfer process. From your local machine, run the following command to pull the disk image over SSH, compress it on the fly using all CPU cores (-T0), and save it locally. The progress will be indicated by the stderr output of dd command. $ ssh root@<server_ip> "dd if=/dev/vda bs=4M status=progress | zstd -T0 -3 -c" > vm-image.img.zst root@<server_ip>'s password: 26566721536 bytes (27 GB, 25 GiB) copied, 347 s, 76.6 MB/s 6400+0 records in 6400+0 records out 26843545600 bytes (27 GB, 25 GiB) copied, 347.652 s, 77.2 MB/s Be sure to replace <server_ip> with your actual server IP and /dev/vda with the actual root disk identified during the live boot. Importing the Disk Image into Onidel Cloud Onidel Cloud Panel only takes the URL address of the image. You will need to temporarily upload it somewhere. In this example, we have uploaded the compressed disk image onto Onidel Object storage. Since the image will be downloaded over the internet, it is strongly recommended to only serve it over an encrypted HTTPS connection. Imported images follow the same scheme as VM snapshots. After the image is successfully added, you are able to restore existing VMs from it or provision new ones which will use the provided disk image. To import an image, go to Orchestration > Snapshots and then click the Import Image button. You will be asked to provide an URL to the disk image - either raw (.img) or compressed (.zst), the imported name and location where the image should be imported. After you click Import, the downloading process should begin. Once the Import process is complete, the image was be retrieved and stored as a Snapshot within the selected location. In the Snapshots List, imported image will have the OS field set as Imported. Creating a VM from Imported Image Since disk images are imported as snapshots, you can deploy a new VMs selecting the imported snapshot as template in the Software tab. Make sure the Root Disk size is greater or equal the real (uncompressed) size of your imported image. After the VM is provisioned, it should boot from the provided image. If it does not, see the Troubleshooting section below. In most cases you will need to use the VNC console first to perform manual network configuration (changing static IP address, unless DHCP was used previously). Troubleshooting If your VM gets stuck before the bootloader is loaded, it is likely a boot mode incompatibility. Make sure you are booting with the same boot mode your VM expects by changing the Boot Mode option in the VM Settings tab.

Installing MikroTik CHR on a VPS

This tutorial explains how to deploy a MikroTik Cloud Hosted Router (CHR) on an Onidel VPS. What is MikroTik CHR and Why Deploy It? MikroTik Cloud Hosted Router (CHR) is a specialized version of the RouterOS operating system tailored specifically for running in virtual machines. Unlike hardware-bound versions of RouterOS, CHR comes optimized with VirtIO drivers out-of-the-box for high-throughput virtualized networking. Common reasons for deployment of MikroTik CHR in Onidel Cloud environment include: - Building High-Performance VPN Hubs: Create highly configurable WireGuard, IPsec, L2TP, or OpenVPN endpoints to securely link remote home, office, and mobile clients together. - Utilizing Advanced Cloud Routing: Leverage enterprise routing protocols (BGP, OSPF, MPLS) in an inexpensive cloud environment for staging or production setups. - Creating Powerful Firewall and QoS: Use RouterOS's intricate packet filtering, queuing, and traffic shaping features. - Cost-Effectiveness: Obtain enterprise-grade networking features for a fraction of the cost of traditional cloud networking appliances. Prerequisites System Requirements Minimum System Requirements of MikroTik CHR v7: - 1 CPU core - 256 MB RAM (1 GB recommended) - at least 128 MB disk space Any VPS configuration available on Onidel Cloud should be sufficient. Live CD Installing MikroTik CHR requires flashing the virtual drive with a disk image provided by the vendor. This action overwrites the main drive of the VM, so running in a live environment is highly recommended. You may use any Live Linux distribution of your choice or choose the included SystemRescue CD during deployment or VM reinstallation. During VM deployment: On already existing VMs: For convenience, we will be using SSH in later parts of this tutorial and by default SystemRescue comes with firewall enabled. To disable it, interrupt the GRUB boot process by pressing Tab key while first boot option is still selected. This will let you edit the boot parameters, append nofirewall option at the end and press Enter to continue boot. Once the Live environment is booted, you'll need to set a temporary root password used for SSH connection. Then, using SSH client you should be able to connect to your VM providing the previously set temporary password. $ ssh root@<vps-ip> [email protected]'s password: [root@sysrescue ~]# Installation Obtaining the MikroTik CHR image Inside the live environment, we will download and unpack the latest MikroTik RouterOS version. $ ROS_VER=$(wget -qO- https://upgrade.mikrotik.com/routeros/NEWESTa7.stable | cut -d' ' -f1) $ echo $ROS_VER 7.23.1 $ wget "https://download.mikrotik.com/routeros/${ROS_VER}/chr-${ROS_VER}.img.zip" ... 2026-06-28 10:39:00 (56.2 MB/s) - ‘chr-7.23.1.img.zip’ saved [44973097/44973097] $ unzip chr-7.23.1.img.zip Archive: chr-7.23.1.img.zip inflating: chr-7.23.1.img Flashing image onto main drive Once the image is downloaded and ready, we will flash it onto the main drive of the VM using the dd command. Since the MiktoTik CHR image weights only approximately 130MB, this operation should take at most a few seconds to complete. $ dd if=chr-7.23.1.img of=/dev/vda conv=sync status=progress 129679872 bytes (130 MB, 124 MiB) copied, 3 s, 43.2 MB/s 262144+0 records in 262144+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 3.20383 s, 41.9 MB/s By now the partition layout should look as shown below. $ lsblk /dev/vda NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS vda 254:0 0 20G 0 disk ├─vda1 254:1 0 32M 0 part └─vda2 254:2 0 94M 0 part Pre-boot configuration By default, the RouterOS configuration allows for remote access without a password until first-time configuration is performed. This is a serious security risk, especially when the system is accessible from the internet. We will mount the main RouterOS partition and edit initial configuration before booting for the first time. $ mount /dev/vda2 /mnt Now edit the /mnt/rw/autorun.scr file - set the RouterOS login password (<mikrotikpassword>) and disable unnecessary services to limit exposure. /user/set 0 password=<mikrotikpassword> /ip/service/set disabled=yes api,api-ssl,telnet,ftp Then umount the partition and make sure the changes are synchronized. $ umount /mnt $ sync Booting into MikroTik CHR We can now go back to the storage tab of your VM in the Onidel Panel and detach the Live CD image from your VM. This will automatically reboot the VM into RouterOS. When connecting over SSH, you may need to first remove the old host key fingerprint of the temporary live CD environment. Then login as admin using the password set at the pre-boot configuration stage. $ ssh-keygen -R <vps-ip> $ ssh admin@<vps-ip>

Change primary IPv4 address

It is now possible to change the primary IPv4 address of your Onidel Cloud instance and the process is fully automated. Price The IP change has a one time fee associated: - $3 - change to a different, random IPv4 address - $6 - change to an IPv4 address in a specific subnet Preparation In order to minimize downtime caused by IP change, we will have the VM Console opened beforehand. This allows to quickly modify and apply the static IPv4 configuration once IP gets switched. To open the console, find your VM instance in the panel and click View Console / Console Access button. There, log in as root and open relevant network configuration file in nano (or other text editor). In our default templates, the network configuration is managed by netplan and generated automatically using cloud-init. The path is /etc/netplan/50-cloud-init.yaml. Changing IPv4 address The IP can be changed by going to your instance's Network tab and clicking the Change IP button next to primary IPv4 listed. The modal should open and ask whether you wish to change the IP to a random one, or pick a subnet yourself. In this guide, we will choose a specific subnet. You can also see current availability of IP addresses in each of listed prefixes. Once you click Submit, a new invoice will be generated. After it is paid, the IP address should be changed within a few seconds. Applying the new network configuration Now, going back to the VM Console with network configuration opened, you should edit and apply the static IPv4 network configuration of your Operating System. Change the IPv4 address and gateway to the new ones, visible in Onidel Panel under your VM's Network tab. After this, save the configuration file and exit nano (Ctrl+S, Ctrl+X). Lastly, apply new network configuration using issuing the netplan apply command. Once this is done, your VM should have the new IPv4 address assigned and working. Final / Troubleshooting steps Usual steps to perform after the IP change: - Ensure all the software is configured to use the new IP of your VM (applies to services running inside the VM as well as external CDNs like Cloudflare). - Use the new IP address to SSH into the VM and trust SSH fingerprint (the fingerprint and host keys should remain unchanged). - Modify DNS records if necessary.