Changing Replication SSH port and/or IP to DNS name after the fact.

[Wayne Rasmussen]

FYI please read all before you summarily dismiss because there are no hardware details - which are irrelevant as you will see.
I recently set up FreeNAS-9.2.1.2-RELEASE-x64 (002022c) on two machines connected via a LAN and validated Replication worked as expected. I then changed the SSH port from standard 22 to another (outside reserved space) and the IP address of the replication server to its DNS name. Changed the appropriate firewall setting to ensure the new port was routed to the replication server - firewall log subsequently showed incoming request on expected port. I deleted and recreated the replication task to ensure Remote hostkey could be repopulated correctly (correct Remote hostname is shown in Remote host key after scan) via SSH Key Scan (this button is only available during task creation). Replication no longer worked even with "Initialize Remote side for once set.", which also did not clear between invocations (pressing OK button and checking again).
What did return things back to "expected behavior" was deleting /data/ssh/replication after which the initialization worked as expected - I had tried many other permutations before deleting this file including deleting and recreating the ZFS Dataset on the replication server (which included deleting the previous successful snapshot transfers when done via the LAN), changing port back to 22, using external IP address of replication server vs DNS name.
I do not know the full ramifications (beyond having to retransmit the entire dataset) of deleting /data/ssh/replication (a file) but do know it worked for me, as such it MAY (when there is only one dataset involved) be a reasonable step to add to the trouble shooting section for replication.

 

[cyberjock]

I'm sorry, but if you are going to show up here and ask for help, I don't think you're in the position to determine what is or isn't relevant to the issue. If you are asking for help then it's obvious you couldn't solve it yourself. Which if you couldn't solve it you probably couldn't identify the problem. My first question would be how much RAM and how much data are on the 2 ends... that can affect the outcome(and has for people in the last few days).

I'd have to do more testing to figure out what is going on with your /data/ssh/template file. I don't have that file. But I'm not using 9.2.1.2 either.

 

[Wayne Rasmussen]

I'm sorry, but if you are going to show up here and ask for help, I don't think you're in the position to determine what is or isn't relevant to the issue. If you are asking for help then it's obvious you couldn't solve it yourself. Which if you couldn't solve it you probably couldn't identify the problem. My first question would be how much RAM and how much data are on the 2 ends... that can affect the outcome(and has for people in the last few days).

I'd have to do more testing to figure out what is going on with your /data/ssh/template file. I don't have that file. But I'm not using 9.2.1.2 either.

What - did you reply before even completing a tertiary read? I am NOT asking for help. I am attempting to share my experience! I have already resolved my problem by finding an effective work around, I am sharing that experience and work around but am not naive enough to think one size fits all. I think it is pretty clear that how much memory, what type, what firmware revision levels, not to mention what firewall/s, what ISP, what IP protocol, what switches etc are involved have little to add of value to "I changed IP address to DNS name and SSH Port from 22 to x" and it did not work until I deleted /data/ssh/replication (previously incorrectly reported by me as .../template) and then it did work.

 

[cyberjock]

Actually, I did read your whole post.. especially since you prefaced it with "don't summarily dismiss me".

I thought you were asking for help in that you wanted to know why it behaved in the way it did. That file doesn't exist on my 9.2.0 install. I'm thinking I might try 9.2.1.3 in a VM when it gets finalized. We'll see. I'm curious to know what the contents of that file is to say the least.

 

[Wayne Rasmussen]

It is a little more complicated than that (looking for the file). It appears that file is a temporary one when all is working as expected i.e. the file is no longer present. I will attempt to recreate the problem and copy/analyze the /data/ssh/replication (previously incorrectly reported by me as .../template) before deleting it. I'll post the results.

 

[Wayne Rasmussen]

Firstly my apologies - its /data/ssh/replication NOT /data/ssh/template. Having said that all else is as explained before. I have managed to repeat the scenario by changing the SSH port (on firewall, replication server SSH service and replication client task). The result is the creation of /data/ssh/replication (not to be confused with /data/ssh/replication.pub) which turns out to be a RSA PRIVATE KEY file and failure to replicate. Deleting said file and recreating the Replication task allows "Initialize remote side for once" to complete and once it does /data/ssh/replication is no longer present and replication is continuing as expected.