███████████ ██████████ ███████ █████████
▒▒███▒▒▒▒▒███ ▒▒███▒▒▒▒███ ███▒▒▒▒▒███ ███▒▒▒▒▒███
▒███ ▒███ ▒███ ▒▒███ ███ ▒▒███▒███ ▒▒▒
▒██████████ ▒███ ▒███▒███ ▒███▒▒█████████
▒███▒▒▒▒▒███ ▒███ ▒███▒███ ▒███ ▒▒▒▒▒▒▒▒███
▒███ ▒███ ▒███ ███ ▒▒███ ███ ███ ▒███
█████ █████ ██████████ ▒▒▒███████▒ ▒▒█████████
▒▒▒▒▒ ▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒
RDOS, short for Remote Desktop Operating System, is a lightweight Linux appliance built for remote desktop deployments. The goal is straightforward: turn generic PCs, laptops, and mini systems into consistent, locked-down remote desktop endpoints that are easy to deploy, easy to support, and predictable for end users.
The project is aimed at environments that want a simple login-driven thin client experience without carrying around a full general-purpose desktop. RDOS focuses on fast provisioning, sensible defaults, and operational tools that help support staff diagnose issues without exposing unnecessary local functionality.
RDOS was originally forked from Henk's UFTC project. The codebase has since diverged substantially, but the project continues to acknowledge and credit that original foundation.
- Purpose-built thin client UI with a login screen, core tools, and minimal local surface area.
- Admin options are present but hidden behind secret passwords.
- Users can use the "ping" password to ping the remote server including a full trace route. You don't have to guess where the connection goes wrong just let them send you a picture.
- Error messages that make sense and include your own helpdesk info, your users know exactly who to contact and what to say (Written by an experienced sysadmin who also does first line support).
- Disk image that is not machine bound, you can capture it any time and redeploy your config on other machines. Hostnames change automatically based on the wired adapters mac address.
- Optimized RDP defaults, rdp will just work out of the box with optimal quality. If you need to customize this further the option is available.
- Based on the excellent xfreerdp project like most Linux based thinclients
- Xanmod 6.12 Kernel for wide device compatibility
- Docker as the build system making it easy to build your own custom image.
- auto-maintenance command for system updates (Own risk especially on auto update mode, if a bad update releases and you enabled automatic updates you have to manually roll back your machines).
- No remote access ports and minimal packages to reduce the attack surface even if the machine is outdated (The UI can be navigated easily over the phone, VNC is not neccesary. Instead if you need to assist users request remote access within the remote desktop.)
RDOS began as a fork of henk717/uftc.
That project established the original direction for a lightweight remote desktop thin client. RDOS keeps explicit attribution to that work while evolving into a separate codebase with different goals, build flows, and longer-term platform plans.
To succesfully build the image this project must be git cloned with a Linux system, if not the line endings and file permissions may not be correct.
Image building requires docker and can be done inside of WSL2 if desired.
On Windows, line endings are a common source of shell-script failures. This repository includes .gitattributes to enforce LF endings for Linux-consumed files.
If you are approaching this repo as a developer, see docs/building.md for a step by step explanation of what gets built and how to package a basic installer ISO.
To install the full host-side build dependency set for local builds, WSL, or self-hosted runners:
bash ./setup-build-deps.shFrom Windows, you can invoke the same helper through WSL with:
setup-build-deps.cmd./build.shTo build a super basic installer ISO (auto install + power off):
./build-installer-iso.shInstaller ISO dependencies:
# Debian/Ubuntu
sudo apt-get update
sudo apt-get install -y docker.io shellcheck qemu-utils xorriso zstd curl util-linux parted gdisk dosfstools rsync grub-pc-bin grub-efi-amd64-bin grub-common e2fsprogs file
# Fedora
sudo dnf install -y moby-engine ShellCheck qemu-img xorriso zstd curl util-linux parted gdisk dosfstools rsync grub2-pc-modules grub2-efi-x64-modules grub2-tools-extra e2fsprogs fileqemu-img is provided by qemu-utils on Debian/Ubuntu.
This installer ISO boots, writes RDOS to the first non-removable disk that is not the USB boot media, then powers off so you can remove the flash drive.
grub as the bootloader unlocks a few things most importantly uefi support, you also get a separate fat32 boot partition where you can place the config files when provisioning.
The installer ISO uses the bundled efi.img boot image instead of pointing firmware at the raw BOOTX64.EFI loader, which is more reliable in Hyper-V Gen2 and similar UEFI VMs.
Boot partition is a sizable 4GB to reduce the risk of running out of space for the kernels, with a total size of under 16GB this should fit on a 16GB USB stick if you wish to use a USB Stick for customization and capture.
You can build an ISO from your local rdos.vhd using ./build-installer-iso.sh.
The generated rdos-installer.iso is designed to be minimal: it boots directly into unattended install mode, restores RDOS to the first non-removable target disk (excluding the boot USB), and powers off when done.
If you saw a Permission denied error while editing extracted boot files during ISO build, update to the latest build-installer-iso.sh from this repo (that behavior is handled in the current script).
Flash it to USB with Rufus, Ventoy, or your preferred ISO writer, boot the target system from USB, wait for poweroff, then remove the flash drive.
Safety note: this installer is intentionally simple and destructive. It will erase the selected target disk without an interactive confirmation.
References used for this flow:
- Clonezilla Live docs: https://clonezilla.org/live-doc.php
- Clonezilla advanced boot parameters (
ocs_live_run, batch mode): https://clonezilla.org/show-live-doc-content.php?topic=clonezilla-live/doc/99_Misc
Because a full copy of Clonezilla is bundled on the disk you can use this to facilitate PXE deployments over the network using a tempoary private bittorrent server. A full copy of Clonezilla is normally not present on clonezilla made disks, because of this we will need to apply a small workaround to be able to use this option.
- The PXE server should be one of your target machines with the smallest amount of disk space and an identical type of drive.
- This source machine should be correctly installed and configured as desired without disabling dynamic_hostname.
- Every PXE booting machine will be wiped, ensure no machines that are not part of the deployment will PXE boot during this time.
- Install and configure the source machine with RDOS.
- Load CloneZilla from the installation disk using the Start Clonezilla option.
- Enter Shell
- Type the following command : sudo rm /home/partimag && sudo mkdir /home/partimag && sudo mkdir /home/partimag/live
- Type exit to return back to the main screen and choose the Start_Clonezilla option.
- Choose Lite-Server and then choose Start
- Choose netboot or both
- Choose autodetect unless you know this to be incorrect for your network environment.
- Confirm the warning with Y
- Choose Beginner
- Choose massive-deployment
- Choose from-device
- Choose disk-2-mdisks
- Choose the correct source disk of your thinclient (This needs to be identical on the targets)
- Choose bittorrent (This is the fastest and most reliable option, it will help all your thinclients seed to other thin clients during the setup speeding up the process and allowing proper error checking)
After these steps your source thinclient is now a deployment server for the other machines in your network. Ensure that the target thinclients boot from the network. After you are done you can finish yes to the question if all jobs finished to shut down the PXE server.
This image is a direct drive image without an installer, you can directly flash it to the target media.
For flashing on Windows Rufus is compatible and directly compatible with the .vhd format.
On Linux you can use qemu-img convert /location/of.vhd /dev/targetdevice
Because we don't have a mandatory installer you have every possibility available for deployment that you'd like. The recommended method of flashing VHD's directly is using RescueZilla on a Ventoy USB stick, this will allow you to deploy the provided VHD image as well as capture your own.
WiFi can be enabled by placing a suitable wpa_supplicant.conf on the boot partition.
If you are on the running thin client, there is also a built-in WiFi Wizard available from the login screen, the configuration screen, or by entering wifi as the login password.
Wireless association is handled by wpa_supplicant and DHCP/DNS are handled by systemd-networkd and systemd-resolved.
Here is a template (Don't forget to change the country, I put china as the example due to the broadest range):
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=CN
network={
ssid="SSID GOES HERE"
psk="Password goes here"
bgscan="simple:30:-65:15"
}WireGuard tunnel configs can be imported from USB drives through the same USB import flow as the other runtime configs.
Name the tunnel file like wg0.conf and place it on the USB drive root, then use the Import USB Config tool or let the thin client auto-detect it at startup.
WireGuard import is USB-only for now; there is no remote URL configuration path yet.
RDOS now supports a desktop wallpaper with clear precedence:
- Runtime override from the boot partition:
/boot/wallpaper.(png|jpg|jpeg|webp|bmp|xpm) - Per-user override:
~/wallpaper.(png|jpg|jpeg|webp|bmp|xpm) - Built-in fallback baked into the image:
/usr/share/rdos/wallpaper-default.png
The source file for the baked-in default is tcfiles/wallpaper-default.png in this repository.
Replace that file with your own image before building if you want a different default.
Wallpaper rendering uses aspect-preserving fit (feh --bg-max) by default, so the full image stays visible without distortion. Depending on display ratio differences, this may add letterboxing.
If the thinclient is not preconfigured on the boot partition it will automatically open a multi-step first boot wizard. The first boot wizard focuses on the essentials only: connection details, DHCP vs static IPv4, optional WiFi setup, and support information. Sensible defaults are applied automatically for display, timeout, keyboard, and audio settings.
After first boot, use the Settings button on the login screen to open the full settings page. If an admin password is configured, you will get a separate unlock prompt before the panel opens.
Default settings password: rdos
The first-time setup wizard shows this default and lets you replace it during the Support step.
The full settings page breaks options into separate sections for connection, network, device behavior, support settings, and common tools.
The template for this file is as follows (pay attention to the line endings, they need to be linux compatible):
server="server1|server2|server3"
domain=""
param=""
adminpass="rdos"
helpdesk="the helpdesk"
login_timeout="600"
volume="100"
microphone="100"
brightness="50"
screen_timeout="600"
battery_low_threshold="20"
status_overlay_enabled="true"
status_show_datetime="true"
status_show_battery="true"
status_show_wifi="false"
status_show_ip="false"
status_show_wireguard="false"
wireguard_enabled="true"
keylayout=""
exit_type="Shutdown"
config_url=""
network_mode="dhcp"
network_interface=""
static_address=""
static_prefix="24"
static_gateway=""
static_dns=""Static IPv4 notes:
- Set
network_mode="static"to enable static addressing. - Set
network_interfaceto the exact adapter name such aseth0orwlan0. - Set
static_addressandstatic_prefixat minimum.static_gatewayandstatic_dnsare optional.
If a config_url is defined the thinclient will automatically download its config file every time the login screen is shown. As a safety measure the config is only written on a succesful download and the previous working URL is backed up to a seperate file (If your new location is succesful the old URL is overwritten). Should the config become corrupt the backuped up config URL can be used to recover functionality, there are cases where the incorrect URL can become permanent such as migrating your production thinclients to the configuration of your development environment as this sets a working config_url . To help minimize this risk its recommended not to specify a config_url in configurations that are not meant for production (Do not leave it empty as this will disable remote setup, remove the line entirely).
Because of this and the inherent dangers of remote configuration ensure the config file webserver is well secured and the configuration files are well tested before mass deployment. Even though this functionality was exploit tested it is a possible point of failure if a hacker finds a novel bash exploit or overwrites the RDP server with a malicious one.
tc_hostname in the URL is automatically replaced with the hostname of the thinclient to enable per client configuration.
You implement this functionality strictly on your own risk. If left blank this functionality is fully disabled.
RDOS supports existing RDP files if downloaded from a central location, to do this simply put the RDP URL as the server name.
Moonlight is included as a self contained 50mb binary and can be activated by using moonlight as the server address. Moonlight focuses on remotely connecting to a pre-configured single session PC and provides low latency multimedia as well as game controller support. If you are looking to use this thin client for a living room PC or media heavy display moonlight may provide a suitable option. For use with the Sunlight or Apollo server.
Starting at version 1.10 RDOS supports specifying multiple RDP servers (and optionally also citrix if neither uses additional parameters). To set this up use the regular server field and seperate the servers with |
In the release the root account is disabled with two exceptions that do not require a password: auto-maintenance (Own risk), this tool can be used to manually update the system or can be used to enable automatic updates. set-hostname , this tool changes the hostname of the thinclient. If the dynamic_hostname file is present in the user account hostnames will be set according to the macaddress of the wired adapter. (Likewise the thinclient account has no default password)
When self building you can pass a -p parameter to enable the root password.
config : Open the full settings page
settings : Open the full settings page
terminal: Open the terminal
ping (without your admin password in front): Ping the RDP server with a full traceroute, users can change this to any required destination if needed.
ip (without your admin password in front): Shows the devices network information
wifi (without your admin password in front): Opens the WiFi Wizard
The following terms originated with the upstream UFTC project and are retained here for clarity and attribution until this repository adopts its own finalized licensing model.
- I currently don't know which formal license is the best fit, when using this software please respect the following:
- I am not responsible for what happens with your deployment, its designed to be as robust as I could make it. But should unforseen consequences, bugs or updates happen I am not liable as you accept you use and deploy this on your own risk especially if you enabled automatic updates and your company is now offline due to a bad/incompatible debian update.
- The software is free for both personal and business use and may not be resold. Preinstallation on physical hardware is allowed as long as it is made clear that it runs software based on this free repository.
- You have the freedom to make modifications to this software as long as you do not sell them (Henk.Tech does have the right to sell private modified builds). If distributed publically for free the source code must be provided (If it was modified manually list your changes and how to apply them, don't just post the image). For private internal modifications within your deployment this requirement does not apply ( MSP's using it for a customer they manage counts as internal), but if anyone asks what software is running point them to the public repo.
- Please share your success stories in https://github.com/henk717/uftc/discussions/categories/show-and-tell, while I give out the software for free my reward is the satisfaction of knowing that my work made a positive difference in your organization. Of course for security reasons it is fine if you leave the company name out, deployment size will do.
- If I pick a formal license that embodies these terms your repo/deployment is retroactively licensed under the license of this (parent) repo on the condition that the new license is an open source license similar to the above (If not the above freedoms apply for any version prior to the license change).