**************************************
********* DoD.net Collective *********
**************************************
On Mon, Oct 09, 2000 at 07:43:04PM -0700, oddity@unixpunx.org wrote:
> Damn dude, i got more mail from you then I did spam today =)
Ya sorry about that. I wanted to send out more stuff but I figured this
was a hand-full for now. Also others can post new threads if it's
needed.
>
> 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.
Sounds right on target.
>
> 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.
Again right on target...
>
> 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.
Yes it will be.
>
> 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. =)
I think the idea sounds real good. Although I would like blindcry's
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?)
The name of the game here is distributed computing kiddies. This will
allow us to share the database across multiple machines on the net. It
will also allow for a centralized base of information. When changes are
made they will propagate themselves to the other machines in the network
and allow for us to make changes to any hacked daemon on the dod network
just by changing the database. So the trick is to name off each service
that we believe is going to feed off of this database. By doing so we
should gain a better understanding of what fields the database will
need. I believe the major Idea is to try and keep this simple. So a
boolean value or 0,1 will tell the daemon looking at it worlds of
information about the account. Here are a few things I can think of off
the top of my head.
The following is a list of services to be hacked so they can read the
dodb:
1: Billing system.
2: Account sign up forms.
3: Command line admin tool.
4: Web admin tool.
5: Re-seller account tool.
6: Apache
7: BIND
8: Sendmail
9: SSH?
10: FTP
11: POP
I am sure there are more. I have arranged these in no particular order.
But we are going to need to put a list together so that when we sit down
and talk about the dodb fields we will know what each service will want
to see in the database. I suggest that we get together around supper time
on Saturday and talk more about the database and how we will want to put
it together. Oddity ( Eric ), Blindcry ( James ), and myself should defiantly
be there. Blindcry please let us know if there are going to be time
conflicts for this. If anyone else would like to be present for this
brain storm please speak up ... You are more then welcome to contribute
your ideas and thoughts on the subject.
>
> -Eric
>
> On Mon, 9 Oct 2000, Chris Mooney wrote:
>
> >
> > I am going to attempt to start a few different threads here.
> > Hopefully you all have mail clients that can deal with threads. This
<-*-> SNIP <-*->
Keep it real,
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/ . *
*********************************************************
This archive was generated by hypermail 2b29 : Wed Oct 11 2000 - 23:26:07 PDT