Part II: Apple iPads, Apple TVs, Bonjour & AirPlay Across Subnets Using Open-Source Software

In my previous post HERE, I gave a brief description of Apple's implementation of the mDNS protocol which they named "Bonjour". I explained why the protocol does not function in a segmented (subnetted) network and described the open-source solution that we deploy for our clients which is comprised of a free, open-source Gentoo Linux (virtual) server running the open-source implementation of the mDNS protocol called "Avahi."

My goal in this post is to describe in detail exactly how to implement your very own virtual "Bonjour Gateway" in a VMware vSphere environment.

Apple iPads, Apple TVs, Bonjour & AirPlay Across Subnets Using Open-Source Software

As more schools implement wireless networks, BYOD programs, and Apple TVs, they are quickly finding that on properly configured and subnetted networks they are unable to locate their wired Apple TVs with their wireless iPads, iPhones, Andriod devices, etc and therefore are unable to use Apple's "AirPlay" to stream music or videos to their Apple TVs, and are also unable to mirror their iPad's screen to the Apple TVs.

This is because the protocol by which Apple devices announce themselves and locate other Apple devices on a network does not work when these devices are on different subnets.

To find other Apple devices on a network, Apple devices use a protocol called "multicast DNS" (mDNS), and Apple has named their implementation of the mDNS protocol "Bonjour."

AppleTVs and other Apple devices on home networks don't have any problem locating each other. All the devices appear to magically "just work"(TM) together because all the devices are on the same subnet (broadcast domain) and Bonjour works perfectly fine in this type of small, non-routed network.

However, Bonjour is a multicast (broadcast) protocol, and as such does not traverse across routers to other subnets. When Apple devices are on a larger, properly segmented (subnetted) network, Apple devices on one subnet will not be able to locate Apple devices on another subnet.

Generating Basic Bacula Backup Email Summary Reports

Update: 20170408 - A lot of work has been done to this script over the past four years. What started out as a "simple bash shell script" now has a lot of new options. Please use the latest version.

A request was made on the Bacula mailing list for a way to get daily and weekly backup reports. This got me to thinking that such a daily email would be useful.

So, off I went to write a simple bash shell script to generate these reports.

Keep in mind that this is a pretty simple report and it works for our needs. You may wish to modify it to include HTML formatting, additional fields such as StartTime and EndTime, total GB for all jobs, etc.

Encrypted offsite backups on auto-mounted media with Bacula & vchanger

Since backups are the most important process regardless of what industry you are in, it pays to put a lot of thought into creating a reliable, easy-to-use, scalable, and secure backup solution.

Why reliable?
This should be pretty obvious. Without a reliable backup solution that "just works" you can not be 100% sure that you will be able to restore any data at any time, and this clearly a bad thing. Files are lost or accidentally deleted by users and there is no excuse for not being able to restore this data.

Why easy-to-use?
If your backup process is not simple and painless for the end users (eg: the person or persons responsible for rotating the backup media) then sooner or later shortcuts will be taken, steps will be skipped, errors or warnings will be ignored, and you will not have the data you need when disaster strikes - and it will strike, it's just a matter of time.

Why Scalable?
How much data are you backing up today? Tomorrow? Next week, month, year? If you build a backup system to only handle your current needs, it will surely need to be replaced sooner than you'd think. You want to make sure that the backup solution you build will take care of your needs now and will continue to work into the future with minor adjustments rather than needing to be completely replaced in a year or two

Why Secure?
The only thing more important than having good offsite backups of your data is making sure that someone else does not have access to your data. This is where encryption comes in. If your backups are written to an encrypted device (hard drive, tape drive, CDROM, etc) then you can safely transport your backup media on a regular schedule to an off-site location without the fear of your data being compromised.