Tuning Zypper repositories and YaST Network Settings on openSUSE Leap 15.5 for Production Cluster Nodes

Optimizing Zypper Repository Configuration for Production Clusters

In a production cluster environment running openSUSE Leap, particularly for critical services, the performance and reliability of package management are paramount. Zypper, the default package manager, relies heavily on its repository configuration. Suboptimal settings can lead to slow updates, increased downtime during maintenance, and potential conflicts. This section details how to fine-tune Zypper repositories for a cluster, focusing on mirror selection, priority, and enabling specific modules.

Repository Mirror Selection Strategy

The default repositories often point to a single upstream mirror, which can become a bottleneck. For production nodes, it’s crucial to leverage geographically closer and performant mirrors. Zypper’s `zypper-mirror` tool can help, but a more robust approach involves manual selection and configuration.

First, identify potential mirrors. The openSUSE wiki and community forums are good starting points. For a cluster, consider mirrors that are known for high availability and low latency from your datacenter’s network. Once identified, you can manually edit the repository configuration files located in /etc/zypp/repos.d/.

Example: Manually Configuring a Mirror

Let’s assume we’re configuring the main openSUSE Leap 15.5 OSS repository. The original file might look something like this:

[repo-oss]
name = openSUSE Leap 15.5 OSS
enabled = 1
autorefresh = 0
baseurl = http://download.opensuse.org/distribution/leap/15.5/repo/oss/
path = /
type = yast2
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-openSUSE-15.5-Oss



To use a specific, faster mirror (e.g., a mirror hosted by your ISP or a known high-performance mirror), you would modify the baseurl. It's also good practice to disable automatic refresh for production systems to prevent unexpected interruptions during critical operations, opting for scheduled, controlled updates instead.



[repo-oss]
name = openSUSE Leap 15.5 OSS (Custom Mirror)
enabled = 1
autorefresh = 0
baseurl = http://mirror.example.com/opensuse/distribution/leap/15.5/repo/oss/
path = /
type = yast2
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-openSUSE-15.5-Oss




Repeat this process for all essential repositories (OSS, Non-OSS, Update, etc.). For cluster nodes, consider using a local mirror server (e.g., using `mirrorcache` or a simple HTTP server) to further reduce external dependencies and improve update speeds.



Repository Priorities for Stability



When multiple repositories provide the same package, Zypper uses priorities to determine which version to install. By default, priorities are often set to 99. For production, it's advisable to assign explicit priorities to ensure that official stable releases are preferred over potentially unstable or third-party repositories.



Lower numerical values indicate higher priority. A common strategy is to assign a high priority (e.g., 10) to official Leap repositories and lower priorities (e.g., 50 or 100) to additional or third-party repositories.



Setting Repository Priorities



You can set priorities directly in the .repo files or use the zypper modify command.



# Example using zypper modify
sudo zypper mr -p 10 repo-oss
sudo zypper mr -p 10 repo-non-oss
sudo zypper mr -p 20 repo-update
# Assign a lower priority to a hypothetical third-party repo
sudo zypper mr -p 50 repo-my-custom-app




Alternatively, edit the .repo files directly and add or modify the priority line:



[repo-oss]
name = openSUSE Leap 15.5 OSS (Custom Mirror)
enabled = 1
autorefresh = 0
baseurl = http://mirror.example.com/opensuse/distribution/leap/15.5/repo/oss/
path = /
type = yast2
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-openSUSE-15.5-Oss
priority = 10




Enabling and Managing Modules



openSUSE uses modules to group related packages and provide different versions or configurations. For production, it's essential to explicitly enable the modules you need and disable those that are not required to minimize the attack surface and avoid potential conflicts.



Listing and Enabling Modules



Use zypper lr -m to list available modules and zypper mr -e <module_name> to enable them.



# List all modules
sudo zypper lr -m

# Enable a specific module (e.g., for a web server stack)
sudo zypper mr -e php81
sudo zypper mr -e apache2




Conversely, to disable a module:



# Disable a module
sudo zypper mr -d python3




Carefully review the modules available and enabled on your cluster nodes to ensure only necessary components are installed. This is a critical step for security and stability.



Advanced YaST Network Configuration for Cluster Nodes



YaST's network configuration module is powerful but can be complex. For production cluster nodes, especially those involved in high-availability setups or inter-node communication, precise network configuration is vital. This includes static IP addressing, bonding, VLAN tagging, and DNS resolution.



Static IP Addressing and Hostnames



Cluster nodes typically require static IP addresses for predictable communication. YaST allows for detailed configuration of network interfaces.



Configuring via YaST TUI/GUI



Launch YaST and navigate to Network Devices > Network Settings. Select the interface (e.g., eth0) and click Edit. Under the IPv4 Settings tab, choose Static and enter the IP address, subnet mask, and gateway. Ensure the Hostname & Dynamic DNS tab is correctly configured with a unique hostname for each node and the appropriate domain name.



Command-Line Configuration (for Automation)



For automated deployments or configuration management, you can directly edit the network configuration files. YaST stores its configurations in /etc/sysconfig/network/. The primary files are ifcfg-* (interface configuration) and routes.



# Example ifcfg-eth0 for a static IP
cat > /etc/sysconfig/network/ifcfg-eth0 << EOF
BOOTPROTO='static'
BROADCAST=''
IPADDR='192.168.1.10/24'
MTU=''
NAME='eth0'
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
EOF

# Example routes file
cat > /etc/sysconfig/network/routes << EOF
default 192.168.1.1 - -
EOF




After modifying these files, you need to restart the network service or reload the configuration. The exact command can vary, but often involves:



# Reload network configuration
sudo systemctl restart network.service
# Or, for specific interface
sudo ifdown eth0 && sudo ifup eth0




Network Bonding for High Availability



For critical cluster nodes, network redundancy is essential. Network bonding (LAG - Link Aggregation Group) combines multiple physical network interfaces into a single logical interface, providing failover and increased throughput.



Configuring Bonding via YaST



In YaST's Network Settings, click Add. Select Bond as the device type. Configure the bond's IP address, subnet mask, and gateway. Then, under the Bonding Devices tab, add the physical interfaces (e.g., eth0, eth1) that will be part of the bond. Choose an appropriate bonding mode (e.g., 802.3ad for LACP, active-backup for failover).



Command-Line Bonding Configuration



Bonding configuration is managed through /etc/sysconfig/network/ifbondX and /etc/sysconfig/network/ifcfg-bondX files.



# Example ifcfg-bond0
cat > /etc/sysconfig/network/ifcfg-bond0 << EOF
BONDING_MODULE_OPTS="mode=active-backup miimon=100"
BOOTPROTO='static'
IPADDR='192.168.1.10/24'
MTU=''
NAME='bond0'
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
EOF

# Example ifcfg-eth0 (slave interface)
cat > /etc/sysconfig/network/ifcfg-eth0 << EOF
MASTER='bond0'
SLAVE='yes'
STARTMODE='auto'
USERCONTROL='no'
EOF

# Example ifcfg-eth1 (slave interface)
cat > /etc/sysconfig/network/ifcfg-eth1 << EOF
MASTER='bond0'
SLAVE='yes'
STARTMODE='auto'
USERCONTROL='no'
EOF

# Ensure the bonding module is loaded
echo "alias bond0 bonding" >> /etc/modules-load.d/bonding.conf
modprobe bonding




After creating these files, restart the network service:



sudo systemctl restart network.service




DNS Resolution Configuration



Accurate DNS resolution is critical for service discovery and inter-node communication in a cluster. YaST's network settings allow for specifying DNS servers and search domains.



Configuring DNS via YaST



In YaST's Network Settings, select the interface and click Edit. Under the Hostname & DNS tab, enter the Name Server addresses (your internal DNS servers or public ones like 8.8.8.8) and the Domain Search List.



Command-Line DNS Configuration



The primary file for DNS configuration is /etc/resolv.conf. While YaST manages this, direct edits are possible, but they might be overwritten by NetworkManager or Wicked (the default network service). For persistent changes managed by Wicked, you'd typically configure it via /etc/sysconfig/network/config or the interface-specific ifcfg-* files.



# Example /etc/resolv.conf (often managed by Wicked/NetworkManager)
cat > /etc/resolv.conf << EOF
nameserver 192.168.1.53
nameserver 8.8.8.8
search cluster.local internal.example.com
EOF




To ensure Wicked uses these settings persistently, you might need to configure them within the ifcfg-* files or the global network configuration. For example, adding DNS servers to the main ifcfg-eth0 file:



[... existing ifcfg-eth0 content ...]
DNS1='192.168.1.53'
DNS2='8.8.8.8'
DOMAIN='cluster.local'




After making changes, restart the network service:



sudo systemctl restart network.service




Thorough testing of DNS resolution using dig or nslookup is crucial after any network configuration changes.