[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netatalk-devel
Subject:    Re: [Netatalk-devel] Netatalk design etc. (Was: Netatalk 1.6.0released)
From:       Simon Bazley <simon () eyeeye ! com>
Date:       2002-12-09 17:53:28
[Download RAW message or body]

Ok, so here's my finger in the air thoughts on netatalk design:

afpd really has 4 things to do.  Firstly it has to talk AFP to any clients that talk \
to it.  Secondly is has to provide access to the filesystem of the local system such \
that it stores/provides everything that AFP requires it to store/provide. Thirdly it \
has to authenticate clients that talk to it against some system to identify clients.  \
Forthly it has to match those authenticated clients against the local file system's \
security model.

Those are IMHO the 4 code sections to the code.  Name advertising and printing all \
fit in as valid add ons to those core sections, but really aren't core to the code.  \
My feeling is that Name advertising should be a separate process wheras printing is a \
different kind of afpd, that doesn't need any of the filesystem stuff.

I've not read a lot about AFP, but I assume that like SMB's there is a negotiation \
process at the begining where a server tells the client what functions it can \
provide.  This sounds like an ideal demarkation line, as if coded properly an 'AFP \
server' could be written that would purely act as an inteface for as many functions \
and versions we wish any AFP based application to provide. The authentication modules \
will have to be externally linked because of all the crypto stuff and the paranoia of \
various governements, but as has been mentioned, I see no reason why these can't be \
linked statically or treated as libraries for general use (they're either purely \
netatalk or they're for third party use; uams have been kind of treated like both). \
The security model is simple at the moment because we rely on each afpd setting \
itself to the security status of its respective client.  This model falls flat when \
we have to try to duplicate the functionality of a file system in a user mode \
program. I've thought a lot about the backend adouble/CNID issue.  My feeling is that \
we should break the code at an API where a library on one side provides all the \
storage facilities on whatever file system is being used, where the API is filesystem \
non-specific.  That would allow the filesystem code to be replaced with other \
libraries as new filesystems are provided.

With respect to the security model, as we've mentioned before for the sanity of all \
network admins that try to support netatalk, there has to be a process that runs at a \
separate security status, that maintains all the centralised filesystem stuff.  It \
would be this process that primarily deals with automatic directory updating and any \
communication that needs take place with other server apps like samba.

Thoughts?

    Simon




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Netatalk-devel mailing list
Netatalk-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netatalk-devel


[prev in list] [next in list] [prev in thread] [next in thread]