| Summary: |
Upgrade moves /etc/sssd/sssd.conf to /etc/sssd/sssd.conf.rpmsave |
| Product: |
[openSUSE] openSUSE Tumbleweed
|
Reporter: |
Georg Pfuetzenreuter <georg.pfuetzenreuter> |
| Component: |
Network | Assignee: |
Samuel Cabrero <scabrero> |
| Status: |
RESOLVED
FIXED
|
QA Contact: |
E-mail List <qa-bugs> |
| Severity: |
Normal
|
|
|
| Priority: |
P5 - None
|
CC: |
gumsley_6, martin.wilck, samba-maintainers, suse-beta
|
| Version: |
Current | |
|
| Target Milestone: |
--- | |
|
| Hardware: |
Other | |
|
| OS: |
openSUSE Tumbleweed | |
|
| Whiteboard: |
|
|
Found By:
|
---
|
Services Priority:
|
|
|---|
|
Business Priority:
|
|
Blocker:
|
---
|
|---|
|
Marketing QA Status:
|
---
|
IT Deployment:
|
---
|
|---|
Hi, upon upgrading `openSUSE Tumbleweed 20231031-0 -> 20231101-0` which contained an update of `sssd`, the configuration file was moved to .rpmsave: ``` warning: /etc/sssd/sssd.conf saved as /etc/sssd/sssd.conf.rpmsave ``` I presume this is part of the /usr/etc merge effort, however my sssd.conf file contained custom options configuring my LDAP backend - the file being (re)moved breaks LDAP login after the upgrade. Furthermore, `sssd` refuses to start completely after the upgrade: ``` # systemctl status sssd ○ sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: disabled) Active: inactive (dead) Condition: start condition unmet at Fri 2023-11-03 15:13:24 UTC; 879ms ago ├─ ConditionPathExists=|/etc/sssd/sssd.conf was not met └─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was not met Nov 03 15:07:29 chip systemd[1]: System Security Services Daemon was skipped because no trigger condition checks were met. # systemctl cat sssd|grep Condition ConditionPathExists=|/etc/sssd/sssd.conf ConditionDirectoryNotEmpty=|/etc/sssd/conf.d/ ``` There is no /usr/etc/sssd either: ``` # ls /usr/etc/sssd ls: cannot access '/usr/etc/sssd': No such file or directory ``` To repair the problem, I need to manually move `/etc/sssd/sssd.conf.rpmsave` back to `/etc/sssd/sssd.conf`: ``` # mv /etc/sssd/sssd.conf.rpmsave /etc/sssd/sssd.conf # systemctl start sssd # systemctl status sssd ● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: disabled) Active: active (running) since Fri 2023-11-03 15:15:56 UTC; 2s ago Main PID: 2359 (sssd) ``` This behavior following a `zypper dup` doesn't seem quite right. The version after the update is the following: ``` zypper se -isx sssd i+ | sssd | package | 2.9.2-2.1 | x86_64 | repo-oss ``` Cheers, Georg