**************************************
********* DoD.net Collective *********
**************************************
Damn dude, i got more mail from you then I did spam today =)
What is going to be needed is both a library and a daemon. For example, a
CGI is called which needs tp update the database. Rather then having to
make all the needed calls for connecting to the daemon, you prolly just
want to call something like dodb_update(flags, data, account, ...). This
call will then connect to the daemon in a *secure* fashion (as database
updates may be coming from machines other then locally), and then send the
appropriate commands/data in simple protocol. The daemon then updates the
the database on disk, and also updates the database segment in shared
memory if needed.
In the cases of say apache though, the daemon may never be touched, ie:
A web request comes in www.dod.net. The hacked apache server we will then
call a library function, something like dodb_retrive(account, data, ...).
In this case, the data is going to be retrived directly from shared
memory, and will not have to talk to the daemon at all. This will provide
the common, small information.
But now, lets say a we have a .htaccess file, and need to authenticate a
user. The user database will not be loaded in RAM (for security and
resource reasons), so we have to get this from the non-shared mem part of
the database. We then make make a library call, something
like: dodb_auth_user(account, user, password, flags). This will in call
talk to the daemon running (again, *securely*), and the daemon will check
the user against the user/password database for the given account.
So it breaks down like this:
Library:
if a shared memory request
check shared memory
else
query db
Daemon:
if retrieval
retrieve from database on disk
if update
update database on disk
update data in shared memory (if applicable)
This is a very simple look, and will be far more complex by the time this
system is done, but thats the general logic fo the lib/daemon action.
Through this I've said things like "this is how it will be", but meaning
more this is my idea of how things could work. So don't think I'm setting
anything in stone or deciding anything for anyone else, just my
opinion. =)
Just keep in mind the primary objectives of having our own database and
not just using a pre-made one:
FAST, effecient lookups of common data (shared memory segment)
Customizable in every way
Secure for retrivals/lookups across the internet.
Modular (can put it on any machine, anywhere)
(any others?)
-Eric
On Mon, 9 Oct 2000, Chris Mooney wrote:
> **************************************
> ********* DoD.net Collective *********
> **************************************
>
>
> I am going to attempt to start a few different threads here.
> Hopefully you all have mail clients that can deal with threads. This
> one will be pertaining to the centralized database that Oddity ( Eric )
> and I have been discussing.
> It's overall objective is to allow for centralized user account
> information. This will be the area that will provide all of our
> daemons with there information. For instance if Apache is looking to
> see if an account needs servlets it will read all the information from
> this database. This database will also be accessed by web scripts
> that will be able to manipulate accounts. For instance if you are
> going to sign up you would find the appropriate account under
> http://home.dod.net/ and fill out the forms. These forms will allow you
> to pay with check or by credit card. If credit is chosen then we can
> have an online authorization validate the account and send the sign up
> form through to the appropriate vessel. There is still some uncertainties
> as to weather this will be a library in the CGI's or weather it will be
> a daemon. Either option appears to provide a good learning experience.
> This is what I will begin working on in the next few weeks. Along with
> a local program that again Will either use a library or daemon to add
> or modify the information. This will be needed for manual account sign
> ups and other modifications.
> We should brain storm as to what fields in the database will be
> needed and how modular we can make it in case of new account features.
> One idea is to have a small core and modular parts that can attach to
> the base core info. This core information will consist of the minimal
> amount of information that is needed for the accounts. That way it can
> be loaded into memory and read from there. Ultimately this should speed
> the daemons access to the database up immensely. Oddity do you have some
> Ideas on this? I would also like to find out what reasons you really
> want to use a library for. Right off I have been thinking of the
> benefits that having a separate daemon would have. You don't need to
> give this particular daemon root access so the scripts can be run from
> trusted users or web users and modify a database that is under the
> control of the daemon. That way the only risk we take is having the
> database modified by an intruder. If this happens it only jeopardize
> the account of the user or daemon. But not root. If this can be done
> with little to no effort with the library then we may want to go that
> route. Right now we would run the database under the user ID dodb and
> still be able to use cgiwrap to protect the CGI bins. Either way get
> back to me on how you think this would work out.
> One more note.. I will be installing Perforce on the server for
> code management. I know not all of you are use to this but I assure you
> it's a rad tool. Once Perforce is up we will begin to check in the
> base revisions of these separate projects.
>
> Regards,
> Chris
>
>
> --
> =====================================================================
> | Chris Mooney | UNIX Systems Administrator |
> | Daemons ofThe Damned | http://home.dod.net/ |
> | P.O. Box 640760 | Tel: (619) 665-3845 |
> | San Jose, CA 95164 | godsflaw@dod.net |
> =====================================================================
>
>
> *********************************************************
> *If you would like to unsubscribe from this mailing list*
> *please e-mail mail-lists@dod.net with the following in *
> *the body of the message. *
> * *
> * unsubscribe collective *
> * *
> *If for any reason you need to contact the administrator*
> *of this list please mail owner-collective@dod.net. You*
> *can access the archives and more information about this*
> *list by going to http://www.dod.net/collective/ . *
> *********************************************************
>
*********************************************************
*If you would like to unsubscribe from this mailing list*
*please e-mail mail-lists@dod.net with the following in *
*the body of the message. *
* *
* unsubscribe collective *
* *
*If for any reason you need to contact the administrator*
*of this list please mail owner-collective@dod.net. You*
*can access the archives and more information about this*
*list by going to http://www.dod.net/collective/ . *
*********************************************************
This archive was generated by hypermail 2b29 : Wed Oct 11 2000 - 23:26:07 PDT