Start a new topic
Deferred

Save Fingerprint for Dynamic Folder Connections

When I refresh my server list with the reload button it loads the expected servers. When I connect to one server it warns me for the fingerprint warning which is expected for the first time. But when I click reload again now, one week later, or next time Royal TS loads the dynamic folder it forgets the fingerprint and asks me again even though the fingerprint is the same as the very first time it asked me.


So the idea/the ask is please provide an option and or default turned on for saving fingerprints for dynamic folders connections. This works as expected when just adding a regular connection to a document.


The other temporary workaround I don't want to do is disable fingerprint for those connections in the Royal JSON.


If there is something I'm missing to fix this, or another solution that's not above please let me know.


Hi,


this is a tricky problem and we're not sure how we can resolve this in a good way. The problem is that we don't really know where to store these fingerprints. The dynamic folder contents don't get persisted and are always recreated when you do a reload. The tricky part is to store this information in a way so that no "dead" data is filling up the hard disc space. When we store this outside of the folder or the document, we will never know how long this information is relevant and we don't really know when we can clean up older fingerprints for hosts not in use anymore.


Not sure where your data source for the rJson is but providing the correct fingerprint for each host upfront and use it in the dynamic folder would probably be the best option.


If you have suggestions on how we can fix this, let me know.


Regards,
Stefan

Thanks for the background. The reasoning behind the decision makes mostly sense. It didn't cross my mind that I could add the fingerprint to the rJSON until you mentioned that. That's a good workaround. I was able to do this and it works as expected now. 


For anybody else that's interested in how I did this, here is the bash code I came up with to grab the fingerprint for rJSON. This could probably be written better, open for suggestions/improvements. Bash not my favorite/best language.

file2=$(mktemp);
file3=$(mktemp);
for i in $(cat nodenames | sed 's/,/ /g') do

 file=$(mktemp)
 ssh-keyscan -t rsa $i > $file 2> /dev/null
 echo $(ssh-keygen -E md5 -lf $file | awk '{print $2}' | cut -d ':' -f 2-) >> $file2
 rm $file
done
sed '$!s/$/,/' $file2 | tr -d '\n' >> $file3;
cat $file3;
rm $file2;
rm $file3

Background why I wrote it this way: nodenames is a comma separated list of hostnames. I first create 2 temp files to manipulate data. Than it starts and looks in nodenames relative file and starts looping (note: takes off commas to loop properly but I put commas back at the end, and we use MD5 fingerprint) through using first ssh-keyscan -t rsa cause that's what is is defined first in /etc/ssh/sshd_config on our servers - Source here: https://askubuntu.com/questions/76337/where-is-the-ssh-server-fingerprint-generated-stored

 

It then uses ssh-keygen -E md5 -lf $file to read that data and understand it more, than some text manipulation to just pull the fingerprint. This sed '$!s/$/,/' adds a comma at the end of every line except the last line, credit from: https://stackoverflow.com/a/35021663 into a new file (I need the commas back for what I do with it afterwards to loop through them properly outside of this for the rJSON)

I then pipe that new file into a tr command to get rid of the new lines, then finally cat it out for output. Then delete all the files used.


Alright with that out of the way some outstanding questions/suggestions I have:

  1. The main suggestion I have is maybe an option to store them for 90 days by default, or more according to what the user wants. I don't think I would mind saying yes to the fingerprint not being in the cache every so often but every time is very much annoying. If time based than old ones would get purged and not fill up disk space. Not ideal, but a suggestion. Putting them up front is better, but if users can't do this than maybe this suggestion.
  2. I first couldn't get the fingerprint to work in the rJSON at first, and then I found out I had to go one layer deeper to the "RoyalDocument data model" aka Properties to use it. My question is it's mentioned here: https://docs.royalapps.com/r2021/scripting/rjson/advanced-scenarios.html that "Another reason we do not recommend using the RoyalDocument data model is that it can change at any time and we cannot guarantee a stable API". This worries me a little. So your saying this fingerprint entry I'm doing it this way can break on any future updates of Royal TS? Granted, I am only using the fingerprint in the properties data for now but still worrisome for you guys to say that.
  3. Under Advanced for a dynamic folder, there is an option that says: "Persist (cache) folder contents". Can you elaborate what this means more? I tried to make sense of it but I haven't yet. It's greyed out for me right now, but at other times I have seen the option to checkmark it. Why am I given the option sometimes for it? And if the whole idea for dynamic folders is not persistent data than why is this even an option?


1 person likes this

Thanks for sharing your solution. I'm happy you got it working. Let me go through your questions:


1) I think that's a great idea and would resolve the issue. Right now, our internal architecture doesn't provide any means to implement such a "feature" and it would be quite an effort to implement it. But we will keep this in mind for future releases.

2) I think you don't have to worry about that. In the past 20 years we haven't changed a single property name but there's always a chance that we have to and in this case, your dynamic folder script would break. Rest assured, should we change such a property it would a) be communicated in the release notes and b) not a huge deal to adapt the script to use the new property/functionality (depending, of course, what changed and why it had to be changed).

3) Persisting of dynamic folder items is only possible in "Personal (Overwrite)" documents (see document type: https://docs.royalapps.com/r2021/royalts/reference/organization/document.html#document-type). If you have such a document and enable the option, it will save the entries for the dynamic folder to disc, so that when you open it, you don't need to run the dynamic folder script in order to get the entries. The saved entries may be out of date though as it reflects the state it had when you last ran the script.


Regards,
Stefan

Login or Signup to post a comment