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!
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.
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.
(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.
Here you are, clicking the Component and hitting backspace worked for me.
Perhaps the sss_cache should be silent by default on such errors?
(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.
*** Bug 1661217 has been marked as a duplicate of this bug. ***
*** Bug 1662480 has been marked as a duplicate of this bug. ***
* master: * 415094687e92789060626176c5ced31d4122692d * 71475f1ed78a65d78f75e5ca0fdc6e20cfdf2f39 * 325df4acae303efeabd96d2247fb5799c728536a * 88c0c3fcd1d97bd499bb28c2065ba19d629fa4f7
master: * 159a2316b8d5560da5264022c598f1072f21bdba * 2de3c5fb2490da0dabed0de498a8296db85a1e61
Has this been fixed? I'm not sure what the master and hash values represent? We still get this error and sssd is disabled.
(In reply to RobbieTheK from comment #11) > Has this been fixed? I'm not sure what the master and hash values represent? Upstream commits > We still get this error and sssd is disabled. Yes, but the patches were not backported to Fedora yet. Rather than backporting we'd like to release a new upstream version soon (Monday?) and include the fixes as part of a new version. There are several Fedora bugs that had been fixed in the meantime upstram and backporting everything would just be too tedious.
(In reply to RobbieTheK from comment #11) > Has this been fixed? I'm not sure what the master and hash values represent? > We still get this error and sssd is disabled. If sssd is disabled then you can uninstall package sssd-common and you will not see any error.
*** Bug 1680446 has been marked as a duplicate of this bug. ***
(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: > ... > > 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. Not sure if it matters, but the machine I experienced the issue on originally had Fedora 22 or 24 or so. It has been through five or so system-upgrade. I experienced the issue for the modem, too. The problem surfaced when tying to add myself to dialout group. The modem is new to the machine and was added last week for testing.
same problem with sss_cache in clamav 0.101.2
(In reply to customercare from comment #16) > same problem with sss_cache in clamav 0.101.2 Please upgrade to sssd 2.1
https://bodhi.fedoraproject.org/updates/FEDORA-2019-efe7e2c5cf
We don't even use sssd and it's disabled. But clearing the.ldb files makes the message go away. 5.1.19-300.fc30 rpm -q sssd sssd-2.2.0-3.fc30.x86_64 systemctl status sssd ● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled; vendor preset: enabled) Active: inactive (dead) usermod -a -G cnslab ragarwal (Sat Aug 3 18:30:02:247487 2019) [sss_cache] [sysdb_domain_cache_connect] (0x0010): DB version too old [0.20], expected [0.21] for domain implicit_files! Higher version of database is expected! In order to upgrade the database, you must run SSSD. Removing cache files in /var/lib/sss/db should fix the issue, but note that removing cache files will also remove all of your cached credentials. Could not open available domains usermod: sss_cache exited with status 69 usermod: Failed to flush the sssd cache. (Sat Aug 3 18:30:02:271662 2019) [sss_cache] [sysdb_domain_cache_connect] (0x0010): DB version too old [0.20], expected [0.21] for domain implicit_files! Higher version of database is expected! In order to upgrade the database, you must run SSSD. Removing cache files in /var/lib/sss/db should fix the issue, but note that removing cache files will also remove all of your cached credentials. Could not open available domains usermod: sss_cache exited with status 69 usermod: Failed to flush the sssd cache.
(In reply to RobbieTheK from comment #19) > We don't even use sssd and it's disabled. But clearing the.ldb files makes > the message go away. > The debug message says it need to upgrade version of sssd cache and therefore it is a different issue. But I have a little bit better solution for you If you do not want to use sssd at all. Just remove package sssd-common and user{mod,add} will not be able to execute binary sss_cache. > > 5.1.19-300.fc30 > rpm -q sssd > sssd-2.2.0-3.fc30.x86_64 > > systemctl status sssd > ● sssd.service - System Security Services Daemon > Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled; vendor > preset: enabled) > Active: inactive (dead) > > > usermod -a -G cnslab ragarwal > (Sat Aug 3 18:30:02:247487 2019) [sss_cache] [sysdb_domain_cache_connect] > (0x0010): DB version too old [0.20], expected [0.21] for domain > implicit_files! > Higher version of database is expected! > In order to upgrade the database, you must run SSSD. > Removing cache files in /var/lib/sss/db should fix the issue, but note that > removing cache files will also remove all of your cached credentials. > Could not open available domains > usermod: sss_cache exited with status 69 > usermod: Failed to flush the sssd cache. > (Sat Aug 3 18:30:02:271662 2019) [sss_cache] [sysdb_domain_cache_connect] > (0x0010): DB version too old [0.20], expected [0.21] for domain > implicit_files! > Higher version of database is expected! > In order to upgrade the database, you must run SSSD. > Removing cache files in /var/lib/sss/db should fix the issue, but note that > removing cache files will also remove all of your cached credentials. > Could not open available domains > usermod: sss_cache exited with status 69 > usermod: Failed to flush the sssd cache.
I'm starting to wonder if shadow-utils shoudl just throw away all stderr from sss_cache on purpose and ignore the error code..
That could be done.
(In reply to Lukas Slebodnik from comment #20) > (In reply to RobbieTheK from comment #19) > > We don't even use sssd and it's disabled. But clearing the.ldb files makes > > the message go away. > > > > The debug message says it need to upgrade version of sssd cache > and therefore it is a different issue. Still seeing this in Fedora 31, should I open another bug? groupadd: sss_cache exited with status 69 groupadd: Failed to flush the sssd cache. (Mon Jan 13 11:46:15:017759 2020) [sss_cache] [sysdb_domain_cache_connect] (0x0010): DB version too old [0.20], expected [0.21] for domain implicit_files! Higher version of database is expected! In order to upgrade the database, you must run SSSD. Removing cache files in /var/lib/sss/db should fix the issue, but note that removing cache files will also remove all of your cached credentials. Could not open available domains groupadd: sss_cache exited with status 69 > > But I have a little bit better solution for you If you do not want to use > sssd at all. > Just remove package sssd-common and user{mod,add} will not be able to > execute binary > sss_cache. Did this, it removes a quite a few packages: dnf remove sssd-common Dependencies resolved. =================================================================================================================================================== Package Architecture Version Repository Size =================================================================================================================================================== Removing: sssd-common x86_64 2.2.2-3.fc31 @updates 5.1 M Removing dependent packages: sssd x86_64 2.2.2-3.fc31 @updates 34 k sssd-kcm x86_64 2.2.2-3.fc31 @updates 404 k Removing unused dependencies: adcli x86_64 0.8.2-7.fc31 @fedora 268 k c-ares x86_64 1.15.0-4.fc31 @fedora 232 k cyrus-sasl-gssapi x86_64 2.1.27-2.fc31 @fedora 45 k libdhash x86_64 0.5.0-43.fc31 @fedora 62 k libipa_hbac x86_64 2.2.2-3.fc31 @updates 62 k libsss_autofs x86_64 2.2.2-3.fc31 @updates 66 k libsss_certmap x86_64 2.2.2-3.fc31 @updates 123 k libsss_idmap x86_64 2.2.2-3.fc31 @updates 78 k libsss_nss_idmap x86_64 2.2.2-3.fc31 @updates 89 k libsss_sudo x86_64 2.2.2-3.fc31 @updates 59 k sssd-ad x86_64 2.2.2-3.fc31 @updates 387 k sssd-client x86_64 2.2.2-3.fc31 @updates 258 k sssd-common-pac x86_64 2.2.2-3.fc31 @updates 246 k sssd-ipa x86_64 2.2.2-3.fc31 @updates 717 k sssd-krb5 x86_64 2.2.2-3.fc31 @updates 78 k sssd-krb5-common x86_64 2.2.2-3.fc31 @updates 286 k sssd-ldap x86_64 2.2.2-3.fc31 @updates 165 k sssd-nfs-idmap x86_64 2.2.2-3.fc31 @updates 42 k sssd-proxy x86_64 2.2.2-3.fc31 @updates 144 k
Still on Fedora 33. sssd-2.4.1-1.fc33.x86_64 usermod -a -G ourgroup ouruser (2021-02-14 20:39:35:810473): [sss_cache] [confdb_get_enabled_domain_list] (0x0040): Failed to get [domains] from [sssd], error [2] (No such file or directory) (2021-02-14 20:39:35:810622): [sss_cache] [init_domains] (0x0020): Could not initialize domains (2021-02-14 20:39:35:839051): [sss_cache] [confdb_get_enabled_domain_list] (0x0040): Failed to get [domains] from [sssd], error [2] (No such file or directory) (2021-02-14 20:39:35:839127): [sss_cache] [init_domains] (0x0020): Could not initialize domains I had to remove the above packages to bypass this error. Note sssd is not in use.
Appears to be an upstream bug as this user on Debian/Ubuntu reports it: https://piuparts.debian.org/sid/pass/sssd-tools_2.4.1-2.log and https://forum.ubuntu-it.org/viewtopic.php?p=5227042#p5227042
(In reply to RobbieTheK from comment #24) > Still on Fedora 33. sssd-2.4.1-1.fc33.x86_64 > > usermod -a -G ourgroup ouruser > (2021-02-14 20:39:35:810473): [sss_cache] [confdb_get_enabled_domain_list] > (0x0040): Failed to get [domains] from [sssd], error [2] (No such file or > directory) > (2021-02-14 20:39:35:810622): [sss_cache] [init_domains] (0x0020): Could not > initialize domains > (2021-02-14 20:39:35:839051): [sss_cache] [confdb_get_enabled_domain_list] > (0x0040): Failed to get [domains] from [sssd], error [2] (No such file or > directory) > (2021-02-14 20:39:35:839127): [sss_cache] [init_domains] (0x0020): Could not > initialize domains > > I had to remove the above packages to bypass this error. Note sssd is not in > use. Hi, the reappearance of the messages is mostly related to the change of the default debug level which affects the command line tools as well, see e.g. https://github.com/SSSD/sssd/issues/5488. bye, Sumit