search

cyverse / gocommands

iRODS Command-line Tools written in Go
Other
29 stars 18 forks source link

gocommands and iRODS instances that use PAM authentication #4

Closed jnimoth closed 1 year ago

jnimoth commented 1 year ago

Hi, we are currently investigating different client solutions for our iRODS users, also the gocommands.

Different trials to connect to an iRODS instance that uses PAM authentication resulted in CAT_INVALID_AUTHENTICATION messages. As I could also not find any reference to different authentication schemes in the code of gocommands, I assume that PAM authentication scheme is currently not possible,

Is this indeed the case or are we missing something?

And if it is not possible right now, is it planned to enable PAM authentication in one of the coming releases?

Thanks!

iychoi commented 1 year ago

Hi @jnimoth

Sorry for late response.

The latest version, v0.4.1, supports PAM authentication. I fixed bugs related to PAM authentication and it is working now. Please test it and let me know if it doesn't work for you.

iychoi commented 1 year ago

Sorry for confusion.

I fixed PAM authentication related issues in iRODS FUSE Lite. I forgot to add the patch to gocommands. Sorry for confusion.

It is not difficult to add PAM authentication to gocommands. I'll work on it soon, maybe end of January.

iychoi commented 1 year ago

Would you try the new release v0.4.2? https://github.com/cyverse/gocommands/releases/tag/v0.4.2

Here's the configuration example. https://github.com/cyverse/gocommands/blob/main/examples/config_pam.yaml

I haven't tested the new PAM auth feature because I don't have iRODS test servers that support PAM auth. So give a try and let me know if it doesn't work.

jnimoth commented 1 year ago

Thanks for making the changes. I just tried with our iRODS instance and I could successfully connect with the new release v0.4.2!

There still are some thing to consider:

ERRO[2023-01-20 15:02:49.362] error while uploading a local file <localPath> to <irodsPath> error="ErrorCode: -169000" function=ScheduleUpload package=commons struct=ParallelTransferManager ERRO[2023-01-20 15:02:49.362] ErrorCode: -169000 function=processPutCommand package=main ErrorCode: -169000

The file does nevertheless appear on the iRODS side and the checksum is also equivalent to the original file. So the file seems to be uploaded fine. Also, I did not get error messages for the the get command.

I did not try the other functionality so far, but I am already happy that I can now connect to our system using gocommands!

iychoi commented 1 year ago

Great to hear that it worked!

About the password in the yaml file, I'm looking for a good way to store it securely. Yet I couldn't find.

For the error while running put command, I need more information about the environment. What version of iRODS server did you connect? Did you try to overwrite the file? Can you provide detailed log messages? You can get more debug log messages by adding -d option.

jnimoth commented 1 year ago

Hey Illyoung, thanks again for your fast reply!

Here some more information about the problem that I experienced for the put command:

My config file currently looks like this:

irods_host: "<our_server_address>"
irods_port: 1247
irods_user_name: "<my_irods_user_name>"
irods_zone_name: "<our_zone_name>"
irods_user_password: "<my_irods_password>"
irods_cwd: ""
irods_default_resource: ""
irods_client_user_name: ""
irods_log_level: 5
irods_authentication_scheme: "pam"
irods_client_server_negotiation: "request_server_negotiation"
irods_client_server_policy: "CS_NEG_REQUIRE"
irods_ssl_ca_certificate_file: "/etc/ssl/certs/ca-bundle.crt"
irods_encryption_key_size: 32
irods_encryption_algorithm: "AES-256-CBC"
irods_encryption_salt_size: 8
irods_encryption_num_hash_rounds: 16

And here an example using the put command with the additional debug flag, while first showing that the destination is indeed empty:

$ ./gocmd -c config_gocmd.yaml ls test_dir
$ ./gocmd -c config_gocmd.yaml put -d test.tar test_dir/
DEBU[2023-01-23 17:04:32.935] use sessionID - 15311                         function=ProcessCommonFlags package=commons
DEBU[2023-01-23 17:04:32.936] reading config file/dir - /home/<username>/config_gocmd.yaml  function=loadConfigFile package=commons
DEBU[2023-01-23 17:04:32.936] reading gocommands YAML config file - /home/<username>/config_gocmd.yaml  function=loadConfigFile package=commons
ERRO[2023-01-23 17:05:08.928] error while uploading a local file /home/<username>/test.tar to /<irods_zone>/home/<irods_username>/test_dir/test.tar  error="ErrorCode: -169000" function=ScheduleUpload package=commons struct=ParallelTransferManager
ERRO[2023-01-23 17:05:08.928] ErrorCode: -169000                            function=processPutCommand package=main
ErrorCode: -169000

When I re-download the file using the get command, I do not see a similar error message. I also compared the sha256 checksum of the original file with the re-downloaded file. Both checksum are identical.

iychoi commented 1 year ago

Thanks for the logs. It looks like there's an issue while replicating the file after upload in your environment. I added a new command-line flag --no_replication to turn the replication off. Please try the new release v0.4.3 to use it. https://github.com/cyverse/gocommands/releases/tag/v0.4.3

Here's an example command. ./gocmd -c config.yaml --no_replication put <file>

jnimoth commented 1 year ago

I just tried the new version v0.4.3., with the --no_replication flag, the error message is gone and iput seems to work without issues now!

I am planning to do a little bit more testing of gocommands with our iRODS instance, especially to see if it could be a nice alternative for Mac users.

Up to now, I just did limited testing, but I already experienced some small other issues. For example, it does seem as if cd also does not work for me. After running cd, I do in fact always stay in my home collection.

If I see additional issues like that, I think it is best to make separate Github issues, or what do you prefer? This one could then be closed.

iychoi commented 1 year ago

Great to hear that it worked.

Yes, create new Github issues separately per bug. It will be the best.

Thanks for the testing 👍