[replying to the latest but copying one older snippet since it's important] > > > Now my problem is still understanding why `bos listkeys` now succeeds but > > > returns an empty set when asetkey does list 4 keys.
This is the expected behavior. "bos listkeys" only knows about legacy rxkad (single-DES) keys, and the desired state is to have zero active keys of that type. (It looks like you have figured this out independently already, but I just wanted to confirm it specifically.) It would be possible in theory to add new RPCs for the bosserver to manage the newer key types, but given the advances in fleet automation and remote management tools since bos was originally written, it seemed like it would not add very much value compared to ssh and akeyconvert. On Sun, Jun 02, 2024 at 12:18:54PM -0400, Ernesto Alfonso wrote: > Dirk Heinrichs: > > Because you deleted the wrong key. The AFS principal should be named > "afs/<domain>@<REALM>". Just follow the instructions in > https://docs.openafs.org/QuickStartUnix/HDRWQ50.html, under "Generating > the Cell's Kerberos V5 Keys", but replace "/usr/afs/etc" with > "/etc/openafs/server", which is used on Debian/Ubuntu, and you should be > all set. > > Thanks. According to the afs-newcell script requirements banner, it would > be acceptable to use `afs` instead of afs/asus.erjoalgo.com` as the > principal. This text in afs-newcell should have been removed since 1.8.10-2 (in favof of afs/cellname); if you are seeing it in that version or later, please report a debian bug. That update to afs-newcell also updated the text you quoted later on (which I am trimming from this message) about single-DES AFS keys. > I was able to run the afs-newcell script, I only had to modify my > /etc/hosts to add my FQDN as an alias for 127.0.0.1. > > However, running `afs-rootvol` fails: > [...] > vos create asus.erjoalgo.com a root.cell -localauth > Volume 536870915 created on partition /vicepa of asus.erjoalgo.com > fs mkm /afs/asus.erjoalgo.com/.root.afs root.afs -rw > fs: You don't have the required access rights on '/afs/ > asus.erjoalgo.com/.root.afs' > Failed: 256 That makes it seem like you do not have a token for a user in the system:administrators group (which could happen if you had restarted or restarted the openafs-client since you ran afs-newcell). So the usual diagnostic steps would include: # tokens # pts mem system:administrators -localauth # fs la /afs/asus.erjoalgo.com/ -Ben _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
