From duluxoz@gmail.com Fri Apr 19 07:51:49 2024
From: duluxoz <duluxoz@gmail.com>
To: ceph-users@ceph.io
Subject: [ceph-users] Latest Doco Out Of Date?
Date: Fri, 19 Apr 2024 17:51:36 +1000
Message-ID: <377ffc01-74ab-491b-b369-e9adbb9bef29@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1854464100026486762=="

--===============1854464100026486762==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi All,

In reference to this page from the Ceph documentation: 
https://docs.ceph.com/en/latest/cephfs/client-auth/, down the bottom of 
that page it says that you can run the following commands:

~~~
ceph fs authorize a client.x /dir1 rw
ceph fs authorize a client.x /dir2 rw
~~~

This will allow `client.x` to access both `dir1` and `dir2`.

So, having a use case where we need to do this, we are, HOWEVER, getting 
the following error on running the 2nd command on a Reef 18.2.2 cluster:

`Error EINVAL: client.x already has fs capabilities that differ from 
those supplied. To generate a new auth key for client.x, first remove 
client.x from configuration files, execute 'ceph auth rm client.x', then 
execute this command again.`

Something we're doing wrong, or is the doco "out of date" (mind you, 
that's from the "latest" version of the doco, and the "reef" version), 
or is something else going on?

Thanks in advance for the help

Cheers

Dulux-Oz


--===============1854464100026486762==--


From zac.dover@proton.me Fri Apr 19 07:58:50 2024
From: Zac Dover <zac.dover@proton.me>
To: ceph-users@ceph.io
Subject: [ceph-users] Re: Latest Doco Out Of Date?
Date: Fri, 19 Apr 2024 07:58:05 +0000
Message-ID: <KyNTRF3WzQW7xWHpaa2KBDR-BO1F5gXTu301KExEyfFJhmzqLOS17LznxpeKsxKFbWSa6DfqrTHUheP2ud6RcRiMRwveyGJb0G7tei9GPY8=@proton.me>
In-Reply-To: <377ffc01-74ab-491b-b369-e9adbb9bef29@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0570752349065594077=="

--===============0570752349065594077==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Did you remove client.x from the config?

I need more information about your cluster before I can determine whether the=
 documentation is wrong.

Zac Dover
Upstream Docs
Ceph Foundation

On Fri, Apr 19, 2024 at 17:51, duluxoz <[duluxoz@gmail.com](mailto:On Fri, Ap=
r 19, 2024 at 17:51, duluxoz <<a href=3D)> wrote:

> Hi All,
>
> In reference to this page from the Ceph documentation:
> https://docs.ceph.com/en/latest/cephfs/client-auth/, down the bottom of
> that page it says that you can run the following commands:
>
> ~~~
> ceph fs authorize a client.x /dir1 rw
> ceph fs authorize a client.x /dir2 rw
> ~~~
>
> This will allow `client.x` to access both `dir1` and `dir2`.
>
> So, having a use case where we need to do this, we are, HOWEVER, getting
> the following error on running the 2nd command on a Reef 18.2.2 cluster:
>
> `Error EINVAL: client.x already has fs capabilities that differ from
> those supplied. To generate a new auth key for client.x, first remove
> client.x from configuration files, execute 'ceph auth rm client.x', then
> execute this command again.`
>
> Something we're doing wrong, or is the doco "out of date" (mind you,
> that's from the "latest" version of the doco, and the "reef" version),
> or is something else going on?
>
> Thanks in advance for the help
>
> Cheers
>
> Dulux-Oz
>
> _______________________________________________
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-leave@ceph.io

--===============0570752349065594077==--


From duluxoz@gmail.com Fri Apr 19 08:00:56 2024
From: duluxoz <duluxoz@gmail.com>
To: ceph-users@ceph.io
Subject: [ceph-users] Re: Latest Doco Out Of Date?
Date: Fri, 19 Apr 2024 18:00:13 +1000
Message-ID: <061dc996-ef66-4e05-830d-c27f482e6646@gmail.com>
In-Reply-To: =?utf-8?q?=3CKyNTRF3WzQW7xWHpaa2KBDR-BO1F5gXTu301KExEyfFJhmzqLO?=
 =?utf-8?q?S17LznxpeKsxKFbWSa6DfqrTHUheP2ud6RcRiMRwveyGJb0G7tei9GPY8=3D=40pr?=
 =?utf-8?q?oton=2Eme=3E?=
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3448319174081218887=="

--===============3448319174081218887==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hi Zac,

Yeap, followed the instructions (ie removed the client) and then re-ran 
the commands - say thing.

What in particular do you need to know?  :-)

Cheers

Dulux-Oz

On 19/04/2024 17:58, Zac Dover wrote:
> Did you remove client.x from the config?
>
> I need more information about your cluster before I can determine 
> whether the documentation is wrong.
>
> Zac Dover
> Upstream Docs
> Ceph Foundation
>
>
> On Fri, Apr 19, 2024 at 17:51, duluxoz <duluxoz@gmail.com <mailto:On 
> Fri, Apr 19, 2024 at 17:51, duluxoz <<a href=>> wrote:
>> Hi All,
>>
>> In reference to this page from the Ceph documentation:
>> https://docs.ceph.com/en/latest/cephfs/client-auth/, down the bottom of
>> that page it says that you can run the following commands:
>>
>> ~~~
>> ceph fs authorize a client.x /dir1 rw
>> ceph fs authorize a client.x /dir2 rw
>> ~~~
>>
>> This will allow `client.x` to access both `dir1` and `dir2`.
>>
>> So, having a use case where we need to do this, we are, HOWEVER, getting
>> the following error on running the 2nd command on a Reef 18.2.2 cluster:
>>
>> `Error EINVAL: client.x already has fs capabilities that differ from
>> those supplied. To generate a new auth key for client.x, first remove
>> client.x from configuration files, execute 'ceph auth rm client.x', then
>> execute this command again.`
>>
>> Something we're doing wrong, or is the doco "out of date" (mind you,
>> that's from the "latest" version of the doco, and the "reef" version),
>> or is something else going on?
>>
>> Thanks in advance for the help
>>
>> Cheers
>>
>> Dulux-Oz
>>
>> _______________________________________________
>> ceph-users mailing list -- ceph-users@ceph.io
>> To unsubscribe send an email to ceph-users-leave@ceph.io

--===============3448319174081218887==--


From zac.dover@proton.me Fri Apr 19 08:03:12 2024
From: Zac Dover <zac.dover@proton.me>
To: ceph-users@ceph.io
Subject: [ceph-users] Re: Latest Doco Out Of Date?
Date: Fri, 19 Apr 2024 08:01:35 +0000
Message-ID: <3XJr15pbYlgC-UW2fyC_mv43JpZ-Ki8xKZNpWWuF4VDaemSwyEiynMFnIArGBxf7hUBef5tgS65QUsGJYSRwSV_wRk6KbMvKJxObuil-Zfo=@proton.me>
In-Reply-To: <377ffc01-74ab-491b-b369-e9adbb9bef29@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2201118156018348666=="

--===============2201118156018348666==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I think I understand, after more thought. The second command is expected to w=
ork after the first.

I will ask the cephfs team when they wake up.

Zac Dover
Upstream Docs
Ceph Foundation

On Fri, Apr 19, 2024 at 17:51, duluxoz <[duluxoz@gmail.com](mailto:On Fri, Ap=
r 19, 2024 at 17:51, duluxoz <<a href=3D)> wrote:

> Hi All,
>
> In reference to this page from the Ceph documentation:
> https://docs.ceph.com/en/latest/cephfs/client-auth/, down the bottom of
> that page it says that you can run the following commands:
>
> ~~~
> ceph fs authorize a client.x /dir1 rw
> ceph fs authorize a client.x /dir2 rw
> ~~~
>
> This will allow `client.x` to access both `dir1` and `dir2`.
>
> So, having a use case where we need to do this, we are, HOWEVER, getting
> the following error on running the 2nd command on a Reef 18.2.2 cluster:
>
> `Error EINVAL: client.x already has fs capabilities that differ from
> those supplied. To generate a new auth key for client.x, first remove
> client.x from configuration files, execute 'ceph auth rm client.x', then
> execute this command again.`
>
> Something we're doing wrong, or is the doco "out of date" (mind you,
> that's from the "latest" version of the doco, and the "reef" version),
> or is something else going on?
>
> Thanks in advance for the help
>
> Cheers
>
> Dulux-Oz
>
> _______________________________________________
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-leave@ceph.io

--===============2201118156018348666==--


From duluxoz@gmail.com Fri Apr 19 08:04:39 2024
From: duluxoz <duluxoz@gmail.com>
To: ceph-users@ceph.io
Subject: [ceph-users] Re: Latest Doco Out Of Date?
Date: Fri, 19 Apr 2024 18:03:06 +1000
Message-ID: <0aadad3d-6db3-4d07-af77-8ddb33d488f7@gmail.com>
In-Reply-To: =?utf-8?q?=3C3XJr15pbYlgC-UW2fyC=5Fmv43JpZ-Ki8xKZNpWWuF4VDaemSw?=
 =?utf-8?q?yEiynMFnIArGBxf7hUBef5tgS65QUsGJYSRwSV=5FwRk6KbMvKJxObuil-Zfo=3D?=
 =?utf-8?q?=40proton=2Eme=3E?=
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5648608318041615960=="

--===============5648608318041615960==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Cool!

Thanks for that  :-)

On 19/04/2024 18:01, Zac Dover wrote:
> I think I understand, after more thought. The second command is 
> expected to work after the first.
>
> I will ask the cephfs team when they wake up.
>
> Zac Dover
> Upstream Docs
> Ceph Foundation
>
>
> On Fri, Apr 19, 2024 at 17:51, duluxoz <duluxoz@gmail.com <mailto:On 
> Fri, Apr 19, 2024 at 17:51, duluxoz <<a href=>> wrote:
>> Hi All,
>>
>> In reference to this page from the Ceph documentation:
>> https://docs.ceph.com/en/latest/cephfs/client-auth/, down the bottom of
>> that page it says that you can run the following commands:
>>
>> ~~~
>> ceph fs authorize a client.x /dir1 rw
>> ceph fs authorize a client.x /dir2 rw
>> ~~~
>>
>> This will allow `client.x` to access both `dir1` and `dir2`.
>>
>> So, having a use case where we need to do this, we are, HOWEVER, getting
>> the following error on running the 2nd command on a Reef 18.2.2 cluster:
>>
>> `Error EINVAL: client.x already has fs capabilities that differ from
>> those supplied. To generate a new auth key for client.x, first remove
>> client.x from configuration files, execute 'ceph auth rm client.x', then
>> execute this command again.`
>>
>> Something we're doing wrong, or is the doco "out of date" (mind you,
>> that's from the "latest" version of the doco, and the "reef" version),
>> or is something else going on?
>>
>> Thanks in advance for the help
>>
>> Cheers
>>
>> Dulux-Oz
>>
>> _______________________________________________
>> ceph-users mailing list -- ceph-users@ceph.io
>> To unsubscribe send an email to ceph-users-leave@ceph.io

--===============5648608318041615960==--


From duluxoz@gmail.com Wed Apr 24 04:10:44 2024
From: duluxoz <duluxoz@gmail.com>
To: ceph-users@ceph.io
Subject: [ceph-users] Re: Latest Doco Out Of Date?
Date: Wed, 24 Apr 2024 14:10:32 +1000
Message-ID: <25f973f8-e473-45e2-9ef6-e743a54f5f40@gmail.com>
In-Reply-To: <0aadad3d-6db3-4d07-af77-8ddb33d488f7@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1034330881801470802=="

--===============1034330881801470802==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hi Zac,

Any movement on this? We really need to come up with an answer/solution 
- thanks

Dulux-Oz

On 19/04/2024 18:03, duluxoz wrote:
>
> Cool!
>
> Thanks for that  :-)
>
> On 19/04/2024 18:01, Zac Dover wrote:
>> I think I understand, after more thought. The second command is 
>> expected to work after the first.
>>
>> I will ask the cephfs team when they wake up.
>>
>> Zac Dover
>> Upstream Docs
>> Ceph Foundation
>>
>>
>> On Fri, Apr 19, 2024 at 17:51, duluxoz <duluxoz@gmail.com <mailto:On 
>> Fri, Apr 19, 2024 at 17:51, duluxoz <<a href=>> wrote:
>>> Hi All,
>>>
>>> In reference to this page from the Ceph documentation:
>>> https://docs.ceph.com/en/latest/cephfs/client-auth/, down the bottom of
>>> that page it says that you can run the following commands:
>>>
>>> ~~~
>>> ceph fs authorize a client.x /dir1 rw
>>> ceph fs authorize a client.x /dir2 rw
>>> ~~~
>>>
>>> This will allow `client.x` to access both `dir1` and `dir2`.
>>>
>>> So, having a use case where we need to do this, we are, HOWEVER, getting
>>> the following error on running the 2nd command on a Reef 18.2.2 cluster:
>>>
>>> `Error EINVAL: client.x already has fs capabilities that differ from
>>> those supplied. To generate a new auth key for client.x, first remove
>>> client.x from configuration files, execute 'ceph auth rm client.x', then
>>> execute this command again.`
>>>
>>> Something we're doing wrong, or is the doco "out of date" (mind you,
>>> that's from the "latest" version of the doco, and the "reef" version),
>>> or is something else going on?
>>>
>>> Thanks in advance for the help
>>>
>>> Cheers
>>>
>>> Dulux-Oz
>>>
>>> _______________________________________________
>>> ceph-users mailing list -- ceph-users@ceph.io
>>> To unsubscribe send an email to ceph-users-leave@ceph.io
>

--===============1034330881801470802==--


From zac.dover@proton.me Wed Apr 24 04:32:10 2024
From: Zac Dover <zac.dover@proton.me>
To: ceph-users@ceph.io
Subject: [ceph-users] Re: Latest Doco Out Of Date?
Date: Wed, 24 Apr 2024 04:31:51 +0000
Message-ID: <xcY_AYOFecBrXq-aIZgIbLGEHz3G456MpteJ1-x-PC0sZ1ccrefbItbjHOMkHOaCfLUOXUD88lqoCaxqOHQvFcbfCmZPZ7e5NFDM2axkCMg=@proton.me>
In-Reply-To: <25f973f8-e473-45e2-9ef6-e743a54f5f40@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7326700418362010807=="

--===============7326700418362010807==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

It's in my list of ongoing initiatives. I'll stay up late tonight and ask Ven=
ky directly what's going on in this instance.

Sometime later today, I'll create an issue tracking bug and I'll send it to y=
ou for review. Make sure that I haven't misrepresented this issue.

Zac

On Wednesday, April 24th, 2024 at 2:10 PM, duluxoz <duluxoz@gmail.com> wrote:

> Hi Zac,
>
> Any movement on this? We really need to come up with an answer/solution - t=
hanks
>
> Dulux-Oz
>
> On 19/04/2024 18:03, duluxoz wrote:
>
>> Cool!
>>
>> Thanks for that :-)
>>
>> On 19/04/2024 18:01, Zac Dover wrote:
>>
>>> I think I understand, after more thought. The second command is expected =
to work after the first.
>>>
>>> I will ask the cephfs team when they wake up.
>>>
>>> Zac Dover
>>> Upstream Docs
>>> Ceph Foundation
>>>
>>> On Fri, Apr 19, 2024 at 17:51, duluxoz <[duluxoz@gmail.com](mailto:On Fri=
, Apr 19, 2024 at 17:51, duluxoz <<a href=3D)> wrote:
>>>
>>>> Hi All,
>>>>
>>>> In reference to this page from the Ceph documentation:
>>>> https://docs.ceph.com/en/latest/cephfs/client-auth/, down the bottom of
>>>> that page it says that you can run the following commands:
>>>>
>>>> ~~~
>>>> ceph fs authorize a client.x /dir1 rw
>>>> ceph fs authorize a client.x /dir2 rw
>>>> ~~~
>>>>
>>>> This will allow `client.x` to access both `dir1` and `dir2`.
>>>>
>>>> So, having a use case where we need to do this, we are, HOWEVER, getting
>>>> the following error on running the 2nd command on a Reef 18.2.2 cluster:
>>>>
>>>> `Error EINVAL: client.x already has fs capabilities that differ from
>>>> those supplied. To generate a new auth key for client.x, first remove
>>>> client.x from configuration files, execute 'ceph auth rm client.x', then
>>>> execute this command again.`
>>>>
>>>> Something we're doing wrong, or is the doco "out of date" (mind you,
>>>> that's from the "latest" version of the doco, and the "reef" version),
>>>> or is something else going on?
>>>>
>>>> Thanks in advance for the help
>>>>
>>>> Cheers
>>>>
>>>> Dulux-Oz
>>>>
>>>> _______________________________________________
>>>> ceph-users mailing list -- ceph-users@ceph.io
>>>> To unsubscribe send an email to ceph-users-leave@ceph.io

--===============7326700418362010807==--


From eblock@nde.ag Wed Apr 24 07:02:40 2024
From: Eugen Block <eblock@nde.ag>
To: ceph-users@ceph.io
Subject: [ceph-users] Re: Latest Doco Out Of Date?
Date: Wed, 24 Apr 2024 07:02:21 +0000
Message-ID: <20240424070221.Horde.X3ZkwaAD83PWBonU38mGEDT@webmail.nde.ag>
In-Reply-To: =?utf-8?q?=3CxcY=5FAYOFecBrXq-aIZgIbLGEHz3G456MpteJ1-x-PC0sZ1cc?=
 =?utf-8?q?refbItbjHOMkHOaCfLUOXUD88lqoCaxqOHQvFcbfCmZPZ7e5NFDM2axkCMg=3D=40?=
 =?utf-8?q?proton=2Eme=3E?=
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6515460546116581831=="

--===============6515460546116581831==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,

I believe the docs [2] are okay, running 'ceph fs authorize' will =20
overwrite the existing caps, it will not add more caps to the client:

> Capabilities can be modified by running fs authorize only in the =20
> case when read/write permissions must be changed.

> If a client already has a capability for file-system name a and path =20
> dir1, running fs authorize again for FS name a but path dir2, =20
> instead of modifying the capabilities client already holds, a new =20
> cap for dir2 will be granted

To add more caps you'll need to use the 'ceph auth caps' command, for example:

quincy-1:~ # ceph fs authorize cephfs client.usera /dir1 rw
[client.usera]
         key =3D AQDOrShmk6XhGxAAwz07ngr0JtPSID06RH8lAw=3D=3D

quincy-1:~ # ceph auth get client.usera
[client.usera]
         key =3D AQDOrShmk6XhGxAAwz07ngr0JtPSID06RH8lAw=3D=3D
         caps mds =3D "allow rw fsname=3Dcephfs path=3D/dir1"
         caps mon =3D "allow r fsname=3Dcephfs"
         caps osd =3D "allow rw tag cephfs data=3Dcephfs"

quincy-1:~ # ceph auth caps client.usera mds 'allow rw fsname=3Dcephfs =20
path=3D/dir1, allow rw fsname=3Dcephfs path=3D/dir2' mon 'allow r =20
fsname=3Dcephfs' osd 'allow rw tag cephfs data=3Dcephfs'
updated caps for client.usera

quincy-1:~ # ceph auth get client.usera
[client.usera]
         key =3D AQDOrShmk6XhGxAAwz07ngr0JtPSID06RH8lAw=3D=3D
         caps mds =3D "allow rw fsname=3Dcephfs path=3D/dir1, allow rw =20
fsname=3Dcephfs path=3D/dir2"
         caps mon =3D "allow r fsname=3Dcephfs"
         caps osd =3D "allow rw tag cephfs data=3Dcephfs"

Note that I don't actually have these directories in that cephfs, it's =20
just to demonstrate, so you'll need to make sure your caps actually =20
work.

Thanks,
Eugen

[2] =20
https://docs.ceph.com/en/latest/cephfs/client-auth/#changing-rw-permissions-i=
n-caps


Zitat von Zac Dover <zac.dover@proton.me>:

> It's in my list of ongoing initiatives. I'll stay up late tonight =20
> and ask Venky directly what's going on in this instance.
>
> Sometime later today, I'll create an issue tracking bug and I'll =20
> send it to you for review. Make sure that I haven't misrepresented =20
> this issue.
>
> Zac
>
> On Wednesday, April 24th, 2024 at 2:10 PM, duluxoz <duluxoz@gmail.com> wrot=
e:
>
>> Hi Zac,
>>
>> Any movement on this? We really need to come up with an =20
>> answer/solution - thanks
>>
>> Dulux-Oz
>>
>> On 19/04/2024 18:03, duluxoz wrote:
>>
>>> Cool!
>>>
>>> Thanks for that :-)
>>>
>>> On 19/04/2024 18:01, Zac Dover wrote:
>>>
>>>> I think I understand, after more thought. The second command is =20
>>>> expected to work after the first.
>>>>
>>>> I will ask the cephfs team when they wake up.
>>>>
>>>> Zac Dover
>>>> Upstream Docs
>>>> Ceph Foundation
>>>>
>>>> On Fri, Apr 19, 2024 at 17:51, duluxoz =20
>>>> <[duluxoz@gmail.com](mailto:On Fri, Apr 19, 2024 at 17:51, =20
>>>> duluxoz <<a href=3D)> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> In reference to this page from the Ceph documentation:
>>>>> https://docs.ceph.com/en/latest/cephfs/client-auth/, down the bottom of
>>>>> that page it says that you can run the following commands:
>>>>>
>>>>> ~~~
>>>>> ceph fs authorize a client.x /dir1 rw
>>>>> ceph fs authorize a client.x /dir2 rw
>>>>> ~~~
>>>>>
>>>>> This will allow `client.x` to access both `dir1` and `dir2`.
>>>>>
>>>>> So, having a use case where we need to do this, we are, HOWEVER, getting
>>>>> the following error on running the 2nd command on a Reef 18.2.2 cluster:
>>>>>
>>>>> `Error EINVAL: client.x already has fs capabilities that differ from
>>>>> those supplied. To generate a new auth key for client.x, first remove
>>>>> client.x from configuration files, execute 'ceph auth rm client.x', then
>>>>> execute this command again.`
>>>>>
>>>>> Something we're doing wrong, or is the doco "out of date" (mind you,
>>>>> that's from the "latest" version of the doco, and the "reef" version),
>>>>> or is something else going on?
>>>>>
>>>>> Thanks in advance for the help
>>>>>
>>>>> Cheers
>>>>>
>>>>> Dulux-Oz
>>>>>
>>>>> _______________________________________________
>>>>> ceph-users mailing list -- ceph-users@ceph.io
>>>>> To unsubscribe send an email to ceph-users-leave@ceph.io
> _______________________________________________
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-leave@ceph.io



--===============6515460546116581831==--


From frans@dtu.dk Wed Apr 24 07:33:31 2024
From: Frank Schilder <frans@dtu.dk>
To: ceph-users@ceph.io
Subject: [ceph-users] Re: Latest Doco Out Of Date?
Date: Wed, 24 Apr 2024 07:33:18 +0000
Message-ID: <DB9P192MB1850126CCDF5E7C795443520D6102@DB9P192MB1850.EURP192.PROD.OUTLOOK.COM>
In-Reply-To: <20240424070221.Horde.X3ZkwaAD83PWBonU38mGEDT@webmail.nde.ag>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4764403470458994817=="

--===============4764403470458994817==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Eugen,

I would ask for a slight change here:

> If a client already has a capability for file-system name a and path
> dir1, running fs authorize again for FS name a but path dir2,
> instead of modifying the capabilities client already holds, a new
> cap for dir2 will be granted

The formulation "a new cap for dir2 will be granted" is very misleading. I wo=
uld also read it as that the new cap is in addition to the already existing c=
ap. I tried to modify caps with fs authorize as well in the past, because it =
will set caps using pool tags and the docu sounded like it will allow to modi=
fy caps. In my case, I got the same error and thought that its implementation=
 is buggy and did it with the authtool.

To be honest, when I look at the command sequence

ceph fs authorize a client.x /dir1 rw
ceph fs authorize a client.x /dir2 rw

and it goes through without error, I would expect the client to have both per=
missions as a result - no matter what the documentation says. There is no "re=
voke caps" instruction anywhere. Revoking caps in this way is a really danger=
ous side effect and telling people to read the documentation about a command =
that should follow how other linux tools manage permissions is not the best a=
nswer. There is something called parallelism in software engineering and this=
 command line syntax violates this in a highly un-intuitive way. The intuitio=
n of the syntax clearly is that it *adds* capabilities, its incremental.

A command like this should follow how existing linux tools work so that conte=
xt switching will be easier for admins. Here, the choice of the term "authori=
ze" seems to be unlucky. A more explicit command that follows setfacl a bit c=
ould be

ceph fs caps set a client.x /dir1 rw
ceph fs caps modify a client.x /dir2 rw

or even more parallel

ceph fs setcaps a client.x /dir1 rw
ceph fs setcaps -m a client.x /dir2 rw

Such parallel syntax will not only avoid the reported confusion but also make=
 it possible to implement a modify operation in the future without breaking s=
tuff. And you can save time on the documentation, because it works like other=
 stuff.

Best regards,
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Frank Schilder
AIT Ris=C3=B8 Campus
Bygning 109, rum S14

________________________________________
From: Eugen Block <eblock@nde.ag>
Sent: Wednesday, April 24, 2024 9:02 AM
To: ceph-users@ceph.io
Subject: [ceph-users] Re: Latest Doco Out Of Date?

Hi,

I believe the docs [2] are okay, running 'ceph fs authorize' will
overwrite the existing caps, it will not add more caps to the client:

> Capabilities can be modified by running fs authorize only in the
> case when read/write permissions must be changed.

> If a client already has a capability for file-system name a and path
> dir1, running fs authorize again for FS name a but path dir2,
> instead of modifying the capabilities client already holds, a new
> cap for dir2 will be granted

To add more caps you'll need to use the 'ceph auth caps' command, for example:

quincy-1:~ # ceph fs authorize cephfs client.usera /dir1 rw
[client.usera]
         key =3D AQDOrShmk6XhGxAAwz07ngr0JtPSID06RH8lAw=3D=3D

quincy-1:~ # ceph auth get client.usera
[client.usera]
         key =3D AQDOrShmk6XhGxAAwz07ngr0JtPSID06RH8lAw=3D=3D
         caps mds =3D "allow rw fsname=3Dcephfs path=3D/dir1"
         caps mon =3D "allow r fsname=3Dcephfs"
         caps osd =3D "allow rw tag cephfs data=3Dcephfs"

quincy-1:~ # ceph auth caps client.usera mds 'allow rw fsname=3Dcephfs
path=3D/dir1, allow rw fsname=3Dcephfs path=3D/dir2' mon 'allow r
fsname=3Dcephfs' osd 'allow rw tag cephfs data=3Dcephfs'
updated caps for client.usera

quincy-1:~ # ceph auth get client.usera
[client.usera]
         key =3D AQDOrShmk6XhGxAAwz07ngr0JtPSID06RH8lAw=3D=3D
         caps mds =3D "allow rw fsname=3Dcephfs path=3D/dir1, allow rw
fsname=3Dcephfs path=3D/dir2"
         caps mon =3D "allow r fsname=3Dcephfs"
         caps osd =3D "allow rw tag cephfs data=3Dcephfs"

Note that I don't actually have these directories in that cephfs, it's
just to demonstrate, so you'll need to make sure your caps actually
work.

Thanks,
Eugen

[2]
https://docs.ceph.com/en/latest/cephfs/client-auth/#changing-rw-permissions-i=
n-caps


Zitat von Zac Dover <zac.dover@proton.me>:

> It's in my list of ongoing initiatives. I'll stay up late tonight
> and ask Venky directly what's going on in this instance.
>
> Sometime later today, I'll create an issue tracking bug and I'll
> send it to you for review. Make sure that I haven't misrepresented
> this issue.
>
> Zac
>
> On Wednesday, April 24th, 2024 at 2:10 PM, duluxoz <duluxoz@gmail.com> wrot=
e:
>
>> Hi Zac,
>>
>> Any movement on this? We really need to come up with an
>> answer/solution - thanks
>>
>> Dulux-Oz
>>
>> On 19/04/2024 18:03, duluxoz wrote:
>>
>>> Cool!
>>>
>>> Thanks for that :-)
>>>
>>> On 19/04/2024 18:01, Zac Dover wrote:
>>>
>>>> I think I understand, after more thought. The second command is
>>>> expected to work after the first.
>>>>
>>>> I will ask the cephfs team when they wake up.
>>>>
>>>> Zac Dover
>>>> Upstream Docs
>>>> Ceph Foundation
>>>>
>>>> On Fri, Apr 19, 2024 at 17:51, duluxoz
>>>> <[duluxoz@gmail.com](mailto:On Fri, Apr 19, 2024 at 17:51,
>>>> duluxoz <<a href=3D)> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> In reference to this page from the Ceph documentation:
>>>>> https://docs.ceph.com/en/latest/cephfs/client-auth/, down the bottom of
>>>>> that page it says that you can run the following commands:
>>>>>
>>>>> ~~~
>>>>> ceph fs authorize a client.x /dir1 rw
>>>>> ceph fs authorize a client.x /dir2 rw
>>>>> ~~~
>>>>>
>>>>> This will allow `client.x` to access both `dir1` and `dir2`.
>>>>>
>>>>> So, having a use case where we need to do this, we are, HOWEVER, getting
>>>>> the following error on running the 2nd command on a Reef 18.2.2 cluster:
>>>>>
>>>>> `Error EINVAL: client.x already has fs capabilities that differ from
>>>>> those supplied. To generate a new auth key for client.x, first remove
>>>>> client.x from configuration files, execute 'ceph auth rm client.x', then
>>>>> execute this command again.`
>>>>>
>>>>> Something we're doing wrong, or is the doco "out of date" (mind you,
>>>>> that's from the "latest" version of the doco, and the "reef" version),
>>>>> or is something else going on?
>>>>>
>>>>> Thanks in advance for the help
>>>>>
>>>>> Cheers
>>>>>
>>>>> Dulux-Oz
>>>>>
>>>>> _______________________________________________
>>>>> ceph-users mailing list -- ceph-users@ceph.io
>>>>> To unsubscribe send an email to ceph-users-leave@ceph.io
> _______________________________________________
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-leave@ceph.io


_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-leave@ceph.io

--===============4764403470458994817==--


From eblock@nde.ag Wed Apr 24 07:50:49 2024
From: Eugen Block <eblock@nde.ag>
To: ceph-users@ceph.io
Subject: [ceph-users] Re: Latest Doco Out Of Date?
Date: Wed, 24 Apr 2024 07:50:34 +0000
Message-ID: <20240424075034.Horde.uvlz11ZCRos6OMHZC4o79WG@webmail.nde.ag>
In-Reply-To: =?utf-8?q?=3CDB9P192MB1850126CCDF5E7C795443520D6102=40DB9P192MB?=
 =?utf-8?q?1850=2EEURP192=2EPROD=2EOUTLOOK=2ECOM=3E?=
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3688523075479226285=="

--===============3688523075479226285==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,

I fully agree that there should be a smoother way to update client =20
caps. But regarding the misleading terms, the docs do mention:

> This is because the command fs authorize becomes ambiguous

So they are aware of the current state, but I don't know if there's =20
any work in progress to improve the client authorization.

Thanks,
Eugen

Zitat von Frank Schilder <frans@dtu.dk>:

> Hi Eugen,
>
> I would ask for a slight change here:
>
>> If a client already has a capability for file-system name a and path
>> dir1, running fs authorize again for FS name a but path dir2,
>> instead of modifying the capabilities client already holds, a new
>> cap for dir2 will be granted
>
> The formulation "a new cap for dir2 will be granted" is very =20
> misleading. I would also read it as that the new cap is in addition =20
> to the already existing cap. I tried to modify caps with fs =20
> authorize as well in the past, because it will set caps using pool =20
> tags and the docu sounded like it will allow to modify caps. In my =20
> case, I got the same error and thought that its implementation is =20
> buggy and did it with the authtool.
>
> To be honest, when I look at the command sequence
>
> ceph fs authorize a client.x /dir1 rw
> ceph fs authorize a client.x /dir2 rw
>
> and it goes through without error, I would expect the client to have =20
> both permissions as a result - no matter what the documentation =20
> says. There is no "revoke caps" instruction anywhere. Revoking caps =20
> in this way is a really dangerous side effect and telling people to =20
> read the documentation about a command that should follow how other =20
> linux tools manage permissions is not the best answer. There is =20
> something called parallelism in software engineering and this =20
> command line syntax violates this in a highly un-intuitive way. The =20
> intuition of the syntax clearly is that it *adds* capabilities, its =20
> incremental.
>
> A command like this should follow how existing linux tools work so =20
> that context switching will be easier for admins. Here, the choice =20
> of the term "authorize" seems to be unlucky. A more explicit command =20
> that follows setfacl a bit could be
>
> ceph fs caps set a client.x /dir1 rw
> ceph fs caps modify a client.x /dir2 rw
>
> or even more parallel
>
> ceph fs setcaps a client.x /dir1 rw
> ceph fs setcaps -m a client.x /dir2 rw
>
> Such parallel syntax will not only avoid the reported confusion but =20
> also make it possible to implement a modify operation in the future =20
> without breaking stuff. And you can save time on the documentation, =20
> because it works like other stuff.
>
> Best regards,
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Frank Schilder
> AIT Ris=C3=B8 Campus
> Bygning 109, rum S14
>
> ________________________________________
> From: Eugen Block <eblock@nde.ag>
> Sent: Wednesday, April 24, 2024 9:02 AM
> To: ceph-users@ceph.io
> Subject: [ceph-users] Re: Latest Doco Out Of Date?
>
> Hi,
>
> I believe the docs [2] are okay, running 'ceph fs authorize' will
> overwrite the existing caps, it will not add more caps to the client:
>
>> Capabilities can be modified by running fs authorize only in the
>> case when read/write permissions must be changed.
>
>> If a client already has a capability for file-system name a and path
>> dir1, running fs authorize again for FS name a but path dir2,
>> instead of modifying the capabilities client already holds, a new
>> cap for dir2 will be granted
>
> To add more caps you'll need to use the 'ceph auth caps' command, =20
> for example:
>
> quincy-1:~ # ceph fs authorize cephfs client.usera /dir1 rw
> [client.usera]
>          key =3D AQDOrShmk6XhGxAAwz07ngr0JtPSID06RH8lAw=3D=3D
>
> quincy-1:~ # ceph auth get client.usera
> [client.usera]
>          key =3D AQDOrShmk6XhGxAAwz07ngr0JtPSID06RH8lAw=3D=3D
>          caps mds =3D "allow rw fsname=3Dcephfs path=3D/dir1"
>          caps mon =3D "allow r fsname=3Dcephfs"
>          caps osd =3D "allow rw tag cephfs data=3Dcephfs"
>
> quincy-1:~ # ceph auth caps client.usera mds 'allow rw fsname=3Dcephfs
> path=3D/dir1, allow rw fsname=3Dcephfs path=3D/dir2' mon 'allow r
> fsname=3Dcephfs' osd 'allow rw tag cephfs data=3Dcephfs'
> updated caps for client.usera
>
> quincy-1:~ # ceph auth get client.usera
> [client.usera]
>          key =3D AQDOrShmk6XhGxAAwz07ngr0JtPSID06RH8lAw=3D=3D
>          caps mds =3D "allow rw fsname=3Dcephfs path=3D/dir1, allow rw
> fsname=3Dcephfs path=3D/dir2"
>          caps mon =3D "allow r fsname=3Dcephfs"
>          caps osd =3D "allow rw tag cephfs data=3Dcephfs"
>
> Note that I don't actually have these directories in that cephfs, it's
> just to demonstrate, so you'll need to make sure your caps actually
> work.
>
> Thanks,
> Eugen
>
> [2]
> https://docs.ceph.com/en/latest/cephfs/client-auth/#changing-rw-permissions=
-in-caps
>
>
> Zitat von Zac Dover <zac.dover@proton.me>:
>
>> It's in my list of ongoing initiatives. I'll stay up late tonight
>> and ask Venky directly what's going on in this instance.
>>
>> Sometime later today, I'll create an issue tracking bug and I'll
>> send it to you for review. Make sure that I haven't misrepresented
>> this issue.
>>
>> Zac
>>
>> On Wednesday, April 24th, 2024 at 2:10 PM, duluxoz =20
>> <duluxoz@gmail.com> wrote:
>>
>>> Hi Zac,
>>>
>>> Any movement on this? We really need to come up with an
>>> answer/solution - thanks
>>>
>>> Dulux-Oz
>>>
>>> On 19/04/2024 18:03, duluxoz wrote:
>>>
>>>> Cool!
>>>>
>>>> Thanks for that :-)
>>>>
>>>> On 19/04/2024 18:01, Zac Dover wrote:
>>>>
>>>>> I think I understand, after more thought. The second command is
>>>>> expected to work after the first.
>>>>>
>>>>> I will ask the cephfs team when they wake up.
>>>>>
>>>>> Zac Dover
>>>>> Upstream Docs
>>>>> Ceph Foundation
>>>>>
>>>>> On Fri, Apr 19, 2024 at 17:51, duluxoz
>>>>> <[duluxoz@gmail.com](mailto:On Fri, Apr 19, 2024 at 17:51,
>>>>> duluxoz <<a href=3D)> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> In reference to this page from the Ceph documentation:
>>>>>> https://docs.ceph.com/en/latest/cephfs/client-auth/, down the bottom of
>>>>>> that page it says that you can run the following commands:
>>>>>>
>>>>>> ~~~
>>>>>> ceph fs authorize a client.x /dir1 rw
>>>>>> ceph fs authorize a client.x /dir2 rw
>>>>>> ~~~
>>>>>>
>>>>>> This will allow `client.x` to access both `dir1` and `dir2`.
>>>>>>
>>>>>> So, having a use case where we need to do this, we are, HOWEVER, getti=
ng
>>>>>> the following error on running the 2nd command on a Reef 18.2.2 cluste=
r:
>>>>>>
>>>>>> `Error EINVAL: client.x already has fs capabilities that differ from
>>>>>> those supplied. To generate a new auth key for client.x, first remove
>>>>>> client.x from configuration files, execute 'ceph auth rm client.x', th=
en
>>>>>> execute this command again.`
>>>>>>
>>>>>> Something we're doing wrong, or is the doco "out of date" (mind you,
>>>>>> that's from the "latest" version of the doco, and the "reef" version),
>>>>>> or is something else going on?
>>>>>>
>>>>>> Thanks in advance for the help
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Dulux-Oz
>>>>>>
>>>>>> _______________________________________________
>>>>>> ceph-users mailing list -- ceph-users@ceph.io
>>>>>> To unsubscribe send an email to ceph-users-leave@ceph.io
>> _______________________________________________
>> ceph-users mailing list -- ceph-users@ceph.io
>> To unsubscribe send an email to ceph-users-leave@ceph.io
>
>
> _______________________________________________
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-leave@ceph.io



--===============3688523075479226285==--