On 08/09/19 at 01:33am, Jun Wang wrote:
> I think that it does not need this changes. What's your
opinion? Jun Wang, Dave and
> other reviewer?
Having UserKnownHostsFile in global ssh_config point to the kdump-server hostkey file or
adding those hostkeys to global known_hosts file would technically take care of the kdump
server authentication problem.
There, however, are some drawbacks with it. There are usually obstacles for any
stand-alone feature/function, such as kdump, to make feature-specific changes to the
global ssh_config or known_hosts file, unless the ssh configuration management software is
modular enough to take inputs from various features/functions -- very unlikely in
Question is why do you need separate known_hosts for kdump only? For
this case a global configuration should be reasonable.
Effectively it makes the kdump feature/package less self-contained.
When kdump fails upon the initial installation, only some users would be able to
troubleshoot the problem. Even among those users, many could be frustrated with dealing
with other teams on putting feature-specific stuff in global central ssh_config management
system. It would at least slow down the deployment/integration. In some cases, the users
would just simply give up.
On the contrary, a solution with an ssh command-line option of "-o
UserKnownHostsFile=$SSH_HOSTS_FILE " is much self-contained in kdump.
Overall, it seems that having a solution self-contained in kdump package and
configuration, be it my original proposed changes or not, would be very beneficial.
I understand the requirement and agree with you about the benefit, but
Kdump scripts have been adding too many corner cases from long time ago,
it is becoming too complicated and hard to maintain especially network part,
it is better to avoid to add new options if it is doable without adding.