Toolkit initialization implications

Ivan R. Judson judson at mcs.anl.gov
Fri May 9 16:14:36 CDT 2003


This large change this close the the code freeze is very worrysome to me.
This really needed to be discussed with everyone before such a comprehensive
set of changes is made.

We need to have seem this kind of outline of what was involved to have made
a better decision as to whether we should have solved cert mgmt this way or
not.  

This is not to say that this isn't a good way to solve the problem, it's
hard to tell -- but we've just added more work to our load by making this
change and it's all new to everyone but you.  This isn't really the best
time to be making that kind of change to the assumptions.

I don't think we have any choice at this point about using it, but I'm
extremely concerned at what it might mean for us actually meeting our
timeline. I'm also frustrated at the lack of information that was presented
before these changes were made.

--Ivan

> -----Original Message-----
> From: owner-ag-dev at mcs.anl.gov 
> [mailto:owner-ag-dev at mcs.anl.gov] On Behalf Of Robert Olson
> Sent: Friday, May 09, 2003 3:28 PM
> To: ag-dev at mcs.anl.gov
> Subject: Toolkit initialization implications 
> 
> 
> I'll be committing AccessGrid.Toolkit soon. I wanted to drop 
> folks a note 
> on how things may have to change in order to support some of 
> what we want 
> to do.
> 
> The Venue client will have the following code in its 
> initialization. Any 
> wx-based app that wants to use the certificate mgmt framework 
> will have to 
> do something similar:
> 
>          self.app = Toolkit.WXGUIApplication()
>          self.app.Initialize()
> 
> That's it; what that does is set up the cert mgmt 
> infrastructure such that 
> it'll bring up the wx dialog to create a proxy if one is not 
> available, and 
> it will set up the process's environment accordingly. The 
> certificate menu 
> items are hooked in thusly:
> 
>          gui = None
>          try:
>              mgr = Tookit.GetApplication().GetCertificateManager()
>              gui = mgr.GetUserInterface()
> 
>          except:
>              log.exception("Cannot retrieve certificate mgr 
> user interface, 
> continuing")
> 
>          if gui is not None:
>              certMenu = gui.GetMenu(self)
>              self.menubar.Append(certMenu, "&Certificates")
> 
> 
> Because this sets up the environment, any process that is 
> created by the 
> client will run with these credentials *if* the process does 
> not do any 
> other initialization.
> 
> However, I recommend that each of our apps should indeed 
> perform explicit 
> initialization.
> 
> The following code is now in the venue server. identityCert 
> and identityKey 
> are to be filenames, passed in on the command line (via the 
> new --cert and 
> --key options). What this does, if the options are passed, is 
> to initialize 
> the security environment to force the use of that 
> cert/privkey for the 
> server's identity. Otherwise, it sets up the environment as 
> "usual", but 
> uses a command-line interface to create a proxy if one is needed.
> 
> if identityCert is not None or identityKey is not None:
>      [sanity check elided]
> 
>      #
>      # Init toolkit with explicit identity.
>      #
> 
>      app = 
> Toolkit.ServiceApplicationWithIdentity(identityCert, identityKey)
> 
> else:
>      #
>      # Init toolkit with standard environment.
>      #
> 
>      app = Toolkit.CmdlineApplication()
> 
> app.Initialize()
> 
> If you want the app to explicitly inherit the environment, 
> initialize like 
> this:
> 
>     app = Toolkit.ServiceApplicationInheritIdentity()
>     app.Initialize()
> 
> I have not made the changes to the individual services. I 
> recommend that as 
> part of the work to make them startable at boot that, like 
> with the venue 
> server example above, they take command-line arguments for explicitly 
> setting the certificate and private key. I think the default 
> of inheriting 
> environment should be fine; this is what the personalNode 
> stuff currently 
> depends on and it appears to work fine.
> 
> --bob
> 




More information about the ag-dev mailing list