Hi Gunnar, Thanks for checking. Additional response inline ...
> On Aug 25, 2025, at 3:41 AM, Gunnar Krull <gkli...@cs.uni-goettingen.de> > wrote: > > Hi Ryan, hi Jeffrey, > > after seeing this issue, I looked into our nameserver log files and found > similar entries. > > There are many queries for _afs3-vlserver including a filename. Sometimes the > full path is included but in that case the "/afs/" prefix is omitted. > The @sys is not involved here. > > The queries are made for each domain suffix that is configured in > /etc/resolv.conf with the "search" directive. > > Here are some selected queries: > > * queries from Debian Bookworm with OpenAFS Client 1.8.13-1, Kernel > 6.1.0-38-amd64 > 24-Aug-2025 19:30:56.916 client @0x7fa6b6f11168 > 2001:638:60c:310::XXX:XXX#34611 (_afs3-vlserver._udp.htaccess): query: > _afs3-vlserver._udp.htaccess IN SRV + (2001:638:60c:310::81:212) > 25-Aug-2025 08:13:19.303 client @0x7fa6b793c168 > 2001:638:60c:310::XXX:XXX#52502 > (_afs3-vlserver._udp.htaccess.informatik.uni-goettingen.de): query: > _afs3-vlserver._udp.htaccess.informatik.uni-goettingen.de IN SRV + > (2001:638:60c:310::81:212) The above queries are ok. The application is attempting to open /afs/.htaccess which doesn’t exist and the OpenAFS cache manager is trying to resolve it as a rw-path to the cell htaccess.informatik.uni-goettingen.de which doesn’t exist. The AuriStorFS client does not attempt to resolve cell aliases via DNS SRV or AFSDB queries but these queries are not unreasonable. > > * queries from Ubuntu 24.04 with OpenAFS Client 1.8.13.2-1ubuntu1, Kernel > 6.14.0-28-generic > 24-Aug-2025 01:26:34.718 client @0x7fa6b794e168 172.27.1.150#36732 > (_afs3-vlserver._udp.timewarrior.json.informatik.uni-goettingen.de): query: > _afs3-vlserver._udp.timewarrior.json.informatik.uni-goettingen.de IN SRV > +E(0) (134.76.81.212) The above two queries could be for the path /afs/timewarrior.json which is being resolved as an alias to the non-existent time warrior.json.informatik.uni-goettingen.de cell. These queries are expected. > 24-Aug-2025 17:46:05.241 client @0x7fa6b783f168 172.27.1.155#41379 > (_afs3-vlserver._udp.informatik.uni-goettingen.de/user/b/xxxx.xxxx/ulsi-prefix/usr/share/desktop-directories.informatik.uni-goettingen.de): > query: > _afs3-vlserver._udp.informatik.uni-goettingen.de/user/b/xxxx.xxxx/ulsi-prefix/usr/share/desktop-directories.informatik.uni-goettingen.de > IN SRV +E(0) (134.76.81.212) The above queries are unexpected. The path being access is /afs/informatik.uni-goettingen.de/user/b/xxxx.xxxx/ulsi-prefix/usr/share/desktop-directories which should not be searched for as a cell or cell alias. A lookup is being performed for "informatik.uni-goettingen.de/user/b/xxxx.xxxx/ulsi-prefix/usr/share/desktop-directories” as a single path component. If your end user can reproduce this query, it would be interesting to strace the process and see what syscalls are being executed. > 25-Aug-2025 07:15:47.756 client @0x7fa6b79fe168 172.27.2.4#34129 > (_afs3-vlserver._udp.informatik.uni-goettingen.de/user/a/xxxxxx/.xxxlogin/.google_authenticator.informatik.uni-goettingen.de): > query: > _afs3-vlserver._udp.informatik.uni-goettingen.de/user/a/xxxxxx/.xxxlogin/.google_authenticator.informatik.uni-goettingen.de > IN SRV +E(0) (134.76.81.212) Likewise a lookup is being performed for “informatik.uni-goettingen.de/user/a/xxxxxx/.xxxlogin/.google_authenticator” as a single path component. An strace of the originating process would be useful to examine. > 25-Aug-2025 07:50:09.586 client @0x7fa6b6e9e168 172.21.0.1#35881 > (_afs3-vlserver._udp.kateconfig.informatik.uni-goettingen.de): query: > _afs3-vlserver._udp.kateconfig.informatik.uni-goettingen.de IN SRV +E(0) > (134.76.81.212) This query is likely for /afs/.kateconfig which is ok. > 25-Aug-2025 07:50:09.626 client @0x7fa6b6e9e168 172.21.0.1#38919 > (_afs3-vlserver._udp.editorconfig.informatik.uni-goettingen.de): query: > _afs3-vlserver._udp.editorconfig.informatik.uni-goettingen.de IN SRV +E(0) > (134.76.81.212) This query is likely for /afs/.editorconfig which is likely ok. > 25-Aug-2025 07:50:10.098 client @0x7fa6b78c5168 172.21.0.1#51962 > (_afs3-vlserver._udp.kateproject.informatik.uni-goettingen.de): query: > _afs3-vlserver._udp.kateproject.informatik.uni-goettingen.de IN SRV +E(0) > (134.76.81.212) This query is likely for /afs/.kateproject which is ok. > The OpenAFS servers are running on Debian Bookworm with version 1.8.13-1. The OpenAFS database and fileservers are uninvolved in the client side queries but thank you for letting us know. > > The DNS SRV records for afs are configured on our nameservers. The Ubuntu 24.04 6.14.0-28-generic kernel supports BPF scripting so it might be possible for someone to write a script to capture the path components passed to afs_linux_lookup() and afs_linux_create() when the dentry->d_parent is /afs. I do not believe OpenAFS fstrace logging has any trace points which would record the path component values at those entry points. Jeffrey Altman _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
