Oel 9 Gui

Option A: Azure Portal

• Go to the Azure Marketplace and search for "Oracle Linux 9 with GNOME Desktop SecureAnyCloud".
• Select the image and choose Create.
• Configure the basics:
• Subscription: Select your Azure subscription.
• Resource Group: Create a new group or select an existing one.
• Virtual Machine Name: Enter a name for your VM.
• Region: Select your preferred Azure region.
• Size: Standard_B2ms or larger.
• Under Administrator Account, select SSH public key and enter your key.
• Under Inbound Port Rules, allow SSH (port 22) only. Do not open any VNC port, because the desktop is reached through an SSH tunnel.
• Choose Review + Create, then Create.

Option B: Azure CLI

Run the following 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-9-gui:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-oracle-linux-desktop \
  --image sac1647283583153:oel-9-gui:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

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

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

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

Check that the machine is Oracle Linux 9 on the Unbreakable Enterprise Kernel, that it boots to the graphical target, that the GNOME login screen (GDM) is running with Wayland disabled, and which desktop and VNC packages are installed:

cat /etc/oracle-release uname -srm systemctl get-default systemctl is-active gdm.service grep '^WaylandEnable' /etc/gdm/custom.conf rpm -q --qf '%{NAME} %{VERSION}\n' gdm gnome-shell mutter xorg-x11-server-Xorg tigervnc-server

Expected output:

Oracle Linux Server release 9.8 Linux 6.12.0-206.104.3.3.el9uek.x86_64 x86_64 graphical.target active WaylandEnable=False gdm 40.1 gnome-shell 40.10 mutter 40.9 xorg-x11-server-Xorg 1.20.11 tigervnc-server 1.15.0

The desktop and TigerVNC come from Oracle's own repositories, not from a third-party repository:

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

dnf repolist shows exactly ol9_UEKR8, ol9_addons, ol9_appstream and ol9_baseos_latest, Oracle's rolling Oracle Linux 9 repositories. No EPEL repository is enabled, and none is configured.

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

sudo sac-vnc status

Expected output on a new VM:

VNC policy: localhost only, security types tlsvnc,vncauth (/etc/tigervnc/vncserver-config-mandatory) xvnc.socket (unauthenticated mode): disabled / inactive VNC desktops configured: none listening on VNC ports 5900-5999: none users with a VNC password set: none (each user runs: vncpasswd)

The helper lives at /usr/local/sbin/sac-vnc. On Oracle Linux, sudo replaces your PATH with its own secure_path, which does not include /usr/local/sbin, so the image also ships /usr/sbin/sac-vnc as a symlink and sudo sac-vnc works as written. Its subcommands are status, enable [<user>], disable [<user>] and details; <user> defaults to your administrator account.

Confirm the policy and the network side as well:

grep -vE '^#|^$' /etc/tigervnc/vncserver-config-mandatory
sudo ss -tln | awk '$1=="LISTEN"{print $4}' | sort

localhost securitytypes=tlsvnc,vncauth 0.0.0.0:22 [::]:22

SSH on port 22 is the only service listening.

First, set your account password. Run the following yourself on the VM and enter the new password twice when prompted:

sudo passwd azureuser

Then set your VNC password. Run vncpasswd as yourself, without sudo. Enter the password twice, and answer n to the view-only question:

vncpasswd

Password: Verify: Would you like to enter a view-only password (y/n)? n A view-only password is not used

Only the first 8 characters of a VNC password are used, and vncpasswd stores it in ~/.config/tigervnc/passwd with mode 0600. Your SSH access is unaffected, because SSH remains key-only.

sudo sac-vnc enable

Expected output:

VNC desktop for azureuser enabled on display :1: listening on localhost port 5901 only from your own machine: ssh -N -L 5901:localhost:5901 azureuser@<vm-ip> then point a VNC viewer at localhost:5901 and enter azureuser's VNC password

The helper adds :1=azureuser to /etc/tigervnc/vncserver.users, runs systemctl enable --now vncserver@:1.service, waits until port 5901 is listening, and refuses and stops the desktop again if the port is bound anywhere other than localhost. The desktop starts again after a reboot.

If a password is missing it refuses and tells you which one:

refusing to start a VNC desktop for azureuser: the account has no password yet. The GNOME lock screen and administrator prompts inside the desktop ask for it. Set it first:
sudo passwd azureuser

refusing to start a VNC desktop for azureuser: no VNC password is set. As azureuser (without sudo) run: vncpasswd

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

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

Then point your VNC viewer at localhost:5901 (TigerVNC and RealVNC accept localhost:5901; some viewers want the display form localhost:1; on macOS open Screen Sharing and connect to vnc://localhost:5901). Enter your VNC password, and your GNOME desktop opens.

firewalld is active on this image, and the tunnel needs no firewalld rule and no Network Security Group rule: the connection arrives over SSH on port 22 and reaches the VNC server on the machine's own loopback address.

TigerVNC Viewer marks the password dialog "This connection is not secure". It says that because the server has no certificate for the viewer to verify: TigerVNC's TLSVnc security type uses anonymous TLS. Through the SSH tunnel the connection is encrypted and the server is authenticated by SSH, which is why the image only allows VNC over the tunnel.

GNOME opens in the Activities overview. Press Escape for the desktop, or the Super key to return to the overview. The top right system menu offers Restart, Power Off and Log Out. Suspend is deliberately absent, because a suspended Azure virtual machine stops answering while Azure still reports it as running:

The application grid holds the applications that come with the Server with GUI group:

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 yum 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. The session type is X11, and the VNC server is listening on the loopback addresses only:

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.

Closing your VNC viewer leaves the session running on the VM; connect again and you return to it.

Each user gets their own display and port. Create the user with a password, have them run vncpasswd, then enable their desktop. The helper assigns the next free display (:2 is port 5902):

sudo useradd -m alice
sudo passwd alice
sudo -u alice -H vncpasswd
sudo sac-vnc enable alice

Alice then tunnels her own port, for example ssh -N -L 5902:localhost:5902 alice@<vm-ip> once her SSH key is in place.

sudo sac-vnc disable

VNC desktop for azureuser disabled: display :1 removed, nothing listening on port 5901

This stops the session, disables vncserver@:1.service and removes the mapping, so nothing listens after a reboot. sudo sac-vnc status shows the state at any time.

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

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 busctl call org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager CanSuspend

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

Enforcing passwordauthentication no kbdinteractiveauthentication no root LK accounts with a password: 0 s "na"

LK means the root account is locked, and na means logind will not suspend the machine. The sleep policy and the SSH policy are both pinned by drop-in files, so a later package update to the main configuration cannot quietly loosen them:

grep -vE '^#|^$' /etc/systemd/sleep.conf.d/20-sac-no-guest-sleep.conf
grep -vE '^#' /etc/ssh/sshd_config.d/60-sac-hardening.conf

[Sleep] AllowSuspend=no AllowHibernation=no AllowSuspendThenHibernate=no AllowHybridSleep=no PermitRootLogin prohibit-password PasswordAuthentication no KbdInteractiveAuthentication no ChallengeResponseAuthentication no

The image boots with module_blacklist=hyperv_fb on the kernel command line, and it matters. Two drivers in the Unbreakable Enterprise Kernel can claim the Hyper-V synthetic video device: the legacy framebuffer driver hyperv_fb and the modern DRM driver hyperv_drm, and whichever registers first wins. On the stock Oracle Linux 9 cloud image hyperv_fb wins, so there is no DRM device at all: the login screen's X server cannot use its modesetting driver, falls back to a 1024x768 framebuffer, and has to run as root instead of as the unprivileged gdm account. With hyperv_fb blocked, hyperv_drm provides the display and the login screen's X server runs without root privileges.

grep -o 'module_blacklist=hyperv_fb' /proc/cmdline cat /etc/kernel/cmdline ls /dev/dri

module_blacklist=hyperv_fb root=/dev/mapper/rootvg-rootlv ro crashkernel=1G-64G:448M,64G-:512M rd.lvm.lv=rootvg/rootlv console=ttyS0 module_blacklist=hyperv_fb card1

/etc/kernel/cmdline is what gives a kernel you install later the same setting, so a dnf update that brings a new kernel keeps the desktop's graphics device. Do not remove module_blacklist=hyperv_fb from either place. The Red Hat Compatible Kernel does not build hyperv_fb at all, so the setting is harmless if you choose to boot it.

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|reboot) ' /etc/dnf/automatic.conf

Expected output:

enabled upgrade_type = default download_updates = yes apply_updates = yes reboot = never

upgrade_type = default applies every available update rather than only those tagged as security errata, which is how every SecureAnyCloud Oracle Linux image is set. A security-only policy silently applies nothing for an update that carries no errata metadata.

Check both views of what is pending yourself at any time: whether any package update is available, and whether any security advisory applies to an installed package:

dnf -q check-update >/dev/null 2>&1; echo "check-update exit=$? (0 = nothing pending, 100 = updates available)" echo "pending security advisories: $(dnf -q updateinfo list --security --available 2>/dev/null | wc -l)"

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

dnf needs-restarting -r || true

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

GNOME Software may show "Software Updates Ready to Install" on your first login even when dnf reports nothing pending. That notification comes from the firmware updater (fwupd), not from a package: on Azure it offers Microsoft's UEFI Secure Boot revocation list (the "dbx") update published through the Linux Vendor Firmware Service. It is not an operating system package, it is not part of this image, and whether to apply a firmware variable update to your virtual machine is your decision. fwupdmgr get-updates shows exactly what it offers.

The Azure Network Security Group is the outer firewall for this image, and firewalld is the host firewall inside it. You do not need to open any port in either for the desktop: it travels inside SSH.

Several daemons are switched off in this image. rpcbind arrives enabled on the Oracle Linux cloud base itself, listening on port 111, and Avahi, CUPS and Bluetooth arrive with or alongside the Server with GUI group; Cockpit is installed but ships disabled. 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:

for u in cockpit.socket avahi-daemon.service cups.service bluetooth.service rpcbind.socket xvnc.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 xvnc.socket: disabled

To enable any of them, for example the Cockpit web console, run sudo systemctl enable --now cockpit.socket, then open its port in your Network Security Group and in firewalld (sudo firewall-cmd --permanent --add-service=cockpit and sudo firewall-cmd --reload). Do not enable xvnc.socket: it serves a login screen over VNC on port 5900 with no VNC password (-SecurityTypes=None).

firewalld itself is active and enabled, allowing SSH:

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

active dhcpv6-client ssh

The network stack is NetworkManager, configured by cloud-init exactly as on Oracle Linux Server.

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

findmnt -no SOURCE /
sudo lvs --noheadings -o lv_name,vg_name,lv_size

/dev/mapper/rootvg-rootlv crashlv rootvg 15.00g rootlv rootvg <31.90g

Because the root filesystem is on a logical volume, cloud-init does not grow it when you provision a larger operating system disk. After resizing the disk in Azure, find the physical volume with sudo pvs, grow that partition with sudo growpart, run sudo pvresize on it, and extend the root volume and its XFS filesystem in one step with sudo lvextend -r -l +100%FREE /dev/rootvg/rootlv. To add a separate data volume instead, attach an Azure data disk, pvcreate it, vgextend rootvg onto it, then create or extend a logical volume.