Using rsync to Distribute Patches to a Remote vMA

Published by Christian Mohn · Read in about 4 min (841 words)

I recently posted Using vMA as a local vSphere Patch Repository, where I outlined how you can use your vMA instances as local file repositories for updates.

This post is a continuation of that concept, but this time I’ll 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. So, the premise is that you have one central vMA instance, and one or more remote vMA instances that should pull updates from the centrally located one.

Installing rsync in vMA #

Sadly, rsync isn’t included in vMA by default. To get it installed, 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.

Warning: Do this on your own risk, I have not checked but I think this will fall under the “unsupported” tab at VMware.

Configuring YUM in vMA #

These instructions are pretty much copied from Williams post, but added here for context:

Creating the repository configuration file #

To create the file, in the correct directory, run the followingf command:

[vi-admin@vMA /]$ sudo vi /etc/yum.repos.d/centos-base.repo

Add the following lines to the repository file:

name=CentOS-5 - Base
name=CentOS-5 - Updates

Exit the vi editor by hitting esc and entering :wq and hit enter. That saves the file, and exits the editor.

Installing rsync via yum #

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

[vi-admin@vMA /]$ sudo yum -y install rsync

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

Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
--> Running transaction check
---> Package rsync.x86_64 0:2.6.8-3.1 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

 Package           Arch               Version                Repository        Size
 rsync             x86_64             2.6.8-3.1              base             235 k

Transaction Summary
Install      1 Package(s)
Update       0 Package(s)
Remove       0 Package(s)

Total download size: 235 k
Downloading Packages:
rsync-2.6.8-3.1.x86_64.rp 100% |=========================| 235 kB    00:01
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing     : rsync                                             [1/1]

Installed: rsync.x86_64 0:2.6.8-3.1
[vi-admin@vMA /]$

And there it is, rsync installed inside vMA!

Configuring rsync to fetch upgrades from central 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”.

[vi-admin@vMA /]$sudo rsync -r vi-admin@* /var/www.html/repo
The authenticity of host ' (' can't be established.
RSA key fingerprint is 3f:af:7c:53:5a:15:47:56:b8:25:77:79:14:b2:f5:2f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (RSA) to the list of known hosts.
vi-admin@'s password:
[vi-admin@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:

[vi-admin@vMA repo]$ ls -la
total 210988
drwxr-xr-x 2 root root      4096 Mar  8 18:51 .
drwxr-xr-x 4 root root      4096 Mar  8 18:50 ..
-rw-r--r-- 1 root root         0 Mar  8 18:51 testfile
-rw-r--r-- 1 root root         0 Mar  8 18:51 testfile1
-rw-r--r-- 1 root root         0 Mar  8 18:51 testfile2
-rw-r--r-- 1 root root         0 Mar  8 18:51 testfile3
-rw-r--r-- 1 root root 215820281 Jan 27 19:15
[vi-admin@vMA repo]$

Conclusion #

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 automated 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™

Post last updated on January 2, 2024: Add author

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

The primary focus is on IT architecture and data center technologies like virtualization and related topics, but other content also pops up from time to time.