RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1661182 - sss_cache prints spurious error messages when invoked from shadow-utils on package install
Summary: sss_cache prints spurious error messages when invoked from shadow-utils on pa...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sssd
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: 8.0
Assignee: Tomas Halman
QA Contact: Anuj Borah
URL:
Whiteboard:
Depends On: 1659656 1682305
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-20 10:29 UTC by Jakub Hrozek
Modified: 2021-10-04 09:23 UTC (History)
11 users (show)

Fixed In Version: sssd-2.1.0-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1659656
Environment:
Last Closed: 2019-11-05 22:33:53 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4904 0 None closed sss_cache prints spurious error messages when invoked from shadow-utils on package install 2021-02-11 08:27:29 UTC
Github SSSD sssd pull 5796 0 None open Tests: sss_cache prints spurious error messages 2021-09-26 13:43:13 UTC
Red Hat Issue Tracker RHELPLAN-14943 0 None None None 2021-09-26 13:45:43 UTC
Red Hat Product Errata RHSA-2019:3651 0 None None None 2019-11-05 22:34:08 UTC

Description Jakub Hrozek 2018-12-20 10:29:15 UTC 
+++ This bug was initially created as a clone of Bug #1659656 +++

Description of problem:

When I upgraded the clamav 0.101.0-1 packages from Koji using dnf, I saw the following errors in the clamav-filesystem, clamd, and clamav-milter pre-install scriplets:

[sss_cache] [confdb_get_domains] (0x0010): No domains configured, fatal error!
Could not open available domains
usermod: sss_cache exited with status 2
usermod: Failed to flush the sssd cache.

The error appears to involve no domains being configured for the sss cache of sssd. The upgrade completed as shown in the full output I put in the additional infomation part.

Version-Release number of selected component (if applicable):
clamav-0.101.0-1.fc29.i686

How reproducible:

I ran the update once.

Steps to Reproduce:
1. sudo dnf upgrade https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/i686/clamav-0.101.0-1.fc29.i686.rpm https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/i686/clamav-lib-0.101.0-1.fc29.i686.rpm https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/i686/clamav-milter-0.101.0-1.fc29.i686.rpm https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/i686/clamav-update-0.101.0-1.fc29.i686.rpm https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/noarch/clamav-data-0.101.0-1.fc29.noarch.rpm https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/noarch/clamav-filesystem-0.101.0-1.fc29.noarch.rpm https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/i686/clamd-0.101.0-1.fc29.i686.rpm

2.
3.

Actual results:

I saw errors in the clamav-filesystem, clamd, and clamav-milter pre-install scriplets during the clamav 0.101.0-1 upgrade from Koji.

Expected results:

No errors in the clamav upgrade


Additional info:

The full output of the upgrade was the following:

sudo dnf upgrade https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/i686/clamav-0.101.0-1.fc29.i686.rpm https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/i686/clamav-lib-0.101.0-1.fc29.i686.rpm https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/i686/clamav-milter-0.101.0-1.fc29.i686.rpm https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/i686/clamav-update-0.101.0-1.fc29.i686.rpm https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/noarch/clamav-data-0.101.0-1.fc29.noarch.rpm https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/noarch/clamav-filesystem-0.101.0-1.fc29.noarch.rpm https://kojipkgs.fedoraproject.org//packages/clamav/0.101.0/1.fc29/i686/clamd-0.101.0-1.fc29.i686.rpm
Last metadata expiration check: 18:35:08 ago on Thu 13 Dec 2018 10:39:02 PM EST.
clamav-0.101.0-1.fc29.i686.rpm                     254 kB/s | 360 kB     00:01    
clamav-lib-0.101.0-1.fc29.i686.rpm                 641 kB/s | 831 kB     00:01    
clamav-milter-0.101.0-1.fc29.i686.rpm               56 kB/s |  98 kB     00:01    
clamav-update-0.101.0-1.fc29.i686.rpm              112 kB/s |  89 kB     00:00    
clamav-data-0.101.0-1.fc29.noarch.rpm              1.4 MB/s | 163 MB     01:55    
clamav-filesystem-0.101.0-1.fc29.noarch.rpm         24 kB/s |  14 kB     00:00    
clamd-0.101.0-1.fc29.i686.rpm                       61 kB/s | 105 kB     00:01    
Dependencies resolved.
===================================================================================
 Package                Arch        Version                Repository         Size
===================================================================================
Upgrading:
 clamav                 i686        0.101.0-1.fc29         @commandline      360 k
 clamav-lib             i686        0.101.0-1.fc29         @commandline      831 k
 clamav-milter          i686        0.101.0-1.fc29         @commandline       98 k
 clamav-update          i686        0.101.0-1.fc29         @commandline       89 k
 clamav-data            noarch      0.101.0-1.fc29         @commandline      163 M
 clamav-filesystem      noarch      0.101.0-1.fc29         @commandline       14 k
 clamd                  i686        0.101.0-1.fc29         @commandline      105 k

Transaction Summary
===================================================================================
Upgrade  7 Packages

Total size: 165 M
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                           1/1 
  Running scriptlet: clamav-filesystem-0.101.0-1.fc29.noarch                   1/1 
  Running scriptlet: clamav-filesystem-0.101.0-1.fc29.noarch                  1/14 
(Fri Dec 14 17:17:58:926064 2018) [sss_cache] [confdb_get_domains] (0x0010): No domains configured, fatal error!
Could not open available domains
usermod: sss_cache exited with status 2
usermod: Failed to flush the sssd cache.

  Upgrading        : clamav-filesystem-0.101.0-1.fc29.noarch                  1/14 
  Upgrading        : clamav-data-0.101.0-1.fc29.noarch                        2/14 
  Upgrading        : clamav-update-0.101.0-1.fc29.i686                        3/14 
  Running scriptlet: clamav-update-0.101.0-1.fc29.i686                        3/14 
warning: /etc/freshclam.conf created as /etc/freshclam.conf.rpmnew

  Upgrading        : clamav-lib-0.101.0-1.fc29.i686                           4/14 
  Running scriptlet: clamav-lib-0.101.0-1.fc29.i686                           4/14 
  Upgrading        : clamav-0.101.0-1.fc29.i686                               5/14 
  Running scriptlet: clamd-0.101.0-1.fc29.i686                                6/14 
(Fri Dec 14 17:18:58:840220 2018) [sss_cache] [confdb_get_domains] (0x0010): No domains configured, fatal error!
Could not open available domains
usermod: sss_cache exited with status 2
usermod: Failed to flush the sssd cache.

  Upgrading        : clamd-0.101.0-1.fc29.i686                                6/14 
  Running scriptlet: clamd-0.101.0-1.fc29.i686                                6/14 
  Running scriptlet: clamav-milter-0.101.0-1.fc29.i686                        7/14 
(Fri Dec 14 17:19:00:767503 2018) [sss_cache] [confdb_get_domains] (0x0010): No domains configured, fatal error!
Could not open available domains
usermod: sss_cache exited with status 2
usermod: Failed to flush the sssd cache.

  Upgrading        : clamav-milter-0.101.0-1.fc29.i686                        7/14 
  Running scriptlet: clamav-milter-0.101.0-1.fc29.i686                        7/14 
  Running scriptlet: clamd-0.100.2-2.fc29.i686                                8/14 
  Cleanup          : clamd-0.100.2-2.fc29.i686                                8/14 
  Running scriptlet: clamd-0.100.2-2.fc29.i686                                8/14 
  Cleanup          : clamav-0.100.2-2.fc29.i686                               9/14 
  Cleanup          : clamav-lib-0.100.2-2.fc29.i686                          10/14 
  Running scriptlet: clamav-lib-0.100.2-2.fc29.i686                          10/14 
  Cleanup          : clamav-update-0.100.2-2.fc29.i686                       11/14 
  Cleanup          : clamav-data-0.100.2-2.fc29.noarch                       12/14 
  Running scriptlet: clamav-milter-0.100.2-2.fc29.i686                       13/14 
  Cleanup          : clamav-milter-0.100.2-2.fc29.i686                       13/14 
  Running scriptlet: clamav-milter-0.100.2-2.fc29.i686                       13/14 
  Cleanup          : clamav-filesystem-0.100.2-2.fc29.noarch                 14/14 
  Running scriptlet: clamav-filesystem-0.100.2-2.fc29.noarch                 14/14 
  Verifying        : clamav-0.101.0-1.fc29.i686                               1/14 
  Verifying        : clamav-0.100.2-2.fc29.i686                               2/14 
  Verifying        : clamav-lib-0.101.0-1.fc29.i686                           3/14 
  Verifying        : clamav-lib-0.100.2-2.fc29.i686                           4/14 
  Verifying        : clamav-milter-0.101.0-1.fc29.i686                        5/14 
  Verifying        : clamav-milter-0.100.2-2.fc29.i686                        6/14 
  Verifying        : clamav-update-0.101.0-1.fc29.i686                        7/14 
  Verifying        : clamav-update-0.100.2-2.fc29.i686                        8/14 
  Verifying        : clamav-data-0.101.0-1.fc29.noarch                        9/14 
  Verifying        : clamav-data-0.100.2-2.fc29.noarch                       10/14 
  Verifying        : clamav-filesystem-0.101.0-1.fc29.noarch                 11/14 
  Verifying        : clamav-filesystem-0.100.2-2.fc29.noarch                 12/14 
  Verifying        : clamd-0.101.0-1.fc29.i686                               13/14 
  Verifying        : clamd-0.100.2-2.fc29.i686                               14/14 

Upgraded:
  clamav-0.101.0-1.fc29.i686            clamav-lib-0.101.0-1.fc29.i686             
  clamav-milter-0.101.0-1.fc29.i686     clamav-update-0.101.0-1.fc29.i686          
  clamav-data-0.101.0-1.fc29.noarch     clamav-filesystem-0.101.0-1.fc29.noarch    
  clamd-0.101.0-1.fc29.i686            

Complete!

--- Additional comment from Orion Poplawski on 2018-12-15 00:02:28 UTC ---

The scriptlet is running:

usermod %{updateuser} -a -G virusgroup

The guidelines for users and groups (https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/) does not directly address calling usermod, but the useradd examples do not redirect stderr - presumably because it is useful at times.

I'm guessing that usermod is calling sss_cache.  I'm not really sure what should be done here.  Let's see if the SSSD folks have an opinion about whether generating this error output is useful.  It's also possible that usermod should be ignoring this error.

--- Additional comment from Miro Hrončok on 2018-12-19 11:09:42 UTC ---

One of our students was just hit by this at a Fedora 29 workstation.

He run:

$ sudo usermod -a -G dialout username

And got:

(Wed Dec 19 11:58:00:558187 2018) [sss_cache] [confdb_get_domains] (0x0010): No domains configured, fatal error!

Could not open available domains

usermod: sss_cache exited with status 2

usermod: Failed to flush the sssd cache.


I cannot reproduce it on my own machine or a virtual one.

I've changed the component to shadow-utils, so the maintainers are aware as well.

--- Additional comment from Jakub Hrozek on 2018-12-19 11:15:56 UTC ---

(In reply to Miro Hrončok from comment #2)
> One of our students was just hit by this at a Fedora 29 workstation.
> 
> He run:
> 
> $ sudo usermod -a -G dialout username
> 
> And got:
> 
> (Wed Dec 19 11:58:00:558187 2018) [sss_cache] [confdb_get_domains] (0x0010):
> No domains configured, fatal error!
> 
> Could not open available domains
> 
> usermod: sss_cache exited with status 2
> 
> usermod: Failed to flush the sssd cache.
> 
> 
> I cannot reproduce it on my own machine or a virtual one.
> 
> I've changed the component to shadow-utils, so the maintainers are aware as
> well.

shadow-utils only execs sss_cache, so sssd is the proper component. But for some reason (BZ upgrade?) I can't reassign the bug back.

--- Additional comment from Sumit Bose on 2018-12-19 11:43:15 UTC ---

Here you are, clicking the Component and hitting backspace worked for me.

--- Additional comment from Tomas Mraz on 2018-12-19 13:00:50 UTC ---

Perhaps the sss_cache should be silent by default on such errors?

--- Additional comment from Jakub Hrozek on 2018-12-19 13:27:10 UTC ---

(In reply to Tomas Mraz from comment #5)
> Perhaps the sss_cache should be silent by default on such errors?

Yes and the errors should not be produced IMO (IOW, no domains should be just a no-op).

Also, I'm not sure how a no-domains error happens, there should always be at least the implicit files domain.
Comment 1 Tomas Halman 2019-01-09 15:18:36 UTC 
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3919
Comment 2 Jakub Hrozek 2019-01-29 19:58:53 UTC 
* master:
 * 415094687e92789060626176c5ced31d4122692d
 * 71475f1ed78a65d78f75e5ca0fdc6e20cfdf2f39
 * 325df4acae303efeabd96d2247fb5799c728536a
 * 88c0c3fcd1d97bd499bb28c2065ba19d629fa4f7
Comment 3 Jakub Hrozek 2019-02-05 21:42:11 UTC 
Additional fixes:
 * master:
  * 159a2316b8d5560da5264022c598f1072f21bdba
  * 2de3c5fb2490da0dabed0de498a8296db85a1e61
* sssd-1-16:
  * 6c8084778fa5450b07b437ecf72cae247767b9d6
  * 3ec716bb042dc51ae7a75e546c64c8e89c1a2d80
Comment 6 Amith 2019-08-27 22:54:40 UTC 
Verified the bug on SSSD Version : sssd-2.2.0-16.el8.x86_64

Steps followed during verification:

1. Reproduce the issue with older build, for example install sssd-2.0.0-6.el8.x86_64 and verify step 2.

2. Test a scenario wherein SSSD have never been started but some utilities in shadow-utils call sss_cache. So stop SSSD service and delete cache files from /var/lib/sss/db/ dir and execute the following:

# sss_cache -U ; echo $?
(Wed Aug 28 03:42:26:575405 2019) [sss_cache] [confdb_get_domains] (0x0010): No domains configured, fatal error!
Could not open available domains
2

# sss_cache -G ; echo $?
(Wed Aug 28 03:42:50:940325 2019) [sss_cache] [confdb_get_domains] (0x0010): No domains configured, fatal error!
Could not open available domains
2

# sss_cache -E ; echo $?
(Wed Aug 28 03:42:58:567361 2019) [sss_cache] [confdb_get_domains] (0x0010): No domains configured, fatal error!
Could not open available domains
2

3. The above commands log "fatal error" which infact is not that fatal. In such scenarios, sss_cache shouldn't fail or log extreme messages. Now upgrade SSSD to latest version ie sssd-2.2.0-16 and run some sss_cache tests. 

4. Scenario-1: when SSSD is inactive and db files don't exist, run sss_cache command for invalidating entries.

# sss_cache -U ; echo $?
0

# sss_cache -G ; echo $?
0

# sss_cache -E ; echo $?
0

# sss_cache -u non-existinguser ; echo $?
0

NOTE: As expected, fatal error is not logged.

5. Scenario-2: when SSSD is active however entries does not exist in cache.

# sss_cache -U ; echo $?
0

# sss_cache -G ; echo $?
0

# sss_cache -E ; echo $?
0

# sss_cache -u non-existinguser ; echo $?
No cache object matched the specified search
2

NOTE: As expected, no fatal errors and command only fails when non existing entries are invalidated.

6. Scenario-3: when SSSD is active and a non-existing domain is invalidated.

# sss_cache -d nonexisting -g TEST ; echo $?
Could not open domain nonexisting. If the domain is a subdomain (trusted domain), use fully qualified name instead of --domain/-d parameter.
2


OBSERVATION: Tests show expected results.
Comment 9 errata-xmlrpc 2019-11-05 22:33:53 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3651
Note You need to log in before you can comment on or make changes to this bug.