i trying to make some automatisation scripts for some, let say stupid tasks.
as example I have created a script which one should modify the role capabilities, and it works fine, but only the first entry is aplyed everything else ist ignored, and i dont know why, could be some one can help my by this... here is my sourcecode:
my $add_role = NaElement->new("useradmin-role-modify");
my $add_role_sub = NaElement->new("useradmin-role");
my $add_role_sub_info = NaElement->new("useradmin-role-info");
my $add_role_sub_capa = NaElement->new("allowed-capabilities");
my $add_role_sub_capa_info = NaElement->new("useradmin-capability-info");
print $add_role->sprintf(); # to check the request struktur a preoutput of the request string
my $role_results = $s->invoke_elem($add_role);
print $role_results->sprintf(); #
so far ok, but on the end it will only apply the green line
all other redlines
are simply ignored.
strange but the structure of this is rigth and looks ok when i do a sprintf()
so my question:
howe i can make this change with the perl API? it looks like a multiple substring with same name are simpy ignored, or what i'm doing wrong?
Suggestion, just so you can isolate whether it's an API issue or a setup/calling issue, is to manually use the ZEDI tool to build the equivalent XML and run it directly against your target controller/cluster. If it doesn't work in the ZEDI tool with multple capabliities, then it just doesn't work and you can stop fighting the Perl to try and get it to work the way you've written it and approach it from a different angle.
The ZEDI tool is part of the NMSDK and I find it extremely helpful to ensure I have all the right calling parameters as well as verifying the expected output.
Given the roles you have listed this appears to be in 7-mode. Don't have a 7-mode system handy to check against, but the equivalent function - to add a capability to a role - in cluster mode appears to take a singleton role per call of the APi. Hence multiple calls would be needed to setup all the roles you want. If you verify that through ZEDI, then that's just how you have to write your code.
It makes sense that it would be a singleton due to the nature of the change. For example - if one of the elements fails, how should any previous successful elements be processed? Undo them (even if someone has already started using the capability), skip the failed one and process the rest, stop processing and leave what worked in place? And then how to indicate what failed, especially if there were multiple failures? Easier from a development and logic standpoint to simply allow only one update per call and make the requester call multuple times and thus let the requester determine the proper failure response.
Actually, your ZEDI output shows exactly what I was talking about. It appears that the first <useradmin-role-modify> call which had two capabilities in it only set one - "api-cifs-*" per the "list" API.
That is either a bug in intended behavior or it is intended because of the two capabilities you listed - if you combine the two capabilities in the first call "api-*" and "api-cifs-*" the logical "least" capability intersection of those two is just "api-cifs-*". More experimentation would be needed, or documentation, to ensure that's what it really does. Of course given the code in the original post, I'm leaning toward "bug".
For the second call, remember that in the CLI you have to fully specify all permissions because modify acts as a replace. So the second call, with just a single capability listed, modifies the role to have only those capabilities. If you want to add a capability, you also need to specify all the existing capabilities, as I recall from the CLI. If I remember correctly, and since the CLI just calls the underlying API, the 2nd output is what I would expect.