[Glass] Help defining gemstone users for a multi-user app

[Dale K. Henrichs]

----- Original Message -----

| From: "Mariano Martinez Peck" <marianopeck at gmail.com>
| To: "Dale K. Henrichs" <dale.henrichs at gemtalksystems.com>
| Cc: glass at lists.gemtalksystems.com
| Sent: Monday, January 6, 2014 1:02:17 PM
| Subject: Re: [Glass] Help defining gemstone users for a multi-user
| app

| On Mon, Jan 6, 2014 at 1:34 PM, Dale K. Henrichs <
| dale.henrichs at gemtalksystems.com > wrote:

| | If you are going to share code between users, then I would suggest
| | that you start by installing the GLASS/seaside code into a
| | SymbolList that is not UserGlobals and perhaps even use a Gemstone
| | user that is not DataCurator.
| 

| OK...

| | The attached script creates a 'glass' user with the same
| | permissions
| | as DataCurator and loads the GLASS code (starting with a
| | $GEMSTONE/bin/extent0.dbf) into a GLASS SymbolDictionary.
| 

| Dale, I have just tried that and indeed it was quite helpful. At
| least, I was able to create a user with DataCurator like privileges,
| load my code there, and run my app. So I could have "two instances
| of my app running with 2 different gemstone users". So it was quite
| a good step.
| A few notes:

| 1) could this script be committed somewhere to the public? Maybe to
| the same place were you were grouping scripts like the purge logs
| from Norbert?
I've submmitted an Issue[1] as a reminder to clean up script and publish... 

[1] https://github.com/glassdb/glass/issues/16 

| 2) I had to execute: "export upgradeDir=$GEMSTONE/upgrade" before
| running the script..otherwise, #upgradeDir doesn't exist.
| 3) After finishing the load, I noticed that I have 2 entries called
| 'GLASS' in my SymbolList. In addition, the SystemDictionary created
| for #'GLASS' was actually a SymbolDictionary whose key was #'GLASS'
| and the value was a reference to itself (the SymbolDictionary). So
| class in there..... In fact, classes were loaded into the third
| dictionary, which is....UserGlobals. I guess something is wrong here
| since I expect all glass classes to be in #'GLASS' SymbolDictionary,
| right?
I'll have to take a closer look at the results of the script ... SymbolDictionaries will have a self-referencing association with the name of the symbollist ... by design ... Not sure about the the two entries in the Symbol list with GLAS, tho... 

I did cobble together this script form some other scripts that I use (without testing) so I will have to look a little bit closer at the source scripts and this one ... 

Appreciate the feedback .. 

| | Once you've done this, you can arrange to install the glass users's
| | #GLASS SymbolDictionary into another users SymbolList and thus
| | share
| | the code ... The `web` user will have to have write permission on
| | all of the slots of the Seaside code, so it might make sense to
| | load
| | the seaside code into the `web` users space directory ...
| 

| | I have to get ready for work right now, so the additional
| | instructions will have to wait:)
| 

| | In the meantime, though I would like to better understand the
| | rationale for separate GemStone users ... things will be much
| | simpler if you done have separate users, so I would think that
| | you'd
| | need a good reason for the extra hassle:)
| 

| Well, the reason so far is security. Mostly because users are able to
| define they own rules. I answered this later on in another entry of
| this thread.

Yes I saw that ... and it makes sense to use the GemStone users to secure your data from the prying eyes of other users... 

Dale 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140106/dafce1be/attachment.html>