CLIENTUPDATE(1)

✨ CLIENTUPDATE ✨

okay so bestie, we're looking at clientupdate from the General Commands Manual section 1, and it's genuinely one of the most underrated little utilities in the whole Xymon fam. Let me tell you everything πŸ’–


🌸 NAME 🌸

clientupdate β€” the Xymon client update utility. that's it, that's the girl. πŸ‘‘


πŸŽ€ SYNOPSIS πŸŽ€

clientupdate [options]

πŸ’« DESCRIPTION πŸ’«

so clientupdate is part of the Xymon client, and her whole job β€” her entire main character arc β€” is updating an existing client installation from a central repository of client packages that live on the Xymon server. no cap. πŸ¦‹

here's the vibe of how it goes down: when the Xymon client sends a normal client report to the Xymon server, the server claps back with the section of the client-local.cfg(5) file that's relevant to this client. and tucked inside that response there might be a "clientversion" value. πŸ‘€

so the client takes that clientversion it just got from the server and compares it against the current clientversion installed on the client β€” which it figures out from the contents of the $XYMONHOME/etc/clientversion.cfg file. if those two versions are not identical? boom. clientupdate gets launched to update the client installation. it's giving automatic glow-up ✨


πŸ’… OPTIONS πŸ’…

  • --level β€” report the current clientversion. just a lil status check, she's telling you where she's at 🫢
  • --update=NEWVERSION β€” attempt to update the client to NEWVERSION by fetching this version of the client software from the Xymon server. the glow-up request, fr fr πŸ”₯
  • --reexec β€” used internally during the update process, see OPERATION below. lowkey mysterious, don't worry about it πŸ’œ
  • --remove-self β€” used internally during the update process. this option causes the running clientupdate utility to delete itself 😭 β€” it's used during the update to purge a temporary copy of the clientupdate utility that's installed in $XYMONTMP. she said "my work here is done" and evaporated πŸ’€

🌈 USING CLIENTUPDATE IN XYMON 🌈

so if you wanna manage updating clients without having to logon to each server one by one (which, no, we are not doing that in this economy), you use the clientupdate utility. here's how you set up the release of a new client version, step by step, bestie:

🌟 Create the new client

set up the new client $XYMONHOME directory β€” e.g. by copying an existing client installation to an empty directory and modifying it for your needs. pro tip: it is a good idea to delete all files in the tmp/ and logs/ directories, since there's literally no need to copy those over to all of the clients. πŸ™ˆ

pay attention to the etc/ files, and make sure they're suitable for the systems where you wanna deploy this new client. you can add files β€” e.g. extension scripts in the ext/ directory β€” but heads up: the clientupdate utility cannot delete or rename files. so plan accordingly, she has limits πŸ’…

🌟 Package the client

when your new client software is ready, create a tar-file of the new client. all files in the tar archive must have file names relative to the clients' $XYMONHOME (usually, ~xymon/client/). save the tar file on the Xymon server in ~xymon/server/download/somefile.tar. don't compress it. πŸš«πŸ—œοΈ

it's recommended that you use some sort of operating-system and version-numbering scheme for the filename, but honestly you can choose whatever filename suits you β€” the only requirement is that it must end with ".tar". and the part of the filename preceding ".tar" is what Xymon will use as the "clientversion" ID. iconic naming convention honestly ⭐

🌟 Configure which hosts receive the new client

in the client-local.cfg(5) file, you must now setup a clientversion:ID line where the ID matches the filename you used for the tar-file. so if you've packaged the new client into the file linux.v2.tar, then the corresponding entry in client-local.cfg would be clientversion:linux.v2. see how that works? matchy matchy πŸŽ€

🌟 Wait for xymond to reload client-local.cfg

xymond will automatically reload the client-local.cfg file after at most 10 minutes. if you want to force an immediate reload, send a SIGHUP signal to the xymond process. impatient queen behavior, we support it πŸ‘‘

🌟 Wait for the client to update

the next time the client contacts the Xymon server to send the client data, it'll notice the new clientversion setting in client-local.cfg, and will run clientupdate to install the new client software. so when the client runs the next time, it'll use the new client software. and that's the whole pipeline, slay ✨


πŸ¦‹ OPERATION πŸ¦‹

clientupdate runs in two steps:

πŸ’œ Re-exec step

the first step is when clientupdate is first invoked from the xymonclient.sh script with the "--re-exec" option. this step copies the clientupdate program from $XYMONHOME/bin/ to a temporary file in the $XYMONTMP directory. this is to avoid conflicts when the update procedure installs a new version of the clientupdate utility itself. upon completion of this step, the clientupdate utility automatically launches the next step by running the program from the file in $XYMONTMP. she's cloning herself, it's giving sci-fi 🧚

πŸ’œ Update step

the second step downloads the new client software from the Xymon server. the new software must be packed into a tar file, which clientupdate then unpacks into the $XYMONHOME directory. unwrap the gift, bestie 🎁


πŸ“ ENVIRONMENT VARIABLES πŸ“

clientupdate uses several of the standard Xymon environment variables, including XYMONHOME and XYMONTMP. those two are the ones carrying the whole operation ngl πŸ’–


⭐ SEE ALSO ⭐

xymon(7), xymon(1), client-local.cfg(5)


and that's the whole page, bestie!! this one's from Xymon, Version 4.3.30: 4 Sep 2019 β€” vintage but still serving πŸ’…βœ¨πŸ«Ά

πŸ“¦ where this page comes from