On Mon, Aug 9, 2021 at 5:14 PM Robert W. Eckert <r...@rob.eckert.name> wrote:
>
> I have had the same issue with the windows client.
> I had to issue
> ceph config set mon auth_expose_insecure_global_id_reclaim false
> Which allows the other clients to connect.
> I think you need to restart the monitors as well, because the first few times
> I tried this, I still couldn't connect.
For archive's sake, I'd like to mention that disabling
auth_expose_insecure_global_id_reclaim isn't right and it wasn't
intended for this. Enabling auth_allow_insecure_global_id_reclaim
should be enough to allow all (however old) clients to connect.
The fact that it wasn't enough for the available Windows build
suggests that there is some subtle breakage in it because all "expose"
does is it forces the client to connect twice instead of just once.
It doesn't actually refuse old unpatched clients.
(The breakage isn't surprising given that the available build is
more or less a random development snapshot with some pending at the
time Windows-specific patches applied. I'll try to escalate issue
and get the linked MSI bundle updated.)
Thanks,
Ilya
>
> -----Original Message-----
> From: Richard Bade <hitr...@gmail.com>
> Sent: Sunday, August 8, 2021 8:27 PM
> To: Daniel Persson <mailto.wo...@gmail.com>
> Cc: Ceph Users <ceph-users@ceph.io>
> Subject: [ceph-users] Re: BUG #51821 - client is using insecure global_id
> reclaim
>
> Hi Daniel,
> I had a similar issue last week after upgrading my test cluster from
> 14.2.13 to 14.2.22 which included this fix for Global ID reclaim in .20. My
> issue was a rados gw that I was re-deploying on the latest version. The
> problem seemed to be related with cephx authentication.
> It kept displaying the error message you have and the service wouldn't start.
> I ended up stopping and removing the old rgw service, deleting all the keys
> in /etc/ceph/ and all data in /var/lib/ceph/radosgw/ and re-deploying the
> radosgw. This used the new rgw bootstrap keys and new key for this radosgw.
> So, I would suggest you double and triple check which keys your clients are
> using and that cephx is enabled correctly on your cluster.
> Check your admin key in /etc/ceph as well, as that's what's being used for
> ceph status.
>
> Regards,
> Rich
>
> On Sun, 8 Aug 2021 at 05:01, Daniel Persson <mailto.wo...@gmail.com> wrote:
> >
> > Hi everyone.
> >
> > I suggested asking for help here instead of in the bug tracker so that
> > I will try it.
> >
> > https://tracker.ceph.com/issues/51821?next_issue_id=51820&prev_issue_i
> > d=51824
> >
> > I have a problem that I can't seem to figure out how to resolve the issue.
> >
> > AUTH_INSECURE_GLOBAL_ID_RECLAIM: client is using insecure global_id
> > reclaim
> > AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED: mons are allowing insecure
> > global_id reclaim
> >
> >
> > Both of these have to do with reclaiming ID and securing that no
> > client could steal or reuse another client's ID. I understand the
> > reason for this and want to resolve the issue.
> >
> > Currently, I have three different clients.
> >
> > * One Windows client using the latest Ceph-Dokan build. (ceph version
> > 15.0.0-22274-g5656003758 (5656003758614f8fd2a8c49c2e7d4f5cd637b0ea)
> > pacific
> > (rc))
> > * One Linux Debian build using the built packages for that kernel. (
> > 4.19.0-17-amd64)
> > * And one client that I've built from source for a raspberry PI as
> > there is no arm build for the Pacific release. (5.11.0-1015-raspi)
> >
> > If I switch over to not allow global id reclaim, none of these clients
> > could connect, and using the command "ceph status" on one of my nodes
> > will also fail.
> >
> > All of them giving the same error message:
> >
> > monclient(hunting): handle_auth_bad_method server allowed_methods [2]
> > but i only support [2]
> >
> >
> > Has anyone encountered this problem and have any suggestions?
> >
> > PS. The reason I have 3 different hosts is that this is a test
> > environment where I try to resolve and look at issues before we
> > upgrade our production environment to pacific. DS.
> >
> > Best regards
> > Daniel
> > _______________________________________________
> > ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an
> > email to ceph-users-le...@ceph.io
> _______________________________________________
> ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to
> ceph-users-le...@ceph.io
> _______________________________________________
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
