Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Softpanorama Search

Suse Installation in Large Enterprise Environment

News	Recommended Books	Recommended Links	SLES Installation Checklist	YaST	RPM	Packages
autoyast	SLES Registration	Swap partition	Siga	Installing Suse from ISO image	Humor	Etc

There are multiple ways to install and run SUSE Linux. See Boot from Suse SP2 Installation DVD or Other Medium from SLES 10 Installation Checklist . The latter conain several parts that might be useful for Suse administrators:

OpenSuse 10.2 packages are generally compatible with SLES 10.

There are two versions of Suse 32 bit and 64 bit. 64-bit version requires CPUs with extended instruction set (AMD64 and Intel 64 CPU). Intel Duo series used in D620 is such CPU. It cannot run on old Pentium 4.

For dual boot 64 bit system is better as it will match the system used on the server: For servers 64-bit version is better as it allow to access more then 16G of RAM and on configurations from 4G to 16G works faster.

The only exception is virtual machine environment: 32-bit kernel is better for VMware environment.

Availability of SUSE for 64-bit Intel and AMD hardware platforms does not necessarily mean that all the applications included have already been ported to 64-bit platforms. Often this is not true and some application even commercial one are distributed in 32-bit mode. OpenSuse supports the use of 32-bit applications in a 64-bit system environment.

To be executed correctly, every application requires a range of libraries. Unfortunately, the names for the 32-bit and 64-bit versions of these libraries are identical. They must be differentiated from each other by placement:

To retain compatibility with the 32-bit version, the libraries are stored at the same place in the system as in the 32-bit environment. The 32-bit version of libc.so.6 is located under /lib/libc.so.6 in both the 32-bit and 64-bit environments.
All 64-bit libraries and object files are located in directories called lib64. The 64-bit object files you would normally expect to find under /lib, and /usr/lib are now found under /lib64, and /usr/lib64. This means that there is space for the 32-bit libraries under /lib and /usr/lib, so the filename for both versions can remain unchanged.

Subdirectories of 32-bit /lib directories whose data content does not depend on the word size are not moved.

The installed 32-bit and 64-bit libraries must have an API (application programming interface) that matches the installed header files. The normal openSUSE environment is designed according to this principle.

The 64-bit kernels for x86_64 offer both a 64-bit and a 32-bit kernel ABI (application binary interface). The latter is identical with the ABI for the corresponding 32-bit kernel. This means that the 32-bit application can communicate with the 64-bit kernel in the same way as with the 32-bit kernel.
The 32-bit emulation of system calls for a 64-bit kernel does not support all the APIs used by system programs. This depends on the platform. For this reason, a small number of applications, like lspci, must be compiled
A 64-bit kernel can only load 64-bit kernel modules that have been specially compiled for this kernel. It is not possible to use 32-bit kernel modules.

In the case of manually updated libraries, you need to resolve these issues yourself.

The Linux Boot Process

The Linux boot process consists of several stages each represented by another component. The following list briefly summarizes the boot process and features all the major components involved.

BIOS After the computer has been turned on, the BIOS initializes the screen and keyboard and tests the main memory. Up to this stage, the machine does not access any mass storage media. Subsequently, the information about the current date, time, and the most important peripherals are loaded from the CMOS values. When the first hard disk and its geometry are recognized, the system control passes from the BIOS to the boot loader.
MBR boot Loader The first physical 512-byte data sector of the first device defined in BIOS load chain is loaded into the main memory and the program that resides at the beginning of this sector takes over. It usually loads another loader but it can do so only if the latter is located at fixed disk addresses as no file system is present. That's why it is often referred to as Master Boot Record (MBR). The boot loader then passes control to the actual operating system, in this case, the Linux kernel at /boot partition.
Kernel and initramfs MBR loads both the kernel and an initial RAM–based file system (initramfs) into memory. initramfs is a small cpio archive It contains a small executable that uses BIOS calls called init that handles the mounting of the real root file system. It provides a minimal Linux environment that enables the execution of programs before the actual root file system is created. This minimal Linux environment is loaded into memory by BIOS routines and does not have specific hardware requirements other than sufficient memory.
- init on initramfs This program performs all actions needed to mount the proper root file system on the installation media, like providing kernel functionality for the needed file system and device drivers for typical mass storage controllers. After the root file system has been found, it is checked for errors and mounted. If this has been successful, the initramfs is cleaned and the init program on the root file system is executed.
- Before the root file system can be mounted and the operating system can be started, the kernel needs the corresponding drivers to access the device on which the root file system is located. These drivers may include special drivers for certain kinds of hard drives or even network drivers to access a network file system. The needed modules for the root file system may be loaded by init on initramfs. After the modules are loaded, udev provides the initramfs with the needed devices. Later in the boot process, after changing the root file system, it is necessary to regenerate the devices. This is done by boot.udev with the command udevtrigger.

The main purpose of init on initramfs is to prepare the mounting of and access to the real root file system. Depending on your system configuration, init is responsible for the following tasks.

Loading Kernel Modules. Depending on your hardware configuration, special drivers may be needed to access the hardware components of your computer (the most important component being your hard drive). To access the final root file system, the kernel needs to load the proper file system drivers.
Providing Device Special Files. For each loaded module, the kernel generates device events. udev handles these events and generates the required device special files on a RAM file system in /dev. Without those special files, the file system and other devices would not be accessible.
Managing RAID and LVM Setups. If you configured your system to hold the root file system under RAID or LVM, init sets up LVM or RAID to enable access to the root file system later.
Managing Network Configuration. If you configured your system to use a network-mounted root file system (mounted via NFS), init must make sure that the proper network drivers are loaded and that they are set up to allow access to the root file system.

When init is called during the initial boot as part of the installation process, its tasks differ from those mentioned earlier:

Finding the Installation Medium. As you start the installation process, your machine loads an installation kernel and a special initrd with the YaST installer from the installation medium. The YaST installer, which is run in a RAM file system, needs to have information about the location of the installation medium to access it and install the operating system.
Initiating Hardware Recognition and Loading Appropriate Kernel Modules. The boot process starts with a minimum set of drivers that can be used with most hardware configurations. init starts an initial hardware scanning process that determines the set of drivers suitable for your hardware configuration. The names of the modules needed for the boot process are written to INITRD_MODULES in /etc/sysconfig/kernel. These names are used to generate a custom initramfs that is needed to boot the system. If the modules are not needed for boot but for coldplug, the modules are written to /etc/sysconfig/hardware/hwconfig-*. All devices that are described with configuration files in this directory are initialized in the boot process.
Loading the Installation System or Rescue System. As soon as the hardware has been properly recognized, the appropriate drivers have been loaded, and udev has created the device special files, init starts the installation system, which contains the actual YaST installer, or the rescue system.
Starting YaST. Finally, init starts YaST, which handles package installation and system configuration.

Installation from CD/DVD

CD/DVD are default installation medium for YAST. Local CD/DVD installations are very much the same for Solaris and OpenSuse. The installation program prompts for information when it is required. A menu of options is presented in some parts so that you can select the appropriate choice or choices. As with a Solaris installation, Linux will perform the following operations.

Probe the hardware for devices and load the appropriate device drivers.
Select language
Accept license agreement
Select a time zone.
Select GUI (Gnome of KDE). Gnome will be used in lectures.
Assign a host name.
Set up a network setup type (DHCP or static IP)
1. If static IP, you will be asked to enter the IP address, subnet mask, default gateway, and DNS servers to use.
2. You can also use DHCP.
Select installation type (the initial not upgrade ).
Repartition hard disk:
- Desktop has 150G drive
- Laptops have 100G drive
Prompt for a automatic or manual disk layout for the file systems. Select manual and allocate 4G for swap and 10G for root and 8G for /home partitions (if you have a separate /home partition you can upgrade system without need to restore your data)
Select filesystem for partitions. You should use ext3fs as your filesystem
Prompt for the software bundle or packages to install. You need carefully browse and add your own choices of software packages to the default selection proposed by the installer, so click on the Change button and select Software from the menu, which brings you to the main Software Selection screen
- suse installs vim and screen automatically
- Add several packages that I will use in lectures:
  - vino -- VNC for Gnome
  - mc (Midnight commander, requres glib),
  - gvim
  - expect (requres TCL).
  - Wireshark
  - nmap
  - Other packages that you might be interested in.

OpenSuse 10 usually recognizes most devices and installs without major hardware problems on standard desktop and laptop.

Note: In Solaris, the installation program will use the current console as an I/O device, and if you are using a serial interface, it will use that same serial interface. In Linux for IA32 , the default console device used for installation is the graphics card. If you need to install the system using a serial interface, you need to specifically tell the installation program to do so by adding the nofb console=ttyS0 kernel boot options.

Installing using remote display

In Solaris, you can install using the local graphic display or the serial interface. In Linux, you can install using the local graphic display, serial interface, and a few other remote modes.

In RHEL, you have the following options:

Add a display=IP_OF_REMOTE_X:0 argument to the kernel boot line for using a remote X Server for displaying the installation GUI.

Add a vnc vncpassword=MIN_6_CHAR_PASS argument to the kernel boot line for using a VNC client from another machine to connect to the installation GUI.

In SLES, you have the following options:

Add a usessh=1 sshpassword=MIN_1_CHAR_PASS argument to the kernel boot line for starting a ssh installation. If you connect with ssh -X, you can have graphical GUI.

Add a vnc=1 vncpassword=MIN_5_CHAR_PASS argument to the kernel boot line for using a vnclient from another machine to connect to the installation GUI.

Partitioning

The two minimum partitions are the root partition, signified with a forward slash (/), and a swap partition, which Linux uses as virtual memory. You also would benefit form a separate /home partitions for the reasons explained above. Traditionally, the size of the swap partition is equivalent to (or a multiple of) the amount of hardware RAM you have installed.

If you have only these two partitions, YaST will put all standard directories on the same partition as /. These are

/bin—Binary files.
/boot—Files to boot Linux.
/dev—Device drivers.
/etc—Configuration files.
/home—Each user gets a data directory under this one (should generally be a separate partition)
/lib—Libraries, the underlying code for many applications.
/media—Removable disks and drives (floppy discs, CD-ROMs, Zips).
/mnt—The mount directory, where all partitions (mount points) are listed.
/opt—Some applications install to this directory instead of /usr.
/proc—A dynamic directory where all running processes are logged. Constantly changing.
/root—Not to be confused with plain / (also called "root"), this is the home directory for the root user.
/sbin—System binaries, usually files that need to run during startup.
/srv—Services.
/tmp—Temporary files.
/usr—Most applications, libraries and man files.
/var—Variable data, including syslog, print spoolers, mail files, cron files, are stored here.

Fun with Configuration Files

Instead of a single file linux configuration files are often spitted into chunks which are stored then into directories. The main file just assembles the chunks. As in other areas of life this quest to more flexibility actually sometimes backfire and turns into its opposite.

Some of those "hacked" files include /etc/profile (with chunks stored at /etc/profile.d), crontab (crontab.d), syslog (actually Suse uses syslog-ng instead of regular syslog), etc. RC files are structures similarly to Solaris with links to each run level.

Some of the more important system-related configuration files in this directory are

fstab — corresponds to Solaris vfstab. Lists mountable storage devices. Structures are similar to Solaris and lists each device's mount point, its location on the partition table, instructions on whether it should mount automatically on boot, and a few other mounting options.
inittab —The system initialization table defines the different runlevels that the system uses at boot to start your computer. Changes to this file (which can be made manually, but also in YaST) can determine whether you boot to a graphical GUI or to text mode.
modprobe.conf and modprobe.conf.local —The main modprobe.conf file contains directions and options used when loading kernel modules to operate various pieces of hardware, such as sound cards, USB devices, network cards, and the like. The contents of this file are used during boot. SUSE updates this file from time to time so manual chances can be overwritten. You can use modprobe.conf.local to keep those changes from being overwritten.
passwd and shadow. Like Solaris Suse uses /etc/shadow to store hashes and password expiration information.

Choosing and Using a Shell

Suse uses different default shell then Solaris called Bash. Often new Suse users try to avoid it, preferring old ksh shell. But it is a better interactive shell then Korn shell.

Also the default ksh in linux is broken. That means that bash is preferable. Unless you are an expert in shell programming you will not notice any difference except more user friendliness (arrow keys work as well as ! command completion). Profiles for bash are usually better then profiles for ksh (which in many cases are dismal).

bash was one of the original GNU projects, it has been in development since 1987. Version 3.0 was released in July 2004. As you might guess from the name, bash (Bourne Again Shell) is the logical successor to the venerable Unix shell (sh) written by Steve Bourne. This is the best Korn-style interactive shell.

You can tweak bash's performance by editing the .bashrc configuration file. Root can edit the systemwide .bashrc, and each user on the system may have his or her own configuration file, although a user cannot override the system configuration.

Running YaST from the Shell

YaST is an old and rather clumsy tool with pretty idiosyncratic interface but it has goood capabilities to recognize hardware and install correct software. So while interface is antiquted 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.

This can also be useful in recovery mode when the system won't boot to the GUI login screen. It also can also serve for the installation of new packages if yast is configured correctly.

To maneuver around the menus and choices, use the accelerator keys highlighted on each screen. Press the Alt key with the highlighted letter to move to the item you want. For example, in any screen, press Alt+H to get Help on that screen. When finished, press Alt+Q to Quit and return to the shell prompt.

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

Old News ;-)

21 Jun 2007
Automate Installation of Web Server in openSUSE 10.2
Scott Morris shares a new bash script that will help you get a web server installed and running with minimal effort.
Scott Morris shares a new bash script that will help you get a web server installed and running with minimal effort.

30 Aug 2007
SUSE Linux Enterprise Desktop 10 Hands-Free Installations (feature)
Check out this new Novell Connection article by Nathan Conger for instructions on how to set up and configure a Network Installation Server for speedy, hands-free installations.

30 Aug 2007
Lock, Stock and Barrel: Moving SUSE Linux Enterprise to a new Machine (tip)
It turns out that SUSE Linux Enterprise won't boot properly if you move the hard drive from one machine to another machine (even if you connect the hard drive to the same controller). Not to worry - Muhammad Sharfuddin figured out a workaround, and shares it here.

30 Aug 2007
Installing SUSE Linux Enterprise Server Without a Bootable CD (tip)
Ashish Kumar shares a tip on how to install SLES on a machine that has Linux (boot loaded GRUB) already installed.

[Jan 28, 2008] Network Install HOWTO by Graham White

September 12, 2002 | IBM

SuSE Server Setup

4.1 Setting Up Filespace

4.2 Copy Installation Media

4.3 Enable Remote Access

4.4 Package Customisation

SuSE Client Install

5.1 Create AutoYaST Config Files

5.2 Boot the Machine

[Oct 8, 2007] Techzone Why SUSE Why

The installer certainly takes a while, but after the install, the system is set up with all online repose including non-oss repos (including if I remember correct packman) and all installed packages (and thus the whole OS) were up to date.

It certainly takes a while (though only an hour orso here) but it isn't 'antiquated'. It has many more options and features available than ubuntu and pclinuxos for example, and it leaves your system fully updated with all the latest updates.

That said, I do imagine that would be difficult to see after being bored to death for 6 hours. I certainly don't blame you for some hard feelings there. The livecd system would indeed by a good idea.

===

It is not necessary to download anything from the internet during installation. If you only want to use the CD medium uncheck the "Use online repositories" checkbox. It needs to be selected by default so netinstalls will "just work", and CD users can still have a complete experience with flash, java etc if they have an internet connection during install.

A live-cd with installer will be released in a week or so. (There is one for RC-1) This allows installing from the desktop as in some other distributions. It is significantly less flexible than the normal installer though. And using a livecd does not show whether things will work, in fact things are far less likely to work on a livecd.

Codec installation from packman you should find significantly easier than in previous versions. If you attempt to play an mp3 in e.g. amarok if you don't have fluendo's support installed (I think it will be if you included media from the online repositories) Then you would be linked to http://software.opensuse.org/codecs

The "community information" there will get you the fullest support, and will no longer require knowing how to add the packman repository etc.

Etc

Blogging is futile — SuSE sucks!

A guy with negative installation experience. Some points are well taken : attempt to minimize Suse breaks patching process, others are exaggerated. He also forgot to mention that OpenSuse is free.

Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Disclaimer:

The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with.
We do not warrant the correctness of the information provided or its fitness for any purpose
In no way this site is associated with or endorse cybersquatters using the term "softpanorama" with other main or country domains (e.g. softpanorama.com) with bad faith intent to profit from the goodwill belonging to someone else.

Last modified: February 08, 2010

Getting Started	view		size	last update
openSUSE 10.2 Start-Up	html	pdf	2 MB	12/07/2006
KDE Quick Start	html	pdf	2 MB	12/07/2006
GNOME Quick Start	html	pdf	2 MB	12/07/2006


User Guides	view		size	last update
KDE User Guide	html	pdf	.1 MB	12/07/2006
GNOME User Guide	html	pdf	10 MB	12/07/2006


Administration	view		size	last update
openSUSE 10.2 Reference Guide	html	pdf	7 MB	12/07/2006
AppArmor 2.0.1 Administration Guide	html	pdf	2 MB	12/07/2006
AppArmor 2.0.1 Quick Start	html	pdf	1 MB	12/07/2006


Additional Information	view	size	last update
Release Notes	html		12/07/2006