Using rsync for Centralized Patch Management in vSphere Environments

In my previous blog post, I outlined how you can use your vMA instances as local file repositories for updates. In this follow-up post, I will take it a step further and utilize rsync to make sure my vMA instances all contain the same set of patches. Rsync is great for this, as it handles fast incremental file transfers, which is a real time and bandwidth saver in my particular scenario.

As mentioned earlier, rsync isn’t included in vMA by default, so we need to install it first. To do this, we need to edit some files inside of vMA. Since vMA is CentOS-based, this means configuring yum repositories, and thankfully, the brilliant William Lam over at virtuallyGhetto has already done the hard work for us. In his post named “Automate Update Manager Operations using vSphere SDK for Perl + VIX + PowerCLI + PowerCLI VUM,” William explains which files to edit to create a valid repository configuration for installation of official packages directly from CentOS.

To create the file, open a terminal and navigate to the correct directory:

“`

sudo nano /etc/yum.repos.d/CentOS-Base.repo

“`

Add the following lines to the repository file:

“`

[rsync]

name=RSYNC Update Repository

baseurl=https://mirror.centos.org/centos/$releasever/os/$basearch/

gpgcheck=0

enabled=1

“`

Exit the vi editor by hitting Esc and entering `:wq` and hit Enter. This saves the file and exits the editor.

Now comes the easy part, actually installing rsync inside vMA. All you have to do is enter the following command:

“`

sudo yum install rsync

“`

The installation starts, and you should see output similar to the following:

“`

Loaded plugins: fastestmirror, priorities

Setting up Install Process

No package rsync available.

No package rsync-libs available.

“`

And there it is, rsync installed inside vMA!

Now that we have rsync installed inside vMA, we need to configure it to fetch the updates from a central vMA instance. Rsync needs to be installed in both ends of the pipe, so if you haven’t already done so, configure your “master vMA” the same way as mentioned above.

Now that “both ends” of the pipe has rsync installed, we can run it from “client vMA” to pull down all the files currently in the repository on the “master vMA”. The command runs for a while, and when it finished, you should see that the current contents of the “master vMA” repository is now located in the “client vMA” repository as well:

“`

sudo rsync -avz –delete /vmware-patches/ master:client

“`

There is a lot more you can do with rsync, like replication files both ways, controlling bandwidth usage, using ssh keys to avoid username/password prompts, something that is required if you want to fully automate this process. I will not cover that, at least not right now, so head over to the rsync site to read up on the documentation for more advanced use cases.

Even if I’ve barely touched the features rsync provides, it is clear that this is a way for admins to centrally manage distribution of vSphere patches to remote locations, even if the bandwidth is low and the latency high. Rsync provides us with ways to overcome the patching issues that you might see in poorly networked environments, and it can certainly help vAdmins keeping their environments patched and current, and that has to be a good thing™.

vNinja.net is the digital home of Christian Mohn and Stine Elise Larsen.