SUSE Manager for Retail 3.2 is an open source infrastructure management solution, optimized and tailored specifically for the retail industry. It uses the same technology as SUSE Manager, but is customized to address the needs of retail organizations.
SUSE Manager for Retail is designed for use in retail situations where customers can use point-of-service terminals to purchase or exchange goods, take part in promotions, or collect loyalty points. In addition to retail installations, it can also be used for novel purposes, such as maintaining student computers in an educational environment, or self-service kiosks in banks or hospitals.
SUSE Manager for Retail is intended for use in installations that include servers, workstations, point-of-service terminals, and other devices. It allows administrators to install, configure, and update the software on their servers, and manage the deployment and provisioning of point-of-service machines.
Migrating configuration from SUSE Linux Enterprise Point of Service to SUSE Manager for Retail is a technology preview and will be enhanced in future releases of SUSE Manager.
This document provides an overview of SUSE Manager for Retail, and guides you through initial installation and setup. It should be read in conjunction with the SUSE Manager documentation suite, available from https://www.suse.com/documentation/suse-manager-3/
For more information about managing your SUSE Manager for Retail environment, or to find out where to get help, see https://www.suse.com/documentation/suse-manager-for-retail-3-2/retail-getting-started/retail.chap.next.html
SUSE Manager for Retail uses a layered architecture:
The first layer contains the SUSE Manager server and one or more build hosts.
The second layer contains one or more branch servers to provide local network and boot services.
The final layer contains any number of deployed point-of-service terminals.
The SUSE Manager server contains information about infrastructure, network topology, and everything required to automate image deployment and perform day-to-day operations on branches and terminals. This can include database entries of registered systems, Salt pillar data for images, image assignments, partitioning, network setup, network services, and more.
Build hosts can be arbitrary servers or virtual machines. They are used to securely build operating system images. Build hosts should be based on SUSE Linux Enterprise Server 12 SP3.
Branch servers should be physically located close to point-of-service terminals, such as in an individual store or branch office. We recommend you have a fast network connection between the branch server and its terminals. Branch servers provide services for PXE boot, and act as an image cache, Salt broker, and proxy for software components (RPM packages). The branch server can also manage local networking, and provide DHCP and DNS services.
The branch server can operate in several different network configurations:
The branch server has a dedicated network interface card and terminals use an isolated internal branch network. In this configuration, the branch server manages the internal network and provides DHCP, DNS, PXE, FTP, and TFTP services.
The branch server shares a network with the terminals, and provides a connection to the SUSE Manager server. In this configuration, the branch server is not required to manage a network (DHCP and DNS services), but acts as a PXE boot server and provides FTP and TFTP services.
For more information on SUSE Manager for Retail Branch servers, see documentation on SUSE Manager Proxy servers.
Point-of-Service (PoS) terminals can come in many different formats, such as point-of-sale terminals, kiosks, digital scales, self-service systems, and reverse-vending systems. Every terminal, however, is provided by a vendor, who set basic information about the device in the firmware. SUSE Manager for Retail accesses this vendor information to determine how best to work with the terminal in use.
In most cases, different terminals will require a different operating system (OS) image to ensure they work correctly. For example, an information kiosk has a high-resolution touchscreen, where a cashier terminal might only have a very basic display. While both of these terminals require similar processing and network functionality, they will require different OS images to ensure that the different display mechanisms work correctly.
The minimum memory requirement is 1024 MB for hosts that need to run OS images built with Kiwi (PXE booted or not)
Hardware Requirements for PoS Terminals: . At least 1 GB of RAM. For more information, see the documentation of the underlying system (in this case: SUSE Linux Enterprise Server 12). . Enough disk space depending on the image size.
For more information on SUSE Manager for Retail PoS terminals, see documentation on SUSE Manager Salt clients.
SUSE Manager for Retail uses the same technology as SUSE Manager, but is customized to address the needs of retail organizations.
Because every environment is different, and can contain many different configurations of many different terminals, SUSE Manager for Retail uses hardware types to simplify device management.
Hardware types allow you to group devices according to manufacturer and device name, so that all devices of a particular type can be managed as one.
SUSE Manager for Retail uses Salt formulas to help simplify configuration. Formulas are pre-written Salt states, that are used to configure your installation.
You can use formulas to apply configuration patterns to your hardware groups. SUSE Manager for Retail uses the Saltboot formula, which defines partitioning and OS images for terminals.
You can use default settings for formulas, or edit them to make them more specific to your environment.
Formulas are discussed in more detail in this guide, at Formulas Chapter.
SUSE Manager for Retail uses system groups to organize the various devices in your environment.
Each branch requires a system group, containing a single branch server, and the PoS terminals associated with that server. Each system group is identified with a Branch ID, which is used in formulas and scripts to automatically update the entire group.
Before you install SUSE Manager for Retail, ensure your environment meets the minimum requirements. This section lists the requirements for your SUSE Manager for Retail installation. These requirements are in addition to the SUSE Manager requirements listed at https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-getting-started/html/book.suma.getting-started/quickstart.chapt.overview.requirements.html#quickstart.sect.prereq
SUSE Manager for Retail is only supported on x86_64 architecture.
Hardware | Recommended |
---|---|
CPU | Multi-core 64-bit CPU |
RAM: | Test Server Minimum 8 GB |
Base Installation Minimum 16 GB | |
Production Server Minimum 32 GB | |
Disk Space: |
|
| |
| |
|
Hardware | Recommended |
CPU | Multi-core 64-bit CPU |
RAM: | 4 GB |
Disk Space: |
|
Hardware | Recommended |
CPU | Multi-core 64-bit CPU |
RAM: | 8 GB |
Disk Space: |
|
The SUSE Manager server requires a reliable and fast WAN connection
The branch server requires a reliable WAN connection, to reach the SUSE Manager server
If you are using a shared network, ensure that DHCP requests are filtered before reaching the rest of your shared network
If you are using a dedicated network, the branch server requires at least two network interfaces: one connected to the WAN with reachable SUSE Manager server, and one connected to the internal branch LAN.
Terminals require a LAN connection to the branch server network.
SUSE Manager for Retail can be installed in various ways depending on individual needs. We recommend these steps:
Install the SUSE Manager server
Configure the SUSE Manager server
Install the SUSE Manager for Retail pattern on the SUSE Manager server
Install the build host and register it to SUSE Manager
Configure the build host
Create required system group
Branch server installation steps:
Install the branch server and register it to SUSE Manager
Assign and configure branch server formulas
Synchronize images to the servers
Each procedure is detailed in this section.
For instructions to install SUSE Manager, see the https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-getting-started/html/book.suma.getting-started/quickstart.chapt.overview.requirements.html#quickstart.sect.introduction
Do not enable PXE boot functionality on the SUSE Manager Proxy during initial setup. This functionality will be installed later, after the initial setup.
It is important that all required SUSE channels are available on your system and synchronized in order for SUSE Manager for Retail to operate correctly. For more information on channel management, see https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-advanced-topics/html/book.suma.advanced.topics/suse.mgr.command.line.tools.html#syncing.suse.mgr.repositories.scc
Channels required for SUSE Manager for Retail functionality:
- SLES 12 SP3 (SP4 in the future) as a base - SLES Pool - SLES Update - SUSE Manager 3.2 Tools - SUSE Manager 3.2 Tools Pool - SUSE Manager 3.2 Tools Update - SUSE Manager 3.2 Proxy - SUSE Manager 3.2 Proxy Pool - SUSE Manager 3.2 Proxy Update - SUSE Manager 3.2 Proxy for Retail - SUSE Manager 3.2 Proxy for Retail Pool - SUSE Manager 3.2 Proxy for Retail Update
After you have synchronized the required SUSE channels, create channels for any custom software. Channels are used to provide custom software for OS image building. For more information on software channels, see https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-reference/html/book.suma.reference.manual/ref.webui.channels.html
Install the SUSE Manager for Retail
pattern on the SUSE Manager server:
zypper in -t pattern suma_retail
Check that you have these packages installed and available, after installing SUSE Manager and SUSE Manager for Retail pattern:
bind-formula
branch-network-formula
dhcpd-formula
image-sync-formula
pxe-formula
saltboot-formula
susemanager-retail-tools
tftpd-formula
vsftpd-formula
Install any missing packages with zypper
:
zypper install package_name
Synchronize the salt filesystem and salt modules:
salt-run fileserver.update salt '*' saltutil.sync_all
Restart the salt master service to pick up the changes:
Restart salt master service now. systemctl restart salt-master
For more information about formulas, see Formulas.
Your build host should be a Salt minion, running SUSE Linux Enterprise Server 12 SP3. For instructions to install Salt minion see https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-getting-started/html/book.suma.getting-started/preparing.and.registering.clients.html
The build host must be a Salt minion. Do not install the build host as a traditionally managed client.
The build host must be set as an OS Image build host in the SUSE Manager Web UI, and highstate applied.
In the SUSE Manager Web UI, navigate to
→ . Locate the system to be made a build host, and click on its name.In the System Properties
window, click .
In the Edit System Details
window, ensure the OS Image Build Host
option is checked, and click to save your changes.
Select the States
tab, and navigate to the Highstate
window.
In the States
tab, click .
Check that the build host has these packages installed after you have run Highstate:
kiwi
kiwi-desc-saltboot
If any package is missing, make sure the SUSE Manager 3.2 Tools
repository is available on the build host and install any missing packages manually using zypper install
.
SUSE Manager for Retail requires system groups for terminals and servers. Manually create these system groups during installation:
TERMINALS
SERVERS
Additionally, you will need to create a system group for each branch server, and each terminal hardware type in your environment.
You can create system groups using the SUSE Manager Web UI. Navigate to
→ and click on .For more information about system groups, see https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-reference/html/book.suma.reference.manual/ref.webui.systems.systems.html#ref.webui.systems.systemgroups
Your branch server should be installed as a default Salt-based client ("minion"), running SUSE Manager Proxy 3.2.
Do not install the branch server as a traditionally managed client.
For instructions to install Salt-based proxy minions and register them to SUSE Manager, see https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-advanced-topics/html/book.suma.advanced.topics/advanced.topics.proxy.quickstart.html
The activation key should have the following channels:
- SLES 12 SP3 (SP4 in the future) as a base - SLES Pool - SLES Update - SUSE Manager 3.2 Tools - SUSE Manager 3.2 Tools Pool - SUSE Manager 3.2 Tools Update - SUSE Manager 3.2 Proxy - SUSE Manager 3.2 Proxy Pool - SUSE Manager 3.2 Proxy Update - SUSE Manager 3.2 Proxy for Retail - SUSE Manager 3.2 Proxy for Retail Pool - SUSE Manager 3.2 Proxy for Retail Update
For mass deployments, see Branch Server Mass Configuration.
When you are installing the branch server with a dedicated internal network, check that you are using the same fully qualified domain name (FQDN) on both the external and internal branch networks. If the FQDN does not match on both networks, the branch server will not be recognized as a proxy server.
Before you configure the branch server, ensure you have decided on networking topology, and know the Salt ID of the branch server.
The branch server can be configured automatically using the retail_branch_init
command, as shown in this section.
If you prefer to manually configure the branch server, you can do so using formulas.
For more information about formulas, see Formulas.
Branch server configuration is performed using the retail_branch_init
command:
retail_branch_init <branch_server_salt_id>
This command will configure branch server formulas with recommended values. You can use the retail_branch_init --help
command for additional options.
Verify that your changes have been configured correctly by checking the SUSE Manager Web UI branch server system formulas.
Apply highstate on the branch server. You can do this through the Web UI, or by running this command:
salt <branch_server_salt_id> state.apply
The OS image you use on the SUSE Manager server must be synchronized for use on the branch server.
You can do this with the Salt image-sync
tool.
On the branch server, run this command:
salt <branch_server_salt_id> state.apply image-sync
The image details will be transferred to /srv/saltboot
on the branch server.
Formulas are pre-written Salt states, that are used to configure your SUSE Manager for Retail installation.
This section lists the primary formulas shipped with SUSE Manager for Retail and their configuration options.
All the formulas in this section must be accurately configured for your SUSE Manager for Retail installation to function correctly. If you are unsure of the correct formula configuration details, run the retail_branch_init
command before you begin to create the recommended formula configuration. You can then manually edit the formulas as required.
If a formula uses the same name as an existing Salt state, the two names will collide, and could result in the formula being used instead of the state. Always check the names of states and formulas to avoid name collisions.
Most formulas can be updated using the SUSE Manager Web UI. Once you have made changes to your formula, ensure you apply the highstate to propagate your changes to the appropriate services.
The Bind formula is used to configure the Domain Name System (DNS) on the branch server. POS terminals will use the DNS on the branch server for name resolution of saltboot specific hostnames.
When you are configuring the bind formula for a branch server with a dedicated internal network, check that you are using the same fully qualified domain name (FQDN) on both the external and internal branch networks. If the FQDN does not match on both networks, the branch server will not be recognized as a proxy server.
The following procedure outlines a standard configuration with two zones. Adjust it to suit your own environment.
Zone 1 is a regular domain zone. Its main purpose is to resolve saltboot hostnames such as TFTP, FTP, or Salt. It can also resolve the terminal names if configured.
Zone 2 is the reverse zone of Zone 1. Its main purpose is to resolve IP addresses back to hostnames. Zone 2 is primarily needed for the correct determination of the FQDNs of the branch.
Check the Bind
formula, and click Save
.
Navigate to the
→ tab, and set these parameters for Zone 1:In the Config
section, select Include Forwarders
.
In the Name
field, enter the domain name of your branch network (for example: branch1.example.org
).
In the Type
field, select master
.
Click Add item
to save your changes.
Set these parameters for Zone 2:
In the Name
field, use the reverse zone for the configured IP range (for example: 1.168.192.in-addr.arpa
).
In the Type
field, select master
In the Available Zones
section, use these parameters for Zone 1:
In the Name
field, enter the domain name of your branch network (for example: branch1.example.org
).
In the File
field, type the name of your configuration file.
In the Start of Authority (SOA)
section, use these parameters for Zone 1:
In the Nameserver (Ns)
field, use the FQDN of the branch server (for example: branchserver.branch1.example.org
).
In the Contact
field, use the email address for the domain administrator.
Keep all other fields as their default values.
In the Records
section, in subsection A
, click and use these parameters to set up an A record for Zone 1:
In the Hostname
field, use the hostname of the branch server (for example: branchserver
).
In the IP
field, use the IP address of the branch server (for example, 192.168.1.1
).
In the Records
section, subsection NS
, click and use these parameters to set up an NS record for Zone 1:
In the input box, use the hostname of the branch server (for example: branchserver
).
In the Records
section, subsection CNAME
, click on and add the hostname of the branch server in each of these fields:
tftp
ftp
dns
dhcp
salt
. The salt
CNAME should be the FQDN of the branch server’s external interface for proxy functionality to work correctly.
Set up Zone 2 using the same parameters as for Zone 1, but ensure you use the reverse details:
The same SOA section as Zone 1.
Empty A and CNAME records.
Additionally, configure in Zone 2:
Generate Reverse
field by the network IP address set in branch server network formula (for example, 192.168.1.1/24
).
For Zones
should specify the domain name of your branch network (for example, branch1.example.org
).
Click
to save your configuration.Apply the highstate.
Reverse name resolution on terminals might not work for networks that are inside one of these IPv4 private address ranges:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
If you encounter this problem, go to the Options
section of the Bind formula, and click :
* In the Options
field, enter empty-zones-enable
.
* In the Value
field, select No
.
The branch network formula is used to configure the networking services required by the branch server, including DHCP, DNS, TFTP, PXE, and FTP.
The branch server can be configured to use networking in many different ways. The most common ways provide either a dedicated or shared LAN for terminals.
In this configuration, the branch server requires at least two network interfaces: one acts as a WAN to communicate with the SUSE Manager server, and the other one acts as an isolated LAN to communicate with terminals.
This configuration allows for the branch server to provide DHCP, DNS, TFTP, PXE and FTP services to terminals, which are configured through SUSE Manager for Retail formulas in the SUSE Manager Web UI.
In the SUSE Manager Web UI, open the details page for the branch server, and navigate to the Formulas
tab.
In the Branch Network
section, set these parameters:
Keep Dedicated NIC
checked
In the NIC
field, enter the name of the network device that is connected to the internal LAN.
In the IP
field, enter the static IP address to be assigned to the branch server on the internal LAN.
In the Netmask
field, enter the network mask of the internal LAN.
Check Enable Route
if you want the branch server to route traffic from internal LAN to WAN.
Check Enable NAT
if you want the branch server to convert addresses from internal LAN to WAN.
Select the bind
DNS forwarder mode.
Check DNS forwarder fallback if you want to rely on an external DNS if the branch DNS fails.
Specify the working directory, and the directory owner and group.
Click
to save your changes.Apply the highstate.
The DHCPd formula is used to configure the DHCP service on the branch server.
In the SUSE Manager Web UI, open the details page for the branch server, and navigate to the Formulas tab.
Select the Dhcpd
formula, and click .
Navigate to the
→ tab, and set these parameters:In the Domain Name
field, enter the domain name for the branch server (for example: branch1.example.com
).
In the Domain Name Server
field, enter either the IP address or resolvable FQDN of the branch DNS server (for example: 192.168.1.1
).
In the Listen Interfaces
field, enter the name of the network interface used to connect to the local branch network (for example: eth1
).
Navigate to the Network Configuration (subnet)
section, and use these parameters for Network1:
In the Network IP
field, enter the IP address of the branch server network (for example: 192.168.1.0
).
In the Netmask
field, enter the network mask of the branch server network (for example: 255.255.255.0
).
In the Domain Name
field, enter the domain name for the branch server network (for example: branch1.example.com
).
In the Dynamic IP Range
section, use these parameters to configure the IP range to be served by the DHCP service:
In the first input box, set the lower bound of the IP range (for example: 192.168.1.51
).
In the second input box, set the upper bound of the IP range (for example: 192.168.1.151
).
In the Broadcast Address
field, enter the broadcast IP address for the branch network (for example: 192.168.1.255
).
In the Routers
field, enter the IP address to be used by routers in the branch server network (for example: 192.168.1.1
).
In the Next Server
field, enter the hostname or IP address of the branch server (for example: 192.168.1.1
).
In the Filename
field, keep the default value of /boot/pxelinux.0
.
Click
to save your configurationApply the highstate.
The PXE formula is used to configure PXE booting on the branch server.
In the SUSE Manager Web UI, open the details page for the branch server, and navigate to the Formulas
tab.
Select the Pxe
formula, and click Save
.
Navigate to the
→ tab, and set these parameters:In the Kernel filename
field, keep the default value.
In the Initrd filename
field, keep the default value.
In the Kernel commandline parameters
field, keep the default value.
In the PXE root directory
field, enter the path to the saltboot directory (for example, /srv/saltboot
).
In the Branch id
field, type a name to use as a branch identifier (for example: Branch0001
).
Use only alphanumeric characters for the branch identifier.
Click Save Formula
to save your configuration
Apply the highstate.
The Saltboot formula is used to configure disk images and partitioning for the selected hardware type.
Saltboot formula is meant to be used as a group formula. Enable and configure saltboot formula for hardware type groups.
Open the details page for your new hardware type group, and navigate to the Formulas
tab.
Select the saltboot-formula
and click .
Navigate to the new
→ tab.In the Disk 1
section, set these parameters:
In the Disk symbolic ID
field, enter a custom name for the disk (for example, disk1
).
In the Device type
field, select DISK
.
In the Disk device
field, select the device that corresponds to the device name on the target machine (for example, /dev/sda
).
In the RAID level
field, leave it empty.
In the Disk Label
field, select gpt
.
In the Partition
section, set these parameters for Partition 1
:
In the Partition symbolic ID
field, enter a custom name for the partition (for example, p1
).
In the Partition size
field, specify a size for the partition in Mebibytes (MiB).
In the Device mount point
field, select a location to mount the partition (for example, /data
).
In the Filesystem format
field, select your preferred format (for example, xfs
).
In the OS Image to deploy
field, leave it empty.
In the Partition encryption password
field, enter a password if you want to encrypt the partition.
In the Partition flags
field, leave it empty.
In the Partition
section, set these parameters for Partition 2
:
In the Partition symbolic ID
field, enter a custom name for the partition (for example, p2
).
In the Partition size
field, specify a size for the partition in Mebibytes (MiB).
In the Device mount point
field, leave it empty.
In the Filesystem format
field, select swap
.
In the OS Image to deploy
field, leave it empty.
In the Partition encryption password
field, enter a password if you want to encrypt the partition.
In the Partition flags
field, select swap
.
In the Partition
section, set these parameters for Partition 3
:
In the Partition symbolic ID
field, enter a custom name for the partition (for example, p3
).
In the Partition size
field, leave it empty.
This will ensure the partition uses up all remaining space.
In the Device mount point
field, select /
.
In the Filesystem format
field, leave it empty.
In the OS Image to deploy
field, enter the name of the image to deploy.
In the Image version
field, leave it empty.
This will ensure you use the latest available version.
In the Partition encryption password
field, enter a password if you want to encrypt the partition.
In the Partition flags
field, leave it empty.
Click
to save your formula.The TFTPd formula is used to configure the TFTP service on the branch server.
In the SUSE Manager Web UI, open the details page for the branch server, and navigate to the Formulas
tab.
Select the Tftpd
formula, and click .
Navigate to the
→ tab, and set these parameters:In the Internal Network Address
field, enter the IP address of the branch server (for example: 192.168.1.1
).
In the TFTP Base Directory
field, enter the path to the saltboot directory (for example, /srv/saltboot
).
In the Run TFTP Under User
field, enter saltboot
.
Click
to save your configuration.Apply the highstate.
The VsFTPd formula is used to configure the FTP service on the branch server.
In the SUSE Manager Web UI, open the details page for the branch server, and navigate to the Formulas
tab.
Select the Vsftpd
formula, and click .
Navigate to the
→ tab, and set these parameters:In the Internal Network Address
, enter IP address of branch server (for example: 192.168.1.1
).
All other fields can retain their default values.
Click
to save your configurationApply the highstate.
This sections contains notes on administering your SUSE Manager for Retail installation. For general administration tasks, see the SUSE Manager documentation at https://www.suse.com/documentation/suse-manager-3/
Branch servers are configured individually using formulas. If you are working in an environment with many branch servers, you might find it easier to configure the terminals automatically with a pre-defined configuration file, rather than configuring each branch server individually.
This procedure requires the python-susemanager-retail
package, which is provided with SUSE Manager for Retail.
Install the python-susemanager-retail
package on the SUSE Manager server.
Create a YAML file describing the infrastructure you intend to install. An example YAML file is at the end of this chapter, for you to reference.
On a clean SUSE Manager installation, import the YAML file you have created:
retail_yaml --from-yaml filename.yaml
You can use the retail_yaml --help
command for additional options.
If you need to change your configuration, you can edit the YAML file at any time, and use the retail_yaml --from-yaml
command to upload the new configuration.
Use the empty profiles together with activation keys to onboard all the systems of your infrastructure. Use an activation key to assign the channels listed in Configuring Server.
For hardware requirements, see Point-of-Service Terminals.
Before terminals can be deployed, ensure you have prepared a saltboot based OS image. For how to build OS images, see https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-advanced-topics/html/book.suma.advanced.topics/at.images.html#at.images.kiwi.
Each terminal requires a specific hardware type, which contains information about the product name and terminal manufacturer.
However, the SUSE Manager database does not have this information to begin with.
In order to tell SUSE Manager what image to deploy on each terminal, you can set hardware type groups.
After you have created your new hardware type group, you can apply the saltboot-formula
to the group and configure it for your environment.
After you have registered new terminals, always check the SUSE Manager Web UI to ensure your terminal has connected successfully to the branch server, and you have not connected directly to the SUSE Manager server by mistake.
Hardware types allow you to group devices according to manufacturer and device name, so that all devices of a particular type can be managed as one.
You will need to create appropriate hardware types in your system.
Empty profiles can be assigned to a hardware type group either before or after registration. If an empty profile is not assigned to a hardware type group before registration, it will be assigned to group that best matches the product information available to it.
For this procedure, you will require the system manufacturer name and product name for your terminal.
Determine the hardware type group name.
Prefix the name with HWTYPE:
, followed by the system manufacturer name and product name, separated by a hyphen.
For example:
HWTYPE:POSVendor-Terminal1
Only use colons (:
), hyphens (-
) or underscores (_
) in hardware type group names.
Spaces and other non-alphanumeric characters will be removed when the name is processed.
In the SUSE Manager Web UI, navigate to Groups
tab.
Click the
button.In the Create System Group
dialog, create a new system group, using the hardware type group name you created earlier.
In the SUSE Manager Web UI, terminals have a standard naming format which allows you to match the physical device with its record. By default, the name uses this format:
BranchName.Manufacturer-ProductName-SerialNumber-MachineID
For example:
B002.TOSHIBA-6140100-41BA03X-c643
You can adjust this behavior by toggling the DISABLE_HOSTNAME_ID
and DISABLE_UNIQUE_SUFFIX
parameters in the PXE formula settings.
For more information about the PXE formula, see PXE Formula.
If you are working in an environment with many terminals, you might find it easier to configure the terminals automatically with a pre-defined configuration file, rather than configuring each terminal individually.
In order to do this, you will need to have your infrastructure planned out ahead of time, including the IP addresses, hostnames, and domain names of branch servers and terminals. You will also require the hardware (MAC) addresses of each terminal.
The settings specified in the configuration file cannot always be successfully applied. In cases where there is a conflict, SUSE Manager will ignore the request in the file. This is especially important when designating hostnames. You should always check the details have been applied as expected after using this configuration method.
Create a YAML file describing the infrastructure you intend to install, specifying the hardware address for each terminal. An example YAML file is at the end of this chapter, for you to reference.
On a clean SUSE Manager installation, import the YAML file you have created:
retail_yaml --from-yaml filename.yaml
You can use the retail_yaml --help
command for additional options.
In the SUSE Manager Web UI, check that your systems are listed and displaying correctly, and the formulas you require are available.
Create activation keys for each of your branch servers, connect them using bootstrap, and configure them as proxy servers. For further information on these steps, see the SUSE Manager documentation.
Apply highstate to apply your configuration changes.
In the States
tab, click .
Connect your terminals according to your infrastructure plan.
If you need to change your configuration, you can edit the YAML file at any time, and use the retail_yaml --from-yaml
command to upload the new configuration.
If you have a current configuration that you would like to export to a YAML file, use:
retail_yaml --to-yaml filename.yaml
This can be a good way to create a basic mass configuration file. However it is important to check the file before using it, as some mandatory configuration entries will be missing.
When you are designing your configuration and creating the YAML file, ensure the branch server ID matches the fully qualified hostname, and the Salt ID. If these do not match, the bootstrap script could fail.
You can use the retail_yaml
command to import configuration parameters from a pre-prepared YAML file.
This section contains a commented example YAML file for you to reference.
Example: YAML mass terminal configuration file.
branches: # there are 2 possible setups: with / without dedicated NIC # # with dedicated NIC branchserver1.branch1.cz: # salt ID of branch server branch_prefix: branch1 # optional, default guessed from salt id server_name: branchserver1 # optional, default guessed from salt id server_domain: branch1.cz # optional, default guessed from salt id nic: eth1 # nic used for connecting terminals, default taken from hw info in SUMA dedicated_nic: true # set to true if the terminals are on separate network salt_cname: branchserver1.branch1.cz # hostname of salt master / broker for terminals, mandatory configure_firewall: true # modify firewall configuration branch_ip: 192.168.2.1 # default for dedicated NIC: 192.168.1.1 netmask: 255.255.255.0 # default for dedicated NIC: 255.255.255.0 dyn_range: # default for dedicated NIC: 192.168.1.10 - 192.168.1.250 - 192.168.2.10 - 192.168.2.250 # without dedicated NIC # the DHCP formula is not used, DHCP is typically provided by a router # the network parameters can be autodetected if the machine is already connected to SUSE Manager branchserver2.branch2.cz: # salt ID of branch server branch_prefix: branch2 # optional, default guessed from salt id server_name: branchserver2 # optional, default guessed from salt id server_domain: branch2.cz # optional, default guessed from salt id salt_cname: branchserver2.branch1.cz # FQDN of salt master / broker for terminals, mandatory branch_ip: 192.168.2.1 # optional, default taken from SUMA data if the machine is registered netmask: 255.255.255.0 # optional, default taken from SUMA data if the machine is registered exclude_formulas: # optional, do not configure listed formulas - dhcp # without dedicated NIC the dhcp service is typically provided by a router hwAddress: 11:22:33:44:55:66 # optional, required to connect pre-configured entry with particular machine # during onboarding terminals: # configuration of static terminal entries hostname1: # hostname hwAddress: aa:aa:aa:bb:bb:bb # required as unique id of a terminal IP: 192.168.2.50 # required for static dhcp and dns entry saltboot: # optional, alternative 1: configure terminal-specific pillar data partitioning: # partitioning pillar as described in saltboot documentation disk1: device: /dev/sda disklabel: msdos partitions: p1: flags: swap format: swap size_MiB: 2000.0 p2: image: POS_Image_JeOS6 mountpoint: / type: DISK hostname2: # hostname hwAddress: aa:aa:aa:bb:bb:cc # required as unique id of a terminal IP: 192.168.2.51 # required for static dhcp and dns entry hwtype: IBMCORPORATION-4838910 # optional, alternative 2: assign the terminal to hwtype group # if neither of hwtype nor saltboot is specified, a group is assigned according to hwtype # reported by bios on the first boot hwtypes: IBMCORPORATION-4838910: # HWTYPE string (manufacturer-model) as returned by bios description: 4838-910 # freetext description saltboot: partitioning: # partitioning pillar as described in saltboot documentation disk1: device: /dev/sda disklabel: msdos partitions: p1: flags: swap format: swap size_MiB: 1000.0 p2: image: POS_Image_JeOS6 mountpoint: / type: DISK TOSHIBA-6140100: description: HWTYPE:TOSHIBA-6140100 saltboot: partitioning: disk1: device: /dev/sda disklabel: msdos partitions: p1: flags: swap format: swap size_MiB: 1000.0 p2: image: POS_Image_JeOS6 mountpoint: / type: DISK
This document covers only a sub-section of information about your SUSE Manager for Retail installation. If you need further information or support, try one of these options.
For SUSE Manager documentation, visit https://www.suse.com/documentation/suse-manager-3/
For legacy SUSE Linux Enterprise Point of Service documentation, visit https://www.suse.com/documentation/slepos11/index.html Note, however, that SUSE Manager for Retail documentation supersedes this information.
For personalized support, log in to your SUSE Customer Center account here: https://scc.suse.com/login
For assistance with planning and installing your SUSE Manager for Retail environment, contact the SUSE Consulting team.
This appendix contains the GNU Free Documentation License version 1.2.
Copyright © 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.
A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text.
A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.
State on the Title page the name of the publisher of the Modified Version, as the publisher.
Preserve all the copyright notices of the Document.
Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice.
Include an unaltered copy of this License.
Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.
Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.
Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.
You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled{ldquo}GNU Free Documentation License{rdquo}.
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “ with…Texts.” line with this:
with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.