Hi,
I'm following openafs-stable-1_6_x commits via RSS, but since some time (don't
know exactly), I don't get any messages anymore using different readers,
although the last commit is only 9 hours ago.
Bye...
Dirk
--
Dirk Heinrichs
Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913
On Tue, 3 Sep 2013 10:20:24 -0400 (EDT)
step...@physics.unc.edu wrote:
> Thanks for the explanation.
>
> The use case I was thinking of is exactly what you mention: revoking
> someone's rights by removing them from a group. Right or wrong, users'
> expectations seem to be "I removed a user from a
On Tue, 3 Sep 2013 10:24:01 -0500
Andrew Deason wrote:
> Nicolas, if you want to get going right this minute, it may work to just
> go into src/afs/LINUX, and replace all instances of d_count with
> d_lockref.count, and d_lock with d_lockref.lock. We'll get some autoconf
> glue and such for opena
On Tue, 3 Sep 2013 08:28:12 +0200
nicolas prochazka wrote:
> hello,
> it seems tha't
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=98474236f72e5a8b89c14cd7c74f0bb77a4b1a99
> recent change
> cause openafs git tree module ( 1.6.x) does not comile anymore with kernel
On Tue, 3 Sep 2013 08:43:55 -0400
chas williams - CONTRACTOR wrote:
> Yes, I certainly believe there is an existing base that currently
> prevents any change. But that doesn't mean we have to keep letting
> this happen. Creating an admin API library would be nice but not
> doable in the short t
On Tue, Sep 3, 2013 at 2:28 AM, nicolas prochazka
wrote:
> hello,
> it seems tha't
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=98474236f72e5a8b89c14cd7c74f0bb77a4b1a99
> recent change
> cause openafs git tree module ( 1.6.x) does not comile anymore with kernel
>
Andrew,
Thanks for the explanation.
The use case I was thinking of is exactly what you mention: revoking
someone's rights by removing them from a group. Right or wrong, users'
expectations seem to be "I removed a user from a group, s/he is immediately
denied access to the affected directories
On Tue, 3 Sep 2013 08:43:55 -0400
chas williams - CONTRACTOR wrote:
> Yes, I certainly believe there is an existing base that currently
> prevents any change. But that doesn't mean we have to keep letting
> this happen. Creating an admin API library would be nice but not
> doable in the short t
Yes, I certainly believe there is an existing base that currently
prevents any change. But that doesn't mean we have to keep letting
this happen. Creating an admin API library would be nice but not
doable in the short term, but adding XML output to the commands for
others that wish to parse outpu
True. On the other hand you should consider that this is a generalised problem:
I bet there are tons of system utilities around (perl,….) which directly depend
on this output. So practically speaking you are locked-in already.
In our case, all parsing is anyway factored out into one single plac
On Mon, 2 Sep 2013 14:23:47 +0200
Christof Hanke wrote:
> Like Jakub, I think parsing the results of vos, fs commands is completely
> sufficient.
> The pathes to those binaries are not hardcoded, but can be changed quite
> easily.
While sufficient, it does create problems in other ways. For i
>
>
openafs-server-1.4.14.1-1.1.x86_64
>>>
>>> I am running openafs-server-1.6.5-145.sl6 on SL 6.0. From the
>>> sl-security repo. Is there any reason to stick with 1.4.14?
>>
>> I just follow the specification of CERN and many tests on it passed.
>
> Then the guys from CERN should answer
12 matches
Mail list logo
