[Gluster-devel] Gluster CLI for setting options for glusterd.vol

[M. Mohan Kumar]

Vijay Bellur <vbellur at redhat.com> writes:

> On 06/19/2013 09:51 PM, M. Mohan Kumar wrote:
>> Hello,
>>
>> When qemu is invoked by a non-root user with -drive
>> file=gluster://server/volname/imagename option, unprivileged port is
>> used for gluster rpc and by default glusterd and gluster brick process
>> deny the request if the request is from a unprivileged port. The option
>> "rpc-auth-allow-insecure" needs to be enabled in glusterd.vol so that
>> non privileged ports can be used to access Gluster volumes.
>>
>> In a typical environment VDSM might want to enable rpc-auth-allow-insecure
>> option and the administrator has to edit the glusterd.vol manually and
>> restart glusterd process.
>>
>> CLI options available to enable volume specific options to work with
>> unprivileged ports by using gluster volume set <volname> <option>
>> <value>. For example per volume server.allow-insecure option can be
>> enabled so that unprivileged users can mount a GlusterFS volume.
>>
>> But as of now there is no CLI option available to set glusterd.vol
>> options. How about adding a gluster CLI set option to configure
>> glusterd.vol options? Can following CLI command line 'gluster volume set
>> all <glusterd.option> <value>" be used for setting glusterd options?
>> IIUC "all" is a reserved volume name and we can use this reserved name
>> for setting glusterd option.
>
> 'volume set all' is mostly used for options that are applicable to all 
> volumes. Since glusterd options are beyond the scope of a volume, tying 
> them to the peer entity might be a good idea. We can introduce 'peer set 
> all <key> <value>' which sets a particular option on all peers.
>

You mean by 'gluster peer set all rpc-auth-allow-insecure on' will
enable insecured port access to all glusterds in the peer environment?
 
>>
>> IIUC glusterd.info file can be used to store about these parameters
>> similar to how volume specific options are stored in vols/<volname>/info
>> file?
>>
>
> We can persist this in glusterd.vol referred by the respective glusterd 
> instance.

So glusterd.vol is not [re]generated during glusterd init?
>
> -Vijay