setting up new users

I decided to upgrade my image to a newer system. At the moment I have gs 2.3.1 dhk.231 with seaside 2.8 and pier. As long as there is no pier2 I'll stick to the pier1. What I plan to do:

- bootstrapping a gs 2.4
- upgrading to beta.6
- adding a new user for each pier instance
- installing seaside and pier in the new users space

I don't think there is anything that prevents me from using gs 2.4, right? Upgrading to beta.6 was easy. I also figured out how to create a new user. But then I'm stuck. I can login with the new user via topaz but login in via gemstone client gives me an error.

MessageNotUnderstood: receiver of "openDebuggerOn:" is nil

It happens in GsProcess>>openDebugger: where session jadeServer is nil.

I toyed around a bit with privileges and groupd but didn't succeed.

How can I set up a user that is able to load code and that may login via gemtools?

thanks,

Norbert

to figure this out, first select Admin>>'Popup on Debug'...that'll bring up a Pharo side debugger ... then grunge through the stack looking for a GciErrSType64 ... passed in as an arge to the opendebugger (if that's what's on the stack) then look at the message ... usually that's enough to go aha... or make me go aha ...

2.4 should work fine ... I work daily in both 2.3 and 2.4 with various versions of Seaside and GLASS...

Just in case it's a permissions problem, here's the code I use to create a user other that DataCurator:

set user DataCurator pass swordfish
login
run
| seaside |
seaside := AllUsers userWithId: 'seaside' ifAbsent: [ nil ].
seaside ~~ nil
  ifTrue: [
    AllUsers removeIfPresent: seaside.
    System commitTransaction.
 ].
(AllUsers
  addNewUserWithId: 'seaside'
  password: 'swordfish')
    addPrivilege: #'CodeModification';
    addPrivilege: #'UserPassword';
    addPrivilege: #'OtherPassword';
    yourself.
System commitTransaction.
%
logout

Dale
----- "Norbert Hartl" <[hidden email]> wrote:

| I decided to upgrade my image to a newer system. At the moment I have
| gs 2.3.1 dhk.231 with seaside 2.8 and pier. As long as there is no
| pier2 I'll stick to the pier1. What I plan to do:
|
| - bootstrapping a gs 2.4
| - upgrading to beta.6
| - adding a new user for each pier instance
| - installing seaside and pier in the new users space
|
| I don't think there is anything that prevents me from using gs 2.4,
| right? Upgrading to beta.6 was easy. I also figured out how to create
| a new user. But then I'm stuck. I can login with the new user via
| topaz but login in via gemstone client gives me an error.
|
| MessageNotUnderstood: receiver of "openDebuggerOn:" is nil
|
| It happens in GsProcess>>openDebugger: where session jadeServer is
| nil.
|
| I toyed around a bit with privileges and groupd but didn't succeed.
|
| How can I set up a user that is able to load code and that may login
| via gemtools?
|
| thanks,
|
| Norbert

Ah ok, I didn't try the pop on before. It is strange that I need to log into another session in order to get the admin button. Switching pop up debugger on gives me the debugger for the new session I want to log in.

Nevertheless the first error I get is

An attempt was made to do a priviledged operation for which no privilege has been granted

Adding the privileges CodeModification, UserPassword, OtherPassword (??) gets me to the next problem.

It is

Compiler error for JadeServer>>#referencesToIt:

in

GciSession>>initializeServer

The result variable in the context shows:

'   referencesToIt: aSymbol

       | entry |
      entry := Smalltalk at: aSymbol ifAbsent: [nil].
        (entry isKindOf: Class) ifFalse: [entry _ entry class].
        OBReferencesBrowser browseRoot: entry asNode
 *                                                          ^1                                                                                                             ^2                                          

1: [1031] undefined symbol
2: [1031] undefined symbol
'

Hope this helps,

Norbert

On 23.03.2010, at 01:28, Dale Henrichs wrote:

I tested this but it doesn't help. You would say there is no reason even in a bootstrapped image that should prevent a normal user from logging in? Could it be that there is some visibility missing to needed classes? Just wild guessing :)

Norbert

On 23.03.2010, at 01:28, Dale Henrichs wrote:

Hi!

Here is the code I use to create a new user with the same access rights and privileges as the DataCurator user.
The new user must access the same UserGlobals as the DataCurator.

| dc user userIdx idx |
dc := AllUsers detect: [:u | u userId = 'DataCurator'].
user := UserProfile newWithUserId: 'FastCGI'
 password: 'xxxxxxxxxxx'
 privileges: dc privileges
 inGroups: dc groups.

idx := dc symbolList names indexOf: #UserGlobals.
userIdx := user symbolList names indexOf: #UserGlobals.
user symbolList removeAtIndex: userIdx.
user symbolList addAll: (Array with: (dc symbolList at: idx)) beforeIndex: 1.
idx := dc symbolList names indexOf: #SessionMethods.
user symbolList addAll: (Array with: (dc symbolList at: idx)) afterIndex: 1.


Gerhard

Well,

Norbert,

To have "complete isolation" then you need to do a bootstrap install as each user.

Dale
----- "Norbert Hartl" <[hidden email]> wrote:

| Well,
|
| that works (of course?). So I need the intersection of both that is
| mandatory ;) I like to have complete separate users. So sharing
| UserGlobals is not the way to go. And I want to load code copies into
| each users space. But it is good to have a working example. I can
| restrict this one by one to see when a clash occurrs.
|
| Norbert
|
| On 23.03.2010, at 16:39, Gerhard Obermann wrote:
|
| > Hi!
| >
| > Here is the code I use to create a new user with the same access
| rights and privileges as the DataCurator user.
| > The new user must access the same UserGlobals as the DataCurator.
| >
| > | dc user userIdx idx |
| > dc := AllUsers detect: [:u | u userId = 'DataCurator'].
| > user := UserProfile newWithUserId: 'FastCGI'
| >  password: 'xxxxxxxxxxx'
| >  privileges: dc privileges
| >  inGroups: dc groups.
| >
| > idx := dc symbolList names indexOf: #UserGlobals.
| > userIdx := user symbolList names indexOf: #UserGlobals.
| > user symbolList removeAtIndex: userIdx.
| > user symbolList addAll: (Array with: (dc symbolList at: idx))
| beforeIndex: 1.
| > idx := dc symbolList names indexOf: #SessionMethods.
| > user symbolList addAll: (Array with: (dc symbolList at: idx))
| afterIndex: 1.
| >
| >
| > Gerhard
| >
| > On Tue, Mar 23, 2010 at 3:39 PM, Norbert Hartl <[hidden email]>
| wrote:
| > I tested this but it doesn't help. You would say there is no reason
| even in a bootstrapped image that should prevent a normal user from
| logging in? Could it be that there is some visibility missing to
| needed classes? Just wild guessing :)
| >
| > Norbert
| >
| > On 23.03.2010, at 01:28, Dale Henrichs wrote:
| >
| > > run
| > > | seaside |
| > > seaside := AllUsers userWithId: 'seaside' ifAbsent: [ nil ].
| > > seaside ~~ nil
| > >  ifTrue: [
| > >    AllUsers removeIfPresent: seaside.
| > >    System commitTransaction.
| > > ].
| > > (AllUsers
| > >  addNewUserWithId: 'seaside'
| > >  password: 'swordfish')
| > >    addPrivilege: #'CodeModification';
| > >    addPrivilege: #'UserPassword';
| > >    addPrivilege: #'OtherPassword';
| > >    yourself.
| > > System commitTransaction.
| > > %
| >
| >

Dale,

I'm not after that "complete" separation. It is more separated after concerns. To me the gemstone system is the base and stable part. Fundamental things won't change that often. And if it occurs you might need to bootstrap anyway. So to me the base system (after bootstrapping) should be handled by DataCurator and maintained by you (gemstone). This is status quo. My own projects will have lesser dependencies on the base system but quite a few on the modules on top of this.
I had the assumption that any newly created user will have at least read-only rights on the DataCurator segment and therefor could access the classes that DataCurator installed. Looking at the error message I sent in one of my last mail it doesn't appear this way to me now. I need to figure out what permissions are needed and what they do. I like just to be cautious because I think if I assign to much rights the newly created user will have the ability to change to code in the DataCurator space (base system). But then it might be the case that I have to less knowledge about how this works, UserGlobals and global state access are handled.
Anyway on top of the bootstrapped system I like to create a project. A project would be the creation of a new user and using metacello to load the project dependent code into the space of the new user. Dependent projects would include seaside and companions.
I would start one gem with fastcgi for every user and would be able to log in via gemtools for each individual user to maintain the site.

That is the plan. If you have any additions that might enlighten my path then this is super appreciated.

Norbert



On 23.03.2010, at 17:43, Dale Henrichs wrote:

I played a bit more and got the impression that it won't be easy to achieve what I want to. I took the user creation example from Gerhard and just removed the groups from the user. Removing the group DataCuratorGroup takes away the write access from the user. Then the login via gemtools hangs indefinetely.
On the other hand things will be hard any way. There is barely a chance to create base system protected by some user. I think it would be impossible to install projects like magritte. This because magritte has a method extension to Object for which I want to remove write access.
I'll test the whole setup with bootstrapping everything for the new user. But if Object is not affected in a way it lives in the users space then there is no chance of separating other then have two installations of a gemstone image.

Norbert

On 24.03.2010, at 11:03, Norbert Hartl wrote:

I hope you are not too be bothered by me talking to myself :) I just tested the "complete separation" and this is actually quite close to what I could use. It only needs a user with less privileges (I think CodeModification is the important one). After bootstrapping I had one beta.6 (DataCurator user) and one beta.4 (other user) GLASS base. I was glad to see that it seems that all classes are separated. Well, my only test was adding a method foo to Object and seeing that on the other user it doesn't exist :)

Well, so far that is something to work on. I can at least have separate installations that use one shared page cache with having the overhead of base classes being doubled That is fine for me at the moment.

Norbert

On 24.03.2010, at 11:46, Norbert Hartl wrote:

Norbert,

right now creating a separate user and loading the code into that users name space is the easiest way to work....

James and I have discusses the ideal of sharing the code amongst a bunch of users while keeping the the data unique for each user ...

Obviously (or maybe not so obviously) class vars and class instance vars can't be used in this scenario, since they are shared ...

This is where storing state in UserGlobals comes in (you may have seen the posts where James talked about doing this for migration purposes)...

By storing state in UserGlobals instead of directly in class vars and class instance vars, you can then arrange for users to share code but not state.

Of course it means monkeying with class vars in code that is ported to GemStone and the mods probably aren't portable themselves, but these kinds of changes are relatively isolated ...

Anyway, right now I would say that we are in the experimentation/characterization phase, but once we comfortable with this approach, we'll probably make a pass through the code that has already been ported to GemStone to make these additions...


Dale
----- "Norbert Hartl" <[hidden email]> wrote:

| I hope you are not too be bothered by me talking to myself :) I just
| tested the "complete separation" and this is actually quite close to
| what I could use. It only needs a user with less privileges (I think
| CodeModification is the important one). After bootstrapping I had one
| beta.6 (DataCurator user) and one beta.4 (other user) GLASS base. I
| was glad to see that it seems that all classes are separated. Well, my
| only test was adding a method foo to Object and seeing that on the
| other user it doesn't exist :)
|
| Well, so far that is something to work on. I can at least have
| separate installations that use one shared page cache with having the
| overhead of base classes being doubled That is fine for me at the
| moment.
|
| Norbert
|
| On 24.03.2010, at 11:46, Norbert Hartl wrote:
|
| > I played a bit more and got the impression that it won't be easy to
| achieve what I want to. I took the user creation example from Gerhard
| and just removed the groups from the user. Removing the group
| DataCuratorGroup takes away the write access from the user. Then the
| login via gemtools hangs indefinetely.
| > On the other hand things will be hard any way. There is barely a
| chance to create base system protected by some user. I think it would
| be impossible to install projects like magritte. This because magritte
| has a method extension to Object for which I want to remove write
| access.
| > I'll test the whole setup with bootstrapping everything for the new
| user. But if Object is not affected in a way it lives in the users
| space then there is no chance of separating other then have two
| installations of a gemstone image.
| >
| > Norbert
| >
| > On 24.03.2010, at 11:03, Norbert Hartl wrote:
| >
| >> Dale,
| >>
| >> I'm not after that "complete" separation. It is more separated
| after concerns. To me the gemstone system is the base and stable part.
| Fundamental things won't change that often. And if it occurs you might
| need to bootstrap anyway. So to me the base system (after
| bootstrapping) should be handled by DataCurator and maintained by you
| (gemstone). This is status quo. My own projects will have lesser
| dependencies on the base system but quite a few on the modules on top
| of this.
| >> I had the assumption that any newly created user will have at least
| read-only rights on the DataCurator segment and therefor could access
| the classes that DataCurator installed. Looking at the error message I
| sent in one of my last mail it doesn't appear this way to me now. I
| need to figure out what permissions are needed and what they do. I
| like just to be cautious because I think if I assign to much rights
| the newly created user will have the ability to change to code in the
| DataCurator space (base system). But then it might be the case that I
| have to less knowledge about how this works, UserGlobals and global
| state access are handled.
| >> Anyway on top of the bootstrapped system I like to create a
| project. A project would be the creation of a new user and using
| metacello to load the project dependent code into the space of the new
| user. Dependent projects would include seaside and companions.
| >> I would start one gem with fastcgi for every user and would be able
| to log in via gemtools for each individual user to maintain the site.
| >>
| >> That is the plan. If you have any additions that might enlighten my
| path then this is super appreciated.
| >>
| >> Norbert
| >>
| >>
| >>
| >> On 23.03.2010, at 17:43, Dale Henrichs wrote:
| >>
| >>> Norbert,
| >>>
| >>> To have "complete isolation" then you need to do a bootstrap
| install as each user.
| >>>
| >>> Dale
| >>> ----- "Norbert Hartl" <[hidden email]> wrote:
| >>>
| >>> | Well,
| >>> |
| >>> | that works (of course?). So I need the intersection of both that
| is
| >>> | mandatory ;) I like to have complete separate users. So sharing
| >>> | UserGlobals is not the way to go. And I want to load code copies
| into
| >>> | each users space. But it is good to have a working example. I
| can
| >>> | restrict this one by one to see when a clash occurrs.
| >>> |
| >>> | Norbert
| >>> |
| >>> | On 23.03.2010, at 16:39, Gerhard Obermann wrote:
| >>> |
| >>> | > Hi!
| >>> | >
| >>> | > Here is the code I use to create a new user with the same
| access
| >>> | rights and privileges as the DataCurator user.
| >>> | > The new user must access the same UserGlobals as the
| DataCurator.
| >>> | >
| >>> | > | dc user userIdx idx |
| >>> | > dc := AllUsers detect: [:u | u userId = 'DataCurator'].
| >>> | > user := UserProfile newWithUserId: 'FastCGI'
| >>> | >  password: 'xxxxxxxxxxx'
| >>> | >  privileges: dc privileges
| >>> | >  inGroups: dc groups.
| >>> | >
| >>> | > idx := dc symbolList names indexOf: #UserGlobals.
| >>> | > userIdx := user symbolList names indexOf: #UserGlobals.
| >>> | > user symbolList removeAtIndex: userIdx.
| >>> | > user symbolList addAll: (Array with: (dc symbolList at: idx))
| >>> | beforeIndex: 1.
| >>> | > idx := dc symbolList names indexOf: #SessionMethods.
| >>> | > user symbolList addAll: (Array with: (dc symbolList at: idx))
| >>> | afterIndex: 1.
| >>> | >
| >>> | >
| >>> | > Gerhard
| >>> | >
| >>> | > On Tue, Mar 23, 2010 at 3:39 PM, Norbert Hartl
| <[hidden email]>
| >>> | wrote:
| >>> | > I tested this but it doesn't help. You would say there is no
| reason
| >>> | even in a bootstrapped image that should prevent a normal user
| from
| >>> | logging in? Could it be that there is some visibility missing
| to
| >>> | needed classes? Just wild guessing :)
| >>> | >
| >>> | > Norbert
| >>> | >
| >>> | > On 23.03.2010, at 01:28, Dale Henrichs wrote:
| >>> | >
| >>> | > > run
| >>> | > > | seaside |
| >>> | > > seaside := AllUsers userWithId: 'seaside' ifAbsent: [ nil
| ].
| >>> | > > seaside ~~ nil
| >>> | > >  ifTrue: [
| >>> | > >    AllUsers removeIfPresent: seaside.
| >>> | > >    System commitTransaction.
| >>> | > > ].
| >>> | > > (AllUsers
| >>> | > >  addNewUserWithId: 'seaside'
| >>> | > >  password: 'swordfish')
| >>> | > >    addPrivilege: #'CodeModification';
| >>> | > >    addPrivilege: #'UserPassword';
| >>> | > >    addPrivilege: #'OtherPassword';
| >>> | > >    yourself.
| >>> | > > System commitTransaction.
| >>> | > > %
| >>> | >
| >>> | >
| >>
| >

----- "Norbert Hartl" <[hidden email]> wrote:

| That sounds all quite good. I myself try to figure out how this all
| works. I understand that instead of having an Object Smalltalk that
| carries global state in gemstone it is a depth-first search through a
| list of dictionaries. I can imagine that "bootstrapping" in your sense
| means importing classes into the Globals dictionary therefor replacing
| the old ones, right? But then I'm not sure when I import what into
| which dictionary. If I load code as Datacurator it is imported into
| Globals, right? This way the classes can be seen by anyone. And while
| the objects have been created in the DataCurator segment they will be
| read-only for any non-system user. If I load code as a user it is
| imported into UserGlobals per se?
| And bootstrapping the code again just creates a second Globals
| dictonary that gets attached to the default symbolList for this user?
|
| I think a need a little clarification on some of these. Thanks,

Before going to far, let's take a little tour of the image.

Each user has a symbolList: a list of SymbolDictionary instances. Here's the symbol list from DataCurator after a GLASS bootstrap:

  GsSession currentSession userProfile symbolList
    collect: [:symbolDict | symbolDict name ].

    anArray( #'UserGlobals', #'SessionMethods', #'Globals', #'Published')

Prior to the bootstrap the symbol list for DataCurator looks like this:

    anArray( #'UserGlobals', #'Globals', #'Published')

When this code runs as the initial part of the Bootstrap:
  run
  | policy package targetSymbolDictionary |
  package := GsPackageLibrary createPackageNamed: #SessionMethods.
  GsPackageLibrary installPackage: package.
  policy := GsPackagePolicy current.
  targetSymbolDictionary := GsCurrentSession currentSession
             objectNamed: BootstrapSymbolDictionaryName.
  (targetSymbolDictionary isKindOf: SymbolDictionary)
    ifFalse:
      [nil error: 'BootstrapSymbolDictionaryName must be the name of a SymbolDictionary'].
  policy homeSymbolDict:  targetSymbolDictionary.
  policy externalSymbolList: Array new.
  true
  %

The #SessionMethods SymbolDictionary is installed in the user's symbol list. This symbolDictionary contains some methods that enable the use of Session Methods....

In a GemStone repository the #Globals symbol dictionary is owned by SystemUser (root) and in a normal system a non-SystemUser is not allowed to modify any objects owned by SystemUser ... including adding methods.

Session Methods allow non-SystemUser users to add methods to Classes owned by SystemUser...this is how under GLASS you are able to extend Object, etc.

What this means is that when you bootstrap GLASS, the extension methods to Object are _not_ stored in the Globals symbol dictionary but are actually stored in the UserGlobals symbol dictionary.

So in the end bootstrapping does two things:

  - enables SessionMethods
  - loads code into UserGlobals

Now, take a closer look at these two lines:

  package := GsPackageLibrary createPackageNamed: #SessionMethods.
  GsPackageLibrary installPackage: package.

If you go underneath the covers you'll see that there is SymbolDictionary called #PackageLibrary where SymbolDictionary instances containing SessionMethods may be stored...#installPackage takes the SymbolDictionary named #SessionMethods and installs it in the current user's Symbol List ...

There is more the this GsPackage stuff, you can specify dependencies, etc., but the key things to take away are:

  - all of the code loaded into GLASS, starting with the Bootstrap process goes
    into UserGlobals by default (you can specify different SymbolDictionaries
    if you want).
  - If you are interested in sharing some code amongst a collection of users, you
    should install that code into it's own SymbolDictionary (we can talk about the
    way to do that in a separate message) and then that SymbolDictionary can be
    installed into each users SymbolList (probably using #installPackage:)
  - Each user can have their own SymbolDictionary (separate from the shared symbol
    dictionary) into which the code that they load is stored.

So I think this answers your original question and opens the door for additional questions:)

Dale

Hi Norbert

This is a bit old, but I'm now getting this JadeServer error on login
with 2.4.4.1.

Was it a permissions issue? I've got GemTools-Client-Session 540
installed in my Pharo image.

What was the workaround? Doesn't look like a permissions problem. I
tried logging in as DataCurator and SystemUser with the same result.

Steve

On Tue, Mar 23, 2010 at 1:11 AM, Norbert Hartl <[hidden email]> wrote:

Hey again, user error. I knew it would be.

Obviously after replacing my extent0.dbf I should have rerun the
bootstrap topaz script.

I really promise to read the instructions again before posting dumb
questions to the list.

Cheers,
Steve

On Tue, Jul 20, 2010 at 8:15 PM, Steve Wart <[hidden email]> wrote:

Steve Wart wrote: Steve,

I encourage folks to post dumb questions ... it's part of the process
for solving problems, besides you can't tell that a question is dumb
until the problem is solved:)

Dale