Oel 10 Gui

Option A: Azure Portal

• Go to the Azure Marketplace and search for "Oracle Linux 10 with GNOME Desktop SecureAnyCloud".
• Select the image and choose Create.
• On the basics tab, set Subscription to your Azure subscription, Resource Group to a new or existing group, Virtual Machine Name to a name for your VM, Region to your preferred Azure region, and Size to Standard_B2ms or larger.
• Under Administrator Account, select SSH public key and enter your key.
• Under Inbound Port Rules, allow SSH (port 22) only. You do not need to open port 3389, because the recommended way to reach the desktop is through an SSH tunnel (Step 6).
• Choose Review + Create, then Create.

Option B: Azure CLI

Run these commands on your own workstation, substituting your resource group, VM name and preferred region. Accept the Marketplace terms once per subscription, then create the machine:

az vm image terms accept --urn sac1647283583153:oel-10-gui:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-oracle-desktop \
  --image sac1647283583153:oel-10-gui:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

To start with a larger operating system disk, add --os-disk-size-gb 128 and follow Step 12 once the machine is up. The root filesystem is on a logical volume, so the system does not claim Azure's extra capacity automatically.

On your own workstation, not on the VM, find the public IP, then connect:

az vm show --resource-group myResourceGroup --name my-oracle-desktop --show-details --query publicIps -o tsv ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks for one, the key you supplied at create time is not the key your client is offering.

Check that the machine is Oracle Linux 10, that it boots to the graphical target, that the GNOME login screen (GDM) is running and which desktop packages are installed:

cat /etc/oracle-release uname -srm systemctl get-default systemctl is-active gdm.service rpm -q --qf '%{NAME} %{VERSION}\n' gdm gnome-shell gnome-settings-daemon mutter gnome-remote-desktop

Expected output:

Oracle Linux Server release 10.2 Linux 6.12.0-206.104.3.3.el10uek.x86_64 x86_64 graphical.target active gdm 47.0 gnome-shell 49.4 gnome-settings-daemon 47.2 mutter 49.4 gnome-remote-desktop 49.3

The desktop comes from the distribution's own environment group, not from a third-party repository. Check the group:

dnf group list --installed | grep -i 'Server with GUI' || true echo "packages installed: $(rpm -qa | wc -l)" df -h /

There is no Xorg server on Oracle Linux 10, because RHEL 10 removed it. The session is Wayland, and Xwayland runs X applications inside it. Check both:

rpm -q xorg-x11-server-Xorg || echo "(no Xorg server: Oracle Linux 10 GNOME is Wayland only)" rpm -q --qf '%{NAME} %{VERSION}\n' xorg-x11-server-Xwayland

A new virtual machine has remote desktop switched off. The helper shows the whole picture in one command:

sudo sac-remote-desktop status

The helper lives at /usr/local/sbin/sac-remote-desktop. On Oracle Linux, sudo replaces your PATH with its own secure_path (/sbin:/bin:/usr/sbin:/usr/bin), which does not include /usr/local/sbin. For that reason, the image also ships /usr/sbin/sac-remote-desktop as a symlink to the helper.

The short form sudo sac-remote-desktop status used throughout this guide therefore works, and so does the full path.

Expected output on a new VM (the fingerprint is unique to your machine):

remote desktop service: disabled / inactive RDP backend: disabled listening on 3389: no per-VM RDP credential: generated (/root/sac-remote-desktop-credentials.txt) TLS certificate SHA-256: <the SHA-256 fingerprint of this VM's own certificate> accounts able to log in at the GNOME login screen: none (set one with: sudo passwd <user>)

Confirm it from the network side as well:

sudo ss -tln | awk '$1=="LISTEN"{print $4}' | sort

0.0.0.0:22 [::]:22

SSH on port 22 is the only service reachable from outside the machine. Any other entry you see is bound to a loopback address (127.0.0.1 or ::1) and is not reachable from the network.

The GNOME login screen asks for your account password, and a new VM has none. Choose your own. Run this yourself on the VM and enter the new password twice when prompted:

sudo passwd azureuser

Your SSH access is unaffected. SSH remains key-only, and this does not enable SSH password logins.

Now switch remote desktop on:

sudo sac-remote-desktop enable

Expected output:

remote desktop enabled: listening on port 3389 TLS certificate SHA-256: <the SHA-256 fingerprint of this VM's own certificate> RDP credential: sudo sac-remote-desktop credentials safest route: ssh -L 3389:localhost:3389 <user>@<vm-ip>, then point your RDP client at localhost:3389 note: firewalld is active on this image. The SSH tunnel needs no firewall change; a DIRECT connection to 3389 needs the port opened in the Azure NSG AND in firewalld.

If no administrator account has a password yet, the helper refuses rather than opening a login screen with nothing behind it, and tells you exactly which command to run first:

refusing to enable remote desktop: no administrator account has a password yet, so the GNOME login screen would have nothing to accept. Set your own first:
sudo passwd azureuser

The setting survives reboots. The helper runs grdctl --system rdp enable followed by systemctl enable --now gnome-remote-desktop.service. It then waits until port 3389 is listening before it reports success.

Now print this VM's RDP credential, which you need in the next step:

sudo sac-remote-desktop credentials

RDP_USERNAME=azureuser RDP_PASSWORD=<24 random characters, generated at this VM's first boot> RDP_PORT=3389 RDP_TLS_SHA256=<SHA-256 fingerprint of this VM's certificate> RDP_TLS_SHA1=<SHA-1 fingerprint of the same certificate, shown as the thumbprint by Windows>

RDP_USERNAME is your own administrator account name, but RDP_PASSWORD is used by your RDP client only: it is not an operating system password and it does not work for SSH.

Port 3389 is not open by default, and the SSH tunnel is the recommended route. The tunnel keeps RDP inside your existing SSH connection, so nothing new is exposed to the internet, and it needs no firewall change on either side.

On your own workstation, open the tunnel and leave it running:

ssh -N -L 3389:localhost:3389 azureuser@<vm-ip>

Then point your RDP client at localhost:3389:

• Windows: Remote Desktop Connection (mstsc) or Windows App, computer localhost:3389
• macOS: Windows App, add a PC with the name localhost:3389
• Linux: Remmina (RDP), server localhost:3389, or FreeRDP 3 (xfreerdp on Oracle Linux and Fedora, xfreerdp3 on Debian and Ubuntu): xfreerdp /v:localhost:3389 /u:azureuser /gfx /bpp:32

When the client asks for credentials, enter RDP_USERNAME and RDP_PASSWORD from Step 5. The client asks before any screen is drawn.

On the first connection, the client shows the server's certificate. It is self-signed and unique to your VM, so compare its fingerprint with RDP_TLS_SHA256 (or RDP_TLS_SHA1, which is what Windows displays as the thumbprint) before you accept it.

The GNOME login screen then appears. Select your account and enter the password you set in Step 5, and the full desktop session opens.

If you prefer a direct connection instead of the tunnel, remember that firewalld is active on this image, so the port must be open in both places. From your workstation, allow 3389 in the network security group from your own public address only, never from the whole internet:

az network nsg rule create --resource-group myResourceGroup --nsg-name my-oracle-desktopNSG \
  --name allow-rdp-from-me --priority 1010 --access Allow --protocol Tcp \
  --direction Inbound --destination-port-ranges 3389 --source-address-prefixes <your-public-ip>/32

Then allow the port in firewalld on the VM itself:

sudo firewall-cmd --permanent --add-port=3389/tcp sudo firewall-cmd --reload

Open Activities, or press the Super key, to reach the application grid. The dock carries Files (Nautilus), Software, the Ptyxis terminal, Text Editor and Calculator. The grid adds Clocks, Settings, Camera, Characters, Firefox, ULN Registration and the Utilities and System folders.

These are the applications the Server with GUI group installs. Nothing is added on top of the distribution.

ULN Registration is Oracle's optional tool for registering the machine with the Unbreakable Linux Network, which is for customers who hold a paid Oracle Linux Support subscription. You do not need it: this image already receives its updates from Oracle's public repositories, with no registration and no account.

A terminal inside the session behaves exactly as your SSH session does, and your administrator account keeps its sudo rights. To confirm you are on a Wayland session, run this in Ptyxis inside the desktop:

echo "$XDG_SESSION_TYPE"

To add software, use dnf as on any Oracle Linux machine, for example sudo dnf install -y libreoffice, then open the application from the grid.

Disconnecting your RDP client leaves the session running on the VM. Connect again to return to it.

When you have finished, switch it back off. This closes port 3389 and keeps it closed across reboots:

sudo sac-remote-desktop disable

remote desktop disabled: nothing listening on port 3389

sudo sac-remote-desktop status shows the state at any time, whether the service is on or off.

Confirm that SELinux is enforcing, that SSH is key-only and that no account has a password until you set one:

getenforce
sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication) '
sudo passwd -S root | awk '{print $1, $2}'
sudo awk -F: '$2 !~ /^[!*]/ && $2 != "" {n++} END {print "accounts with a password: " n+0}' /etc/shadow

Expected output on a new VM (after Step 5 the last line reads 1, your own account):

Enforcing passwordauthentication no kbdinteractiveauthentication no root L accounts with a password: 0

L in the second field means the root account is locked. The SSH policy is pinned by a drop-in file, so a later package update to the main configuration cannot quietly loosen it:

grep -vE '^#' /etc/ssh/sshd_config.d/60-sac-hardening.conf

PermitRootLogin prohibit-password PasswordAuthentication no KbdInteractiveAuthentication no PermitEmptyPasswords no

Every available update was applied when this image was built, and dnf-automatic is armed so the machine applies updates on its own schedule:

systemctl is-enabled dnf-automatic.timer grep -E '^(upgrade_type|download_updates|apply_updates) ' /etc/dnf/automatic.conf

Expected output:

enabled upgrade_type = default download_updates = yes apply_updates = yes

Updates are applied, not merely downloaded. upgrade_type is default rather than security deliberately. A security-only policy resolves against errata metadata and silently applies nothing for any update that does not carry it, so this image applies the full set.

Check whether anything is pending at any time:

dnf -q check-update >/dev/null 2>&1; echo "exit=$? (0 = nothing pending, 100 = updates available)"

Automatic updates never restart the machine for you. After a kernel update, check whether a restart is owed and pick your own window:

dnf needs-restarting -r || true

You can always update on your own schedule with sudo dnf -y upgrade. Reboot if a new kernel was installed. To opt out of the automatic updates entirely, run sudo systemctl disable --now dnf-automatic.timer.

This image boots the Unbreakable Enterprise Kernel by default and also carries the Red Hat Compatible Kernel. The same update path keeps both kernel lines patched.

The Azure Network Security Group is the outer firewall for this image, and firewalld is the host firewall inside it. Both are enforced, so a port you open for a direct connection must be open in both.

Several daemons are switched off in this image. rpcbind arrives enabled on the Oracle Linux cloud base itself, and the stock base leaves it listening on port 111. Cockpit, Avahi, CUPS and Bluetooth arrive with the Server with GUI group.

All of them are left installed but disabled, never masked, so the image exposes only port 22 and you can turn any of them back on with a single command. Check their state:

for u in cockpit.socket avahi-daemon.service cups.service bluetooth.service rpcbind.socket; do echo "$u: $(systemctl is-enabled "$u" 2>/dev/null || true)" done

cockpit.socket: disabled avahi-daemon.service: disabled cups.service: disabled bluetooth.service: disabled rpcbind.socket: disabled

To enable any of them, for example the Cockpit web console, run sudo systemctl enable --now cockpit.socket and open the port in your Network Security Group and in firewalld.

firewalld itself is left active and enabled, as Oracle ships it and as every other SecureAnyCloud Oracle Linux image does. Check it:

systemctl is-active firewalld
sudo firewall-cmd --list-services

active dhcpv6-client ssh

The network stack is NetworkManager, the native enterprise Linux stack, configured by cloud-init exactly as on Oracle Linux Server. The desktop adds no second network stack.

Like every Oracle Linux image on Azure, this image uses an LVM root layout. The root filesystem sits on a logical volume inside volume group rootvg, alongside a dedicated crashlv for kernel crash dumps. The /boot and EFI partitions stay as plain partitions, which is what the firmware and boot loader need. Show the layout:

findmnt -no SOURCE,FSTYPE /
sudo vgs
sudo lvs

Because the root filesystem is on a logical volume, cloud-init does not extend it automatically when you provision a larger operating system disk. Growing it takes three standard commands.

First, find the disk and partition that carries the LVM physical volume:

sudo pvs -o pv_name,vg_name --noheadings lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

The physical volume is partition 4 of the operating system disk. With that name in hand, grow the partition and make LVM see the extra space. Then extend the logical volume and its XFS filesystem in one step:

sudo growpart /dev/sda 4
sudo pvresize /dev/sda4
sudo lvextend -r -l +100%FREE /dev/rootvg/rootlv

If the disk name you saw in lsblk is not /dev/sda, substitute it. Then confirm the result:

df -h /

Adding a separate data volume instead is the ordinary LVM path. Attach an Azure data disk, run pvcreate on it and vgextend rootvg onto it, then lvcreate a new volume or lvextend an existing one.