Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Federate the iRODS instance behind Yoda with another iRODS instance #82

Open
chStaiger opened this issue Oct 27, 2021 · 1 comment

Comments

@chStaiger
Copy link
Member

chStaiger commented Oct 27, 2021

Is your feature request related to a problem? Please describe.

I would like to federate the iRODS instance behind YODA with another iRODS instance

Describe the solution you'd like

The commands iget, iput, and irsync should work for federated iRODS users. Note, the federated iRODS users do not necessarily have to be also enabled in the YODA portal.

Additional context

I federated a test YODA instance and a test iRODS instance. The remote user coming from the plain iRODS instance can do all iCAT operations like ils, ilsresc, iquest, imeta etc on the remote YODA zone. However, iput, iget and irsync hang and are not executed.
I see the agent on behalf of the remote user starting in the YODA-iRODS instance but then nothing more happens.

The other direction, a user from the YODA instance, can do all actions as remote user on the iRODS instance.

Can you please have a look, what is preventing any bit-stream operations as remote user in YODA-iRODS?

@lwesterhof lwesterhof changed the title [FEATURE] [FEATURE] Federate the iRODS instance behind YODA with another iRODS instance Oct 28, 2021
@ccacciari
Copy link
Contributor

I federated two Yoda instances v1.8 or, better, I federated the two underlying irods zone, with irods v4.2.11.
A remote user from one instance can list data and metadata correctly in the other zone.
However when I execute a icp or irsync between the two zone, I got an error:

$ imiscsvrinfo 
RCAT_ENABLED
relVersion=rods4.2.11
apiVersion=d
rodsZone=tempZoneTwo
up 2 days, 0:8
$ irsync -K i:/tempZoneTwo/home/research-core-0/test1.txt i:/tempZone/home/research-core-0/
remote addresses: 127.0.0.1 ERROR: rsyncUtil: rsync error for /tempZone/home/research-core-0/test1.txt status = -827000 CAT_INVALID_USER

If I look at the data object /tempZone/home/research-core-0/test1.txt, it has been synchronized correctly:

$ ils -L /tempZone/home/research-core-0/
/tempZone/home/research-core-0:
  researcher        0 irodsResc;dev001;dev001_p2;dev001_2           12 2023-10-18.15:25 & test1.txt
    sha2:GJShnIW6FTrL90OsTkP8AEyJFgSyb4xp4eg+oq/HxI8=    generic    /var/lib/irods/Vault1_2/home/research-core-0/test1.txt

However in the irods log of the target zone (tempZone), I can see that the error is raised by a Yoda rule that is triggered to change the ACL permissions for replication because the rule uses the remote zone (tempZoneTwo) for user rods, while it should use the local zone (tempZone):

Oct 18 15:10:32 pid:26825 NOTICE: writeLine: inString = Agent process started for puser=rods and cuser=researcher from 145.xxx.xxx.xxx
Oct 18 15:10:32 pid:26825 NOTICE: rsModAccessControl: rcModAccessControl failed
Oct 18 15:10:32 pid:26825 NOTICE: msiSetACL: ACL modifications has failed for user rods#tempZoneTwo on object /tempZone/home/research-core-0/test1.txt, error = -827000
Oct 18 15:10:32 pid:26825 remote addresses: 145.xxx.xxx.xxx, ::1 ERROR: caught python exception: Traceback (most recent call last):
  File "/etc/irods/rules_uu/util/rule.py", line 91, in r
    result = f(Context(callback, rei), *a)
  File "/etc/irods/rules_uu/policies.py", line 512, in pep_resource_modified_post
    replication.replicate_asynchronously(ctx, path, instance_name, config.resource_replica)
  File "/etc/irods/rules_uu/replication.py", line 26, in replicate_asynchronously
    msi.set_acl(ctx, "default", "own", "rods#{}".format(zone), path)
  File "/etc/irods/rules_uu/util/msi.py", line 76, in <lambda>
    return lambda callback, *args: _run(getattr(callback, msi), exception, *args)
  File "/etc/irods/rules_uu/util/msi.py", line 52, in _run
    raise exception(None, None, None, e)
SetACLError: Could not set ACL: iRODS error <[iRods__Error__Code:-827000] [-]   /repos/irods/server/re/include/irods_re_plugin.hpp:326:irods::error irods::dynamic_operation_execution_manager<std::__1::tuple<>, RuleExecInfo *, irods::DONT_AUDIT_RULE>::call(std::string, std::string, OP, As &&...) [T = std::__1::tuple<>, C = RuleExecInfo *, Audit = irods::DONT_AUDIT_RULE, OP = std::__1::function<irods::error (const std::__1::basic_string<char> &, RuleExecInfo *&, irods::unpack &&)>, As = <const std::__1::basic_string<char> &, RuleExecInfo *&, irods::unpack>] :  status [CAT_INVALID_USER]  errno [] -- message [exec_microservice_adapter failed]
        [-]     /repos/irods/server/re/src/irods_re_plugin.cpp:132:irods::error irods::default_microservice_manager<RuleExecInfo *>::exec_microservice_adapter(std::string, irods::default_ms_ctx, std::list<boost::any> &) :  status [CAT_INVALID_USER]  errno [] -- message [exec_microservice_adapter failed]

>
Oct 18 15:10:32 pid:26825 remote addresses: 145.xxx.xxx.xxx, ::1 ERROR: [invoke_file_modified] - failed to signal the resource that [/tempZone/home/research-core-0/test1.txt] on [irodsResc;dev001;dev001_p2;dev001_2] was modified
Oct 18 15:10:32 pid:26825 remote addresses: 145.xxx.xxx.xxx, ::1 ERROR: failed to publish replica states for [10605]
Oct 18 15:10:32 pid:26825 remote addresses: 145.xxx.xxx.xxx, ::1 ERROR: [finalize_data_object:390] - failed to finalize data object [error_code=[-827000], path=[/tempZone/home/research-core-0/test1.txt], hierarchy=[irodsResc;dev001;dev001_p2;dev001_2]]
Oct 18 15:10:32 pid:26825 NOTICE: writeLine: inString = {researcher#tempZoneTwo} DEBUG: py_acPostProcForCopy
Oct 18 15:10:32 pid:26825 NOTICE: writeLine: inString = {researcher#tempZoneTwo} debug: DEBUG: check data create </tempZone/home/research-core-0/test1.txt>

@lwesterhof lwesterhof changed the title [FEATURE] Federate the iRODS instance behind YODA with another iRODS instance [FEATURE] Federate the iRODS instance behind Yoda with another iRODS instance Jan 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants