I have some additional questions on the client/server issue. In this
new version, will the write-lock mechanism still be used for writing
operations? Will only one user be able to write at the same time, and
will a user, who want to write after another one has saved while the
first one was reading, have to restart to see the changes?
This is really an emphasized version of my message to the list a
couple of days ago, about the write-lock issue.
Mummi
In article <38BA66FF.71AF4A2E at sanger.ac.uk>,
Ed Griffiths <edgrif at sanger.ac.uk> wrote:
> Nathaniel,
>> OK, here are some answers for the 4_7 version of the client/server
> (which uses RPC for communication):
>> > Also, if someone knows the port number and ip address of a running
AceDB
> > server, is there any way to keep them from connecting to it ?
>> This version of the server used an ingenious method for restricting
> read/write access which did not require the user to have a password.
The
> basic idea was that the server would write two magic files (one for
> read, one for write) in a directory(ies) known to the client and
> server. If the client could read and return the contents of the read
> file, it got read access, if it could read/return the contents of the
> write file it got write access. Thus if the client and server were on
> different machines then the directory where these files appeared had
to
> be NFS mounted by the two machines. So the answer to your question is
> that you can restrict access if the client and server can see this
> directory. You can give read access to everybody without them having
to
> see this directory. This is explained in the file wspec/server.wrm.
>> > Also, in the passwd.wrm file, you're supposed to list user ids with
write
> > access to the database. I assume this is only for non-remote
clients ?
>> You assume correctly, passwd.wrm file is used by the program actually
> accessing the database (xace, tace, aceserver etc.).
>> > another machine. Surely I don't have to NFS mount directories do I
?
>> The problem with this method (as you point out in a later note) is
that
> it doesn't allow that much control if NFS mounting is not possible.
With
> ace 4_7 I'm afraid you are just stuck with this.
>> Now...for ace 4_8 we have rewritten the server to directly use sockets
> instead of RPC (for portability and interfacing reasons). We have also
> taken the opportunity to add a password mechanism for users, so this
> will answer your question. Now you will have a "true" client/server
> setup with control files for restrict access to just the people you
> want. There are new admin commands to manage these control files.
>> When this all be available ? Well its available now for Beta-testing.
> The caveat is that a number of other parts of acedb have been changed
> and we are still testing locally to iron out bugs. I can build you a
> binary (we are about to do a monthly build) and you can try it out if
> you like. I am also just doing the documentation because we have added
> some new commands to manage the user stuff and a number of other
> additions to the server.
>> I hope this answers your questions, please feel free to email me
direct
> or append here if you need more information.
>> cheers Ed
>>------------------------------------------------------------------------
------
> | Ed Griffiths, Informatics
> Group, |
> | The Sanger Centre, Wellcome Trust Genome
> Campus, |
> | Hinxton, Cambridge CB10 1SA,
> UK |
> |
> |
> | email: edgrif at sanger.ac.uk URL:
>http://www.sanger.ac.uk/Users/edgrif |
> | Tel: +44-1223-494780 (switch +44 1223 834244) Fax: +44 1223
> 494919 |
>>------------------------------------------------------------------------
------
>
Sent via Deja.com http://www.deja.com/
Before you buy.
