Bug 1413999 - atomic install sssd --migrate fails
Summary: atomic install sssd --migrate fails
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd-container
Version: 7.4
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Namita Soman
URL:
Whiteboard:
: 1483210 (view as bug list)
Depends On:
Blocks: 1483210
TreeView+ depends on / blocked
 
Reported: 2017-01-17 14:18 UTC by Niranjan Mallapadi Raghavender
Modified: 2021-01-08 09:05 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1483210 (view as bug list)
Environment:
Last Closed: 2021-01-08 09:06:20 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Niranjan Mallapadi Raghavender 2017-01-17 14:18:37 UTC
Description of problem:

When migrating the atomic host sssd configuration to container with --migrate, it fails with error:


[root@atomic-00 sssd]# atomic install sssd --migrate
docker run --rm=true --privileged --net=host -v /:/host -e NAME=sssd -e IMAGE=sssd -e HOST=/host sssd /bin/install.sh --migrate
Initializing configuration context from host ...
Usage: ipa-client-install [options]

ipa-client-install: error: no such option: --migrate


Version-Release number of selected component (if applicable):
sssd-docker-7.3.13

How reproducible:


Steps to Reproduce:
1. Configure sssd.conf on atomic host as below:

[root@atomic-00 sssd]# cat sssd.conf 
[sssd]
domains = LDAP
config_file_version = 2
services = nss, pam

[domain/LDAP]
cache_credentials = TRUE
id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307
chpass_provider = ldap
ldap_uri = ldaps://client2.example.test
ldap_tls_cacertdir = /etc/openldap/certs
debug_level = 0x400

2. Run migrate
atomic install sssd --migrate (or atomic install rhel7/sssd --migrate)

Actual results:

[root@atomic-00 sssd]# atomic install sssd --migrate
docker run --rm=true --privileged --net=host -v /:/host -e NAME=sssd -e IMAGE=sssd -e HOST=/host sssd /bin/install.sh --migrate
Initializing configuration context from host ...
Usage: ipa-client-install [options]

ipa-client-install: error: no such option: --migrate


Expected results:
Should successfully migrate sssd.conf from atomic host to container.


Additional info:
[root@atomic-00 sssd]# atomic host status
State: idle
Deployments:
● rhel-atomic-host:rhel-atomic-host/7/x86_64/standard
       Version: 7.3.2 (2017-01-13 22:00:41)
        Commit: 96826a0d917d7ff10f9fd0289581649f2ffbddd76f3b80efd3d95cc11915cacb
        OSName: rhel-atomic-host

Comment 1 Jan Pazdziora 2017-01-17 14:22:41 UTC
Can you run

mkdir -p /etc/ipa ; touch /etc/ipa/default.conf

on the host before running the atomic install sssd --migrate to see if it makes a difference?

Comment 2 Jan Pazdziora 2017-01-17 14:23:15 UTC
We seem to be checking existence of /etc/ipa/default.conf, not /etc/sssd/sssd.conf, in install.sh. I wonder if that check should be removed altogether.

Comment 3 Niranjan Mallapadi Raghavender 2017-01-17 14:32:42 UTC
Yes that worked

[root@atomic-00 sssd]# mkdir -p /etc/ipa ; touch /etc/ipa/default.conf

[root@atomic-00 sssd]# atomic install rhel7/sssd --migrate
docker run --rm=true --privileged --net=host -v /:/host -e NAME=sssd -e IMAGE=rhel7/sssd -e HOST=/host rhel7/sssd /bin/install.sh --migrate
IPA client is already configured on this system.
Service sssd.service configured to run SSSD container.


[root@atomic-00 sssd]# systemctl start sssd
[root@atomic-00 sssd]# systemctl status sssd
● sssd.service - System Security Services Daemon in container
   Loaded: loaded (/etc/systemd/system/sssd.service; disabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/sssd.service.d
           └─journal.conf
   Active: active (exited) since Tue 2017-01-17 14:31:21 UTC; 3s ago
  Process: 26651 ExecStart=/usr/bin/atomic run --name=sssd rhel7/sssd (code=exited, status=0/SUCCESS)
 Main PID: 26651 (code=exited, status=0/SUCCESS)

Jan 17 14:31:19 atomic-00.localdomain systemd[1]: Starting System Security Services Daemon in container...
Jan 17 14:31:20 atomic-00.localdomain atomic[26651]: docker run -d --restart=always --privileged --net=host --name sssd -e NAME=sssd -e IMAGE=rhel7/sssd -v /etc/ipa/:/etc/ipa/:ro -v /etc/krb5.conf:/etc/krb5.conf:ro -v /...conf:ro -v /etc/
Jan 17 14:31:20 atomic-00.localdomain atomic[26651]: This container uses privileged security switches:
Jan 17 14:31:20 atomic-00.localdomain atomic[26651]: INFO: --net=host
Jan 17 14:31:20 atomic-00.localdomain atomic[26651]: Processes in this container can listen to ports (and possibly rawip traffic) on the host's network.
Jan 17 14:31:20 atomic-00.localdomain atomic[26651]: INFO: --privileged
Jan 17 14:31:20 atomic-00.localdomain atomic[26651]: This container runs without separation and should be considered the same as root on your system.
Jan 17 14:31:21 atomic-00.localdomain atomic[26651]: 8fa79b849433bd12adbf9d4883b9f15eecccb0db3ead931959fb71cf5b5cdd4b
Jan 17 14:31:21 atomic-00.localdomain atomic[26651]: For more information on these switches and their security implications, consult the manpage for 'docker run'.
Jan 17 14:31:21 atomic-00.localdomain systemd[1]: Started System Security Services Daemon in container.

Comment 7 Lukas Slebodnik 2017-08-19 09:09:27 UTC
*** Bug 1483210 has been marked as a duplicate of this bug. ***

Comment 10 Tomas Halman 2021-01-08 09:06:20 UTC
This BZ has been evaluated multiple times over the last several years and we assessed that it is a valuable request to keep in the backlog and address it at some point in future. Time showed that we did not have such capacity, nor have it now nor will have in the foreseeable future. In such a situation keeping it in the backlog is misleading and setting the wrong expectation that we will be able to address it. Unfortunately we will not. To reflect this we are closing this BZ. If you disagree with the decision please reopen or open a new support case and create a new BZ. However this does not guarantee that the request will not be closed during the triage as we are currently applying much more rigor to what we actually can accomplish in the foreseeable future. Contributions and collaboration in the upstream community and CentOS Stream is always welcome!

Thank you for understanding

Red Hat Enterprise Linux Identity Management Team


Note You need to log in before you can comment on or make changes to this bug.