Except this time I hit the wrong key and wiped the message before sending.

I’d been adding to that draft over the course of the morning. I knew some of what was in it, but not all of it. I retyped what I could remember and submitted that, but I had a nagging feeling I’d lost something. So I asked a Cursor agent in the same repo to try to recover the original.

What followed was a pretty good piece of detective work through Cursor’s internals.

The search

The agent started with the obvious places. It scanned the agent transcript .jsonl files and the submitted chat bubble history. It found the re-typed version I’d submitted from memory - but not the original draft.

Next it went looking in Cursor’s SQLite databases on disk. macOS stores Cursor’s app data under ~/Library/Application Support/Cursor/. There are several:

• Session Storage/000003.log - empty, not useful
• Local Storage/leveldb/000003.log - only DevTools and PDF viewer state
• User/globalStorage/state.vscdb - this is the main one; it stores submitted chat bubbles under keys like bubbleId:<composerId>:<bubbleId>
• User/workspaceStorage/<workspaceId>/state.vscdb - workspace-scoped state

The submitted bubbles were all there in globalStorage/state.vscdb, but that’s only the sent messages. The unsent draft wasn’t among them - which makes sense, since I never submitted it.

The key insight

At this point I mentioned I had hour-old backups of the Cursor app support folder. The agent asked for two specific files from the backup. I restored them to Cursor_0906/ and Cursor_1006/ (the timestamps refer to when the backups were taken).

That’s when it found something interesting: a key called composerData:<composerId> in globalStorage/state.vscdb.

This key stores the unsent rich text draft of the Cursor chat input box as a Lexical editor JSON blob. Lexical is the rich text framework Cursor uses for the chat input. It persists the draft state across quits and restarts - so if you close Cursor mid-thought and reopen it, your unsent message is still there.

The structure looks roughly like this:

{
  "composerData": {
    "richText": {
      "root": {
        "children": [
          {
            "type": "paragraph",
            "children": [
              { "type": "text", "text": "your unsent message here" }
            ]
          }
        ]
      }
    }
  }
}

The text fields in the Lexical node tree contained the full original message. Compared to what I’d retyped from memory, there were four extra items I’d completely forgotten about and were meaningful thing to have back.

What to check if this happens to you

If you clear an unsent Cursor message and want to recover it:

1. Check your backups first. Time Machine, rsync, whatever you use - the window where the draft still exists in the SQLite database is before Cursor overwrites it (which happens when you next open the composer or quit cleanly, I think).

2. Open ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb with any SQLite browser (sqlite3, DB Browser for SQLite, etc.).

3. Look for keys matching composerData:<composerId> in the ItemTable. The composerId is a UUID - there may be one per chat window/composer.

4. Parse the value as JSON and look for text nodes in the Lexical tree. The draft content is in there.

The composerId you want corresponds to the chat composer where you were typing. If you know the chat session, you can cross-reference the submitted bubble keys (bubbleId:<composerId>:...) to confirm which composerId is the right one.

Luck required

This only worked because I had a recent backup. If Cursor had already overwritten the composerData key - which presumably happens once you open a new composer or send a new message - the draft would be gone from disk too.

The lesson: if you accidentally wipe an important Cursor draft, stop using Cursor immediately and back up ~/Library/Application Support/Cursor/ before doing anything else. The draft might still be in state.vscdb.

Cursor agent doing forensics on its own app’s storage files is a slightly strange loop, but it worked.

any.down is a small Python CLI I wrote to fix that. It logs into Any.do’s web API, pulls your tasks, and saves them as timestamped JSON and Markdown files. Run it once a day (or let Docker do it for you) and you’ve got a local paper trail of everything.

How it works

First run, any.down asks for your Any.do email and password, then sends a 2FA code to your inbox. After that it saves the session so you don’t have to re-authenticate each time. It only writes new files when your tasks have actually changed, so you don’t end up with hundreds of identical exports.

git clone https://github.com/aioue/any.down.git
cd any.down
uv sync
uv run anydown

The output lands in outputs/ - raw JSON for archival and Markdown tables that are easy to read or grep through.

Unattended backups with Docker

The main reason I built this was to run it on a schedule without thinking about it. A docker compose up -d gives you hourly syncs via supercronic, with session state in a Docker volume so it survives container rebuilds:

docker compose up -d

There’s also a --watch flag if you’d rather run the process directly without Docker - it syncs every 90 minutes or so with some random jitter.

Bonus: duplicate cleaner

Any.do occasionally creates duplicate tasks - maybe from sync conflicts across devices, maybe from the API being weird. any.down ships with a separate anydown-dupes command that finds exact duplicates (matching title, list, note, and subtasks) and lets you clean them up:

uv run anydown-dupes               # dry run
uv run anydown-dupes --delete      # prompt before deleting

Why not just use the app?

Mostly peace of mind. I don’t distrust Any.do, but I’ve been burned before by services that shut down or lose data. Having a local copy of my tasks - in plain text formats I can read without any special tooling - means I’m not locked in. If I ever move to a different system, the data is already there.

Source: aioue/any.down

Install

ansible-galaxy collection install git+https://github.com/aioue/ansible-unifi-inventory.git

Or in requirements.yml:

collections:
  - name: aioue.network
    source: https://github.com/aioue/ansible-unifi-inventory.git
    type: git

Inventory file

Create unifi.yaml (or whatever you like):

plugin: aioue.network.unifi
url: "https://192.168.1.1"
token: "your-api-token"
site: "default"
verify_ssl: false
last_seen_minutes: 30

Supports API token auth (preferred) or username/password for a local admin account with 2FA disabled. All settings can also come from environment variables (UNIFI_URL, UNIFI_TOKEN, etc.).

What you get

$ ansible-inventory -i unifi.yaml all --graph
@all:
  |--@unifi_clients:
  |  |--phone
  |  |--laptop
  |  |--Kitchen Echo
  |  |--pc
  |  |--nas
  |--@unifi_wireless_clients:
  |  |--phone
  |--@unifi_wired_clients:
  |  |--pc
  |  |--nas
  |--@network_default:
  |  |--laptop
  |--@network_iot:
  |  |--Kitchen Echo
  |--@vlan_30:
  |  |--Kitchen Echo
  |--@ssid_iot:
  |  |--Kitchen Echo

Groups are created automatically:

• unifi_clients, unifi_wireless_clients, unifi_wired_clients - by connection type
• network_<name> - by UniFi network name
• vlan_<id>, vlan_<name> - by VLAN
• ssid_<name> - by wireless SSID

Each host gets ansible_host set to its IP (IPv4 preferred, IPv6 fallback), plus variables like mac, vlan, network, ssid, is_wired, last_seen_iso, switch port, AP MAC, and manufacturer OUI.

With include_devices: true, UniFi infrastructure (APs, switches, gateways) appears too, grouped by device type (unifi_uap, unifi_usw, etc.) with firmware version and adoption status.

Caching

API results are cached locally for 30 seconds by default (cache_ttl). First run takes 2-10 seconds; subsequent runs within the TTL window are near-instant. Set cache_ttl: 0 to disable.

Use case

I use this alongside the Proxmox dynamic inventory to manage everything on my LAN. The UniFi inventory gives me ad-hoc access to any client that’s shown up on the network - useful for deploying SSH keys to new machines, checking which devices are on which VLAN, or targeting a group of hosts by network segment without maintaining a static inventory file.

Source: aioue/ansible-unifi-inventory

The problem

Canon’s High Sierra .dmg installers ship unsigned .pkg files that Gatekeeper blocks on modern macOS. Even if you force-install them, the printer filters are x86_64 binaries that won’t run on Apple Silicon without Rosetta. The scanner driver needs its ICA bundle placed in the right location and a USB re-plug cycle before Image Capture will recognise it. None of this is documented anywhere obvious.

What the bundle does

The repo contains Canon’s original DMGs alongside install scripts that handle the extraction and placement:

• Printer - deploy_printer_canon_full.sh mounts the DMG, extracts the full BJPrinter tree and the official gzipped PPD, and copies them into /Library. A separate script creates a CUPS queue using Bonjour/IPP discovery via ippfind, so you don’t need to know the printer’s IP address.

• Scanner - deploy_canon_scanner.sh does the equivalent for the ICA scanner bundle: mount, extract, codesign removal (the old signatures fail validation on newer macOS), and install to /Library/Image Capture/Devices.

Everything runs through hdiutil, pkgutil, and lpadmin - no third-party dependencies.

Quick start

Clone the repo and run two scripts:

# Printer (network/Bonjour)
cd printer-driver
./install_canon_mg6250_bonjour_network.sh

# Scanner (USB)
cd ../scanner-driver
./deploy_canon_scanner.sh

The printer script finds the device on the network automatically. The scanner requires a USB unplug/replug after install so that Image Capture picks up the new ICA bundle.

Tested on

This has been verified on macOS Tahoe 26.3 (Apple Silicon) for both printing and scanning. The printer filters run under Rosetta 2 - if you haven’t installed it yet, macOS will prompt you.

Caveats

Classic PPD-based drivers are living on borrowed time. Apple and the CUPS project are moving toward driverless IPP Everywhere, and a future macOS release could drop PPD support entirely. For now, though, this gets a perfectly good multifunction printer back in service without buying new hardware.

The Canon DMGs are included in the repo for convenience but are Canon’s software under Canon’s license terms, not MIT. If you prefer, you can download them directly from Canon’s support site and point the scripts at your copies.

Source: aioue/canon-mg6250-mac-driver-bundle

The permission problem

Utterances is a GitHub OAuth App. When you sign in to leave a comment, it requests the public_repo scope. That’s a broad permission — it grants read and write access to all of your public repositories, not just the one you’re commenting on. If the Utterances token were ever compromised, an attacker could create, modify, or delete issues and code across any of your public repos.

Giscus is a GitHub App, which uses a fundamentally different permission model. It can only access repositories where the owner has explicitly installed it. When you sign in to comment on this blog, Giscus can only interact with this blog’s repository. It has no access to your personal repositories unless you’ve specifically installed Giscus there yourself.

In short: Utterances gets keys to every public room in the building. Giscus only gets keys to the rooms it’s been invited into.

The migration

Straightforward. Enable GitHub Discussions on the repository, install the Giscus app, swap the script tag in the page template, and convert the existing comment threads from Issues to Discussions. Existing comments carried over without any trouble.

The Problem

The Proxmox inventory plugin has want_proxmox_nodes_ansible_host for nodes, but nothing equivalent for QEMU guests. For VMs using cloud-init with ip=dhcp, the plugin sets proxmox_ipconfig0 to:

{"ip": "dhcp"}

Not an actual address. The documented compose example from the plugin docs:

compose:
  ansible_host: proxmox_ipconfig0.ip | default(proxmox_net0.ip) | ipaddr('address')

doesn’t help — "dhcp" isn’t an IP, and proxmox_net0 only contains the MAC address and bridge config, not an IP.

The Solution

If the QEMU guest agent is running (agent: 1 in the VM config), the inventory plugin populates proxmox_agent_interfaces with live network data from inside the VM. This includes actual DHCP-assigned addresses.

The tricky part: the agent data uses hyphenated keys (ip-addresses, mac-address) which Jinja2 interprets as subtraction. You can’t use map(attribute='ip-addresses') — it parses as attribute='ip' - addresses. Use .get('ip-addresses', []) instead.

compose:
  ansible_host: >-
    ((proxmox_agent_interfaces | default([])
    | selectattr('name', 'equalto', 'eth0') | list | first | default({}))
    .get('ip-addresses', [])
    | ansible.utils.ipv4 | first | default(''))
    | ansible.utils.ipaddr('address')
    | default(ansible_host | default(inventory_hostname, true), true)

What this does:

1. Finds the eth0 interface in proxmox_agent_interfaces
2. Extracts its ip-addresses list (working around the hyphenated key)
3. Filters to IPv4 only with ansible.utils.ipv4
4. Strips the CIDR suffix (192.168.1.83/24 → 192.168.1.83)
5. Falls back to existing ansible_host or inventory_hostname for hosts without agent data

The default(..., true) at the end is important — without the second argument, Jinja2’s default only triggers on undefined variables, not on None or False. The ipaddr filter returns False for invalid input, and want_proxmox_nodes_ansible_host can set ansible_host to None.

Requirements

• QEMU guest agent installed and running in the VM
• agent: 1 in the VM config (so Proxmox queries the agent)
• want_facts: true in the inventory plugin config
• ansible.utils collection (included with the full ansible package)
• netaddr Python library (pulled in as a dependency of ansible.utils)

Verification

ansible-inventory -i inventory/pve.proxmox.yaml --list 2>/dev/null \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
for host, vars in data['_meta']['hostvars'].items():
    print(f\"{host}: {vars.get('ansible_host', 'NOT SET')}\")"

homeassistant: homeassistant
pve: pve
tank: tank
ubuntu-cloud: 192.168.1.83

Travel here not as hard work as expected. Singapore Air flights were comfortable and the 12+ hour flight to Singapore went surprisingly quickly. Food was particularly tasty. Entertainment system worked with the airline adapter cable provided by my Sennheiser headphones. Noise cancelling made the audio for media easy to hear without boosting the volume. No discernible impact on 🦻T.

M and C very welcoming hosts. They have a big house with a pool. 3 ginger cats called John Cena, John Malkovich (Meowkovich?), and Captain Nibbles the Third.

Little excursion to a bar last night, C and I excused ourselves relatively early and I settled in for a big jet-lag sleep until 11:00 this morning.

Noodles and some marmite on toast (brought on request) for brekkie. Coffee via ‘Grab’ (like Uber+Uber Eats combined).

We went for a sauna and swim on the scooter before work for $4.50. The roads are ‘exciting’ but not crazy busy.

It’s sunny and warm here. I’m sitting on my bed with fan on and the shutters open doing some work. I can hear bird tweeting outside and a cockerel just doodle-do’d! My mood has improved enormously.

Photo album link available on request.

2026-01-30 10:41 [ICT] (Indochina Time)

M & C went to a birthday early evening while I was working. There is quite a big ex-pat community that they are friends with. Tied to drinking culture, although there is gym, golf, bouldering etc that brings people together. They host poker and board games at their house.

We had a swim in the pool and hung out when they got back. Everyone packed up around midnight. I didn’t sleep super well, possibly due to the different ADHD meds I’m taking here. I was concerned about bringing potentially controlled items across a border - it was difficult to work out what was ok or not. Anyway, nothing a good few laps of the pool won’t sort out.

Ordered some breakfast on the local Grab app. Apparently everything comes with rice so we might have a bit of a surplus! Ordered 6 items (some for lunch while I’m working - £11.50 including delivery). Would probably be pushing £40 in the UK.

I’m being a conscientious, clean, and tidy house guest. I’m hoping to visit the shops with them today/tomorrow to pick up some essentials like bread (apparently the bread is good due to French colonial influences) and other bits so we’re not ordering every day.

Am quite content to just work and rest. Much the same as the UK but warm and bright out. The work day did get a little tricky finishing at ~2100-2200 but I suspect a good portion of that was jet lag. I didn’t really need to wake up so early, and in fact would probably fall back to my normal UK mode of 10AM starts alarms, if I wasn’t with company.

–Resumed ~15:00

We drove motorcycles to the city to get some coffee, have a walk, and do some shopping. I’m not insured for driving even a scooter since I don’t hold a full license, but the speeds are low enough I accepted the risk. The roads are somewhat chaotic, but ultimately relatively chill. The only dangerous person I saw was a white guy pulling out of a bar in front of someone.

We got coffees (and a lychee tea for myself) at a clean air-conditioned place. Then I went with C to a newly opened shopping place that might as well have been Marks and Spencer. Eggs, bread, and some cheeky Korean chocolate ice cream later, C took a tuk tuk back with the shopping and I rode home.

Time for work. I’m going to hopefully sleep well this evening - fading a little and it’s only the ‘start’ of the work day at 3PM.

2026-02-02 16:49 [ICT]

It’s Monday and I’m working again. Today we went to a different spa type place for sauna and plunge pool. It wasn’t very busy, half full with ex-pats who I assume are Cambodian or Chinese businessmen. I guess this is how rich people live in the UK - going to places where everything is quite cozy and not super busy.

The sauna and steam room had herbs into colander things over the rocks making them smell alternately like lemongrass and the curry I had for breakfast.

You could get a coconut opened for you with a straw in. It was very nice.

We then went to a ‘healthy’ restaurant for some lunch. Turmeric in everything.

–

The Saturday was fun, we started off with a massage. You change into a tshirt and Cambodian pantaloons - very wide waisted which I attempted to tie a knot into. The lady ended up doing it for me, you fold it over then roll it down, much like a towel in a gym.

The massage options were Thai and Khmer (“kam-eye”), and possibly both have stretch and no-stretch options. You can also have oil or no-oil. I initially opted for no-oil no-stretch which seemed to be Thai, but the lady seemed disappointed to do no-stretch so we swapped to stretch. It was moderate intensity, and a full body treatment with arms and legs being stretched - like a lay-down exercise warm-up, interleaved with ‘normal’ massage. At some points the person sat in the middle of my legs and held a foot while pressing against my thigh - quite physical! As someone who doesn’t get touched very much in my life it was surprisingly easy to relax and go with the flow. I sometimes get a massage in Norwich, maybe twice a year, and this felt less “trained”, but nonetheless very nice.

After that we drove on the motorcycles to a dumpling place. Very good dumplings, big portions for like $6. We met up with some ex-pats there and then all went to play minigolf on the edge of town. Good music at the golf, lot of classic rock. Then went to a bar owned by a friend of theirs for drinks and snacks, then another bar. Good chats and some pool - American sized table, but UK sized balls and cues which made it quite tricky.

Then we went home and chilled out before bed.

Sunday was a very lazy day. I had paced myself quite well - only had 6 beers or so the whole day but I still needed 10 hours kip to recharge. M and I ordered hearty UK style pies for dinner. C had a curry. M played a bit of Arc Raiders on the playstation and we then retired to Bedfordshire.

VM Template Configuration

Video/Graphics Support

Add to your OpenNebula template before starting the VM:

VIDEO = [
  TYPE = "virtio",
  VRAM = "187500" ]

VirtIO video adapter with ~183 MB VRAM for desktop environments and RDP sessions.

Network Configuration (Critical for RDP)

This solved RDP connecting but showing only a black screen.

Switch to NetworkManager instead of systemd-networkd:

CONTEXT = [
  ...
  NETCFG_TYPE = "nm",
  ... ]

Without this, RDP connections establish but the desktop session fails to render.

Software Changes

Desktop Environment

Install the minimal GNOME desktop:

apt install --no-install-recommends ubuntu-desktop-minimal

The --no-install-recommends flag significantly reduces install time.

Remove cloud-init

Prevent conflicts with OpenNebula contextualisation:

apt remove cloud-init
apt-mark hold cloud-init

Set Default Boot Target

Change from CLI to graphical boot:

systemctl set-default graphical.target

Required when converting a server install to desktop.

Shutdown and save your VM as a new desktop template, start up a new VM with it, and proceed with Part 2

Troubleshooting: Black Screen

If RDP connects but shows only black:

1. Verify NETCFG_TYPE = "nm" in the VM template CONTEXT section
2. Check NetworkManager: systemctl status NetworkManager
3. Verify boot target: systemctl get-default should return graphical.target

The Problem

Homepage styled correctly. Post pages completely bare — no CSS at all. The <head> section was empty except for Utterances styles injected by JavaScript.

The Cause

Custom _includes/head.html wasn’t being included because the remote theme’s default.html layout wasn’t being overridden locally.

When you use remote_theme, Jekyll pulls the theme files from GitHub. But if you have a custom _includes/head.html, you also need a local _layouts/default.html that explicitly includes it.

The Fix

Create _layouts/default.html:

<!DOCTYPE html>
<html lang="{{ page.lang | default: site.lang | default: "en" }}">
  {%- include head.html -%}
  <body>
    {%- include header.html -%}
    <main class="page-content" aria-label="Content">
      <div class="wrapper">
        {{ content }}
      </div>
    </main>
    {%- include footer.html -%}
  </body>
</html>

Create assets/main.scss:

---
---

@import
  "minima/skins/{{ site.minima.skin | default: 'classic' }}",
  "minima/initialize"
;

Your _includes/head.html should link to /assets/main.css:

<link rel="stylesheet" href="{{ "/assets/main.css" | relative_url }}">

What NOT to Do

Don’t create assets/css/style.scss with @import "minima" — this causes build failures because minima isn’t in the Sass load path when using remote_theme.

Debugging Tips

• Check GitHub Actions for build failures
• Add ?nocache=123 to URLs to bypass browser cache
• View page source to verify <head> contains stylesheet links
• Check /assets/main.css returns actual CSS, not a 404 page

If you’re working on OpenNebula you’ll need to modify the template first.

Overview

GNOME Remote Desktop provides native RDP support in Ubuntu, making it ideal for:

• Headless VM access via Apache Guacamole
• Multi-user remote login to a graphical desktop
• Hardware-accelerated graphics with virtio-gpu

Ansible Config

# Configure Ubuntu desktop for Guacamole RDP access
# This role sets up a secure RDP connection via GNOME Remote Desktop service
# for seamless integration with Apache Guacamole HTML5 remote desktop gateway.

- name: Install packages
  become: true
  ansible.builtin.apt:
    name: "{{ package_name }}"
    autoremove: true
    state: present
  loop:
    - winpr-utils # Required for TLS certificate generation
    - gnome-remote-desktop # Provides the remote desktop service
    # Packages for hardware-accelerated graphics with virtio-gpu
    - mesa-utils
    - mesa-vulkan-drivers
    - libgl1-mesa-dri
  loop_control:
    loop_var: package_name
  notify:
    - Reboot if needed

- name: Allow client to pass locale environment variables and timezone
  become: true
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^#?AcceptEnv'
    line: 'AcceptEnv LANG LC_* TZ'
    state: present
    create: false
  notify: restart SSH

- name: Enable PasswordAuthentication for SSH
  become: true
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^#?PasswordAuthentication'
    line: 'PasswordAuthentication yes'
    state: present
    create: false
  notify: restart SSH

- name: Enable linger for admin user to maintain graphical session after reboot
  become: true
  command: loginctl enable-linger {{ guacamole_guest_admin_user }}
  changed_when: false

- name: Set graphical target as default boot target
  become: true
  systemd:
    name: graphical.target
    enabled: true

- name: Remove nomodeset from GRUB to enable graphics driver detection
  become: true
  lineinfile:
    path: /etc/default/grub
    regexp: '^GRUB_CMDLINE_LINUX_DEFAULT='
    line: 'GRUB_CMDLINE_LINUX_DEFAULT="quiet text"'
    backrefs: true

- name: Update GRUB configuration to apply boot parameter changes
  become: true
  command: update-grub
  notify:
    - Reboot if needed

- name: Apply immediate reboot if required by configuration changes
  meta: flush_handlers

# TLS certificate generation for secure RDP connections
# https://gitlab.gnome.org/GNOME/gnome-remote-desktop#tls-key-and-certificate-generation
- name: Generate TLS certificate and key for GNOME Remote Desktop
  become: true
  command: sudo -u gnome-remote-desktop sh -c 'winpr-makecert -silent -rdp -path ~/.local/share/gnome-remote-desktop tls'

# Configure GNOME Remote Desktop for headless multi-user remote login
# https://gitlab.gnome.org/GNOME/gnome-remote-desktop#headless-multi-user-remote-login
- name: Configure TLS key for RDP connections
  become: true
  command: sudo grdctl --system rdp set-tls-key ~gnome-remote-desktop/.local/share/gnome-remote-desktop/tls.key

- name: Configure TLS certificate for RDP connections
  become: true
  command: sudo grdctl --system rdp set-tls-cert ~gnome-remote-desktop/.local/share/gnome-remote-desktop/tls.crt

- name: Set RDP access credentials
  become: true
  command: sudo grdctl --system rdp set-credentials rdpuser rdppass

- name: Enable interactive input control for RDP sessions
  become: true
  command: sudo grdctl --system rdp disable-view-only

- name: Enable RDP protocol support in GNOME Remote Desktop
  become: true
  command: sudo grdctl --system rdp enable

- name: Enable GNOME Remote Desktop service to start at boot
  become: true
  command: sudo systemctl enable --now gnome-remote-desktop.service

- name: Restart GNOME Remote Desktop service to apply all configurations
  become: true
  command: sudo systemctl restart --now gnome-remote-desktop.service

Key Steps Explained

1. Package Installation

The winpr-utils package provides winpr-makecert for generating TLS certificates. The Mesa packages enable hardware-accelerated graphics when running on VMs with virtio-gpu.

2. Session Persistence

loginctl enable-linger ensures user sessions survive after logout, which is essential for headless RDP access.

3. Boot Configuration

Setting graphical.target and removing nomodeset from GRUB ensures the system boots into a graphical environment with proper driver detection. Not needed if you started off with a Desktop system rather than installing ubuntu-desktop-minimal over a server install.

4. TLS Certificates

Certificates are generated using winpr-makecert and stored in ~gnome-remote-desktop/.local/share/gnome-remote-desktop/. Running as the gnome-remote-desktop user ensures correct ownership.

5. System-Wide RDP

Using grdctl --system configures the system-wide RDP service for multi-user headless access, as opposed to per-user desktop sharing.

Verifying the Setup

After running the playbook, verify the configuration:

sudo grdctl --system status --show-credentials

You should see:

Overall:
    Unit status: active
RDP:
    Status: enabled
    Port: 3389
    TLS certificate: /var/lib/gnome-remote-desktop/.local/share/gnome-remote-desktop/tls.crt
    TLS key: /var/lib/gnome-remote-desktop/.local/share/gnome-remote-desktop/tls.key
    Username: rdpuser
    Password: rdppass

macOS RDP Client Fix

If using Windows App (formerly Microsoft Remote Desktop) on macOS, edit your .rdp file:

use redirection server name:i:1

See: https://www.reddit.com/r/Ubuntu/comments/1n8pq1e/rdp_to_ubuntu_from_the_windows_app_on_macos/

Ubuntu 25.10 Considerations

A detailed troubleshooting guide for Ubuntu 25.10 documents some differences that may require changes:

OpenSSL Alternative for Certificates

If winpr-utils becomes unavailable or problematic, use OpenSSL instead:

sudo openssl req -newkey rsa:2048 -nodes \
    -keyout /var/lib/gnome-remote-desktop/rdp-tls.key \
    -x509 -days 365 \
    -out /var/lib/gnome-remote-desktop/rdp-tls.crt \
    -subj "/CN=$(hostname)"

sudo chown gnome-remote-desktop:gnome-remote-desktop /var/lib/gnome-remote-desktop/rdp-tls.*
sudo chmod 600 /var/lib/gnome-remote-desktop/rdp-tls.key
sudo chmod 644 /var/lib/gnome-remote-desktop/rdp-tls.crt

Approach is fundamentally the same across versions. Test on 25.10 before upgrading production systems.

References

• GNOME Remote Desktop GitLab
• Ubuntu 25.10 RDP Guide