SOLVED 11.2-U6: sync errors... Should I downgrade to U5?

[zamana]

I did upgrade from U5 to U6 by using a new boot device and then restoring the config file.

This morning I received e-mails from my FreeNas with errors regarding my "Replication Tasks", all of them about "permission denied" due to ssh keys etc, even though I had updated all of them yesterday.

Now I tried to update one of the keys again, and got this error:

Code:

Error: Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/middlewared/main.py", line 165, in call_method
    result = await self.middleware.call_method(self, message)
  File "/usr/local/lib/python3.6/site-packages/middlewared/main.py", line 1096, in call_method
    return await self._call(message['method'], serviceobj, methodobj, params, app=app, io_thread=False)
  File "/usr/local/lib/python3.6/site-packages/middlewared/main.py", line 1044, in _call
    return await methodobj(*args)
  File "/usr/local/lib/python3.6/site-packages/middlewared/schema.py", line 664, in nf
    return await f(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/middlewared/plugins/replication.py", line 307, in ssh_keyscan
    raise CallError(errmsg)
middlewared.service_exception.CallError: [EFAULT] ssh key scan failed for unknown reason

Does anybody know what's going on?

Thanks.
Regards.

 

[dlavigne]

For security reasons, SSH keys are not stored in the config:
SSH keys are not stored in the configuration database and must be backed up separately. System host keys are files with names beginning with ssh_host_ in /usr/local/etc/ssh/. The root user keys are stored in /root/.ssh.

You shouldn't be getting a traceback though. Which steps reproduce it?

 

[zamana]

Hi. Thanks for reply.

I did backup the root user keys but not the host keys. Anyway I didn't use any of them and prefer to update my remote systems with the new generated keys, both root (for ssh) and host (for zfs send/recv, replication, rsync etc).

I`m not sure how to reproduce exactly. The only thing I remember now is that the first time that I scanned the keys in the replication task page, they were all updated, but in the end they didn't work, and from the second time on, when I tried to update them, I did receive that exception.

UPDATE: things seems to did get a little bit worse... I deleted one of my replication tasks and now I can't recreate it, due to the same error...

Thanks.
Regards.

 

[zamana]

Is there a way to resume the replication tasks without starting from scratch again?

 

[dlavigne]

Were you able to resolve this?

 

[zamana]

Hi!

I'm sorry for the lack of feedback and thanks for asking.

It turns out that the remote system, the one where the backups were sent, was offline...

After turning it on, everything came back to normal again.

Thanks.
Regards.

 

[c4rp3d13m]

please check your Services, make sure that SSH is enabled

 

[Redcoat]

A little late in response for someone apparently dedicated to seizing the day...?