Description of problem:
sss_cache fails to clear the cache:
$ sudo sss_cache -UG
(Fri Oct 19 07:38:23:724827 2012) [sss_cache] [sysdb_domain_init_internal] (0x0010): Wrong DB version (got 0.13 expected 0.11)
Could not open available domains
Version-Release number of selected component (if applicable):
$ rpm -q sssd
sssd is running
[stef@stef-rawhide realmd]$ ps -xa | grep sss
7521 ? Ss 0:00 /usr/sbin/sssd -D -f
7522 ? S 0:00 /usr/libexec/sssd/sssd_be --domain ipa.thewalter.lan --debug-to-files
7523 ? S 0:00 /usr/libexec/sssd/sssd_be --domain AD --debug-to-files
7524 ? S 0:00 /usr/libexec/sssd/sssd_be --domain RADI08 --debug-to-files
7525 ? S 0:00 /usr/libexec/sssd/sssd_nss --debug-to-files
7526 ? S 0:00 /usr/libexec/sssd/sssd_pam --debug-to-files
The domains are upgraded automatically when the SSSD is started after being upgraded to a package version that uses a newer internal DB version.
Is it possible that you had a domain configured with an old SSSD version, then unconfigured it while the cache was still on the dist, upgraded the SSSD and then ran the sss_cache tool?
btw if you can still reproduce the bug, here's how you can inspect which database has the wrong db version:
for db in /var/lib/sss/db/cache_*; do echo === DB: $db ===; ldbsearch -H $db cn=sysdb version; done
ldbsearch is a part of ldb-tools.
The other reason might be that the cache upgrade really failed -- that would be indicated by a very loud DEBUG message in the logs.
AH, sorry, I was reading the error backwards. The sss_cache was complaining that the database was NEWER than expected.
The 0.11 version is pre-1.9. Can you check what version of sssd-tools you had that produced the error? (sss_cache is still part of sssd-tools, not sssd even though there is a bug to change it)
Here you go:
Name : sssd-tools
Arch : x86_64
Version : 1.9.2
Release : 1.fc18
Size : 560 k
It's likely that I did alternate old and new sssd versions, although don't ask me when and which ones :)
OK, I was playing with sss_cache and trying to break it, but couldn't along my colleague Michal who is fixing and breaking the command line tools all the time :-).
Given that the only way we could reproduce the error message was by really trying to load a newer db version with an old version of the SSSD, we're going to just improve the error message upstream. Currently it's cryptic and scary.
sssd-1.9.3-1.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.9.3-1.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
sssd-1.9.3-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.