skip to content

You are handed a headless SUSE Linux Enterprise 15 server and told to configure it with YaST. What is YaST, how do you drive it without a graphical desktop, and how does it relate to editing configuration files by hand?

level: middleimportance: nice to knowfreq 33%

answer

  1. one framework, many modules
  2. no desktop required
  3. front end, not a private store
  4. normal files under /etc and /etc/sysconfig
  5. its answer to Kickstart is XML

basics

~20 s

YaST is SUSE's integrated administration framework: modules for partitioning, network, users, services, bootloader and software behind one menu. On a headless server it runs as a text-mode interface over SSH, and its modules write the normal system configuration files.

solid answer

~50 s

YaST is the piece of SUSE with no real counterpart in the Debian or Red Hat families: a single administration framework whose modules cover partitioning, network configuration, users, services, the bootloader and software management, all speaking to the same backends the command-line tools use — its software module drives `libzypp`, the same library behind `zypper`. On a headless box you do not need a desktop: `yast` starts the ncurses text interface over SSH, and `yast2 <module>` opens one module directly, for example `yast2 lan` or `yast2 sw_single`. Crucially it is not a parallel configuration store like the Windows registry — modules read and write the system's normal files, including SUSE's `/etc/sysconfig` settings, so hand-editing and YaST are compatible in principle. The practical caution is ownership: a module rewrites the files it manages, so pick one owner per file and don't interleave YaST with a configuration-management tool on the same file.

code

bash · 7 lines
bash
# text-mode control centre over SSH, no desktop required
yast

# jump straight to one module
yast2 lan
yast2 sw_single
yast2 sysconfig

go deeper

for a junior

Know that YaST is SUSE's built-in administration tool with modules for common tasks, and that it has a text interface you can use over SSH on a server with no desktop.

for a middle

Explain that YaST is a front end over the normal backends — its software module drives the same library as zypper — and that modules read and write real configuration files, including SUSE's /etc/sysconfig settings.

for a senior

Show provisioning judgment: AutoYaST as the unattended-install profile, the ownership discipline needed when configuration management also writes those files, and the fact that SUSE's newer generation is moving off YaST.

for a principal

Own the platform decision: whether a fleet is configured by an integrated vendor tool or by declarative configuration management, what that choice costs in reproducibility and auditability, and how you migrate as the vendor's tooling generation changes.

## What YaST is YaST (Yet another Setup Tool) is SUSE's integrated system-administration framework. It is both the installer and the post-install configuration tool, structured as a control centre listing modules: software management, partitioning, network, users and groups, services, bootloader, firewall, NTP, NFS and Samba shares, and more. Debian and Red Hat systems have nothing quite equivalent — they have per-domain tools and, latterly, Cockpit — which is why "what is YaST" is a fair interview question for anyone claiming SUSE experience. The key architectural point is that YaST is a front end, not a parallel universe. Its software module drives `libzypp`, the same library `zypper` uses, so packages installed through YaST are ordinary packages in the same database. Its other modules read and write the system's real configuration files rather than keeping settings somewhere private. ## Driving it on a headless server The most common misconception is that YaST needs a desktop. It does not: ```bash yast # ncurses text interface, works fine over SSH yast2 # graphical if a display is available, otherwise text yast2 lan # open the network module directly yast2 sw_single # software management (install/remove packages) yast2 bootloader # bootloader configuration yast2 users # user and group administration ``` The text interface is keyboard-driven, with function keys for accept/cancel and highlighted letters for menu navigation. Some modules additionally offer a non-interactive command-line mode, which is what makes YaST usable from a script at all — though for real automation most people reach for the underlying tools directly. ## The relationship with hand-edited files SUSE has a strong `/etc/sysconfig` tradition: many subsystem knobs live as shell-style variable assignments in files under `/etc/sysconfig/`, and YaST has a module (`yast2 sysconfig`) that presents them as a browsable, documented tree. On SLE 15 the network module writes the interface configuration files consumed by SUSE's `wicked` network backend, the bootloader module writes the bootloader configuration, and so on. Nothing is hidden. So hand editing works, and YaST reading your hand edits works. The friction is *write ownership*: when you open a module, it renders its own view of the configuration and writes that view back on accept, which can reformat or drop things it does not model. The rule of thumb on a managed fleet is one owner per file — if Ansible, Salt or a package's own template owns a file, keep YaST out of that module; if YaST owns it, don't also template it. ## Unattended installation: AutoYaST The unattended-install story is AutoYaST: an XML profile describing partitioning, packages, users, network and post-install scripts, handed to the installer via a boot parameter. It is SUSE's analogue of Kickstart on Red Hat and preseed or the newer autoinstall on Debian and Ubuntu, and knowing that mapping is usually what an interviewer is really after when they ask about YaST in a provisioning context. A profile can be generated from an already-configured reference machine, which is the usual way teams bootstrap one. ## Where this is going YaST is the answer for the SLE 15 / Leap 15 generation. SUSE has been moving the next generation onto a new installer (Agama) with Cockpit for post-install administration, so treat YaST as current-for-15 rather than eternal, and say so — an interviewer testing recent SUSE experience will notice. ## What the interviewer is checking Three things: that you know YaST exists and is genuinely distinctive to SUSE; that you will not be stranded on a headless box because you assumed it needs X11; and that you understand it manipulates ordinary configuration files rather than hiding state, which is what makes mixing it with manual administration merely a discipline problem rather than an impossibility.

  • What is the SUSE equivalent of a Red Hat Kickstart file?
    AutoYaST. It is an XML profile describing partitioning, the package selection, users, network configuration and post-install scripts, passed to the installer through a boot parameter. It fills the same role as Kickstart on Red Hat and preseed or autoinstall on Debian and Ubuntu, and a profile can be generated from an already-configured reference machine as a starting point.
  • Is it safe to manage the same service with both YaST and a configuration-management tool such as Ansible?
    It works, but only with discipline. YaST modules read and rewrite the real configuration files, so whichever ran last wins and a module may reformat or drop settings it does not model. Decide one owner per file: if Ansible templates it, stay out of the corresponding YaST module; if YaST owns it, do not also template it. Mixed ownership produces configuration that silently flaps.
  • Someone says they cannot use YaST because the server has no graphical environment. How do you respond?
    YaST has always had a text interface. Running `yast` gives the ncurses control centre, which works perfectly over SSH, and `yast2 <module>` opens a single module directly, falling back to text when no display is available. Some modules also expose a non-interactive command-line mode. A headless server is the normal environment for YaST, not an obstacle.

saying these in an interview costs you the question

  • Assumes YaST requires a graphical desktop
  • Thinks YaST keeps settings in a private database
  • Describes YaST as only an installer
  • Expects Kickstart files to work on SUSE
  • Mixes YaST and Ansible on the same file without ownership rules

context

resolving links…