On Wed, Apr 4, 2018 at 5:40 AM, Nick Couchman <[email protected]> wrote: > > The schema itself sounds reasonable, my one concern is in the upgrade > process for a database that has existing data in it and that needs to move > from one schema version to the next. This is going to require inserting > the existing guacamole_user objects into the guacamole_entity table and > then adding the foreign key constraint to the guacamole_user table. Have > you done much in the way of testing that upgrade process? >
Some. You're definitely right about the upgrade process. The SQL in question for the Postgres case is here: https://github.com/mike-jumper/guacamole-client/blob/3b2ccfe357ba54191732dfd05306f96ea20f7a88/extensions/guacamole-auth-jdbc/modules/guacamole-auth-jdbc-postgresql/schema/upgrade/upgrade-pre-1.0.0.sql#L126-L164 Other than test things more extensively, and continue to recommend that admins back up their databases prior to attempting the upgrade so they can rollback if needed, I'm not sure there's any alternative. > Also, aside from just the back-end logistics of how to redo the schema > while maintaining existing data, are there any gotchas that people will > need to be aware of once that schema change takes place in how that is > shown on the front-end? That is, if I'm running 0.9.14, and upgrade to > 1.0.0 (assuming this is in 1.0.0), and I apply the schema update, update my > client and server, etc., will I be able to continue to use all of the > existing stuff configured in Guacamole prior to the upgrade without making > additional changes in the admin UI (e.g. re-assigning permissions, etc.)? > Nope. Everything is exactly identical except you can now maintain permissions by creating and assigning groups. You can still continue to assign permissions on a per-user basis, and existing per-user permissions will work as before. > Other than making sure the upgrade process is sorted out, it sounds like a > great approach to me! > Thanks! > Oh, one other thing, presumably after the JDBC module changes are done we > will have to go back to some of the other modules (LDAP, primarily, I would > guess) and make some changes, there, correct? Are those in scope of what > you're doing here for this particular JIRA issue, or would you consider > adding group support to the LDAP module a separate issue? > Good question. The LDAP changes are definitely in scope, and it was my original intent to try to tackle those. Assuming these changes are part of 1.0.0, I can understand limiting the scope to just the database and extension API in the interest of getting the release out. If the group support is part of 1.0.0, I suppose we'll have to see how we feel about release timing vs. including LDAP group support once the database+API portion is complete. Being able to apply the permissions related to group memberships defined in another extension (ie: an LDAP user is within an LDAP group, but only the group has a corresponding entry+permissions within the database) is a critical aspect of the API changes involved, so this angle will need to be tested even if LDAP itself is not in scope. - Mike
