On Nov 19, 2025, at 7:45 AM, Albert Shih <Albert.Shih@obspm.fr> wrote:
Le 18/11/2025 à 14:35:54+0100, Redouane Kachach a écrit Hi,
Not sure why you need the ceph.conf in a cephadm installation (as most of the config is done through the config db). Anyway, If you are using a (modern) cephadm installation then you can just put the label "*_admin*" on the hosts where you would like to have the config and the ceph.conf and keyring will be copied to */var/lib/ceph/<fsid>/config/*
When you start a cephadm shell normally it first checks if there's any running monitor, if found then it will use its config file, otherwise it will check for the above directory to get the fsid.
I don't need the ceph.conf for ceph himself. I «need» the ceph.conf so I can launch
ceph fsid
on any node.
I suspect that the requirement for this to be in ceph.conf may be an artifact of the days when vanity cluster names were intended for multiple logical clusters to run on the same node. One might assert today that a client should be able to get this from the mons, I would suggest entering a tracker ticket to that effect.
As why I need to launch ceph fsid on any node, it's because I'm using puppet to manage everything, and currently I need to add in the cron table of every node something like
chown -R ceph:ceph /var/lib/ceph/FSID/crash/posted
so with the hability to launch ceph fsid on any node I can get that info through a «facter» in puppet so I can add this line in the crontab.
I have to ask: why not use a wildcard?
Of course I can manage the fsid by putting it in some variable, but that's less portable and less «elegant».
Regards.
-- Albert SHIH 🦫 🐸 France Heure locale/Local time: mer. 19 nov. 2025 13:40:18 CET _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io