Strange lfric_core export issue.

[BShipway]

I've just started working with rose stem with vn1.1 lfric_apps and have hit a problem. The lfric_core_rev is not being picked up by the fcm export. E.g.
export lfric_core_rev=50658
export lfric_core_sources=

and yet, the log gives (head of trunk):
Exported revision 50871.

This is the case with a clean checkout of vn1.1 trunk. Others don't seem to have this issue, so it's likely something wrong with my environment. Anyone got any ideas?

[BShipway]

Solved after some digging.

It appears that this was due to a problem with my ssh known_hosts. Having recently messed about with them, it seems I wasn't able to non-interactively ssh from my own machine to itself. This led to the cat command at line 32 of determine_source.py to fail, but resulted in an empty string for the dependencies rather than capturing a failure.

[James Bruten (james-bruten-mo)]

Hi Ben, Thanks for sharing your findings. I think adding a check on the return code of the ssh command would be a sensible step - I'll have a look at adding that.

[BShipway]

Thanks James. That would be great. I think just looking at result.returncode being non-zero would suffice, although result.stderr would provide some useful additional info. Having fixed my ssh issue, I'm afraid I won't be able to check your solution for that though!

[Maggie (maggiehendry)]

I've got this issue too although I don't recall having messed around with my ssh known_hosts. I've checked out vn1.1 LFRic apps, but it is checking out the lfric_core head.

[info] location lfric_apps: 0: svn://fcm1/lfric_apps.xm_svn/main/trunk@4167 (4155)
[info] location lfric_apps: 1: vld087.cmpd1.metoffice.gov.uk:/var/tmp/persistent/hadhm/lfric_apps_work/vn1.1_trunk
[info] location lfric_core: 0: svn://fcm1/lfric.xm_svn/LFRic/trunk@51147 (51144)
[info] location shumlib: 0: svn://fcm1/utils.xm_svn/shumlib/trunk@7618 (7464)

What was the solution BShipway to get it working? I think a ticket that I'm reviewing may also have had this problem.

Thanks,
Maggie

[BShipway]

Hi Maggie. The problem I had was that I couldn't ssh into the target machine. You should just be able to test this from the command line. The solution then is then to fix your ssh keys.

I believe James Bruten (@james-bruten-mo) has now put an error trap for this in revision [3656].

[James Bruten (james-bruten-mo)]

Yep, rose stem should raise an error if it can't read the dependencies file. This was added during the release though so won't be in a version branch just yet.

[Maggie (maggiehendry)]

So it turns out that this was also an ssh issue, although I have no idea why the ssh issue arose in the first place as I haven't done anything to my known hosts. The Rose stem ssh command is 'ssh vldXXX.cmpd1.metoffice.gov.uk’ and not 'ssh vldXXX’. So, while I can ssh to vldXXX no problem, I had a mismatch with 'ssh vldXXX.cmpd1.metoffice.gov.uk’. See the error message:

Warning: the ECDSA host key for 'vldXXX.cmpd1.metoffice.gov.uk' differs from the key for the IP address.
Offending key for IP in ~/.ssh/known_hosts:107
Matching host key in ~/.ssh/known_hosts:132

I deleted the keys and ssh’d to them both to add the correct keys. It all works fine now. Thanks for your help 😊.

[svadams (svadams)]

I think I'm getting a related problem with ssh when using a working copy. I get this error

An error occured while running the command 'ssh vld344.cmpd1.metoffice.gov.uk cat /net/data/users/sadams/LFRic_expts/NGARCH/lfric_apps_4035/dependencies.sh' in order to read the dependencies file.
    The error message is:  'Host key verification failed. '

I can however ssh here from the command line just fine! On asking some of the cylc experts around me (I had another error running cylc previously) they suggested to add '-oStrictHostKeyChecking=no' to the ssh command. I added this to the determine_source.py and this works but obviously this is a local modification which isn't a permanent solution

[Sam Clarke-Green (t00sa)]

The error indicates a mismatch between the stored host key in your ~/.ssh/known_hosts file and the current host key - which usually gets regenerated when the system is re-installed. Try running the following commands on the platform where the problem occurs:

ssh-keygen -R vld344
ssh -o StrictHostKeyChecking=no vld344 date

If this works, you should be able to repeat the ssh command without the StrictHostKeyChecking option and it shouldn't produce an error

[svadams (svadams)]

[like] Samantha Adams reacted to your message:

…

________________________________ From: Sam Clarke-Green ***@***.***> Sent: Tuesday, November 5, 2024 10:41:08 AM To: MetOffice/simulation-systems ***@***.***> Cc: Samantha Adams ***@***.***>; Comment ***@***.***> Subject: Re: [MetOffice/simulation-systems] Strange lfric_core export issue. (Discussion #237) This email was received from an external source. Always check sender details, links & attachments. The error indicates a mismatch between the stored host key in your ~/.ssh/known_hosts file and the current host key - which usually gets regenerated when the system is re-installed. Try running the following commands on the platform where the problem occurs: ssh-keygen -R vld344 ssh -o StrictHostKeyChecking=no vld344 date If this works, you should be able to repeat the ssh command without the StrictHostKeyChecking option and it shouldn't produce an error — Reply to this email directly, view it on GitHub<#237 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACA6LRVOCD26EWVQI2PJVH3Z7COEJAVCNFSM6AAAAABMZOXRLKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMJVGMZDOOA>. You are receiving this because you commented.Message ID: ***@***.***>