On 4/6/2020 8:59 AM, David Howells wrote: > Giovanni Bracco <giovanni.bra...@enea.it> wrote: >> My feeling is that to put it really in production the main missing points >> are: >> >> 1) pam module > > Yep. But the systemd folks are doing their best to make this tricky, I > believe...
When "systemd --user" services its not safe to use session keyrings. Network credentials must be stored in user keyrings so that the user services have access to the credentials. >> 2) user commands, essentially "fs" first of all and also "pts" > > And there's another issue with implementing the fs tools - and that's that I'm > not allowed to implement pioctl(2) or afs(2), so I have to find other ways of > doing things: > > https://www.infradead.org/~dhowells/kafs/user_interface.html > > But the main issue is that, for the most part, I'm the only one working on > them - and that's in addition to my normal job. The "fs" command suite does not talk to the fileserver directly. For kafs the "fs" command should be implemented as a front-end to the interfaces that are described by the above URL. OpenAFS should consider implementing those interfaces as well; at least on Linux. The vos and pts commands from OpenAFS currently have a dependency on the existence of a cache manager. If that dependency was removed there would be no need for kafs to provide its own implementation of these tools that are somewhat specific to the administration of OpenAFS cells. Which functionality from "pts" do your users require? >> 3) inotify > > Implementing inotify/dnotify/fanotify is hard because I can't tell from a > callback what changed - only that something has. By examining the data > version I can tell whether the contents of the object changed or whether it > was an attribute/ACL change, but then I have to compare the attributes or, if > a directory, the contents, to see which event to generate. One of the benefits of the Extended Callback protocol is to provide this level of detail https://tools.ietf.org/html/draft-benjamin-extendedcallbackinfo-02 >> The bos, vos and backup command can be run on server nodes, which can be >> standard OpenAFS systems, am I right? > > The OpenAFS bos, vos and backup commands can be run from the client too, I > think, since they don't require any interaction with the afs kernel module. The OpenAFS version of these tools requires an OpenAFS cache manager. The AuriStorFS version does not.
smime.p7s
Description: S/MIME Cryptographic Signature
