GFSERVICE(1)

GFSERVICE(1) πŸ’…

okay bestie, welcome to the Gfarm corner of the manual universe β€” this is gfservice, and she is that girl. ✨


✨ NAME ✨

gfservice β€” control Gfarm servers from a remote host 🫢


✨ SYNOPSIS ✨

gfservice [options] sub-command [host-id] [argument ...]

✨ DESCRIPTION ✨

so basically, gfservice is the little utility Gfarm admins use to boss around servers (gfmd, gfsd and PostgreSQL) on remote hosts. OpenLDAP is not supported currently β€” like, she's just not doing that rn, okay? πŸ™ˆ

what she can do: start, stop, set up (she runs config-gfarm and config-gfsd for you) and clean up the servers. lowkey iconic, highkey useful. πŸ’–

a sample command line looks like this:

gfservice start-gfmd gfmd2

where start-gfmd is a sub-command and gfmd2 is a host-id respectively. so when you run that, gfservice tries to start gfmd on the host named gfmd2. to point at a remote server host, gfservice uses a host-id instead of a hostname β€” yes bestie, they're different things, keep up πŸ’….

all the host-ids (gfmd1, gfmd2, and so on) live in a configuration file of gfservice. here's a lil example of that configuration file:

gfmd1=metadb1.example.com
gfmd1_CONFIG_GFARM_OPTIONS="-A $LOGNAME -X"
gfmd2=metadb2.example.com
gfmd2_CONFIG_GFARM_OPTIONS="-A $LOGNAME -X"

gfsd1=spool1.example.com
gfsd2=spool2.example.com

now, how does gfservice decide which config file to read? she follows these procedures, in order:

  1. if the -f file option is specified, she reads that file. periodt.
  2. otherwise, if the environment variable GFSERVICE_CONF is defined and not empty, she reads that file.
  3. otherwise, she reads $HOME/.gfservice.

if gfservice fails to read a configuration file, she prints an error message and exits immediately β€” no vibes, no waiting. 😭

⚠️ heads up: the configuration file itself is a Bourne-shell script, and gfservice includes (exactly to say, evaluates) the file. so like… she's running it, bestie. see gfservice.conf(5) for more details about the configuration file.

gfservice uses SSH (Secure Shell) to connect with a remote host. and since she may execute ssh several times during a sub-command operation, it is recommended to use an SSH agent (e.g. ssh-agent of OpenSSH) or an authentication key with an empty passphrase, so you're not typing your passphrase every single time. imagine. πŸ’€

in addition to SSH, gfservice uses Sudo to get root privilege on the remote host. please add a line like the one below to the sudoers file (Sudo's configuration file) on each remote host:

user ALL=(root, _gfarmfs, _gfarmmd) NOPASSWD: gfservice-agent

where user is an user name who executes gfservice. the NOPASSWD option is not mandatory, but sudo may ask you for a password several times if you omit it. (and by "may" we mean "will", and by "several" we mean "you will be typing forever". 😭)

since gfservice executes an agent command named gfservice-agent on the remote host using SSH and Sudo, the gfservice-agent command must have been installed on all hosts you want to operate using gfservice. no agent, no service, that's the rule. 🌸

oh and β€” gfservice has a plug-in system so that user can add new sub-commands. see the "PLUG-IN SYSTEM" section of this man page for more details. yes she's extensible, she contains multitudes. πŸ’–


✨ OPTIONS ✨

  • -d β€” print debug information. gfservice passes this option to gfservice-agent so that also gfservice-agent outputs debug information. double the debug, double the fun. πŸ”₯
  • -f file β€” read configuration from file instead of the default.
  • -t time β€” set operation timeout in time seconds. when gfservice tries to start or stop a server program (gfmd, gfsd or a backend database), she waits until the operation is complete or the time interval is elapsed. if "no" is specified as time, timeout never occurs. the default value is "no". (so by default she's patient. very demure. very mindful. πŸŽ€)
  • -k β€” when this option is specified with sub-command config-gfarm or config-gfarm-master, gfservice creates a shared secret key files using gfkey command. πŸ”‘

✨ SUB-COMMANDS FOR GFMD ✨

the followings are sub-commands which operate gfmd. and listen β€” the given host-id argument must be "gfmdn" (gfmd1, gfmd2, ...). otherwise gfservice reports an error and exits immediately. she is not flexible about this. she is not going to figure it out for you. 😀

  • backend-db-status host-id β€” exit with an exit code 0, if a backend database is currently running. otherwise exits with 1.
  • gfmd-status host-id β€” exit with an exit code 0, if gfmd is currently running. otherwise exits with 1.
  • start-backend-db host-id β€” start a backend database if it is not running currently.
  • start-gfmd host-id β€” start gfmd if it is not running currently.
  • start-gfmd-master host-id β€” an alias of "start-gfmd" sub-command.
  • start-gfmd-slave host-id β€” this sub-command is the same as "start-gfmd", but -S option is added to gfmd.
  • start-gfarm host-id β€” start a backend database and gfmd if they are not running currently.
  • start-gfarm-master host-id β€” an alias of "start-gfarm" sub-command.
  • start-gfarm-slave host-id β€” this sub-command is the same as "start-gfarm", but -S option is added to gfmd.
  • stop-backend-db host-id β€” stop a backend database if it is running currently.
  • stop-gfmd host-id β€” stop gfmd if it is running currently.
  • stop-gfarm host-id β€” stop gfmd and a backend database if they are running currently.
  • kill-gfmd host-id β€” kill gfmd (send SIGKILL) if it is running currently. yeah, she said what she said. πŸ’€
  • restart-backend-db host-id β€” perform "stop-backend-db" and "start-backend-db" sub-commands successively.
  • restart-gfmd host-id β€” perform "stop-gfmd" and "start-gfmd" sub-commands successively.
  • restart-gfmd-master host-id β€” an alias of "restart-gfmd" sub-command.
  • restart-gfmd-slave host-id β€” perform "stop-gfmd" and "start-gfmd-slave" sub-commands successively.
  • restart-gfarm host-id β€” perform "stop-gfarm" and "start-gfarm" sub-commands successively.
  • restart-gfarm-master host-id β€” an alias of "restart-gfarm" sub-command.
  • restart-gfarm-slave host-id β€” perform "stop-gfarm" and "start-gfarm-slave" sub-commands successively.
  • promote host-id β€” promote gfmd from a slave to a master. glow up moment fr fr πŸ‘‘
  • promote-gfmd host-id β€” an alias of "promote" sub-command.
  • set-gfmd-conf host-id directive value β€” add
directive value

line to gfmd.conf file on the remote host. if gfmd.conf already has a directive line, gfservice deletes it and then add a new line. out with the old, in with the new ✨

  • set-gfsd-conf host-id directive value β€” add
directive value

line to gfsd.conf file on the remote host. if gfsd.conf already has a directive line, gfservice deletes it and then add a new line.

  • unset-gfmd-conf host-id directive β€” delete a directive line in gfmd.conf file on the remote host. if gfmd.conf file doesn't contain directive line, the file is unchanged.
  • unset-gfsd-conf host-id directive β€” delete a directive line in gfsd.conf file on the remote host. if gfsd.conf file doesn't contain directive line, the file is unchanged.
  • backup-backend-db β€” backup a backend database on the remote host and output the backup data to standard out. πŸŽ€
  • backup-gfmd-conf host-id β€” output gfmd.conf file on the remote host to standard out.
  • backup-gfsd-conf host-id β€” output gfsd.conf file on the remote host to standard out. this sub-command can be worked only when the remote host is configured in the private mode.
  • backup-usermap host-id β€” output usermap file on the remote host to standard out. this sub-command can be worked only when the remote host is configured in the private mode.
  • restore-backend-db host-id β€” restore a backend database on the remote host. the backup data are read from standard in.
  • restore-gfmd-conf host-id β€” recover gfmd.conf file on the remote host. gfservice reads a backup of gfmd.conf from standard in.
  • restore-gfsd-conf host-id β€” recover gfsd.conf file on the remote host. gfservice reads a backup of gfsd.conf from standard in. this sub-command can be worked only when the remote host is configured in the private mode.
  • restore-usermap host-id β€” recover usermap file on the remote host. gfservice reads a backup of usermap from standard in. this sub-command can be worked only when the remote host is configured in the private mode.
  • config-gfarm host-id β€” execute config-gfarm command on the remote host. if "gfmdn_CONFIG_GFARM_OPTIONS" variable is declared in the configuration file of gfservice, its value is passed to config-gfarm command as options. don't use this sub-command when you want to enable replication of gfmd. instead, use "config-gfarm-master" or "config-gfarm-slave" sub-command in that case. if -k option is specified, gfservice also creates a shared secret key files onto the gfmd host, using gfkey command. πŸ”‘
  • config-gfarm-master host-id β€” this sub-command is the same as config-gfarm but gfmd replication is enabled automatically.
  • config-gfarm-slave host-id master-host-id β€” this sub-command is the same as config-gfarm but gfmd replication is enabled automatically and the remote gfmd host is configured as a slave of master-host-id. then gfservice registers the slave host to a server list using gfmdhost command. gfservice also adds the slave host to metadb_server_list directive in gfarm2.conf file on the master gfmd host and distribute the updated gfarm2.conf file to all hosts defined in the configuration file. it also updates gfsd.conf file and distributes it to all gfmd and gfsd hosts, if "gfmdn_PRIVATE_MODE" variable is set to "true". if the value of the variable "gfmdn_AUTH_TYPE" is "sharedsecret", it also copies a shared key file from the master gfmd to the slave gfmd host. she does a lot, okay? she's carrying this whole operation. πŸ’…
  • unconfig-gfarm host-id β€” execute "stop-gfarm" sub-command and then delete all files and directories created by gfmd and a backend database. if you want to unconfigure a slave gfmd, use "unconfig-gfarm-slave" sub-command instead.
  • unconfig-gfarm-master host-id β€” an alias of "unconfig-gfarm" sub-command.
  • unconfig-gfarm-slave host-id master-host-id β€” this sub-command is the same as "unconfig-gfarm", but gfservice does some additional works. it also deletes the slave host from a server list using gfmdhost command and from metadb_server_list directive in gfarm2.conf file on all hosts defined in the configuration file. it also updates gfsd.conf file and distributes it to all gfmd and gfsd hosts, if "gfmdn_PRIVATE_MODE" variable is set to "true".

…and bestie, that's literally not even all of it, don't go anywhere πŸ’–

✨ SUB-COMMANDS FOR GFSD ✨

Okay bestie, these ones drive gfsd around πŸ’…. And listen β€” the host-id you hand over must be gfsdn shaped (gfsd1, gfsd2, …). If it's not, gfservice just goes "nope" and exits immediately, no negotiation, no vibe check. 😭

  • gfsd-status host-id β€” exits with code 0 if gfsd is running right this second. If it's not? Exits with 1. That's it, that's the whole personality. ✨
  • start-gfsd β€” starts gfsd, but only if it isn't already running. No double-starting, we're not messy. πŸŽ€
  • stop-gfsd β€” stops gfsd, but only if it is currently running. Considerate. 🫢
  • restart-gfsd host-id β€” does stop-gfsd and then start-gfsd, one right after the other. Glow-up arc, basically. 🌸
  • set-gfsd-conf host-id directive value β€” same as the set-gfsd-conf sub-command for gfmd. πŸ‘‘
  • unset-gfsd-conf host-id directive β€” same as the unset-gfsd-conf sub-command for gfmd.
  • backup-gfsd-conf host-id β€” same as the backup-gfsd-conf sub-command for gfmd.
  • backup-usermap host-id β€” same as the backup-usermap sub-command for gfmd.
  • restore-gfsd-conf host-id β€” same as the restore-gfsd-conf sub-command for gfmd.
  • restore-usermap host-id β€” same as the restore-usermap sub-command for gfmd.
  • config-gfsd host-id β€” runs the config-gfsd command on the remote host. If the variable gfsdn_CONFIG_GFSD_OPTIONS is declared in the config file of gfservice, its value gets passed to the config-gfsd command as options. gfservice also registers that configured remote host as a filesystem node using the gfhost command. And if the value of the variable gfsdn_AUTH_TYPE is sharedsecret, it also copies a shared key file from gfmd1 over to the gfsd host. πŸ”₯
  • unconfig-gfsd host-id β€” runs the stop-gfsd sub-command and then deletes all files and directories that gfsd created. Full clear-out. πŸ’€

πŸ’œ SUB-COMMANDS FOR CLIENT πŸ’œ

Now we're doing client stuff. The host-id here has to be gfmdn (gfmd1, gfmd2, …), gfsdn (gfsd1, gfsd2, …) or clientn (client1, client2, …). Get it wrong and gfservice reports an error and exits immediately. Be so serious. 😀

  • mount host-id directory option... β€” mounts a Gfarm2 filesystem on directory on the remote host. Each option is an option to the gfarm2fs command. 🌈
  • unmount host-id directory β€” unmounts a Gfarm2 filesystem on directory on the remote host.
  • umount host-id directory β€” an alias of the unmount sub-command. Same girl, different name. πŸ’…
  • set-gfarm-conf host-id directive value β€” adds a line
directive value

to the gfarm2.conf file on the remote host. If gfarm2.conf already has a directive line, gfservice deletes it and then adds a new line. Out with the old, in with the new. ✨

  • unset-gfarm-conf host-id directive β€” deletes a directive line in the gfarm2.conf file on the remote host. If the gfarm2.conf file doesn't contain that directive line, the file stays unchanged. No touchy. πŸ™ˆ
  • backup-gfarm-conf host-id β€” outputs the gfarm2.conf file on the remote host to standard out. πŸ“€
  • backup-shared-key host-id β€” outputs a shared secret key file to standard out. πŸ”
  • restore-gfarm-conf host-id β€” recovers the gfarm2.conf file on the remote host. gfservice reads a backup of gfarm2.conf from standard in. πŸ“₯
  • restore-shared-key host-id β€” recovers a shared secret key file on the remote host. gfservice reads a backup of the shared secret key from standard in. πŸ”‘
  • config-client host-id β€” copies the gfarm2.conf file from gfmd1 to the client host. If the value of the variable clientn_AUTH_TYPE is sharedsecret, it also copies a shared key file from gfmd1 to the client host. πŸ¦‹
  • unconfig-client host-id β€” deletes the gfarm2.conf file and a shared secret key file on the remote host.
  • gfcmd host-id command-name command-argument ... β€” executes a Gfarm command on the remote host. πŸŽ€
  • gfcmd-root host-id command-name command-argument ... β€” executes a Gfarm command on the remote host with root privilege. Main character energy, but make it root. πŸ‘‘
  • grid-proxy-init host-id command-argument ... β€” executes the grid-proxy-init command on the remote host. ⭐

🌟 SUB-COMMANDS FOR MULTIPLE HOSTS 🌟

These ones operate on a whole squad of hosts at once. And here's the thing β€” the host-id argument must not be specified. Don't even try it bestie. 🚫

  • start-all β€” starts all backend databases, gfmd servers and gfsd servers. Everybody up! πŸŽ‰
  • stop-all β€” stops all gfsd servers, gfmd servers and backend databases,
  • kill-gfmd-all β€” kills (sends SIGKILL) all gfmd servers. Dramatic? Yes. Necessary? Also yes. πŸ’€
  • restart-all β€” performs the stop-all and start-all sub-commands successively.
  • config-all β€” performs config-gfarm-master for gfmd1 and config-gfarm-slave for all other gfmd nodes. Then, performs config-gfsd for all gfds nodes. Finally, performs config-client for all client nodes. It's giving assembly line. 🏭
  • unconfig-all β€” performs unconfig-client for all client nodes. Then, performs unconfig-gfsd for all gfds nodes. Finally, performs unconfig-gfarm for all gfmd nodes. Reverse order, we're dismantling the whole thing. 🧹

🧚 PLUG-IN SYSTEM 🧚

Not me telling you gfservice is literally extensible?? It has a plug-in system so you β€” yes YOU β€” can add new sub-commands. If a given sub-command isn't provided by gfservice, it goes looking for a file with the name of that sub-command under the %%DATADIR%%/gfarm/gfservice directory. iykyk. 🌸

The sub-command file must be written as a Bourne shell script. For a sub-command called name, the sub-command file must have a shell function named subcmd_name, which will be executed from gfservice, and subcmd_name_agent, which will be executed from gfservice-agent. ✨

For the case where a sub-command depends on another user-provided sub-command, the sub-command file for sub-command name must have a shell function named name_depends, which must return a list of sub-commands. That list of sub-commands must be a string which is a space separated list of sub-command names. If the sub-command or its agent does not have dependencies, return an empty string. Similarly, the sub-command file must have a shell function named name_agent_depends, which must return a list of the sub-command's agents. 🫢

Bestie reminder: those function names and that path are exact. Shell function names don't do nicknames. πŸ’…

And that's the whole page, gorgeous. 🌈 This one's from the Gfarm crew, dated 6 Jun 2013, filed under GFSERVICE(1) β€” go forth and configure your cluster, you absolute icon. πŸ’–βœ¨πŸŽ€