problems with LocalDynamicMetadataResolver and shibb 5.1.6 on rocky9 (tier container)

[Brent Putman]

What Scott said, esp about permissions. But also:


On 9/25/25 2:09 PM, Nathan Christopher Lewan via users wrote:
> ROCKY 9:
> TRACE 
> [org.opensaml.saml.metadata.resolver.impl.LocalDynamicMetadataResolver:118] 
> - LocalDynamicMetadataResolver OurLocalMetadataProvider: Attempting 
> to load from local source manager with generated key 
> 'f4325ed353dcc638925265e7aa47b6dc457b77a4.xml'
> ROCKY  8:
> TRACE 
> [org.opensaml.saml.metadata.resolver.impl.LocalDynamicMetadataResolver:118] 
> - LocalDynamicMetadataResolver OurLocalMetadataProvider: Attempting 
> to load from local source manager with generated key 
> 'f4325ed353dcc638925265e7aa47b6dc457b77a4.xml'

Both your Rocky 8 and 9 examples are consistent in what the provider is 
looking for, i.e. there is no change to the SHA-1 calculation in Java. 
So that's the filename it's going to expect to be there.


>
> When I go look on the running container filesystem for 5.1.6 running 
> rocky9, I see the digested file referencing the metadata file I 
> mentioned above is this:
>
> f2743c7e3c397a27ceec8a2950f1a9994c1c3496.xml -> localtest_site_edu.xml
>
> which doesn't match.
>
Yes, the mismatch is the problem (assuming that's the digest-named file 
you are expecting it to find).  The issue is likely in whatever/however 
that SHA-1-digested filename is being generated.  I'd look at that as 
the culprit.

As it says in the wiki the entityID should be digested without any 
leading/trailing whitespace, including newline.  So you can test what 
you directory population is doing against what it should be doing with 
something like this:

|echo-n "http://localtest.site.edu.edu:8091/sso/metadata"|openssl sha1|

If your filenames don't match that CLI test, then your filenames are 
wrong, somehow.


> I have tried with multiple metadata files, all that work except with 
> rocky9. I verified the metadata files are UTF8 with LF endings.

The actual file content, encoding or line endings won't matter, b/c 
it's only the entityID string that is the input to the SHA-1 digest for 
the filename.  If your process to populate the directory is reading the 
metadata XML, extracting the entityID attribute and then digesting it 
with SHA-1, then I'd suspect something in the Rocky9 platform changed 
that has broken that, such as a change to XML parser, or to language 
interpreter, like Python, etc.  You'd need to dig into the details of 
how you've engineered the process that populates your local directory 
with the digested filenames.



>
> I am wondering if there is some sensitivity in string reading that is 
> occuring in one process (generating the symlink digest file), and not 
> the other(recomputing and searching for it), but I have no idea about 
> that process, or if how i've outlined it above with two separate 
> parts is even accurate.

Yes, almost certainly it's something like that. The digest calculation 
on the Java side in the metadata provider hasn't changed, as indicated 
by your log output.  So I'd suspect your local process for ingesting 
files and populating the directory has inadvertently changed how the 
digest filename is calculated in Rocky9.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250925/e9ea56f2/attachment.htm>