You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by "ohaya@yahoo.com" <oh...@yahoo.com> on 2019/11/20 22:12:07 UTC
Some problems encountered while testing Syncope CLI
Hi,
We have been testing Syncope CLI and especially the tasks execute and list command, and we have encountered a few problems:
- When we tried running "./syncopeadm.sh --list PULL" or "./syncopeadm.sh --list PULL", it listed the runs, but the output was old, dated Nov. 6 and Nov. 7 (today is Nov. 20). In other words, the output from the "–list PULL" and "–list PUSH" commands seems to be stuck and not recording current statuses, I think.
- The CLI tasks commands use a task "key" to identify each task. The task "key" is a long hex-like string, and is probably not memorizable. Also, so far, the only way that I have been able to find the task "key" for a given task is to review the output from the --list PULL" or "–list PUSH" commands, which may also be problematic. Is it possible to use the task names instead of the task "key" when running commands?
Slightly different area:
- We accidentally mapped a single internal attribute, "dutyOrg" to 2 different external attributes, "co" and "dutyOrg" on a target LDAP. However, when we ran the pull task followed by the push task, only the "co" attribute in the target LDAP instance was changed. In other words, the mapping from the one internal attribute to two different external attributes didn't appear to work. For us, if this is the case, this would be a MAJOR problem, as in the current product we use, we have many attribute flows where a single attribute is pushed to multiple attributes in the target LDAPs.
Please advise if there are any ways to workaround the above problems?
Thanks,Jim
Re: Some problems encountered while testing Syncope CLI
Posted by "ohaya@yahoo.com" <oh...@yahoo.com>.
Hi,
For the record, I've found one way (NOT a good way) to find the task UUID for a given task name, by using Mysql.
The following search will list several attributes (the "id" attribute appears to be the UUID) for a task whose "name" is 'xxxxxx':
select id,DTYPE,name,RESOURCE_ID from syncope.Task where name = 'xxxxxx';
Like I said, this is not an ideal way to find the task UUID, in that it is dependent on the schema not changing, but it does seem to work, and is easier than trying to extract the information from the "--list".
It would be nicer if there as an API'ish way to get this same info (hint!).
Jim
On Thursday, November 21, 2019, 11:13:39 AM UTC, ohaya@yahoo.com <oh...@yahoo.com> wrote:
Hi,
My apologies, but please ignore the question about the mapping to multiple external attributes on the PUSH.
I just re-tested and it looks like that does work. I am not sure why it did not appear to be working when we tested that (by mistake :) yesterday!!
We will would like to know how we can find the task UUID from the task "Name", if there is a way other than doing the list command and then searching through the output of that command?
Again, my apologies for the above.
Jim
On Thursday, November 21, 2019, 10:25:08 AM UTC, ohaya@yahoo.com <oh...@yahoo.com> wrote:
Hi Francesco,
Thank you for the responses. I will try the curl way for the task list and execute, but can you also let me know about this problem:
"We accidentally mapped a single internal attribute, "dutyOrg" to 2 different external attributes, "co" and "dutyOrg" on a target LDAP. However, when we ran the pull task followed by the push task, only the "co" attribute in the target LDAP instance was changed. In other words, the mapping from the one internal attribute to two different external attributes didn't appear to work. For us, if this is the case, this would be a MAJOR problem, as in the current product we use, we have many attribute flows where a single attribute is pushed to multiple attributes in the target LDAPs."
Can we map an internal attribute to multiple external attributes (on the PUSH)?
Or can we only map the internal=>external attributes 1 to 1?
Also, is there any other way to find the task UUID, other than the way I have been finding them, by using the task --list command and searching for the task key in the output?
Thanks,Jim
On Thursday, November 21, 2019, 7:37:47 AM UTC, Francesco Chicchiriccò <il...@apache.org> wrote:
Hi,
as a general concept, please consider that because of
https://issues.apache.org/jira/browse/SYNCOPE-1413
the Syncope CLI code was removed from master branch: this means that Syncope 2.1.X is the last series providing such a component.
I have just created
https://issues.apache.org/jira/browse/SYNCOPE-1514
to review the Reference Guide accordingly.
About your specific items, please see in-line below. Regards.
On 20/11/19 23:12, ohaya@yahoo.com wrote:
Hi,
We have been testing Syncope CLI and especially the tasks execute and list command, and we have encountered a few problems:
- When we tried running "./syncopeadm.sh --list PULL" or "./syncopeadm.sh --list PULL", it listed the runs, but the output was old, dated Nov. 6 and Nov. 7 (today is Nov. 20). In other words, the output from the "–list PULL" and "–list PUSH" commands seems to be stuck and not recording current statuses, I think.
I guess that by "date" you are referring to last executions.
Unfortunately, the CLI command returns the task list ordered by creation, with no paging support.
As an alternative to CLI, you can empower the popular curl program; for example, if you want to get the list of pull tasks ordered by their most recent last executions:
curl -X GET -u admin:password -H "Accept: application/json""http://host:port/syncope/rest/tasks/PULL?page=1&size=25&orderby=start%20DESC&details=true"
assuming that:
* Core is reachable at http://host:port/syncope/
* you are using basic authentication with admin user (and you haven't changed the default password, which is definitely a bad practice)
- The CLI tasks commands use a task "key" to identify each task. The task "key" is a long hex-like string, and is probably not memorizable. Also, so far, the only way that I have been able to find the task "key" for a given task is to review the output from the --list PULL" or "–list PUSH" commands, which may also be problematic. Is it possible to use the task names instead of the task "key" when running commands?
The key values for tasks - as for many other entities including Users - are not "hex-like" but UUID version 4 - see
https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random)
for an introduction.
I confirm there is no other value than key that can be used to run tasks; for example:
curl -X POST -u admin:password -H "Accept: application/json""http://host:port/syncope/rest/tasks/418a70e8-6c38-4f06-a3c9-ecec2787b069/execute"
will trigger execution of task with key 418a70e8-6c38-4f06-a3c9-ecec2787b069.
Slightly different area:
- We accidentally mapped a single internal attribute, "dutyOrg" to 2 different external attributes, "co" and "dutyOrg" on a target LDAP. However, when we ran the pull task followed by the push task, only the "co" attribute in the target LDAP instance was changed. In other words, the mapping from the one internal attribute to two different external attributes didn't appear to work. For us, if this is the case, this would be a MAJOR problem, as in the current product we use, we have many attribute flows where a single attribute is pushed to multiple attributes in the target LDAPs.
Please advise if there are any ways to workaround the above problems?
Thanks, Jim
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Re: Some problems encountered while testing Syncope CLI
Posted by "ohaya@yahoo.com" <oh...@yahoo.com>.
Hi,
My apologies, but please ignore the question about the mapping to multiple external attributes on the PUSH.
I just re-tested and it looks like that does work. I am not sure why it did not appear to be working when we tested that (by mistake :) yesterday!!
We will would like to know how we can find the task UUID from the task "Name", if there is a way other than doing the list command and then searching through the output of that command?
Again, my apologies for the above.
Jim
On Thursday, November 21, 2019, 10:25:08 AM UTC, ohaya@yahoo.com <oh...@yahoo.com> wrote:
Hi Francesco,
Thank you for the responses. I will try the curl way for the task list and execute, but can you also let me know about this problem:
"We accidentally mapped a single internal attribute, "dutyOrg" to 2 different external attributes, "co" and "dutyOrg" on a target LDAP. However, when we ran the pull task followed by the push task, only the "co" attribute in the target LDAP instance was changed. In other words, the mapping from the one internal attribute to two different external attributes didn't appear to work. For us, if this is the case, this would be a MAJOR problem, as in the current product we use, we have many attribute flows where a single attribute is pushed to multiple attributes in the target LDAPs."
Can we map an internal attribute to multiple external attributes (on the PUSH)?
Or can we only map the internal=>external attributes 1 to 1?
Also, is there any other way to find the task UUID, other than the way I have been finding them, by using the task --list command and searching for the task key in the output?
Thanks,Jim
On Thursday, November 21, 2019, 7:37:47 AM UTC, Francesco Chicchiriccò <il...@apache.org> wrote:
Hi,
as a general concept, please consider that because of
https://issues.apache.org/jira/browse/SYNCOPE-1413
the Syncope CLI code was removed from master branch: this means that Syncope 2.1.X is the last series providing such a component.
I have just created
https://issues.apache.org/jira/browse/SYNCOPE-1514
to review the Reference Guide accordingly.
About your specific items, please see in-line below. Regards.
On 20/11/19 23:12, ohaya@yahoo.com wrote:
Hi,
We have been testing Syncope CLI and especially the tasks execute and list command, and we have encountered a few problems:
- When we tried running "./syncopeadm.sh --list PULL" or "./syncopeadm.sh --list PULL", it listed the runs, but the output was old, dated Nov. 6 and Nov. 7 (today is Nov. 20). In other words, the output from the "–list PULL" and "–list PUSH" commands seems to be stuck and not recording current statuses, I think.
I guess that by "date" you are referring to last executions.
Unfortunately, the CLI command returns the task list ordered by creation, with no paging support.
As an alternative to CLI, you can empower the popular curl program; for example, if you want to get the list of pull tasks ordered by their most recent last executions:
curl -X GET -u admin:password -H "Accept: application/json""http://host:port/syncope/rest/tasks/PULL?page=1&size=25&orderby=start%20DESC&details=true"
assuming that:
* Core is reachable at http://host:port/syncope/
* you are using basic authentication with admin user (and you haven't changed the default password, which is definitely a bad practice)
- The CLI tasks commands use a task "key" to identify each task. The task "key" is a long hex-like string, and is probably not memorizable. Also, so far, the only way that I have been able to find the task "key" for a given task is to review the output from the --list PULL" or "–list PUSH" commands, which may also be problematic. Is it possible to use the task names instead of the task "key" when running commands?
The key values for tasks - as for many other entities including Users - are not "hex-like" but UUID version 4 - see
https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random)
for an introduction.
I confirm there is no other value than key that can be used to run tasks; for example:
curl -X POST -u admin:password -H "Accept: application/json""http://host:port/syncope/rest/tasks/418a70e8-6c38-4f06-a3c9-ecec2787b069/execute"
will trigger execution of task with key 418a70e8-6c38-4f06-a3c9-ecec2787b069.
Slightly different area:
- We accidentally mapped a single internal attribute, "dutyOrg" to 2 different external attributes, "co" and "dutyOrg" on a target LDAP. However, when we ran the pull task followed by the push task, only the "co" attribute in the target LDAP instance was changed. In other words, the mapping from the one internal attribute to two different external attributes didn't appear to work. For us, if this is the case, this would be a MAJOR problem, as in the current product we use, we have many attribute flows where a single attribute is pushed to multiple attributes in the target LDAPs.
Please advise if there are any ways to workaround the above problems?
Thanks, Jim
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Re: Some problems encountered while testing Syncope CLI
Posted by "ohaya@yahoo.com" <oh...@yahoo.com>.
Hi Francesco,
Thank you for the responses. I will try the curl way for the task list and execute, but can you also let me know about this problem:
"We accidentally mapped a single internal attribute, "dutyOrg" to 2 different external attributes, "co" and "dutyOrg" on a target LDAP. However, when we ran the pull task followed by the push task, only the "co" attribute in the target LDAP instance was changed. In other words, the mapping from the one internal attribute to two different external attributes didn't appear to work. For us, if this is the case, this would be a MAJOR problem, as in the current product we use, we have many attribute flows where a single attribute is pushed to multiple attributes in the target LDAPs."
Can we map an internal attribute to multiple external attributes (on the PUSH)?
Or can we only map the internal=>external attributes 1 to 1?
Also, is there any other way to find the task UUID, other than the way I have been finding them, by using the task --list command and searching for the task key in the output?
Thanks,Jim
On Thursday, November 21, 2019, 7:37:47 AM UTC, Francesco Chicchiriccò <il...@apache.org> wrote:
Hi,
as a general concept, please consider that because of
https://issues.apache.org/jira/browse/SYNCOPE-1413
the Syncope CLI code was removed from master branch: this means that Syncope 2.1.X is the last series providing such a component.
I have just created
https://issues.apache.org/jira/browse/SYNCOPE-1514
to review the Reference Guide accordingly.
About your specific items, please see in-line below. Regards.
On 20/11/19 23:12, ohaya@yahoo.com wrote:
Hi,
We have been testing Syncope CLI and especially the tasks execute and list command, and we have encountered a few problems:
- When we tried running "./syncopeadm.sh --list PULL" or "./syncopeadm.sh --list PULL", it listed the runs, but the output was old, dated Nov. 6 and Nov. 7 (today is Nov. 20). In other words, the output from the "–list PULL" and "–list PUSH" commands seems to be stuck and not recording current statuses, I think.
I guess that by "date" you are referring to last executions.
Unfortunately, the CLI command returns the task list ordered by creation, with no paging support.
As an alternative to CLI, you can empower the popular curl program; for example, if you want to get the list of pull tasks ordered by their most recent last executions:
curl -X GET -u admin:password -H "Accept: application/json""http://host:port/syncope/rest/tasks/PULL?page=1&size=25&orderby=start%20DESC&details=true"
assuming that:
* Core is reachable at http://host:port/syncope/
* you are using basic authentication with admin user (and you haven't changed the default password, which is definitely a bad practice)
- The CLI tasks commands use a task "key" to identify each task. The task "key" is a long hex-like string, and is probably not memorizable. Also, so far, the only way that I have been able to find the task "key" for a given task is to review the output from the --list PULL" or "–list PUSH" commands, which may also be problematic. Is it possible to use the task names instead of the task "key" when running commands?
The key values for tasks - as for many other entities including Users - are not "hex-like" but UUID version 4 - see
https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random)
for an introduction.
I confirm there is no other value than key that can be used to run tasks; for example:
curl -X POST -u admin:password -H "Accept: application/json""http://host:port/syncope/rest/tasks/418a70e8-6c38-4f06-a3c9-ecec2787b069/execute"
will trigger execution of task with key 418a70e8-6c38-4f06-a3c9-ecec2787b069.
Slightly different area:
- We accidentally mapped a single internal attribute, "dutyOrg" to 2 different external attributes, "co" and "dutyOrg" on a target LDAP. However, when we ran the pull task followed by the push task, only the "co" attribute in the target LDAP instance was changed. In other words, the mapping from the one internal attribute to two different external attributes didn't appear to work. For us, if this is the case, this would be a MAJOR problem, as in the current product we use, we have many attribute flows where a single attribute is pushed to multiple attributes in the target LDAPs.
Please advise if there are any ways to workaround the above problems?
Thanks, Jim
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Re: Some problems encountered while testing Syncope CLI
Posted by Francesco Chicchiriccò <il...@apache.org>.
Hi,
as a general concept, please consider that because of
https://issues.apache.org/jira/browse/SYNCOPE-1413
the Syncope CLI code was removed from master branch: this means that Syncope 2.1.X is the last series providing such a component.
I have just created
https://issues.apache.org/jira/browse/SYNCOPE-1514
to review the Reference Guide accordingly.
About your specific items, please see in-line below.
Regards.
On 20/11/19 23:12, ohaya@yahoo.com wrote:
> Hi,
>
> We have been testing Syncope CLI and especially the tasks execute and list command, and we have encountered a few problems:
>
> * When we tried running "./syncopeadm.sh --list PULL" or "./syncopeadm.sh --list PULL", it listed the runs, but the output was old, dated Nov. 6 and Nov. 7 (today is Nov. 20). In other words, the output from the "–list PULL" and "–list PUSH" commands seems to be stuck and not recording current statuses, I think.
>
I guess that by "date" you are referring to last executions.
Unfortunately, the CLI command returns the task list ordered by creation, with no paging support.
As an alternative to CLI, you can empower the popular curl program; for example, if you want to get the list of pull tasks ordered by their most recent last executions:
curl -X GET -u admin:password -H "Accept: application/json" "http://host:port/syncope/rest/tasks/PULL?page=1&size=25&orderby=start%20DESC&details=true"
assuming that:
* Core is reachable at http://host:port/syncope/
* you are using basic authentication with admin user (and you haven't changed the default password, which is definitely a bad practice)
> * The CLI tasks commands use a task "key" to identify each task. The task "key" is a long hex-like string, and is probably not memorizable. Also, so far, the only way that I have been able to find the task "key" for a given task is to review the output from the --list PULL" or "–list PUSH" commands, which may also be problematic. Is it possible to use the task names instead of the task "key" when running commands?
>
The key values for tasks - as for many other entities including Users - are not "hex-like" but UUID version 4 - see
https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random)
for an introduction.
I confirm there is no other value than key that can be used to run tasks; for example:
curl -X POST -u admin:password -H "Accept: application/json" "http://host:port/syncope/rest/tasks/418a70e8-6c38-4f06-a3c9-ecec2787b069/execute"
will trigger execution of task with key 418a70e8-6c38-4f06-a3c9-ecec2787b069.
> Slightly different area:
>
> * We accidentally mapped a single internal attribute, "dutyOrg" to 2 different external attributes, "co" and "dutyOrg" on a target LDAP. However, when we ran the pull task followed by the push task, only the "co" attribute in the target LDAP instance was changed. In other words, the mapping from the one internal attribute to two different external attributes didn't appear to work. For us, if this is the case, this would be a MAJOR problem, as in the current product we use, we have many attribute flows where a single attribute is pushed to multiple attributes in the target LDAPs.
>
> Please advise if there are any ways to workaround the above problems?
>
> Thanks,
> Jim
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/