ganesha_conf(8)

💖 ganesha_conf — Ganesha configuration editor 💖

okay bestie, sit down, hydrate, because we're about to edit some Ganesha config together and honestly? it's giving main character energy. this is ganesha_conf, straight out of the System Manager's Manual, and it's the little tool that pokes at your Ganesha configuration file so you don't have to hand-edit it like some kind of medieval scribe. 🎀

---

✨ SYNOPSIS ✨

ganesha_conf set <block-description> [--key1 value1 [--key2 value2]...]
ganesha_conf del <block-description> [--key1 [--key2 ]...]

like. two commands. that's it. set and del. we love a low-effort icon. 💅

---

🌸 DESCRIPTION 🌸

So the set command adds or changes the given key value parameters in the block. And not only that — it will literally create the block for you if the block matching the block description you gave it (peep the BLOCK DESCRIPTION section below, it's right there) isn't in the configuration yet. no cap, it just makes it. ✨

The del command deletes the given keys from the Ganesha configuration block described by the block description. and bestie, listen — if you give it no keys at all, it deletes the entire block itself. she's thorough. 💀

---

🦋 BLOCK DESCRIPTION 🦋

A block description is a list of block names, plus possibly some key value parameters, that together uniquely identify a Ganesha configuration block.

Here's the vibe of the NFS Ganesha configuration file: it contains a list of blocks. Each block starts with a block name followed by a left brace, then a list of key = value; entries. The block may optionally have sub blocks (yes, note the recursive definition, it's giving nesting doll 🪆). Finally, the block ends with a right brace.

Heads up: key = value; entries can come after a sub block as well, but we don't allow this with the ganesha_conf editor! All key value entries should come before any sub blocks. Do not test her. 🙈

An example of a ganesha configuration block:

nfs_core_param {
    Nb_Worker = 256;
    Clustered = TRUE;
    NFS_Protocols = 3,4;
}

Since there should be only one nfs_core_param block, we just need the name of the block to uniquely identify it. So "nfs_core_param" would be its block description! iconic, honestly. 👑

An example of a ganesha configuration block with a couple sub blocks:

log {
    default_log_level = EVENT;
    format {
        date_format = ISO-8601;
        time_format = ISO-8601;
        thread_name = TRUE;
    }
    components {
        all = EVENT;
    }
}

Ganesha configuration should have only one log block as well, so "log" would identify the log block. To identify the format sub block inside the log block, "log format" would be the block description for the above format sub block. Similarly "log components" would be the block description for the above components sub block. it's just spaces separating them, bestie. slay. 🌈

An export block is special in that there can be many export blocks — one for each export. A client block is also special. There can be many client blocks, and they are always sub blocks inside export blocks. The export_id key value uniquely identifies an export block. The clients key value uniquely identifies a client block inside a given export block.

Here are couple export blocks with couple client blocks in them:

export {
    export_id = 1;
    path = /fs1/export1;
    pseudo = /fs1/export1;
    manage_gids = true;
    client {
        clients = 192.168.122.31;
        access_type = RW;
    }
    client {
        clients = *;
        access_type = RO;
    }
}

export {
    export_id = 2;
    path = /fs1/export2;
    pseudo = /fs1/export2;
    manage_gids = true;
    client {
        clients = 192.168.122.31;
        access_type = RW;
    }
    client {
        clients = 192.168.122.32;
        access_type = RO;
    }
}

To identify the correct export block, we need to supply its export_id. For example "export export_id 2" identifies the second export block above. export blocks can be uniquely identified by pseudo or path keys in some environments. One could specify "export path /fs1/export2" to identify the second export block as well. Similarly, a client block needs an additional clients key value to identify the correct client block. For example, "export export_id 2 client clients 192.168.122.31" identifies the first client block in the second export block above! 💅 iykyk.

---

🎀 EXAMPLES 🎀

1. To change number of ganesha worker threads:

ganesha_conf set nfs_core_param --nb_worker 256

2. To change the date and time format of ganesha log messages:

ganesha_conf set log format --date_format ISO-8601 --time_format ISO-8601

3. Create an export and allow client with IP address 192.168.122.31 to be able to do read write and all other clients to do read only:

ganesha_conf set export path /fs1/export2 --export_id 2 --pseudo /fs1/export2 --manage_gids true
ganesha_conf set export path /fs1/export2 client clients 192.168.122.31 --access_type RW
ganesha_conf set export path /fs1/export2 client clients 192.168.122.32 --access_type RO

look at her GO. 🏃♀️💨

---

⭐ NOTES ⭐

ganesha_conf by default uses /etc/ganesha/ganesha.conf file as the configuration file. If your environment uses a different file (or set of files), you can use the CONFFILE environment variable to override the default configuration file. For example, "CONFFILE=/etc/ganesha/ganesha.main.conf ganesha_conf set nfs_core_param --nb_worker 256" will use /etc/ganesha/ganesha.main.conf file for changing the worker threads. 🫶

ganesha_conf can't handle comments within a block at this point. (we know. we're sorry. it's a whole thing. 😭)

Also, heads up fr fr: neither block descriptions nor key value parameters are verified to be valid ganesha configuration blocks or parameter values currently. so she will absolutely let you type nonsense and just... go with it. 💀

---

okay and that's the whole page, bestie, you ate that. this little gem lives in the System Manager's Manual, it's ganesha_conf(8), and it's dated 21 Mar 2017 — vintage but thriving. go forth and edit your config. periodt. 💖✨🎀🦋🌸💅👑🌈⭐