[9fans] logging file changes

[9fans] logging file changes

[Matt]

Hi,

I'm currently researching some stuff for work.

We're trying to arrange our network.

What we're looking for is a way to keep track of data associated with
specific files that isn't part of the normal stat data

you know the stuff : author, client, date created, a list of who has
modified it, keywords to help find it, QA details etc. etc.

All the ways I've come up with so far rely on a database and somehow
maintaining it

It struck me that 9p would be the ideal solution as all file requests go
through a plan9 file server which can have rules that operate at a higher
level than simple permissions and so can maintain the database itself.

Has anyone already implemented such a system?

The sub-problem of course is that we have mainly Windows clients.
They will be getting file access via SAMBA on to the Unix box which would
then use u9fs to connect to the plan9 box.
Extra overhead I realise but AFAIK there isn't another way to implement this
crazy scheme and that's why I'm writing this.

I want to try and put plan9's case forward.

Can anyone see any holes? (apart from me having to write the file server
part :)

Matt

Re: [9fans] logging file changes

[Matt]

>  A simple single-threaded
> ``get an SMB request, do some 9P requests, answer the
> SMB request; repeat'' server would be a great start.
it would indeed, presenting the plan9 FS to windows would be a useful thing.
and would probably aid migration

getting the backup features should be enough encouragement

> I've got some ideas about turning something like
> that into a multithreaded (many pending requests)
> service fairly transparently.  This may be more work
> than you were bargaining for.
Well I've never been shy of it but I can sense that I'd have a lot to learn
but I'd love to be involved.

Got any paid for places for a limey intern or whatever :-) I'd gladly give
up my job

 > U9fs goes the wrong way: it is for Plan 9 boxes to
> mount the namespace on a Unix box, not the other
> way 'round.

Yeah I think i misread the u9fs bit and skipped the bit that said that there
is an NFS server in plan9 for that.

The reason Linux would be involved is that the files to be monitored would
mostly be html, perl, php (ugh), asp (ugh ugh) and the gifs, jpgs & psds we
make. We need to have Apache and IIS be able to get to them. Not for serving
live sites (I think) but for our project managment and QA system (which it
looks like I'm going to be designing).

Mind you we discovered today that SAMBA has a "magic script" feature that
will run a shell script for each file access.

I'm determined to get a plan9 box in the room somewhere  (that's hopefully
where my new laptop will come in) so I can demonstrate it's awesome power
:-)

Matt

Re: [9fans] logging file changes

[Lucio De Re]

On Tue, Sep 19, 2000 at 12:16:23AM -0400, Russ Cox wrote:
> 
> Ignoring the data storage problem for the time being,
> the ``right'' solution for getting to the Windows boxes
> is to eliminate Linux and write something to serve SMB
> by translating for a 9P server.  A simple single-threaded

Something that's only dawned on my recently - Microsoft fans wouldn't
emphasise this particular "feature" of their favourite operating system -
is that SMB is a generic protocol.  Once you enable it, you're exposing
all sorts of resources to the client.  No wonder then that it is such a
security nightmare.

> ``get an SMB request, do some 9P requests, answer the
> SMB request; repeat'' server would be a great start.
> I've got some ideas about turning something like
> that into a multithreaded (many pending requests)
> service fairly transparently.  This may be more work
> than you were bargaining for.
> 
It is probably not beyond one's abilities to borrow broadly from SAMBA
and produce an equivalent Plan 9 product.  I think it was Rob that
pointed out the moving goalposts nature of the project, but with that
understanding, one could move t least as far as current state of the art.
Whether doing it "better" would be worthwhile is a moot point.  But
porting 9P to Windows would not be any more fun :-(

> U9fs goes the wrong way: it is for Plan 9 boxes to
> mount the namespace on a Unix box, not the other
> way 'round.
> 
I was thinking of bringing this up, but of course the entire filesystem
can be on Linux - not the happiest choice, but an option - with Plan 9
providing the intermediate tools.  Messy, but not totally unmanageable.

There are numerous projects lurking within Plan 9.  The suspicion is that
there may be better ways and therefore embarking on them is futile.  I
agree, but that way does not lead to progress.

It is really up to us "users" to contribute to the extension of Plan 9
into the common workplace.  Bell Labs have done their bit, in an
ivory-tower sort of fashion, and we're the richer for it.  Now, I think, is
the time for the pragmatists to do their bit :-)

++L

Re: [9fans] logging file changes

[Russ Cox]

Ignoring the data storage problem for the time being,
the ``right'' solution for getting to the Windows boxes
is to eliminate Linux and write something to serve SMB
by translating for a 9P server.  A simple single-threaded
``get an SMB request, do some 9P requests, answer the
SMB request; repeat'' server would be a great start.
I've got some ideas about turning something like
that into a multithreaded (many pending requests)
service fairly transparently.  This may be more work
than you were bargaining for.

U9fs goes the wrong way: it is for Plan 9 boxes to
mount the namespace on a Unix box, not the other
way 'round.

Russ