How to Deploy Custom Wallpaper and Policies Across Pardus Clients

A central wallpaper rollout has two parts: copy the image to a location every client can read, then configure the desktop to use it. If users must not replace it, lock only the relevant desktop settings. For Pardus, Liderahenk provides central management through a Lider server, Lider Console, and Ahenk agents on managed systems. Its documented tasks include running scripts and transferring files; policies combine profiles and are assigned to user groups.

Illustrative scenario: imagine a hypothetical school district with 30 Pardus workstations. IT wants the same approved campus wallpaper on its Pardus GNOME clients and also wants selected browser and session rules. This example explains the workflow; it is not a report of a real deployment or test. The steps use GNOME's system-wide dconf mechanism. Pardus also offers XFCE, which needs a separate wallpaper configuration.

Pardus 25 release notes describe GNOME and XFCE editions (GNOME 48.4 and XFCE 4.20.2 in those notes). Exact Liderahenk console labels can vary by release, so the names below refer to functional areas, not guaranteed identical screens. Official Liderahenk documentation describes its Task, Profile, and Policy model and Ahenk client role.

1. Inventory clients and choose the right scope

Separate the district's GNOME machines from its XFCE machines. A GNOME dconf keyfile will not set an XFCE wallpaper. Record each pilot computer's hostname, Pardus release, desktop environment, Ahenk connectivity, and logged-in user group. In a GNOME session, check:

printf '%s\n' "$XDG_CURRENT_DESKTOP"
gsettings list-keys org.gnome.desktop.background

If a client is not running GNOME, exclude it from this profile and create a separate XFCE workflow. Check whether the session sets DCONF_PROFILE; a custom profile may not read the default /etc/dconf/profile/user.

For the hypothetical district, create or confirm a small pilot group containing representative GNOME workstations. Do not target every registered client at the start. A pilot can reveal image scaling problems, missing dependencies, or group-scope mistakes before changing every desktop.

2. Stage and verify the wallpaper file

Choose an image with enough resolution for the target displays, keep its filename stable, and host it at an internal HTTPS location reachable by clients. Record the expected SHA-256 digest from the approved source file. The image should be readable by desktop users but writable only by administrators. A system path such as /usr/local/share/backgrounds/ avoids reliance on a particular user's home directory.

Liderahenk's Ahenk documentation lists file transfer as a task capability. Use it for the pilot group if your installed version supports the destination and permissions you need. Alternatively, have a trusted Bash script retrieve the image from an internal HTTPS server. In either case, validate the delivered file before applying the setting. Do not put passwords, long-lived tokens, or private keys in a policy script.

This is the core of a download-and-verify step. Replace the example URL and digest with values from your approved asset pipeline:

set -euo pipefail
WALLPAPER_URL='https://assets.example.org/pardus/company-wallpaper.jpg'
EXPECTED_SHA256='replace-with-the-approved-64-character-sha256-digest'
DEST='/usr/local/share/backgrounds/company-wallpaper.jpg'
TMP="$(mktemp)"
trap 'rm -f "$TMP"' EXIT
curl --fail --silent --show-error --location --output "$TMP" "$WALLPAPER_URL"
echo "$EXPECTED_SHA256  $TMP" | sha256sum --check --status
install -D -o root -g root -m 0644 "$TMP" "$DEST"

For the school district example, the pilot script should stop if download or checksum verification fails. This prevents clients from applying a truncated or unapproved file. If using Liderahenk file transfer instead, compare the installed file's checksum on a pilot client with the source checksum.

3. Set the GNOME background and decide whether to lock it

GNOME documents a system-wide background through the user dconf profile and a local system database. The configuration below sets the wallpaper and uses zoom as its display style. Create the profile only if it does not exist; if one already exists, preserve its other database lines.

sudo install -d -m 0755 /etc/dconf/profile /etc/dconf/db/local.d

if [ ! -f /etc/dconf/profile/user ]; then
  printf 'user-db:user\nsystem-db:local\n' | sudo tee /etc/dconf/profile/user >/dev/null
elif ! grep -Fxq 'system-db:local' /etc/dconf/profile/user; then
  printf '\nsystem-db:local\n' | sudo tee -a /etc/dconf/profile/user >/dev/null
fi

sudo tee /etc/dconf/db/local.d/00-company-wallpaper >/dev/null <<'EOF'
[org/gnome/desktop/background]
picture-uri='file:///usr/local/share/backgrounds/company-wallpaper.jpg'
picture-options='zoom'
EOF
sudo dconf update

If the installed GNOME schema supports picture-uri-dark, and you want the same image in light and dark appearance modes, add that key to the keyfile after confirming it with gsettings list-keys org.gnome.desktop.background. Do not assume every setting exists in every Pardus image.

By default, users can override many system defaults with their own dconf values. If the requirement is only to provide a recommended wallpaper, stop before the lock step; users keep the option to personalize it. If policy requires a fixed background, create a lock file with one setting path per line:

sudo install -d -m 0755 /etc/dconf/db/local.d/locks
sudo tee /etc/dconf/db/local.d/locks/00-company-wallpaper >/dev/null <<'EOF'
/org/gnome/desktop/background/picture-uri
/org/gnome/desktop/background/picture-options
EOF
sudo dconf update

Add /org/gnome/desktop/background/picture-uri-dark to the lock file only if you also configured and verified that key. Locking is a usability trade-off: users can no longer change selected settings through normal GNOME controls. Keep the lock list narrow instead of blocking unrelated preferences. GNOME's administration guide explains the profile, keyfile, database update, and lockdown behavior.

4. Deliver the configuration through Liderahenk

Package the repeatable steps as an administrator-maintained Bash script and use the Lider Console's documented Script task or Script profile for Ahenk clients. Target the pilot client group first. Liderahenk documentation describes tasks as immediate or scheduled work for clients with Ahenk, profiles as configuration units combined into policies, and policies as settings assigned to user groups and retrieved during login.

For the hypothetical district, keep wallpaper deployment separate from other settings so an error in the image script does not complicate diagnosis of browser or session rules. Use a built-in profile for a supported policy, such as browser configuration, USB access, or session management, when it covers the requirement. Use custom scripts only when no suitable profile exists and the behavior has been tested on the same Pardus desktop and version.

For machine-wide dconf configuration, choose deliberately between a client-group task and a user-group policy. A one-time task is useful for distributing and applying files to known clients. A user-group policy can make configuration recur at login, but it affects every matched user and may run at a different point in the session lifecycle than expected. Verify the execution context in your Liderahenk version before associating it with a broad group. Ahenk is a privileged management agent, so only trusted administrators should be allowed to edit scripts or policy membership.

5. Validate the pilot, then expand

After the task or policy reports success, sign out and back in to GNOME; GNOME notes users need a new login for system-wide profile changes to take effect. Confirm the image exists at the expected path, is readable by the user, and matches the approved checksum. Inspect the active value on a pilot client:

gsettings get org.gnome.desktop.background picture-uri
gsettings get org.gnome.desktop.background picture-options
dconf read /org/gnome/desktop/background/picture-uri

Also confirm users cannot change the wallpaper if, and only if, you chose to lock it. Review the Ahenk task or policy result in Lider Console and check the desktop visually. For the school district example, test each display size or layout represented in the pilot; zoom crops edges, while other picture options can stretch or letterbox an image.

Expand the target group only after the pilot confirms the image, policy scope, and rollback path. Keep the previous wallpaper and a copy of any existing dconf profile or managed keyfiles. To roll back, remove only the organization-managed keyfile and lock file, restore prior profile state if your deployment added it, run dconf update, and have users log in again. Do not delete unrelated dconf configuration owned by the operating system or another administrator.

What this method does not cover

This workflow controls GNOME desktop wallpaper settings. It does not automatically set the login-screen background, which GNOME manages through a separate GDM dconf profile. It also does not configure XFCE clients. For either case, build and pilot a separate profile using the relevant desktop documentation.

Liderahenk provides central client and user management, but the exact plugin set and console steps depend on the installed release. Confirm Script, File Transfer, and Policy functions in documentation matching your server and Ahenk versions. The current documentation index summarizes tasks, profiles, policies, and reports; more detailed script pages are version-specific. Pardus release notes identify GNOME and XFCE as separate desktop options, so inventory clients before you target groups.

Official references

• Pardus: Liderahenk central management system
• Liderahenk documentation index: tasks, profiles, policies, and reports
• Liderahenk script task documentation
• GNOME: Set a custom background
• GNOME: Lock down specific settings
• GNOME: dconf profiles
• Pardus 25.1 release notes