Yast

YAST is configuration manager able to store and read configuration files in XML. The development of YaST started in January 1995. It was written in C++ with a ncurses GUI by Thoamas Fehr (one of the S.u.S.E. founders) and Michael Andres.  Initially it was text-mode only. YaST2 was created in 1999.

Recently (as of SLES 11 SP3) it was rewritten in Ruby.

The unique feature of YaST is that it provides both text-based and GUI-based interface. By handling the original configuration files YaST does not excludes the possibility to edit them in old way using an editor. Thus nobody is forced to use YaST exclusively for configuration tasks. YaST is a modular system that consist of main program a set of modules. to view the modules installed use

yast2 -l
yast -l

YaST has pretty idiosyncratic interface but it has good capabilities to recognize hardware and install correct software. So while interface is antiquated the capabilities are not.  Due to history of its development (it was first command line tool later converted into GUI tool, it still can runs in command line. Command line version is called yast while GUI version yast2.  Actually diagnostic is much better in this mode as GUI version is to a certain extent a hack.

You need to be root to invoke YaST. Just type yast at the root prompt.

All YaST modules that are in the GUI version work in the command-line version as well.

YAST also can document existing system configuration: just go to "Create a Reference control file" in Autoinstallation/  and check at least the following items (more if you have packages like DNS or HTTP installed on the server):

• Firewall
• Hostname
• Network card
• NTP configuration
• Proxy
• System services
• Local security
• Data and time
• Graphic card and monitor
• Language

To save time, the individual YaST modules can be started directly. To start a module, enter yast2 module_name. For example, to start the network module, type

yast2 lan

While it is standard on  Novell's SLES and OpenSUSE. distributions Oracle recently ported  Yast  to Oracle Enterprise Linux, which is compatible with RHEL.  YAST usually have a highly polarized community: admires and enemies, not much in between. Architecturally YAST consists of framework and modules. YaST modules are written in the YCP language.  YaST separates the user interface, functional code doing the job (modules) and access to system configuration data (configuration files, etc).

• Text mode. In text mode the user interface is presented in the ncurses environment that provides windowing capabilities and entry forms on a text-based console. Mouse support is not necessary because all dialogs can be operated using only the keyboard.
• Graphics mode (X11). In graphics mode the Qt-library is used. It was added later (in YaST2 in 1999).

Purposes/roles in Yast are very similar to Windows  Control Panel:

• Installation of SUSE on a system
• Configuration of the installed system
• Administration of the installed system
• Reinstallation of the system or new system using pre-existing specification (AutoYast).
• Recovery (here command line mode is indispensible)

The access to system configuration data is realized by means of a special component (or layer if you prefer), the System Configuration Repository (SCR) (see below and Access to the System (SCR in General)). The SCR component basically consists of a number of so-called agents that have been writtento accomplish a specific kind of access. For example there is an agent to run shell-commands and there is another one that reads and writes ASCII-files of a specific format. Additionally there are agents that provide access to the system hardware e.g. by taking hold on the proc-file-system.

YaST modules are written in a YaST-specific scripting language, the YaST Control Language (YCP). These YaST-modules are then called in a predefined sequence to complete a specific task. In fact it is possible to extend YAST by writing additional modules in bash and Perl as long as the module need not have a user interface, i.e. it is not interactive. Such non-interactive modules typically handle specific problems like controlling a particular piece of hardware and can be called from within YCP-modules. This building block approach makes constructing complex workflows easy and maintainable.

Only the YCP language can be used to control the user interface (UI) presented on screen. The UI displays the information already known by the system and retrieves the information entered by the user. 

 “Hello World” in YCP

{
    string message = "Hello, World!";
    
    UI::OpenDialog(
               `VBox( 
                     `Label( message ),
                     `PushButton("&OK")
                    )
              );

    UI::UserInput();

    UI::CloseDialog();
}
          

• {

  The opening curly opens a so-called block in YCP. Blocks are used to “glue” several YCP-statements together to form an entity that can be handled just like a single statement.

• string message = "Hello, World!";

  In this line we define a variable named “message” that is of type string. In YCP any variable definition must imply a value assignment to avoid all errors that might occur due to uninitialized variables. Here we assign the constant string “Hello, World!”. Furthermore the terminating semicolon is mandatory in YCP to indicate the end of a statement (just like C).

• UI::OpenDialog(

  This command opens a dialog on screen. Because we want to display something, the code describing our dialog has to be sent to the UI. This is being done by the leading name space identifier UI::. The (single) parameter that is supplied here determines the content of the dialog.

• `VBox(

  This is a UI-statement related to the geometry of the dialog to be defined. As the name indicates it opens a (virtual) vertical box that displays all content in a column-wise manner. (Geometry management is described in more detail in Chapter 9, Controlling The User Interface).

  The leading back-quote introduces a YCP-feature that stems from the functional programming paradigm. In YCP-speak the `VBox() is a term. In YCP, terms are used as a structured constants and are typically passed to functions provided by YaST infrastructure as parameters as is done here with OpenDialog().

• `Label( message ),

  Displaying strings in YCP is done by means of Labels. This statement gets one parameter, the string variable we defined in the beginning. Because it is the first of two parameters passed to `VBox() this line is not terminated with a semicolon but with a comma. As in most programming languages commas are used to separate parameters in YCP.

• `PushButton("&OK")

  This statement displays a labeled push button. Since it is the next element in the enclosing `VBox(), it is displayed immediately below the preceding label. The & in the label string is a YaST feature declaring the subsequent character to be a key-shortcut. As a result the button can not only be clicked with the mouse but also be activated by typing ALT-O.

• ) and );

  The next two lines first close the open `VBox() and then the open OpenDialog(). Because `VBox() is passed as a parameter to OpenDialog() there is no need to terminate the statement with a semicolon. OpenDialog() on the other hand is a statement in the UI and hence must be terminated with a semicolon.

• UI::UserInput();

  Here we hand over control to the UI which then awaits some sort of user input. In this case it simply waits for the push button to be pressed by the user. Consequently our program blocks at this point until the user really does it.

• UI::CloseDialog();

  After all the UI-related action has finished, i.e. when UI::UserInput() returns, we want to remove the dialog we just created. This is done here.

• }

  Indicating the end of the block, the closing curly bracket ends our little YCP-program.

So if you are reading this document with a browser, you could copy-and-paste the program listed above into a file hello.ycp, and then run /sbin/yast2 hello.ycp which should render the following “spectacular” result.

Output of the “Hello, World!”-program

In summary YaST provides the following features, some of them having already been mentioned above:

• System access. YaST provides thorough probing of the system hardware and presents the information gathered thereby via the SCR-API. The SCR is also the means for reading and writing configuration files.
• Reasonable Suggestions. Based on the system analysis and predefined configuration data, YaST is able to provide reasonable suggestions for almost any configuration task.
• Workflows. Management of particular configuration categories is usually realized in form of workflows that split up the whole task into small steps.
• Modules and YCP. The steps constituting a workflow are usually realized as YaST-modules that are written in the YaST Control Language (YCP)
• User interface. The user interface of YaST is realized by means of a specific API from within the YCP-modules. This API supports a text-based console-mode as well as a graphical X11-mode.
• Internationalization. YaST provides support for various languages.
• Multi-platform support. YaST provides support for various platforms like Intel™ (x86), Apple™, IBM™ (s390) etc.

AutoYaST allows unattended and automated installation. With AutoYaST, administrators can create a consistent baseline configuration for new installations using any existing server. In addition to AutoYaST, other installation methods include PXE Boot, CD-ROM, NFS, CIFS/SMB, HTTP, FTP, and the Service Location Protocol (SLP), which allows autodetection of install servers.

Configuring NTP

The NTP client included with SUSE  can be set using YaST.

Installing Software with YaST

Software management is under Software in YaST.  From the beginning you can install any package from DVD. After registration you can install any package from the WEB.

Yast works only as root. If you are not logged as root it asks for root password. Enter your SuperUser password and YaST will open to the Software page. Click Software Management. After reading the current package setup, YaST displays the Search page.  This is a standard search page, and it is an excellent tool for finding specific applications, either by name or function. You can use Search if, for example, you want to see what Perl modules you have installed and what others are included in the distribution. Enter perl- into the Search box (the hyphen is there because all Perl module packages use the syntax perl-<module name>).

Sometimes you might want to explore the CDs for interesting applications or to look for a particular type of program. The Package Groups filter lets you do that. Use the drop-down Filter menu to display the Package Groups

With Package Groups, everything is organized in a tree by type of application. Click a branch to see all the relevant packages. Some branches are further subdivided for a narrower selection, but the Multimedia branch displays everything in CD, Sound, Video, and Other.

Whatever filter you choose, YaST will show all the matching packages in the upper-right pane, with pertinent details. Click any individual package for a more detailed description of that package in the lower-right pane. Installed packages will be checked. To install any others, check the box. You can also right-click any package and choose from the following menu options:

• Install—Selecting this option will install the package.

• Do Not Install—Selecting this option specifies that the package should not be installed.

• Keep—Selecting this option specifies that a previously installed package should remain installed and not be modified.

• Delete—Selecting this option uninstalls the package.

• Update if Newer Version Available—Selecting this option specifies that an already installed package be updated only if a newer version exists in the installation source.

• Update Unconditionally—Selecting this option specifies that the already installed package be updated with the version residing in the installation source, regardless of its version.

• Taboo—Never Install—Selecting this option specifies that the package is to never be installed.

• Protected—Do Not Modify—Selecting this option specifies that the package is already installed and should not be modified.

You can also configure special installation options without right-clicking the package using the check box. Clicking the check box next to an installed package once displays the Update icon, which is really a reinstall. Double-clicking the check box marks the package for removal. Some installed packages appear in red type; this means that the version you have installed now is newer than the package on the CD. Choosing Update on these packages will revert the current version to the version on the CD.

When you have finished choosing packages, click Accept to complete the installation. Occasionally, you'll see one of two additional screens. One screen tells you that some other packages will be installed in addition to your selected packages to satisfy some dependencies (see more about dependencies in the next section "The Basics of the Red Hat Package Management System [RPM]"). The other screen indicates that one or more of your selections will conflict with an existing package and offers suggestions about how to deal with the conflict.

Command line installation

You can also use YaST to install a package from the command line. To do this, you must first know the name of the package you want to install. When you do, enter the following:

yast -i package_name

For example, if you wanted to install the dosbox package, you would enter the following:

yast -i dosbox

Just as when using the Software Management module, installing a package from the command line performs a dependency check and automatically installs any dependent packages required.

After installing any new package, you should always run updater (YOU) to check for updated versions of the software. This protects your system against security problems.

In the preceding example, you used YaST to install additional packages from the SUSE installation CDs. However, you can use YaST to specify other locations from which packages should be installed. You can select an FTP or HTTP server on the Internet, a server on your local network, or a directory on your local hard drive (assuming the packages have been copied there).

Having an alternative installation source can be a lifesaver when you need to install a new package, but have misplaced or damaged your SUSE Linux CDs. Installing from the Internet also ensures that the packages you are installing are the most current available.

How to add a SUSE mirror site on the Internet as an additional installation source

Note

If you enter the wrong path, you'll see an error message that states something to the effect of ERROR(InstSrc:E_no_instsrc_on_media). if you see this message, one of two things has happened. Usually, this error occurs when you use a leading or a training forward slash in the directory path. It can also occur if you use the wrong path. Remember that the path must point to the root of the distribution on the mirror site, not to the directory where the package files reside.

At this point, you can test your new installation source by opening the Software Management module in YaST. When you do, you'll see that the module retrieves its package information from the remote mirror site instead of from your local CD or DVD drive.

With this in mind, we need to relate a little background about applications and packages.

NEWS CONTENTS

• 20131012 : YaST Developers Explain Move to Ruby by Susan Linton ( Oct. 10, 2013 , OStatic )
• 20100208 : Shrink NTFS Partition Using AutoYaST ( Shrink NTFS Partition Using AutoYaST, Feb 8, 2010 )
• 20100207 : SLE10: Create a YaST Installation Source for Auto Installation ( SLE10: Create a YaST Installation Source for Auto Installation , Feb 7, 2010 )
• 20090320 : yast2-sudo - YaST2 - sudo configuration ( yast2-sudo - YaST2 - sudo configuration, Mar 20, 2009 )
• 20090218 : Martin Vidner YaST Log Summarizer ( Martin Vidner YaST Log Summarizer, Feb 18, 2009 )
• 20090218 : 1 comments: ( )
• 20090218 : SuSELinuxSupport HowTo Add Yast Package Repositories and Install Software Packages with Yast. ( SuSELinuxSupport HowTo Add Yast Package Repositories and Install Software Packages with Yast., )
• 20071023 : Yast (Yet Another Setup Tool) part of its distribution. ( Yast (Yet Another Setup Tool) part of its distribution., Oct 23, 2007 )
• 20071023 : YaST Proxy - openSUSE ( YaST Proxy - openSUSE, Oct 23, 2007 )
• 20070503 : AutoYaST automated installation by Novell ( AutoYaST automated installation by Novell, May 3, 2007 )
• 20070503 : AT3456783210 ( AT3456783210, )
• 20050621 : Developing YaST Modules ( Developing YaST Modules, Jun 21, 2005 )
• 20040924 : YaST2 on SUSE Linux Enterprise Server 9: Getting Started ( YaST2 on SUSE Linux Enterprise Server 9: Getting Started, Sep 24, 2004 )

Old News ;-)

[Oct 12, 2013] YaST Developers Explain Move to Ruby by Susan Linton

Oct. 10, 2013 | OStatic

Last summer Lukas Ocilka mentioned the completion of the basic conversion of YaST from YCP to Ruby. At the time it was said the change was needed to encourage contributions from a wider set of developers, and Ruby is said to be simpler and more flexible. Well, today Jos Poortvliet posted an interview with two YaST developers explaining the move in more detail.

In a discussion with Josef Reidinger and David Majda, Poortvliet discovered the reason for the move was because all the original YCP developers had moved on to other things and everyone else felt YCP slowed them down. "It didn't support many useful concepts like OOP or exception handling, code written in it was hard to test, there were some annoying features (like a tendency to be "robust", which really means hiding errors)."

Ruby was chosen because it is a well known language over at the openSUSE camp and was already being used on other SUSE projects (such as WebYaST). "The internal knowledge and standardization was the decisive factor." The translation went smoothly according to developers because they "automated the whole process and did testing builds months in advance. We even did our custom builds of openSUSE 13. 1 Milestones 2 and 3 with pre-release versions of YaST in Ruby."

For now performance under the Ruby code is comparable to the YCP version because developers were concentrating on getting it working well during this first few phases and user will notice very little if any visual changes to the YaST interface. No more major changes are planned for this development cycle, but the new Yast will be used in 13.1 due out November 19.

See the full interview for lots more detail.

[Feb 8, 2010] Shrink NTFS Partition Using AutoYaST

Feb 1, 2007

Kenneth Stevenson explains how to install openSUSE on a machine that already has Windows occupying a NTFS partition spanning the entire disk.

[Feb 7, 2010] SLE10: Create a YaST Installation Source for Auto Installation (feature)

Cameron Seader shows you how to create a YaST installation source that can be used during an Auto installation or a Network installation.

[Mar 20, 2009] yast2-sudo - YaST2 - sudo configuration

The YaST2 component for sudo configuration. It configures capabilities of users to run commands as root or other user.Author: Katarina Machalkova <[email protected]>

Package version:	2.14.2
Architecture:	noarch
Distribution:	SuSE 10.2
Filename:	yast2-sudo-2.14.2-31.noarch.rpm

[Feb 18, 2009] Martin Vidner YaST Log Summarizer

March 26, 2007

When dealing with YaST logs, it happens every now and then that you wade through the voluminous output only to discover that you are looking at the wrong run and the bug happened three days after the start of the log file.

So I wrote a simple log summarizer y2logpids, that shows the first and last lines for each process ID in the log. And as a side feature, it also measures time differences for the case where the reporter says "and then it hangs for 30 minutes".

$ y2logpids -h
Usage:
y2logpids -h|--help
y2logpids [-m] [-d [<seconds>]] [log-files]

Options and Arguments:
-m, --maximum
Show the maximum time difference between log lines, within a single
PID.

-d [seconds], --difference[=seconds]
Show where the time difference is larger than seconds (60 if
unspecified), within a single PID

$ wc -l logs/255012-y2log
23501 logs/255012-y2log
$ y2logpids logs/255012-y2log
2007-03-20 11:13:31 <1> e111(4034) [liby2] genericfrontend.cc(main):200 Launched YaST2 component 'y2base' 'inst_suse_register' 'qt' ''
2007-03-20 11:13:45 <1> e111(4034) [media] MediaManager.cc(restoreAutoMounter):248 Restored HAL volume handling (automounter)
2007-03-20 11:14:15 <1> e111(4222) [liby2] genericfrontend.cc(main):200 Launched YaST2 component 'y2base' 'inst_suse_register' 'qt' ''
2007-03-20 11:29:07 <1> e111(4222) [media] MediaManager.cc(restoreAutoMounter):248 Restored HAL volume handling (automounter)
2007-03-20 11:32:51 <1> e111(5265) [liby2] genericfrontend.cc(main):200 Launched YaST2 component 'y2base' 'online_update' 'qt' ''
2007-03-20 11:33:12 <1> e111(5265) [media] MediaManager.cc(restoreAutoMounter):248 Restored HAL volume handling (automounter)
2007-03-20 11:34:07 <1> e111(5310) [liby2] genericfrontend.cc(main):200 Launched YaST2 component 'y2base' 'online_update' 'qt' ''
2007-03-20 12:02:02 <1> e111(5310) [YCP] OnlineUpdateCallbacks.ycp:50 PatchProgressCallback 100
2007-03-20 12:02:18 <1> e111(7003) [liby2] genericfrontend.cc(main):200 Launched YaST2 component 'y2base' 'print-product' 'qt' ''
2007-03-20 12:03:51 <1> e111(7003) [zypp] ZYppFactory.cc(unLockFile):139 unlocked
2007-03-20 12:03:55 <0> e111(5310) [zypp] ExternalProgram.cc(checkStatus):333 pid 5881 successfully completed
2007-03-20 12:24:22 <1> e111(5310) [media] MediaManager.cc(restoreAutoMounter):248 Restored HAL volume handling (automounter)
2007-03-20 12:35:41 <1> e111(8715) [liby2] genericfrontend.cc(main):200 Launched YaST2 component 'y2base' 'online_update' 'qt' ''
2007-03-20 12:38:51 <1> e111(8715) [media] MediaManager.cc(restoreAutoMounter):248 Restored HAL volume handling (automounter)

Download the script. Posted by Martin Vidner at 9:03 AM Labels: debugging, logs, PID, timestamp, YaST

1 comments:

Martin Vidner said...

Eh, I've just realized that the use Date::Parse; adds a dependency on perl-TimeDate.rpm. I will try to make that dependency an optional one.

SuSELinuxSupport HowTo Add Yast Package Repositories and Install Software Packages with Yast.

How to install a package from the commandline e.g. like this, from the command-line (still as root): yast2 --install MozillaFirefox

Adding installation sources Ok, now the real meat In this example we are gone install firefox 1.5.0.1 The firefox 1.5.0.1 packages are kept in a separate package, repository, let's add that repository where the new firefox packages are stored. From the command-line, that can be done using the following command: installation_sources -a http://ftp.belnet.be/packages/suse/projects/mozilla/experimental/10.0 -a means add and ftp.belnet.be is a very fast mirror in europe, you could use another one though, but for the sake of simplicity, just use belnet, as above ;) When you type that command, it will take a few seconds to complete

[Oct 23, 2007] Yast (Yet Another Setup Tool) part of its distribution.

Oracle Enterprise Linux became more compatible with Suse. Suse users can use Oracle version as an upgrade.

Yet Another Setup Tool. Yast helps make system administration easier by providing a single utility for configuring and maintaining Linux systems. The version of Yast available here is modified to work with all Enterprise Linux distributions including Enterprise Linux and SuSE.

Special note to Oracle Management Pack for Linux users:

• Enterprise Linux and RHEL Users: Download the Yast rpm. The em-wrapper scripts are included and do not need to be downloaded separately.
• Suse Enterprise Linux Users: Download the em-wrapper scripts rpm and an additional remote access module for Yast.

[Oct 23, 2007] YaST Proxy - openSUSE

Proxy Settings Under YaST

Getting your YaST to work in a proxy environment is a straight forward thing. This is required when you don't have a direct Internet connection and you are using a Web Proxy in your network to make http requests.

Let's say your proxy server is : proxy_server.domain and the port number it listens on for connections is : 8080

Now go to YaST -> Network Services -> Proxy and set the proxy server name and port number in the dialog box. You can do a similar setting for https and others.

If your proxy server uses authentication too, this is the place to enter the details so that YaST will authenticate itself automatically.

Generally, most of the application that require Internet through a proxy will use a shell variable named http_proxy. This should be set as follows:

$ export http_proxy=username:passwd@proxy_server:8080

This will last only for the current session. Hence variables like this should be set in start-up scripts or at least in .profile file of the shell you are using.

Retrieved from "http://en.opensuse.org/YaST_Proxy"

Views

• Article
• Discussion
• Edit
• History

The content on this and other wiki pages is posted by community members who are not acting for or on behalf of Novell, Inc., whether or not they otherwise have affiliation with Novell.

• This page was last modified 12:02, 7 December 2006.
• This page has been accessed 9 times.
• About openSUSE
• Content is available under Legal.
• Disclaimers

[May 3, 2007] AutoYaST automated installation by Novell

AutoYaST is available with recent SuSE products starting from SuSE Linux 8.0 and business products starting from SLES 8.

Products prior to SuSE Linux 8.0 and business products based on SLES 7 have an auto-installation system based on YaST1. A configuration management system is provided by ALICE for these products.

AT3456783210

My current favorite desktop Linux is OpenSUSE 10.1. I can say all kinds of good things about it, except when it comes to the package manager. Unfortunately, the package manager, which the administration tool YaST uses for adding new programs and updating old ones, currently has serious problems.

The default package management software in SUSE 9 and 10 was YOU (YaST online update) in YaST2 and the susewatcher system tray applet. This, however, has been replaced by Libzypp in 10.1.

Libzypp is a backend program that uses RPM (RPM Package manager) packages for installing, removing, and querying program packages. This new program is an attempt by Novell to marry the best features of SUSE's yast2 package manager and Ximian's libredcarpet.

This backend software works with the ZMD (ZENworks Management Daemon) to create the new system-tray notification applet, zen-updater.

The idea was a good one. If it worked, users would get a command-line tool for running updates, rug, and a way to provide common handling of packages and patches.

When it works, it works quite well. Cenuij, a UK-based SUSE user, gives an excellent explanation of how the new system works and how to make the most of it.

However, it doesn't work that well all the time. The combination of yast2 and libredcarpet is only half-baked. In my experience, and those of many others, the new package manager is extremely slow and often breaks.

These problems can show up in a number of ways. One common one is that you can't use YaST to install an updated package from a downloaded RPM, because YaST will not accept a local directory as an install source unless it contains a catalog. You can, however, work around this. The trick is to right click on the RPM and hit "Open with Install Software."

Another problem that many people experience is that YaST will appear to let you add a new installation source, like the ever-popular packman.unixheads.com/suse/10.1, but the program won't let you actually save your new choice.

The problem has become so annoying that some people have taken to using an entirely new approach to updating their systems -- Pascal Bleser's SUSE 10.1-specific update of the Smart Package Manager universal Linux package management program. Bleser is the maintainer of the Guru SUSE software repository.

Spin Ink, in his blog, gives an excellent set of directions on how to use the Smart Package Manager in SUSE 10.1.

I've used it, and I've been very pleased with the results.

In the meantime, Novell/SUSE is well aware of the problems, and is working hard on fixing them.

Kevan Barney, Novell's senior PR manager, tells me that, "Our folks in Germany ... are working hard to get those fixed."

"Getting updates is currently completely possible by running "yast2 online_update" or selecting it from the control center menu (requires root access rights). We are putting together an update for the end of next week, which will include fixes for zen-updater (which seems to not work for everybody with the patches currently available) as well as some other fixes," Barney added.

"If you know of any concrete issues which we aren't currently addressing, please let us know in more detail, since we are anxious to make sure our users are taken care of," he concluded.

Given the overall quality of the rest of OpenSUSE 10.1, I'm sure that SUSE developers are working hard on taking care of users and this set of problems in particular.

-- Steven J. Vaughan-Nichols

[Jun 21, 2005] Developing YaST Modules (feature)

YaST stands for Yet another Setup Tool. It is a management tool for installing and administrating SUSE Linux. This tool is designed to simplified the complexity of managing different aspects of SUSE Linux. It presents a simple interface (both GUI or Text based) to administrators for a particular task. Here are some reasons you should develop YaST modules, and a closer look at the YaST architecture.

[Sep 24, 2004] YaST2 on SUSE Linux Enterprise Server 9: Getting Started (feature)

YaST is a key difference between SUSE Linux and other Linux offerings.This article will help you to understand the internal working of YaST, from user, administrator and developer viewpoints. It provides steps to install the YaST SDK.

Recommended Links

Softpanorama Recommended

Top articles

Sites

YaST2 Documentation

AutoYaST

Uwe's Blog

Linux Patch Management Keeping Linux Systems Up To Date (Bruce Perens' Open Source Series) Books Michael Jang

Setting Up a yum Repository Getting the Packages

SUSE supports two different patch management tools described in Chapter 3, "SUSE's Update Systems and rsync Mirrors": YaST Online Update and Zenworks Linux Management. As noted in Chapters 5 and 6, they now support apt, and plan to support yum in the future.

Review by James Pyles

March 28, 2006

Anyone who has had to manage patches for a single Windows computer or an entire Windows network, has watched at least some of their hair fall out or at least go a bit gray. Trying to keep your Windows systems up to date and secure, while facing the specter of a well-meaning patch breaking your computers, is not for the faint of heart.

Lest we forget however, Linux systems also require patches to update software packages and package management on Linux is not always an easy task. Windows computers have a single web interface...the much vaunted Windows Update Manager...for the user or admin to navigate to and update the variety of Windows workstations and servers...but while "Windows" may be a single, monolithic entity, such is not the case for Linux.

Most books on Linux software package management limit themselves to one or perhaps two distros. After all, each flavor of Linux seems to use a different tool for package management on the system. Michael Jang decides to take on all the major systems including Red Hat Enterprise Linux (RHEL), Fedora, SUSE, and Debian, plus several others. The range of this book goes from patch management on the individual computer to updating software packages on entire networks.

Chances are that if you have just burned your first Ubuntu installation disk from an image and are toying with the idea of loading it on that old computer now harboring a long abandoned Windows 98 OS, you may not want to start out with Linux Patch Management. This book assumes the reader has at least some knowledge with Linux and at a minimum, is a newbie Linux administrator (or perhaps a talented wannabe). The complete Linux newbie will need to earn a few stripes before moving on to this guide.

The proud owner of this text may not necessarily want to read every chapter. The various chapters describe the use of the specific patch management tools used by different distros. If you are a Debian junkie (and who wouldn't want to be?), you may be focused on the apt system and could not care less about YaST or yum. However in this review, we are going to take the complete guided tour of everything Linux Patch Management has to offer. Let's go.

While the stated audience of this book is in the "newbie Linux admin range", Chapter 1 "Patch Management Systems" starts off with a definition of what a patch is and the different types of patches including security fixes, service upgrades, bug fixes and kernel patches and upgrades. There's even a brief mention of the risks you take when you install a patch (Ok, so it's not just a "Windows-thing").RPM vs. DEB package formats are addressed and the three distro-specific repositories are introduced; Red Hat/Fedora, Novell SUSE, and Debian.

It was interesting to me that at one point, the author defined a "tarball" which is a pretty basic concept but didn't provide the instructions on how to package and unpackage a tar.gz file (if I didn't know what a tarball was, I probably wouldn't know what to do with it). On the other hand, much of the rest of the book assumes that the reader has at least mastered the basics of Linux systems management, so it was an odd element to encounter.

The chapter then launches into a compressed illustration of how to install and update Red Hat, SUSE, and Debian systems...just enough to get your feet wet (I did notice that the author seems to favor Dell PowerEdge servers as proxy servers for updating groups of RHEL systems). The rest of the chapter covers how to configure a LAN to accommodate a patch management infrastructure, presenting just enough to set the stage for the rest of the book.

Chapter 2, "Consolidating Patches on a Red Hat/Fedora Network" propels the reader into the true purpose and focus of this book...to teach the newbie admin how to set up and configure a repository server on the network to manage patches for client machines. In this case, the clients are Red Hat or related client OS types (Fedora, CentOS and so on). I wouldn't recommend blinking or you're libel to miss something as you turn pages. The reader is moved directly into creating a Fedora repository, rocketing through hardware requirements, hard drive partitioning, and creating a repository for Fedora. RHEL servers use a Red Hat Network Proxy Server as a repository and we immediately shift gears and cover the various nuts and bolts of this set up including specialized install requirements, firewall provisions, network time servers, routing, registration, and installing proxy packages.

It becomes abundantly clear that the reader is expected to know his or her stuff. The book doesn't spend a lot of time on the basics and if you don't know them by now, you will have a tough time operationalizing what you are being taught here. You are expected to follow the instructions for creating certificate keys, configuring a proxy client, setting up automatic updates, and more. The instructions are in the chapter, however you won't be spoon fed.

Next, you cross the border from Red Hat to SUSE in Chapter 3, "SUSE's Update Systems and rsync Mirrors". The reader is immediately introduced to YaST and Zenworks Linux Management (ZLM), which interestingly enough, can be installed not only on SUSE Linux Enterprise Server (SLES) but on RHEL as well (I know, Novell is sort of the red headed, left-handed step-child of the Linux world, but it may suffer more from poor marketing and management than from poor products). This chapter addresses ZLM later on but begins by focusing on YaST as the primary package management tool of SUSE Linux computers. YaST being a graphical interface, the reader doesn't see a glimpse of the CLI through this portion of the chapter.

This changes when the focus shifts to using rsync to create a local mirror. The set up instructions operate at the same level as those presented in the previous chapter. Chapter 3 rounds out with a HOW TO on configuring a ZLM server and adding clients. Unfortunately, the author states that a full treatment of ZLM is beyond the scope of the book, so to find out more, you'll have to seek out supplementary material.

The next two chapters cover the apt system with the final two chapters discussing yum. Chapter 4, "Making apt Work for You" presents the fundamentals of apt. The pace slows down a little and the chapter takes time to introduce apt and how to use the various options it comes with. There is a set of instructions that discusses setting up an apt mirror but that area isn't as well covered as the "apt basics". Chapter 5, "Configuring apt for RPM Distributions" was written for apt fans who want to use RPM software packages. I didn't think I'd encounter a "history lesson" so deep into the book (history lessons are usually confined to the introductory chapter of a Linux text), but I found "A History of APT for RPM" nestled right at the beginning of the chapter. Apt can be configured to be used with Red Hat/Fedora, SUSE, and other distros and this material is touched upon here, as well as setting up apt RPM-based repositories. Although there was a section in Chapter 4 covering apt commands, a more detailed coverage is provided in this chapter, including Debian-only and RPM-only apt commands. Configuring apt for use with RPM isn't as easy as rolling off a log and the determined tech or admin might want gather other materials and read up a little more about the process before jumping right in.

The final two chapters of the book cover the yum system which is designed to natively handle RPM packages. Chapter 6 "Configuring a yum Client" describes (as you might imagine) how to set up yum clients, including a brief foray into Yellow Dog Linux and yum's predecessor, yup or Yellowdog Updater (continuing with this naming theme, Fedora Core 5 is introducing the Package Updater, also known as "Pup"). Fedora is the only distro that makes extensive use of yum, although there are repositories that service RHEL. This chapter is roughly analogous to Chapter 4's treatment of apt basics except that all the information regarding setting up a yum repository is reserved for the final chapter.

Chapter 7 "Setting Up a yum Repository" is the flip side of the previous chapter, instructing the reader on the ins and outs of configuring yum mirrors for both Fedora and RHEL. This and the previous chapter function well as bookends and are perhaps the two chapters in the book that best do so.

Summary

Michael Jang's Linux Patch Management: Keeping Linux Systems Up to Date is a variable smörgåsbord of Linux software managers compressed in a scant 288 pages. The text covers a brief rundown of the various major distros including Red Hat/Fedora, SUSE, and Debian and some variants as well as the various methods used by each of these to install and manage software packages including yum, YaST, and apt. While the primary focus of the book seems to be how to manage software deployment over a network using software repositories, the tools necessary to update an individual system or small LAN are also included. If you need to understand the comparative methods used by different "Linuxes" to manage patches, this book fits the bill.

Conclusion

This book takes on quite a chunk of information for a smaller text and has its strengths and weaknesses. If you are looking for a text that introduces you to Linux patch management across different distros, or as a tech or admin, you encounter a "mixed bag" of Linux servers in different environments, this is one handy book to have around. The downside is that there is only so much you can learn about any one software management system since the book apparently had to sacrifice detail for coverage. Don't get me wrong...Jang did a noble job of hitting all the high points of each software manager and distribution, but I wouldn't want to tackle any one of them without having more detailed information at my fingertips. While this book is a good place to start, you will still need supplementary material to become expert at configuring apt, YaST or yum for a networked environment. I'd like to see Jang expand the information and perhaps organize it a bit better for the 2nd Edition. Having said that, it does make a very good reference if you want a tour of all of these systems and it seems obvious that the author is familiar with each of them.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019