**************************************
********* DoD.net Collective *********
**************************************
Sup: everyone.
> oddity@unixpunx.org wrote:
>
> **************************************
> ********* 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.
+++ This sound's like a good idea to me. Only one question, are there
any security restrictions on (shm)? I.E. will the daemon have to run as
user webserv in order to access the shared memory? (not that this would
be a problem) Or do you just use a ipc_perm struct as if using normal
IPC? I have a limited knowledge of shm + ipc, so any info you could give
me to help me understand it better would be great. =)
>
> 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. =)
Everything sound's great.
>
> Just keep in mind the primary objectives of having our own database and
> not just using a pre-made one:
+++ Is this going to just be proprietary or do we plan on using the
database on other projects as well. The reason why I am curious is that
I plan on doing allot of database driven WFE (web front ends) and right
now they rely on mySQL. In the future I imagine we will get allot of
traffic hitting the web-based DB's and worry the mySQL may not handle
the load, I worry that searches may take to long, especially in the case
of the news, and event apps coming in the near future. This may not be a
problem any thoughts?
> 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
>
This plan look's great, I am very excited!
Rock, Revolution, and Rebellion... James . . .
--___blindcry_____________________________ - "Great things remain for the great." - ---------------------------------------- http://home.dod.net - webmaster@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/ . * *********************************************************
This archive was generated by hypermail 2b29 : Wed Oct 11 2000 - 23:26:07 PDT