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 followinf command:
[[email protected] /]$ sudo vi /etc/yum.repos.d/centos-base.repo Password:
Add the following lines to the repository file:
[base] name=CentOS-5 - Base baseurl=http://mirror.centos.org/centos/5/os/x86_64/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5 [update] name=CentOS-5 - Updates baseurl=http://mirror.centos.org/centos/5/updates/x86_64/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
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:
[[email protected] /]$ 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 ==================================================================================== Installing: 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 Complete! [[email protected] /]$
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”.
[[email protected] /]$sudo rsync -r [email protected]:/var/www/html/repo/* /var/www.html/repo The authenticity of host '192.168.5.57 (192.168.5.57)' 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 '192.168.5.57' (RSA) to the list of known hosts. [email protected]'s password: [[email protected] /]$
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:
[[email protected] 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 update-from-esxi4.1-4.1_update01.zip [[email protected] repo]$
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™