CKB:Upgrading the distribution from openSUSE Leap 15.6 to 16.0

Problem-2: SSH Root Access Restriction After openSUSE Leap 16.0 Upgrade

After upgrading to openSUSE Leap 16.0, SSH root login with a password no longer works. Customers who previously accessed their systems remotely as root via password authentication will be locked out after the upgrade.

Cause

openSUSE Leap 16.0 disables password-based SSH root login by default, in line with modern Linux security standards. This change reduces the risk of brute-force attacks targeting the root account.

Solution/Workaround

One of the following must be configured before performing the upgrade:

Option 1 — SSH Key Authentication for Root (Recommended) Replace password login with key-based authentication for the root user.

1. On the client machine, generate an SSH key pair (if not already available):
   1. ssh-keygen -t ed25519
2. Copy the public key to the target server:
   1. ssh-copy-id root@<server-ip>
3. Verify key-based login works before upgrading:
   1. ssh root@<server-ip>

Option 2 — Create a Non-Root User with sudo Privileges Use a non-root account for remote access post-upgrade.

1. Create a new user:
   1. useradd -m -s /bin/bash -c "Test User" testuser
   2. sudo passwd testuser
2. Grant sudo privileges:
   1. usermod -a -G wheel testuser
3. Verify the user can log in via SSH and run sudo commands before upgrading.

Reference: openSUSE Leap 16.0 Release Notes – JSC-PED-4965

---

Problem-3: Network Interface Naming Changes in openSUSE Leap 16.0

After upgrading to openSUSE Leap 16.0, network interfaces are renamed from legacy names (e.g., eth0, eth1) to predictable names (e.g., ens32, ens33). Existing network configuration files still reference the old names, causing network connectivity to fail after the upgrade.

Cause

openSUSE Leap 16.0 adopts predictable network interface naming, a systemd standard that names interfaces based on hardware topology (slot, bus, MAC) rather than discovery order. Legacy names like eth0 were assigned arbitrarily at boot and could change between reboots — predictable names are stable and hardware-specific, improving reliability in multi-NIC and virtualized environments.

Solution/Workaround

The application handles this automatically — no manual script execution is required. The migration runs in two phases during the OS upgrade process:

Phase 1 — Pre-Upgrade Backup (automatically triggered after upgrade)

The Cryptshare application backs up all current network configuration files from /etc/sysconfig/network and records the current interface names.

Migration State File

Once the upgrade is initiated, the application creates the file /var/lib/network-migration-state.json. This file is for informational purposes — it gives a clear record of what the application did during the migration and can be used to confirm the upgrade completed successfully.

After phase -1 , the migration state file will have the following fields:

{
  "backup_dir": "/root/network_backups/backup_20260215_130049",
  "timestamp": "20260215_130049",
  "hostname": "CSCS4QA27",
  "backup_date": "2026-02-15T13:00:50+01:00",
  "os_version_before": "15.6"

}

The details of fields in the file are given below.

Field	Description
backup_dir	Path to the backed-up network config files
timestamp	When the backup was taken
hostname	Server hostname at time of backup
backup_date	ISO timestamp of backup
os_version_before	Leap version before upgrade (e.g., 15.6)

Phase 2 — Post-Upgrade Migration (automatically triggered after upgrade)

The Cryptshare application reads the backed-up ifcfg-eth* and ifroute-eth* files, maps each ethX to the corresponding new predictable interface name, and writes renamed config files back to /etc/sysconfig/network. A rollback point is also created before any changes are made. The network service (wicked) is then restarted to apply the new configuration.

After Phase 2 — Post-Upgrade Migration, two additional fields are appended:

{
  "backup_dir": "/root/network_backups/backup_20260215_130049",
  "timestamp": "20260215_130049",
  "hostname": "CSCS4QA27",
  "backup_date": "2026-02-15T13:00:50+01:00",
  "os_version_before": "15.6",
  "migration_completed": "2026-02-16T16:15:56+01:00",
  "migration_status": "success"
}

The details of two new fields are given below.

Field	Description
migration_completed	ISO timestamp when migration finished
migration_status	success if migration completed without error

Reference: openSUSE Leap 16.0 Release Notes - jsc-PED-12725