<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>What Scott said, esp about permissions. But also:</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 9/25/25 2:09 PM, Nathan Christopher
Lewan via users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAObaPJv4oouuVHT7QsvEdjSk-NtDO9PqNQH956-5Gb033ccSOw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">ROCKY 9:<br>
<div>TRACE
[org.opensaml.saml.metadata.resolver.impl.LocalDynamicMetadataResolver:118]
- LocalDynamicMetadataResolver OurLocalMetadataProvider:
Attempting to load from local source manager with generated
key 'f4325ed353dcc638925265e7aa47b6dc457b77a4.xml'</div>
</div>
</div>
</blockquote>
<blockquote type="cite">ROCKY 8:<br>
TRACE
[org.opensaml.saml.metadata.resolver.impl.LocalDynamicMetadataResolver:118]
- LocalDynamicMetadataResolver OurLocalMetadataProvider:
Attempting to load from local source manager with generated key
'f4325ed353dcc638925265e7aa47b6dc457b77a4.xml'</blockquote>
<br>
<p>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.</p>
<br>
<blockquote type="cite"
cite="mid:CAObaPJv4oouuVHT7QsvEdjSk-NtDO9PqNQH956-5Gb033ccSOw@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>f2743c7e3c397a27ceec8a2950f1a9994c1c3496.xml ->
localtest_site_edu.xml</div>
<div><br>
</div>
<div>which doesn't match.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<p>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. <br>
</p>
<p>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:</p>
<p><span data-code-lang="shell" data-ds--code--code-block=""
style="--ads-code-line-number-width: calc(1ch + 16px);
--ads-highlighted-start-text: Highlight start;
--ads-highlighted-end-text: Highlight end;" class="prismjs
_2rko12b0 _1dqoglyw _1wyb1crf _k48pi7a9 _1e0c1txw _vwz4gktf
_1reo1wug _o572qvpr _1eimjvyg _bfhktkvp _syaz1fxt _ect41odn
_1ozdn7od _7xinn7od _t7aun7od _r28du2gc _tajqu2gc _1ohiu2gc
_m802u2gc _i6ntu2gc _1w2xu2gc _1hmyegat _vblregat _vbulegat
_196q1xv3 _1vbw1xv3 _1v9c1xv3 _1srn17d7 _18r6myb0 _vyvc1n1a
_1d4j1y44 _1f8gstnw _1pzyb3bt _ra6gww7y _13cdh2mm _1pp0126e
_zvy9f705 _qcxof705 _qzn01a66 _j0l11wug _1weckb7n _1na21hna
_vsnzgrf3 _x7c815vq _lh0y15vq _1m3815vq _qk1e15vq _12l6ysn8
_uga3ysn8 _mx8b7mnp _1kr87mnp _xo19t94y _1bemt94y _nalpstnw
_151dstnw _1exb1q9c _1hgu1q9c _1mgnt94y _nhket94y _h909m7j4
_scgayz1z _ipl81e17 _40uk1l04 _i81p1a66 _1gx21e5h _1ls01ule
_vm2c1rh5 _12ok1rh5 _rude1ule _1q16glyw _1io6glyw _juomusic
_lcwuusic _pyovu2gc _ccm6u2gc _1ascu2gc _1yuau2gc _xr0w1a66
_4io21a66 _euyxusvi _cahfusvi _zhnuidpf _1amdidpf _mbgcpf9b
_bu7zpf9b _131n1giz _gy101giz _1wfuwrk5 _16kzwrk5 _9kk3moej
_cjus1w1g _9k2r1m30 _nhmw1m30 _yl021m30 _eiht5x2v _t9zb5x2v
_mqok1w1g _3hsg1w1g _i7ngn7od _9wu1fb2s _1xcoh55r _1t361fxt
_137bh55r _1k7d1fxt _97lipnps _12nh9lu1 _1g0517qg _i2ig10m5
_326z1fxt _113p131l _1n6tpnps _tgu817qg _1k47pnps _g0lx1fxt
_ys4e131l _7gp8h55r _1yvq10m5 _1vww10m5 _1rju10m5 _1v0lh55r
_wmyy17qg _748n17qg _1mfn17qg _1d7e17qg _p2vr17qg _19o610m5
_kxov17qg _1np517qg _m2f517qg _1b9tpnps _1tq6pnps _1rd2pnps
_1pbkpnps _k3lipnps _13zt131l _2g12fb2s _k86b10m5 _b5iy131l
_gti3131l _1f0gpnps _9d3e17qg _qdiapnps _72uvpnps _13dgkb7n
_17071olh _1i3h1txw _16noidpf _h4fuidpf _pp6yidpf _1g4tidpf
_11wmidpf _1bx8idpf" data-testid="renderer-code-block"><code class="language-shell" style="white-space: pre;"><span data-testid="renderer-code-block-line-1" data-ds--code--row="" class=""><span class=""><span class=""></span><span class="token builtin class-name">echo</span><span class=""> -n </span><span class="token string"><a class="moz-txt-link-rfc2396E" href="http://localtest.site.edu.edu:8091/sso/metadata">"http://localtest.site.edu.edu:8091/sso/metadata"</a></span><span class=""> </span><span class="token operator">|</span><span class=""> openssl sha1</span></span></span></code></span></p>
<p>If your filenames don't match that CLI test, then your filenames
are wrong, somehow.</p>
<br>
<blockquote type="cite"
cite="mid:CAObaPJv4oouuVHT7QsvEdjSk-NtDO9PqNQH956-5Gb033ccSOw@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div>I have tried with multiple metadata files, all that work
except with rocky9. I verified the metadata files are UTF8
with LF endings.</div>
</div>
</div>
</blockquote>
<br>
<p>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.<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAObaPJv4oouuVHT7QsvEdjSk-NtDO9PqNQH956-5Gb033ccSOw@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>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.<br>
</div>
</div>
</div>
</blockquote>
<br>
<p>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.</p>
<p><br>
</p>
</body>
</html>