iRODS: Add general purpose profile (main) #163
Conversation
|
Updated based on companion PR. Squashed and ready for final review. |
|
@dkocher This profile adds a general purpose profile that will work for any iRODS deployment as long as it is updated appropriately. I'm wondering if the following RENCI profile should be disabled/removed to avoid confusion? The docs reference profiles named RENCI, CyVerse Data Store, and TACC. The ones for CyVerse and TACC seem fine as they are focused on a particular deployment. The one for RENCI seems that way as well, but I don't know if the host referenced by that profile is still available. @trel Do you know if the host referenced by the RENCI profile is still live? Do you recognize that host? I can't ping it, so maybe it's no longer active? |
|
I would recommend we remove all the specific profiles in favor of a single default/generic one. |
I am fine with dropping deprecated connection profiles. They will not be removed on client installations. |
|
@dkocher The changes to Cyberduck bump the minimum version capability for iRODS to 4.3.2. Any user who wants to use Cyberduck to connect to an earlier version of iRODS will need a Cyberduck client of 9.3.x or earlier. Are older versions of Cyberduck available for download? |
I understand that previous connection profiles for deployments using deprecated iRODS version will be rendered incompatible.
|
|
Adjusted a few comments following the documentation PR. No functional changes were made to the configuration properties. This is ready for final review. |
|
@korydraughn Can you confirm this profile works for default installations of iRODS with no required further customization required by the user as this will be available through Preferences →Profiles. |
| <!-- - CS_NEG_DONT_CARE: Let the server decide if TLS should be used. --> | ||
| <!-- - CS_NEG_REFUSE: Do not use TLS. --> | ||
| <key>Client Server Negotiation</key> | ||
| <string>CS_NEG_REFUSE</string> |
There was a problem hiding this comment.
Wouldn't CS_NEG_DONT_CARE be the better default?
There was a problem hiding this comment.
In theory, yes. However, we've leaned into keeping things as explicit as possible to force the user to think about what they are doing. For most users, it's likely better to avoid CS_NEG_DONT_CARE until they really need it.
CS_NEG_REFUSE is the common default used by iRODS clients.
Regardless, all users of this profile will likely need to modify the configuration because of things like the Region/Zone.
Question ... If a user needs different configuration because they are working with different iRODS deployments, will they need to make a copy of the profile under a different name?
I suspect they would since there doesn't appear to be a way to change options like these through the GUI.
There was a problem hiding this comment.
Each profile must have a unique value for the Vendor key.
There was a problem hiding this comment.
Can you explain? I don't understand how the Vendor property affects things, so it hasn't clicked for me how that solves the multi iRODS deployment case.
There was a problem hiding this comment.
Oh wait, you're highlighting that making a copy would also require updating the Vendor due to a uniqueness constraint.
And that seems okay since the Protocol key defines the which protocol to use.
| <!-- The specified resource is only used when uploading files. --> | ||
| <!-- Prefer setting "Destination Resource" under the "Properties" section. --> | ||
| <key>Region</key> | ||
| <string>tempZone</string> |
There was a problem hiding this comment.
Can this be kept empty to connect to a default zone or is this zone always available?
There was a problem hiding this comment.
Not at this time. All iRODS clients are required to manually define the zone in order to connect.
What's the best way to do that? I have bookmarks from earlier testing, so it's not clear if those would affect anything. |
|
It just occurred to me that users of this profile will likely need to modify the profile unless they are working with a completely defaulted deployment, i.e. a test system. For production systems, no one should assume this profile works as is. |
3 participants
Putting in draft until work on the other PR is complete.Taking out of draft now that the companion PR is complete.