Linux Server Admin for OVH Dedicated Host
Budget: $10 – $200 AUD
We need an experienced Linux server admin with who knows cloudlinux, cpanel/whm and especially is experienced with using OVH for dedicated servers.
Problem:
The OVH server images do not apply raid redundancy to the /boot/efi partition. This means technically they are vulnerable and not redundant should a drive fail with the primary EFS boot partition on it.
OVH advised this was like this to support all / older servers some would not support booting via raid.
Instead their boot manager will look for LABEL=EFI_SYSPART and boot from the second drives /boot/efi should the first one fail (but you need to keep them in sync on your own)
The problem here though is CloudLinux which is the operating system of choice for web hosts require you to Replace LABEL or UUID with a path to a partition, e.g /dev/nvme0n1p1 to be able to install. see https://cloudlinux.zendesk.com/hc/en-us/articles/360021620699-CloudLinux-7-8-kernel-unable-to-boot-on-UEFI-enabled-soft-raid-1-server
In addition for other operating systems means the boot/efi needs to be kept in sync should anything major inside the primary change... which is another issue.
The Task:
We need an experienced admin to apply and test a few options and scenarios for us so this process is more bulletproof.
Test and document efs on raid 1
1. Test and document making EFS raid 1 and booting from this raid partition directly.
2. Simulate failure of both drives (one at a time and then the other) to ensure server will still boot
3. Test kernel and bootloader updates.
Test and document alternative 1 (not using raid, using direct device path)
1. Test syncing both partitions so the second partition gets any updates applied to the first (set as regular sync)
2. Test and document the process of main drive failing. e.g Booting into OVH rescue mode and editing FSTAB to point to second drive
Test and document alternative 2 (after install editing FSTAB back to use LABEL=EFI_SYSPART - may not work with CL)
1. Test syncing both partitions so the second partition gets any updates applied to the first (set as regular sync)
2. Test and document the process of main drive failing and see if will auto boot from second drive using label
Problem:
The OVH server images do not apply raid redundancy to the /boot/efi partition. This means technically they are vulnerable and not redundant should a drive fail with the primary EFS boot partition on it.
OVH advised this was like this to support all / older servers some would not support booting via raid.
Instead their boot manager will look for LABEL=EFI_SYSPART and boot from the second drives /boot/efi should the first one fail (but you need to keep them in sync on your own)
The problem here though is CloudLinux which is the operating system of choice for web hosts require you to Replace LABEL or UUID with a path to a partition, e.g /dev/nvme0n1p1 to be able to install. see https://cloudlinux.zendesk.com/hc/en-us/articles/360021620699-CloudLinux-7-8-kernel-unable-to-boot-on-UEFI-enabled-soft-raid-1-server
In addition for other operating systems means the boot/efi needs to be kept in sync should anything major inside the primary change... which is another issue.
The Task:
We need an experienced admin to apply and test a few options and scenarios for us so this process is more bulletproof.
Test and document efs on raid 1
1. Test and document making EFS raid 1 and booting from this raid partition directly.
2. Simulate failure of both drives (one at a time and then the other) to ensure server will still boot
3. Test kernel and bootloader updates.
Test and document alternative 1 (not using raid, using direct device path)
1. Test syncing both partitions so the second partition gets any updates applied to the first (set as regular sync)
2. Test and document the process of main drive failing. e.g Booting into OVH rescue mode and editing FSTAB to point to second drive
Test and document alternative 2 (after install editing FSTAB back to use LABEL=EFI_SYSPART - may not work with CL)
1. Test syncing both partitions so the second partition gets any updates applied to the first (set as regular sync)
2. Test and document the process of main drive failing and see if will auto boot from second drive using label