Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: > > > > I really don't want to have to tell ordinary users that "you can't use this > > > > unless you first go and write some systemd scripting". > > > > > > If you're willing to take on the work to activate afs dependent > > > structures and components, it becomes your responsibility to integrate > > > it well. > > > > By "you" are you referring to me personally, or anyone wanting to use the kafs > > client? > > Anyone willing to do the work. Do *what* work? Do you mean setting up an entire AFS cell and configuring all the servers? > > If you're referring to someone wanting to just use the kafs client, why should > > they need to do anything other than install kafs-client? Say they're a > > student at a university that has an already-existing AFS infrastructure. They > > should just be able to install kafs-client, then they should immediately be > > able access the infrastructure with no required local configuration, provided > > the infrastructure includes DNS SRV or AFSDB records telling kafs where to > > find the cell's Volume Location servers and appropriate kerberos servers. > > Say they're not, and need some other distinct setup. If it's > standardized, as is seeming more apparent from the existing SELinux > hooks, OK. Perhaps it's worth adding to the FSH, if it's such a > standard usage? The case I'm trying to make simplest is someone who just needs to gain access to an already existing AFS infrastructure. It can be made such that someone in that position has to do zero configuration, apart from installing the kafs-client package. Anyone who wants to do anything more interesting, will have to do their own configuration, but the kafs-client rpm contains stuff that can be used as a template. If you happen to be so inclined, kafs is almost completely network-namespace aware and can be used in containerised environments. You can mount individual volumes directly if you wish. The bits that aren't in place yet are the request-key upcall namespacing, which I'm working on, and the ability to provide keys to a container from the outside - which I'm also working on. > > But to some extent what you're describing is not the fault of AFS, no matter > > the client driver. Whatever is trawling the rootfs can observe the crossing > > into a separate filesystem. I should make statx() set attributes to tell you > > Not without getting the directory information about "/" to report > information about that unique node. You see the problem? No. That's something statx() should be able to tell you. Now, I will grant that at the moment it won't tell you that what is mounted on /afs is a magic dir full of automount points, but it *will* set STATX_ATTR_AUTOMOUNT on each inode that is an automount point. This is done by the core kernel for each inode that is flagged S_AUTOMOUNT internally. > > That's a bit out of date. See: > > > > https://www.infradead.org/~dhowells/kafs/ > > https://www.infradead.org/~dhowells/kafs/todo.html > > > > The pioctl thing is the most vexing bit. Linus point-blank refuses to let the > > pioctl interface into the code, so I'm having to build in workarounds: > > > > https://www.infradead.org/~dhowells/kafs/user_interface.html > > > > David > > I'd be inclined to take Linux's opinion over yours on the matter. Not > to question your personal expertise, but he's earned a lot of trust > for his successful authorship and insight in the Linux kernel. I should rotfl at that one! Besides, who said my opinion of the pioctl interface doesn't coincide with Linus's? The reason I was trying to build pioctl into the kernel - or, at least, the kafs filesystem - is so that OpenAFS's toolset could be used directly with kafs. But the pioctl interface has been somewhat, um, abused, so Linus's position is understandable (and it's not just Linus who holds this opinion, I should add). > I'm curious what AFS is providing over NFSv4 and autofs based mounts? Access to 35 years worth of existing AFS infrastructure and the data stored therein, through a global namespace with server transparency. But this is really for other people to answer, and I suspect the answers may differ by organisation. David _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
