jpr's blog

feel like we're getting to a good point of having our raw materials to the
point of some integration that will lead to useful outcomes. combining
the three diagrams into a developer guide book is really doable and having
the target of the that guide be the pycon2005 mailman developers seems
like a workable goal.

been entering in hardware bugs for items that are going unaddressed in
the lab. this triggered a thought that this is the shared responsibility
project we need. this is basically our equipment project. We need to
have our dell contact information published so that we all know who to
contact. we need to have the proceedures documented. we need to have a
common mailing address that we can act as the equipment manager/requestor
to dell. This is basically our vo for equipment mgmt and entails mailing
lists, wikis, we mail clients, formums/archives, etc. getting this set
up and having people participate will be our way of being virtual

[phpwiki]

it's important to redefine a website login as an application launch when
websites are merge together using middleware. the authn step by webiso is
really process initialization by the distributed kernel. this initiallizes
the uid (REMOTE_USER) of the process. the process then looks in the
user-specific initialization file (the "account" container for the web
tool). and sets values defined for that user. this is effectively using
an implicit HOME var and cwd allowing the web tool to load it's config
file. granted, this really all boils down to a select * from account
where user=somebody query

[phpwiki]

the vo service provider is coming along. the architecture is feeling more solid and hopefully makes sense. Have a look: http://lab.ac.uab.edu/~jpr/projects/collab/vo-provider-0.02.png

Is this interface still functioning?

ended up creating a new cert/key for nori using the uabgridca web site
since the key/cert didn't seem to match up for the existing nori cert.
the web interface was convenient but it needs to allow not storing the key
and not necessarily requiring an email address, though the assigner isn't
a bad choice. sent jim an update. couldn't figure out how to verify a
key matches a cert. might need to ask jim. found out more about globus
along the way and see that gatekeeper is just and xinetd service. easy to
follow.

in some ways, an account can simply be thought of as a particular tools mechnism for tracking a set of preferences or setting for an identified user. that is, an account doesn't really identify the user, it's more of a named container for a collection of settings.

in a system, like unix, where everything agrees to a common set of identities, the personal settings are usually stored in a file identified by the applications name in the users general purpose storage area.

in a systems like many web applications, where the application is the system (a single application system?), the personal settings are usually indistinguishable from the account itself. the settings and account definition are, in fact, often intermingled in the same table.

there are a ton of elements that make up a good site. the main pages (drupal, phpwebsite), special function services like documentation (latex2html), faq (phpMyFAQ), images (gallery), file store (read-only via apache, read-write via zope or webdav), search, maillist, the list goes on.

it's clear for this little list that in order for the user experience to be uniform across the applications there needs to be a common definition of users, groups for identities and authorizations.

this is nothing new, really. it is worth being explicit about it, though. that helps bring these elements to the fore front of the system. knowing what they are and how they can be accessed within the system.

seems oscar and rocks follow similar logic. oscar seems a little rougher
but also includes some stuff from major compute centers like oakridge and
ncsa. both are based on redhat-ish distros. they do use similar
approaches to build images, though oscar seems to do more custom building.
seems it takes system rpms and installs them at a different base for the
nodes. both install systems on the nodes and don't share a common central
system. this is fine but does have an install overhead. this is kinda
expensive (i think) for a desktop machine since their likely to have a lot

[phpwiki]
so the question really becomes, how do I structure the project code in cvs
in order to have a grid register and a grid login code base. the grid
register will actually or potenially contain tie ins to registration steps
in other web apps, eg. the rapid cert creates the cert and knows the next
step the reg process. we could structure the code differently and always
leverage the "referer" info so that we have a parent page that controls
the app flow and the individual "rapid" scripts just redirect back to the
refer after they are done running. this makes the individual apps