Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise Point of Service 11 SP3 and SUSE Linux Enterprise Point of Service 12 Image Server

10 SUSE Linux Enterprise Point of Service Customization

10.1 Using Terminals with IDs

Terminals can be registered not only under automatically generated names (see scEnumerationMask and scWorkstationBaseName ) but also under custom names. To enable this, a list of allowed IDs must be specified for the respective scLocation object. The scIdPool multivalue attribute is used to specify the list of allowed IDs. The IDs are entered sequentially via posAdmin:

posAdmin --DN cn=mybranch,ou=myorgunit,o=myorg,c=us --modify --multival
--scLocation --scIdPool '=>Id1'
posAdmin --DN cn=mybranch,ou=myorgunit,o=myorg,c=us --modify --multival
--scLocation --scIdPool '=>Id2'

Using posAdmin only, modifications to scIdPool can be cumbersome, especially when a large number of IDs is present. It is therefore preferable to use the pos script and its id-list, id-add and id-delete subcomands (for more information, see Section B.3.12, “pos”.

Using posAdmin only, modifications of scIdPool can be cumbersome, especially when a large number of IDs is present. This can be alleviated by taking advantage of scIdPool being a multivalued attribute.

When scIdPool is defined, the posleases2ldap script creates the /srv/tftpboot/KIWI/idlist file for terminals to allow ID selection from the pool of values.

When the ID is selected for a given terminal, it is written under the respective scWorkstation object into the scId attribute.

10.2 Using Terminals with Roles

To set up the LDAP database for a role-based approach, the following is necessary:

Note: Creating Necessary Objects with pos

Necessary LDAP objects can be created with posAdmin. You can also use pos, which is easier to use but less general. For more information about pos, see Section B.3.12, “pos”.

10.2.1 Creating the scRole Object

Create the scRole object with the following attributes:

Table 10.1: Attributes for scRole Elements






cn name.



Name of the role displayed in the list on terminal.



Description of the role displayed in the list on terminal.



Multi-value parameter, marks role to be used only with given hardware types.

The scRole object must be located under scRefObjectContainer, which can be located either under the organization or scLocation object. If the role object is located under scLocation, the role is considered local. If the role object is located above scLocation, it is global.

Assuming the scLocation DN is cn=mybranch,ou=myorgunit,o=myorg,c=us, the command to add scRefObjectContainer rolecontainerA under the location is:

posAdmin --base cn=mybranch,ou=myorgunit,o=myorg,c=us --add --scRefObjectContainer --cn rolecontainerA

To add a role roletest, use:

posAdmin --base cn=rolecontainerA,cn=mybranch,ou=myorgunit,o=myorg,c=us --add --scRole --cn roletest --scRoleName 'Testing Role' --scRoleDescription 'Testing description'

10.2.2 Adding Related Objects Under scRole

In the role-based approach, the role object contains scCashRegister objects, which are used in the same sense as the scCashRegister objects under global container (cn=global,o=myorg,c=us in our example) in the non-role-based (legacy) mode.

When a role is selected in a terminal, posleases2ldap tries to find the role in the LDAP database, finds the appropriate scCashRegister object (with scCashRegisterName equal to the HWTYPE of the terminal or default) and uses it to find the scPosImage and other releavant data. The scCashRegister under scRole needs to contain an scDevice object as in the legacy case.

scRole can also contain configuration objects, the scConfigFileTemplate, scConfigFileSyncTemplate and scPxeFileTemplate. These configuration objects can be located under scPosImage, scRole, scCashRegister, scWorkstation objects, and linked by the scConfigFileDn attribute of the scWorkstation object with priority increasing from the former to the latter.

For terminals that should use a role, put a specific or a default scCashRegister under the scRole as in the legacy mode (see Section, “Adding an scCashRegister Object”.

10.2.3 Enabling Roles

To enable roles for a given scLocation, set appropriate values in the scAllowRoles and scAllowGlobalRoles attributes of the relevant scLocation object. The attributes have the following effects:

Table 10.2: Effects of scAllowRoles and scAllowGlobalRoles Attributes






Role-based mode, all roles enabled.



Role-based mode, only roles under scLocation are used.



Non-role-based legacy mode (SLEPOS10, NLPO9 like).



Non-role-based legacy mode (SLEPOS10, NLPO9 like).

To set the scAllowRoles attribute, use:

posAdmin --DN cn=mybranch,ou=myorgunit,o=myorg,c=us --modify --scLocation --scAllowRoles FALSE

Proceed accordingly for other cases.

If roles are enabled, relevant role list files are created in the /srv/tftpboot/KIWI directory. The booting terminal uses these files to show the list of available roles. Then the booting terminal reports the selected role back to the Branch Server in the hwtype.MAC.hash file. The file is processed by the posleases2ldap command to create the /srv/tftpboot/KIWI/config.MAC according to the data specified in the scRole and update or create a new scWorkstation registration in the LDAP.

The terminal then reads the config.MAC file and continues the booting sequence accordingly.

Effectively, each scRole object behaves as a whole LDAP in the previous legacy mode, enabling different behavior for the same terminal type according to the role selected.

10.3 API Description

The API allows third-party terminal-based applications to perform operations on the Branch Server or Administration Server, such as getting lists of available roles and IDs or changing these.

All communication between the client and the server is performed via the TFTP protocol. The terminal is identified by its MAC address to get information about the current terminal configuration. The client downloads the KIWI/config.MAC file.

10.3.1 The KIWI/config.MAC file

The KIWI/config.MAC file consists of VARIABLE=value pairs. It should contain at least these variables:


  • POS_ID



10.3.2 Getting Lists of Available Roles and IDs

To get a list of available IDs, the KIWI/idlist file should be read. This file has a one ID per line format.

To get the list of available roles, the following files should be read in the presented order. The file found first should be used:

  1. KIWI/rolelist.MAC

  2. KIWI/rolelist.encoded hwtype

  3. KIWI/rolelist

The encoded hwtype is the original hwtype string with all characters not matching the regular expression [-_A-Za-z0-9] changed to their hex values in the %xx format. For example a b is encoded as a%20b.

The format of the list of available roles is as follows:


10.3.3 Changing ID and/or Role

  1. The client uploads the upload/hwtype.MAC.HASH file. HASH is the MD5 checksum of the file content. The file consists of NAME=value pairs. It should use only values where a change is requested. Supported names are:

    • POS_ID

    • POS_ROLE

    Note: Clearing the ID

    There is a difference between POS_ID= (which clears the ID) and missing POS_ID (which keeps it unchanged).

  2. The client waits until the uploaded file disappears, which the client checks by trying to download the file.

  3. The client reads KIWI/config.MAC. POS_HWTYPE_ERR_HASH == HASH means that an arror occured. The POS_ERR variable contains information about the error. If there are no errors and the POS_ID variable contains the assigned ID, POS_ROLE contains the assigned role and IMAGE is not empty, the change has been successful.

10.4 Using Role Related Hooks

When booting an image for the first time, the KIWI boot code runs, where users can hook in custom shell script code in several places to extend the boot workflow according to their needs. The following Role-related hooks can be used for modifying the boot process of the terminal (for example to replace the role/ID selection dialog).

In general, a hook that only sets the variables to fixed values can be replaced by putting the variables in the kernel command line.

Note: Hooks Used by Netboot Images

Certain KIWI hooks are used by SUSE Linux Enterprise Point of Service netboot images therefore they cannot be used for customization. The following hooks are used by netboot:


10.4.1 hooks/roles.sh

This hook is called after downloading the role configuration. It can either take over the boot process completely (use the roles API and reboot at the end) or set variables that affect the boot process.

It takes the following inputs:


Path to a locally stored Id list file (the file may be empty or missing).


Path to a locally stored role list file (the file may be empty).


Path to a locally stored roll back file (the file may be empty).


Path to locally stored configuration file (the file may be empty).

The hook can overwrite the $CONFIG file with a new configuration. It can also set the following variables:


Disables the Press C to change configuration message if not empty.


If not empty, forces the role selection and new registration (instead of using the role from $CONFIG).


Selected ID.


Non-empty value indicates that the ID selection has been timed out and the value should be selected by the server.


Selected role DN.


Non-empty value indicates that the role selection has been timed out and the value should be selected by the server.


If non-empty, do not show the role dialog. This should be selected if the hook itself sets the values of the POS_SELECTED_* variables.

10.4.2 hooks/selectRole.sh

This hook can replace the role selection dialog. It is only called when the machine is newly registered or when the role selection was forced. It is not called during normal boot with existing config.MAC. It can show an alternative role selection dialog and/or set the variables POS_SELECTED_* and POS_DISABLE_ROLE_DIALOG, which are described above.

10.5 Securing Your Setup

A SUSE® Linux Enterprise Point of Service setup includes various components that should be secured against intentional and unintentional tampering with the data and against software misbehavior. Securing your setup involves several different aspects:

Physical Server Security

First and foremost, every server component of the SUSE Linux Enterprise Point of Service setup must be secured against unauthorized access. Physically isolating the servers from other machines is one aspect of providing physical security. For details, refer to Section 10.5.1, “Physical Server Security”.

Network Security

All servers connected with each other over potentially insecure networks, for example, Administration Server and Branch Server, need to be secured against unauthorized access via the networks they are connected to. For details, refer to Section 10.5.2, “Network Security”.

Data Security

Both the Administration Server and the Branch Servers contain vital data that need to be protected to maintain a fully functional and secure setup. The most important part is securing the LDAP directory on the Administration Server, which is used to maintain the system structure, configuration and deployment method for all Branch Servers and Point of Service terminals, and other important data. For details, refer to Section 10.5.3, “Data Security”.

Application Security

When physical, network and data security are provided, tighten the security of your setup even further by using AppArmor. AppArmor profiles are used to confine applications and keep them from performing unnecessary file or directory accesses and this helps to make sure that every profiled application only does what it was designed to do and cannot become a security risk. For more details on AppArmor usage on SUSE Linux Enterprise Point of Service, refer to Section 10.5.4, “Application Security”.

10.5.1 Physical Server Security

Your instance of SUSE Linux Enterprise Point of Service is set up in a highly secure corporate environment using third-party security solutions and various other security measures, but you still need to make sure that nobody gains unauthorized physical access to your severs and can log in to tamper with your setups.

The following list provides a few basic security-related things you should bear in mind when creating your setup:

  • Keep your severs in a separate server room that is only accessible to a few authorized people gaining access only via key cards, key codes, PIN numbers, finger print authentication, etc.

  • Use BIOS and boot loader passwords to prevent anyone from manipulating the boot process of your servers.

10.5.2 Network Security

Even if your SUSE Linux Enterprise Point of Service network is secured against the Internet (using third-party security solutions and firewalls), secure your severs against unauthorized access from inside:

  • All servers should only allow access from the root account.

  • Make sure to enable a strong encryption method like WPA2 when a Wi-Fi connection is used for communication between the terminals and the branch servers or between the servers in the SLEPOS infrastructure.

  • Create one single user account via YaST, namely the root account.

  • Do not export or import any file systems on these servers, for example, do not allow NFS or Samba shares on your servers.

SUSE Linux Enterprise Point of Service provides some security against data manipulation via the network:

  • LDAP-related network traffic can be configured via secure SSL/TLS channels.

  • Image data is exchanged between servers via rsync and md5sums are calculated and checked to provide data integrity.

10.5.3 Data Security

The most vital data of your SUSE Linux Enterprise Point of Service setup is stored in the LDAP directory on the Administration Server. Whoever gains control over this setup data can manipulate the setup of any server or terminal in your setup. Therefore, limit the list of users with access to the LDAP directory to the bare minimum and make sure they obtain the least possible privileges only. Use LDAP Access Control Lists (ACL) as part of the LDAP server configuration to restrict access to your LDAP data.

The configuration of your OpenLDAP server is located under /etc/openldap/slapd.conf. For more information on how this configuration file is generated and maintained, refer to Section B.3.3, “posInitAdminserver”.

ACLs allow you to specify separate access controls to different parts of the configuration. You can create different ACLs for user password data, server configuration data, and configuration of different locations, and so forth.

Before creating ACLs, perform an analysis of users and privileges needed to run your configuration. These may depend on the type of setup you have chosen and may vary. As an example, let us assume you run the following setup:

  • A central Administration Server managed by the global administrator role.

  • Independent Branch Servers managed by local administrators.

Thus, you need to make sure that both, your user configuration on the Administration Server and the ACLs in the LDAP server configuration reflect these roles and provide suitable privileges to these user roles without providing too many privileges.

The following example includes creating effective ACLs and a user setup as outlined above. Modify both the ACLs and the user configuration to match your own setup:

  1. Create ACLs similar to the following and make sure you replace the example entries by the ones matching your setup. Ensure the more general rules are specified after the more specific ones. The first matching rule is evaluated and the following rules are ignored:

    access to dn.base="" by * read 1
    access to * attrs=userPassword 
        by anonymous auth 
        by self write 2
    access to dn.regex="^.*(cn=.*,ou=.*,o=myorg,c=us)$"
        by dn.regex="^.*,$1$" write
        by users read 3 
    access to *
        by self write 
        by users read 4


    Allow read access to the Root-DSE.


    Allow unauthenticated clients to use the userPassword attribute for authentication. Authenticated clients (users) are allowed to change their own password.


    Allow access to any DN matching the regular expression. Using the $, you limit the matches to those strings that contain nothing beyond the last character. All DNs matching the regular expression are granted write access, and authenticated users may read the objects, but not write to them.


    Allow access to anything. Entries themselves may write to their entries, authenticated users may read them, but not modify the entries.

  2. For each location, create a location user. For example, create a user for each branch location. This user is then granted (write) access to all LDAP data concerning his location, but cannot change the data of the other locations.

    posAdmin --base cn=mybranch,ou=myorgunit,o=myorg,c=us --add --scPOSUser --cn mybranchuser --userPassword "locationPassword"
  3. Now the --user option can be set to the following in all posAdmin commands concerning the cn=mybranch,ou=myorgunit,o=myorg,c=us location:

    --user cn=mybranchuser,cn=mybranch,ou=myorgunit,o=myorg,c=us

    The default LDAP user can now be replaced by this user, especially for the posInitBranchserver command.

    Enter the DN of the LDAP user for administration tasks [default: cn=admin,o=myorg,c=us]
Tip: For More Information

For more details on the syntax of the slapd.conf configuration file and the ACLs, refer to the manual pages of slapd.conf(5), slapd.access(5), and slapacl(8). The slapacl command allows you to verify that your ACLs work as planned.

10.5.4 Application Security

Any piece of software used in your setup probably contains some inherent security vulnerabilities, which mostly slip by unnoticed as the respective functions may not be used routinely. To protect your setup from these vulnerabilities, SUSE Linux Enterprise Server and SUSE Linux Enterprise Point of Service come with the AppArmor protection framework. AppArmor provides profiles for some of the most important applications that specify which files these programs are allowed to read, write and execute. By using these profiles, you ensure that a program does what it is supposed to do and nothing else.

Use AppArmor to protect each of your servers. If you need additional profiles, use the YaST AppArmor tools to generate new profiles. To learn more about AppArmor, refer to the AppArmor documentation included in the Security Guide available at http://www.suse.com/documentation/sles11/.

10.5.5 Using Encrypted Partitions on Terminals

Image passwords can be defined for both system partition (partition containing system image) and data partition. Since the former is image- and version-related and the latter is data partition-related, the location differs in LDAP and setup.

There are two possible configurations, with passwords present on Branch Server only and with passwords stored also on a USB flash drive.

If passwords are stored on the Branch Server only, the configuration is more secure, but network connection to the Branch Server is needed to mount the encrypted partitions and the service partition cannot be encrypted. For the best security, do not use the service partition and related features (such as Wi-Fi). If the service partition is used, kernel, initrd, Wi-Fi credentials and other files stored on the service partition are unencrypted.

If the passwords are also stored on a USB flash drive, the setup is less secure, manual setup is needed, but booting without network access to the Branch Server is possible. For more information, see Section, “Storing Passwords on a USB Flash Drive”

To enable system partition encryption (to use an encrypted image), add a version of the respective scPosImage via the scImageVersion object, with the following attributes: scVersion=X.Y.Z, scDisabled=FALSE, scPassword=password

It is not possible to enter a password via the scPosImageVersion attribute of the scPosImage object. Password protected image versions must be added via scImageVersion objects. Image versions defined via scPosImageVersion and scPosVersion are used together. In case of conflict, the scPosVersion object takes precedence.

For example:

 posAdmin --base cn=minimal,cn=default,cn=global,o=myorg,c=us --add --scImageVersion --scDisabled FALSE --scVersion 2.1.5 --scPassword 'secret'

For more information about the scImageVersion object, see Section 11.5.19, “scImageVersion”.

Note: Encrypting the System Partition

To enable encryption for the system partition, you must use an encrypted client image. It can be created in KIWI by specifying the luks="PASSWORD" attribute in the config.xml configuration file. For example:

<type checkprebuilt="true" boot="netboot/suse-SLES12" fsnocheck="true"
filesystem="ext3" compressed="true" image="pxe" luks="linux">

To enable encryption for a data partition, define the partition via the scPartition object placed under the appropriate scHarddisk object with the following attributes: scPartNum=0, scPartType=83, scPartMount='/', scPassword=password. For an explanation of the scPartition parameters, see Section 11.5.20, “scPartition”.

It is not possible to enter a partition password using the scPartitionsTable attribute, and these two approaches are mutually exclusive. The partition table defined via scPartition object has higher priority than the definition via scPartitionsTable. If an scPartition object is present, scPartitionsTable is ignored.

A password for the root (scPartMount='/') partition supplied via this mechanism is ignored since for the root partition the image password is used.

For example:

posAdmin --base cn=sda,cn=cshr4152,cn=global,o=myorg,c=us --add --scPartition --scPartNum 0 --scPartSize 2000 --scPartMount 'x' --scPartType 82 --description 'swap'
posAdmin --base cn=sda,cn=cshr4152,cn=global,o=myorg,c=us --add --scPartition --scPartNum 1 --scPartSize 4000 --scPartMount '/' --scPartType 83 --description 'root partition'
posAdmin --base cn=sda,cn=cshr4152,cn=global,o=myorg,c=us --add --scPartition --scPartNum 3 --scPartSize 12000 --scPartMount '/data' --scPassword 'secret' --scPartType 83 --description 'data'

For more information about the scPartition object, see Section 11.5.20, “scPartition”.

Note: Using an Un-Encrypted Image Again

If you deploy an encrypted image to the terminal and then change the default image to a non-encrypted image and reboot the terminal, you will be asked for the luks password. Select No and the dialog disappears. Storing Passwords on a USB Flash Drive

It is recommended to create a USB flash drive to enable local boot with encrypted data partition without connection to the Branch Server. The disk should be kept in a secure place. To create the disk, follow these steps:

  1. Insert a USB flash drive formatted with Ext3 when the system is running.

  2. Create a fstab entry for it:

    mkdir /usb_key
    echo "/dev/sdb1 /usb_key ext3 defaults,nofail 1 2" >> /etc/fstab
  3. Mount it:

    mount /usb_key
  4. Create a keyfile:

    dd if=/dev/random of=/usb_key/keyfile count=1 bs=512
  5. Add the keyfile to the second slot of the luks container:

    cryptsetup luksAddKey /dev/sda3 /usb_key/keyfile

    And enter the first slot password (found in LDAP or config.mac). /dev/sda3 is the encrypted data partition.

  6. Add the crypttab entry:

    echo "luks_sda3 /dev/sda3 /usb_key/keyfile luks" >/etc/crypttab

After the local boot, the encrypted partition will be mounted automatically. For details, see man crypttab and fstab.

10.6 Specifying Kernel Command Line Options for Selected Terminals

To specify kernel command line options for selected terminals, the scPxeFileTemplate object must be added to the LDAP database. This object can be placed in the same position as scConfigFileTemplate and scConfigFileSyncTemplate (typically under the scCashRegister object).

For example, if the test terminal is registered via scCashRegister cn=cashreg1,cn=global,o=myorg,c=us, you can create scPxeFileTemplate pxetest under this scCashRegister with the command:

--base cn=cashreg1,cn=global,o=myorg,c=us
--add --scPxeFileTemplate --cn pxetest --scMust TRUE
--scKernelParameters 'vga=785, RELOAD_IMAGE=yes'

After posleases2ldap is run and the machine registered, there should be a specific PXE file in the /srv/tftpboot/boot/pxelinux.cfg directory. The name of the file is derived from the MAC address of the machine, prefixed with 01 and with digit pairs separated with -, for example: 01-00-11-25-a7-d6-1e.

The file should contain the line 'append default parameters, vga=785, RELOAD_IMAGE=yes', where default parameters are the same parameters as those in the default PXE file in the same directory as well as any other kernel parameters specified in other scPxeFileTemplate objects or created via a specific kernel or initrd in the scDistributionContainer.

The order of parameters is determined by the objects under which they are specified. Linux and initrd are specified first, then parameters from scPxeFileTemplate objects located under scPosImage, scRole, scCashRegister, scConfigFileDn attributes of scWorkstation and under scWorkstation itself.

10.6.1 Specifying Kernel Parameters for All Terminals

To specify kernel paramters for all terminals on all branches at once, place the scPxeFileTemplate under the default distribution container (the scDistributionContainer with cn=default). To specify kernel parameters for all terminals on a single branch, place the scPxeFileTemplate under scLocation or under the TFTP service object of this branch.

Such PXE objects will then be considered default and will be written into /srv/tftpboot/boot/pxelinux.cfg/default and used by all terminals on the given Branch Server. ata in this file are regenerated during each main cycle of posleases2ldap and during the Branch Server initialization by posInitBranchserver.

SUSE Linux Enterprise Point of Service uses some standard default PXE parameters (from the TFTP_DEFAULT_KERNEL_PARAMETERS line in the default configuration file), which are appended under scLocation during the initialization of the Branch Server by posInitBranchserver as an scPxeFileTemplate object named posdefaults.

If a terminal also uses a specific PXE parameter object and a specific PXE file (01-M-A-C..) is generated, the default parameters from the default PXE are also present there. However, they have lower priority (they are written before the specific parameters).

10.7 Configure KIWI to Use the FTP Protocol

KIWI needs atftp only for loading the kernel and initrd. For downloading the actual image the FTP protocol can be used.

To enable FTP, follow these steps:

  1. Create a scPxeFileTemplate under the relevant object (used during registration of the terminal that needs this functionality) of scRole or scCashRegister or scPosImage. Default kernel parameters can also be used. For more information, see Section 10.6.1, “Specifying Kernel Parameters for All Terminals”. Set the following parameters: scMust TRUE, scKernelParameters kiwiservertype=ftp.

  2. Add the scService object under scBranchserver with scServiceName ftp, scDnsName ftp and scServiceStatus TRUE.

  3. Make sure that the needed ports are open on the network interface, where terminals are connected. The FTP/21 port must be open. The open passive port range (default 30000:30400) must match the pure-FTP configuration in /etc/SLEPOS/template/pure-ftpd.conf.template.

  4. Reinitialize the Branch Server if the pure-FTP server has not yet been initialized.

  5. Boot the terminal.

10.8 Changing the Server Language

If you need to change the language that was defined during the initial installation of a SUSE® Linux Enterprise Point of Service Administration Server or Branch Server, you can do so by restarting YaST and selecting a different system language.

10.8.1 Changing the Language Selection

To change the language of your Administration or Branch Server:

  1. Start YaST.

  2. In the YaST control center, select System › Choose Language.

  3. Select the desired language, then click Accept.

    The language selected in YaST applies to the operating system, including YaST and the desktop environment. If your system needs additional packages to support the new language, you can install them with YaST.

10.8.2 Installing a Language RPMs

To install the RPMs required to support the selected language on the server:

  1. In the YaST control center, select Software Management.

    The YaST package manager dialog appears (see Figure 10.1, “YaST Package Manager”).

    YaST Package Manager
    Figure 10.1: YaST Package Manager
  2. Use the Filter › Languages option to verify that the required language support for the Administration Server or Branch Server features is installed on your system.

    • If the language is selected, it is already installed on your system and you do not need to select it.

    • If the language is not selected, it is not installed on your system. Select the required language for installation.

  3. Click Accept to install the selected language support.

  4. Exit YaST.