grouper-users - [grouper-users] RE: Grouper export to gsh
Subject: Grouper Users - Open Discussion List
List archive
- From: Sean Mason <>
- To: "Hyzer, Chris" <>, Julio Polo <>
- Cc: "" <>
- Subject: [grouper-users] RE: Grouper export to gsh
- Date: Fri, 19 Feb 2016 16:28:28 +0000
- Accept-language: en-CA, en-US
This sounds fantastic, thank you very much! Sean. From: Hyzer, Chris [mailto:]
I implemented an export to gsh. https://spaces.internet2.edu/display/Grouper/Grouper+export+to+a+GSH+script This is in the latest patch for v2.2.2. Note, a lot of classes were changed though with this new feature core Grouper code did not get touched so it is still
low risk. I was hoping this enhancement would be smaller and affect fewer files which is why I started working in the v2.2 branch, but it got more and more complex. Grouper can export a folder or the entire registry as a GSH script. This is currently experimental, take a backup or verify in a test env first. In order to
run the script you need a Grouper v2.2.2+ patched env. Note, you should capture the output of running the GSH script so you can review it for errors. Performance on demo server (local mysql database) Exporting 6000 records to GSH takes 26 seconds The GSH script ran 6000 records 1min 6sec with no changes If there were 6000 changes (new registry) it took 6 minutes. The script is idempotent (run it twice, its ok). It will not delete what is there in general though it will delete attribute assignments on exported assignments.
It is assumed that the general configuration of the source environment is equivalent to the destination environment. e.g. if name is not a required external subject attribute in the source env, then it shouldnt be in the destination either. It will not export audits point in time data daemon logs change log entries if you are importing and the objects already exist, it will not sync up the object ID uuid's. In some cases will be use different uuid even if the object doesnt
exist membership fields are not imported (note, privileges are, but if you are using a membership list that is not "members" (not common), that will be skipped if you export a folder, and some necessary objects do not exist in the target (e.g. attribute definitions), they will be reported as an error and skipped note: international characters have been tested on the demo server and works there though your mileage may vary, be careful here (test it) unresolvable subjects will be exported but will throw an error on import (maybe they shouldnt be exported) Start an export grouperSession = GrouperSession.startRootSession(); scriptName = "c:/temp/script.gsh"; new File(scriptName).delete(); XmlExportGshScript().assignStemName(":").assignFileNameToWriteTo(scriptName).exportGsh(); The end of the script will print a summary of changes that occurred: Script complete: total objects: 6222, expected approx total: 6327, changes: 133, known errors (view output for full list): 36 Thanks, Chris From: Sean Mason []
Bah, right at the top too! Sorry about that. This looks like a fine method to manage and migrate stem structure and loader definitions from one instance to another, unless someone else chimes in with a more
accepted practice. Thanks again, Sean. From: Chris Hyzer []
Yes: gsh filename https://spaces.internet2.edu/pages/viewpage.action?pageId=14517859
Read gsh commands from a script file: $GROUPER_HOME/bin/gsh.sh /path/to/your/script.gsh Thanks, Chris From: Sean Mason []
Is there a way to feed gsh a list of commands similar to something like the Postgres client?
Something like gsh < commands.txt Or gsh% executeCommands(“/some/dir/gsh_commands.txt”); I could use this as a way to build group definitions and assign attributes that would become the loader definitions, and then just run those command collections
on the various instances. I don’t see any examples or documentation like this, but maybe I’ve missed something. I have seen similar examples in the grouperClient documentation about testing that suggests perhaps that may be the way to go? Thanks, From: Chris Hyzer []
He wants something to copy the loader settings which are attributes of groups… Thanks, Chris From: Julio Polo []
I am not familiar with loader groups, so maybe someone else can chime in. Maybe the Grouper loader feature can take care of creating the stems and groups you want. Instead of writing gsh scripts, you might
just need to promote new loader settings to the other Grouper environments. Again, I'm not familiar with the loader, so this is just speculation on my part. -julio On Wed, Dec 16, 2015 at 4:25 AM, Sean Mason <> wrote: I’ve replied to ‘all’, as some posts to the list haven’t gotten through over the past couple of days. Thank you for your feedback. It was not my intention to move memberships or subject references between
instances, only stems and loader groups. It makes sense that one would create processes that create and maintain those structures instead to prepare target environments. What is the most popular and practical way to develop those processes? GSH scripts?
(Can GSH be passed a script?) Use of the Grouper Client? Some other means? Thank you, Sean. From: Julio Polo [mailto:]
Thanks Chris, but it was indeed the permissions and attributes that were difficult to export/import. The other stuff was relatively easy to code. I think it would definitely be helpful to provide an option to import/export only the objects that fall under a parent folder, and to use group ID path and subject ID/Identifier instead
of UUIDs (maybe export them as wsSubjectLookup and wsGroupLookup?). Another useful option would be to assume that we do not want to create the subjects or groups that are members of the groups being imported/exported; assume they exist if they are not under
that parent folder. Going back to Sean's original question on how to perform this type of object management, I can only say that we do not move data across environments. We develop subsystems for each type
of group (e.g. registration groups, curriculum groups, faculty groups, etc.) and we promote the subsytem code rather than the data through dev, test and production. The groups/objects are then created by the code in each environment. If we were to move
objects (such as memberships), we'd need to make sure that data across dev, test and prod be in sync, and that's not usually true (for dev, at least) -julio On Tue, Dec 15, 2015 at 11:33 AM, Chris Hyzer <> wrote:
|
- [grouper-users] Grouper export to gsh, Hyzer, Chris, 02/18/2016
- [grouper-users] Re: Grouper export to gsh, Julio Polo, 02/18/2016
- [grouper-users] Re: Grouper export to gsh, Hyzer, Chris, 02/19/2016
- [grouper-users] RE: Grouper export to gsh, Sean Mason, 02/19/2016
- [grouper-users] RE: Grouper export to gsh, Redman, Chad Eric, 02/24/2016
- [grouper-users] RE: Grouper export to gsh, Hyzer, Chris, 02/24/2016
- [grouper-users] RE: Grouper export to gsh, Hyzer, Chris, 02/24/2016
- [grouper-users] RE: Grouper export to gsh, Redman, Chad Eric, 02/25/2016
- [grouper-users] RE: Grouper export to gsh, Hyzer, Chris, 02/25/2016
- [grouper-users] RE: Grouper export to gsh, Redman, Chad Eric, 02/25/2016
- [grouper-users] Re: Grouper export to gsh, Julio Polo, 02/18/2016
Archive powered by MHonArc 2.6.16.