The main benefit of having a separate known_hosts file for kdump is to be able to provision and manage hostkeys for kdump servers in a more self-contained manner. In fact, in our operation environment, it is a separate file to start with.

As to thw concern on kdump software’s complexity, I understand the desire to limit kdump’s scope, though I would argue that complications are there anyway. If the kdump software doesn’t handle them, they just get shipped to users for handling.



Sent from Yahoo Mail for iPhone

On Thursday, August 8, 2019, 10:23 PM, Dave Young <> wrote:

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 reality.

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.