On Tue, 12 Nov 2019, Alfredo Deza wrote:
> > Or... we could skip the package entirely and install the ceph-daemon
> > script in /home/ceph/ceph-daemon, and include an update function that
> > updates the script in place. That is less complicated than knowing how to
> > apt/dnf/yum install a package for all the random distros and repo location
> > combinations (one of the biggest benefits of containers IMO). But it
> > still requires some sort of process to keep ceph-daemon up to date.
> > Maybe if we always pass an md5sum to ceph-daemon whenever we invoke it to
> > assert that we are running the version we want, and if there is a
> > mismatch, ceph-daemon bails out with a special exit code that triggers and
> > update and retry?
>
> Updating a system executable via its own - circumventing distro's
> packaging policies isn't something that is going to be easy to sell.
This would be "installed" at /home/$cephuser/ceph-daemon, so it isn't a
'system executable' (or even 'installed') in the conventional sense. I
don't think the system packaging policies are relevant.
Currently (and in this proposal) everything ceph-daemon does to the host
is done in the way local system configuration is normally layered on top
of the system by a human user (so as not to ruffle packager feathers).
> > Anyway, what are people's thoughts here? How much more complicated are we
> > interested or willing to make this to make people more comfortable with
> > the idea that ceph owns an ssh key?
>
> Why would this need to be solved by ceph-daemon at all? In other
> software (Vagrant for example) that has similar needs, an "insecure"
> SSH key is provided so that
> initial setup (or bootstrap) is done with ease. It is up to the
> administrator to ensure that key is updated after bootstrapping or
> create a separate SSH user with restrictions.
>
> In lots of cases this step of securing the SSH key is not needed, like
> testing or playing around with a throwaway cluster.
Currently, the cluster bootstrap process generates its own ssh key, and
that's the one you use to authorize the cluster to manage each host.
It's clear from the authorized_keys file that the key is for a ceph
cluster with a particular fsid.
The goal of all of this is to minimize or eliminate administrator
decisions like which key to use, where to put it, and so on. We want
step-by-step instructions with a very small number of steps (i.e. <5) and
(ideally) no decisions about where and how to do things, both to make
things easy, and to minimize variation between systems.
In this case, the goal is a short bootstrap process at the command line
(currently ~3 steps), after which point users can switch to the dashboard
(or ceph CLI if they prefer) to do the rest. And, ideally, a user would
never have to go back to the command line if they don't want to. Getting
new hosts added to the cluster makes that hard, so we want to make the
process as simple as possible.
Right now the 'prep' sequence for a new host can be almost as simple as
running a command like
echo ...pub.key.here... | sudo tee -a /root/.ssh/authorized_keys
on the new node, and then telling the cluster the new host's hostname.
Once we start installing packages or relying on external orchestration
tools ("go log into your ansible master node, then update your ansible
inventory like so, then run this playbook like so, wait 5 minutes,
then..." etc) the process is no longer simple.
Right now we have an extremely minimal footprint on the managed host,
but the cost is a root-authorized key. I'm trying to figure out how to
reduce that exposure without (significantly) increasing the footprint
or complexity for the user...
sage
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
