<html><head>
<meta name="Generator" content="Novell Groupwise Client (Version 18.2.0 Build: 135307)">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head>
<body style="font: 10pt/normal Segoe UI; font-size-adjust: none; font-stretch: normal;"><div class="GroupWiseMessageBody" id="GroupWiseSection_1617631416000_TWIN.Administrator@twinmro.com_4D673D8009A70000BE0E37010000C42E_"><div>Hi Malcolm, </div><div><br></div><div>It's been a while, trust all is well. </div><div><br></div><div>Yes unfortunately, everything works great until the system is placed into FIPS mode, then chronyd fails to run/start.</div><div><br></div><div>My team just found out (as I was typing this reply) that if we create a new SLE 15 chronyd local timesource server on the network and we point the SLE 15 FIPS/chronyd clients to the new local chronyd server, the client chronyd loads properly and runs! But we can't run the actual chronyd time server system in FIPS mode even with a public source - so it is still a problem but we can work with this (one system being out of compliance instead of all systems being out of compliance). This is our workaround at the moment. </div><div><br></div><div>It seems SLES15 chronyd clients can not speak to SLES 12 ntp local time clocks if the SLE15 chronyd system/kernel is running in FIPS mode...</div><div><br></div><div>Kevin<br></div><div class="GroupWiseMessageBody" id="GroupWiseSection_1617626507000_malcolmlewis@cableone.net"><span class="GroupwiseReplyHeader"><br><br>>>> On 4/5/2021 at 8:41 AM, <malcolmlewis@cableone.net> wrote:<br></span><div><div>On Mon, 05 Apr 2021 07:51:31 -0400</div><div>"Kevin Salisbury" <Kevin.Salisbury@twinmro.com> wrote:</div><div><br></div><span style="color: rgb(128, 128, 128);">> I have confirmation of a carryover chronyd bug from SP2 into SP3</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> (bugzilla number 1173760).</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> </span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> Steps to reproduce;</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> - Built a new x86_64 SLES15 SP3 Beta box and updated.</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> - Setup an internal time source for chronyd on install both manually</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> and with autoyast - no issues. Time is fine.</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> - Install FIPS pattern, and set grub bootloader kernel boot option</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> 'fips=1' and restart</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> - chronyd fails to load with internal time source. If a public time</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> source is used for chronyd, it seems to load fine (but of course, one</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> can't use a public source if servers are not supposed to see the</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> internet or are "air gapped").</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> </span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> We suspect there needs to be something else done on the internal time</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> source, or a local configuration change not documented for FIPS</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> systems; we've tried several different internal time clock sources</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> and manual edits of chronyd configurations -- nothing seems to work.</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> The issue does not exist on SLES 12 systems. Curious to know if</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> others in FIPS environments have seen this behavior with SLE 15 and</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> if there's a workaround...(it seems that we are missing something</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> very simple, admittedly we are not experts with chronyd yet, but so</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> far SUSE support can replicate the issue - but has no solution for us</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> either).</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> </span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> This post is FYI only. This is a known issue, although not documented</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> in the readme, it's going to limit deployment in many regulated</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> environments... </span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> </span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> Kevin</span><span style="color: rgb(0, 0, 0);"><div><br></div></span><span style="color: rgb(128, 128, 128);">> </span><span style="color: rgb(0, 0, 0);"><div><br></div><div>Hi</div><div>Not a chrony expert or FIPS user either, but am using the aarch64 (RPi3)</div><div>SLES 15 SP3 for a local time source with gps/pps/rtc which is working</div><div>great.</div><div><br></div><div>Have you run makestep, is the time in use UTC, timedatectrl looks good,</div><div>cmos battery ok, are the pools disabled (/etc/chrony.d/pool.conf?</div><div><br></div><div>Changed the stratum level?</div><div><br></div><div>-- </div><div>Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)</div><div>Tumbleweed 20210330 | GNOME Shell 3.38.3 | 5.11.6-1-default</div><div>Intel DQ77MK | Xeon E3-1245 V2 X8 @ 3.40 GHz | Intel/AMD/Nvidia</div><div>up 9:20, 2 users, load average: 0.94, 1.12, 0.83</div></span><span style="color: rgb(0, 0, 0);"></span></div></div></div></body></html>