Managing Flash Player auto-update

Flash Player supports auto-updating itself by periodically checking for new versions of the player on the macromedia.com site. IT administrators can customize the parameters of this update.

The auto-update settings can be configured in two ways:

User settings in Flash Player
mms.cfg file in user's "home" directory
Users can disable the auto-update process or set the periodicity of the checks by using the properties panel in Flash Player. These user-configured auto-update settings are stored in a local shared object.

The second method for configuring the auto-update settings is to create a file named mms.cfg. The mms.cfg file is intended to be configured by an IT administrator and stored on the user's computer. The file is not created by Flash Player installation. You might use a third-party administration tools, such as Microsoft System Management Server, to replicate the configuration file to the user's desktop.

Store the mms.cfg file in the following location, depending on your operating system:
Windows XP/7 %Systemroot%\system32\macromed\flash

Macintosh /Application Support/Macromedia The format of the mms.cfg file is a series of name=value pairs separated by carriage returns. If a parameter is not set in the file, Flash Player assumes the default value. When set, values in this file override the user-configured settings.

The following table describes settings in the mms.cfg file:

AutoUpdateDisable
0 allows auto-update based on user settings.
1 disables auto-update.

AutoUpdateInstallerUrl
String specifies URL as download location for player update.

If this parameter is not set, Flash Player uses the Macromedia server.

AutoUpdateInterval
0 checks for updates every time the player launches.
>0 specifies the minimum number of days between check for updates.

AutoUpdateSettingsUrl
String specifies URL as destination for "Settings..." button in auto-update dialog. If this parameter is not set, Flash Player uses the Macromedia server.

AutoUpdateVersionUrl
Specifies the URL to retrieve XML file containing Flash Player update data. If this parameter is not set, the player uses the Macromedia server.

To disable the auto-update:
Open the mms.cfg file in a text editor.
Add the following auto-update setting:

AutoUpdateDisable=1

Save the mms.cfg file.

Close and restart Flash Player or the browser in which Flash Player is running.

You are not required to remove any other settings so that you can re-enable the auto-update feature and restore your original settings by removing this line (or setting its value to 0).

Disable Java Auto Download

The following article discusses this in more detail :

http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/properties.html

For example, you could try creating a deployment.config file in the folder C:\Windows\Sun\Java\Deployment, which would contain the following line :

deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties
 
and then create a new deployment.properties in the folder C:\Windows\Sun\Java\Deployment which would contain the following lines

deployment.javaws.autodownload=NEVER
deployment.javaws.autodownload.locked=
  

NOTE: Administrators will still be able to update via control panel, and will also be notified of available updates.

Update !

It seems that this still does not prevent the annoying java updater from nagging my users.
The easiest way to disable the updater is to rename the jucheck.exe and jusched.exe located in C:\Program Files (x86)\Common Files\Java\Java Update or C:\Program Files\Common Files\Java\Java Update on a 32bit installation.
 

How to add a manifest to a legacy application.

Copied verbatim from Klaus Bjorn Jensen's blog 

How to add a manifest to a legacy application (which you cannot or will not recompile)

I used mt.exe from Windows SDK

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe"

to add a manifest to an existing legacy exe to make it Run As Administrator (with elevated privileges) on UAC enabled systems (Vista, Win7 , Win 2008 ...). Here's how:

1)Got a legacy exe file named KSDiag.exe

2)In the same folder create a text file named KSDiag.exe.manifest

3)Put the following lines into the text file:

[?xml version="1.0" encoding="UTF-8" standalone="yes"?]

[assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"]

[trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"]

[security]

[requestedPrivileges]

[requestedExecutionLevel

level="requireAdministrator"

uiAccess="False"/]

[/requestedPrivileges]

[/security]

[/trustInfo]

[/assembly]

Replacing [ with LessThan and ] with GreaterThan

4) Run command:

mt.exe /manifest KSDiag.exe.manifest /outputresource:KSDiag.exe;1

(1 for an EXE, 2 for a DLL
mt.exe –manifest MyApp.exe.manifest -outputresource:MyApp.exe;1
or
mt.exe –manifest MyLibrary.dll.manifest -outputresource:MyLibrary.dll;2
See also: http://msdn.microsoft.com/en-us/library/ms235591.aspx
http://msdn.microsoft.com/en-us/library/aa375649(VS.85).aspx )

Now KSDiag.exe has the manifest added to its resource section. On a UAC enabled OS it gets the shield icon and you get the administrator prompt when you try to run it.

Of course if the file was signed to start with you'll have to resign it.

Backup Like a pro with rsync

What's so great about rsync? First, it's designed to speed up file transfer by copying the differences between two files rather than copying an entire file every time. For example, when I'm writing this article, I can make a copy via rsync now and then another copy later. The second (and third, fourth, fifth, etc.) time I copy the file, rsync copies the differences only. That takes far less time, which is especially important when you're doing something like copying a whole directory offsite for daily backup. The first time may take a long time, but the next will only take a few minutes (assuming you don't change that much in the directory on a daily basis).
Another benefit is that rsync can preserve permissions and ownership information, copy symbolic links, and generally is designed to intelligently handle your files.
You shouldn't need to do anything to get rsync installed -- it should be available on almost any Linux distribution by default. If it's not, you should be able to install it from your distribution's package repositories. You will need rsync on both machines if you're copying data to a remote system, of course.
When you're using it to copy files to another host, the rsync utility typically works over a remote shell, such as Secure Shell (SSH) or Remote Shell (RSH). We'll work with SSH in the following examples, because RSH is not secure and you probably don't want to be copying your data using it. It's also possible to connect to a remote host using an rsync daemon, but since SSH is practically ubiquitous these days, there's no need to bother.

Getting to know rsync

The basic syntax for rsync is simple enough -- just run rsync [options] source destination to copy the file or files provided as the source argument to the destination.
So, for example, if you want to copy some files under your home directory to a USB storage device, you might use rsync -a /home/user/dir/ /media/disk/dir/. By the way, "/home/user/dir/" and "/home/usr/dir" are not the same thing to rsync. Without the final slash, rsync will copy the directory in its entirety. With the trailing slash, it will copy the contents of the directory but won't recreate the directory. If you're trying to replicate a directory structure with rsync, you should omit the trailing slash -- for instance, if you're mirroring /var/www on another machine or something like that.
In this example, I included the archive option (-a), which actually combines several rsync options. It combines the recursive and copy symlinks options, preserves group and owner, and generally makes rsync suitable for making archive copies. Note that it doesn't preserve hardlinks; if you want to preserve them, you will need to add the hardlinks option (-H).
Another option you'll probably want to use most of the time is verbose (-v), which tells rsync to report lots of information about what it's doing. You can double and triple up on this option -- so using -v will give you some information, using -vv will give more, and using -vvv will tell you everything that rsync is doing.
rsync will move hidden files (files whose names begin with a .) without any special options. If you want to exclude hidden files, you can use the option --exclude=".*/". You can also use the --exclude option to prevent copying things like Vim's swap files (.swp) and automatic backups (.bak) created by some programs.

Making local copies

Suppose you have an external USB or FireWire drive, and you want to copy data from your home directory to your external drive. A good way to do this would be to keep all your important data under a single top-level directory and then copy it to a backup directory on the external drive using a command like:
rsync -avh /home/usr/dir/ /media/disk/backup/
If you want to make sure that local files you've deleted since the last time you ran rsync are deleted from the external system as well, you'll want to add the --deleted option, like so:
rsync -avh --delete /home/user/dir/ /media/disk/backup
Be very careful with the delete option; with it, you can whack a bunch of files without meaning to. In fact, while you're getting used to rsync, it's probably a good idea to use the --dry-run option with your commands to run through the transfer first, without actually copying or synching files. If you do start an rsync transfer and realize that you've botched the command in some way that might result in the destruction of data, press Ctrl-c immediately to terminate the transfer. Some files may be gone, but you may be able to save the rest.

Making remote copies

What if you want to copy files offsite to a remote host? No problem -- all you need to do is add the host and user information. So, for instance, if you want to copy the same directory to a remote host, you'd use:
rsync -avhe ssh --delete /home/user/dir/ user@remote.host.comThis e-mail address is being protected from spambots. You need JavaScript enabled to view it :dir/
If you want to know how fast the transfer is going, and how much remains to be copied, add the --progress option:
rsync --progress -avhe ssh --delete
/home/user/dir/ user@remote.host.comThis e-mail address is being protected from spambots. You need JavaScript enabled to view it :dir/
If you don't want to be prompted for a password each time rsync makes a connection -- and you don't -- make sure that you have rsync set up to log in using an SSH key rather than a password. To do this, create an SSH key on the local machine using ssh-keygen -t dsa, and press Enter when prompted for a passphrase. After the key is created, use ssh-copy-id -i .ssh/id_dsa.pub user@remote.host.comThis e-mail address is being protected from spambots. You need JavaScript enabled to view it to copy the public key to the remote host.
What if you need to bring back some of the files you copied using rsync? Use the following syntax:
rsync -avze ssh remote.host.com:/home/user/dir/ /local/path/
The z option compresses data during the transfer. If the file you are copying exists on the local host, then rsync will just leave it alone -- the same as if you were copying files to a remote host.

Wrapping it up with a script

Once you've figured out what directory or directories you want to sync up, and you've gotten the commands you need to sync everything, it's easy to wrap it all up with a simple script. Here's a short sample:

rsync --progress -avze ssh --delete 

/home/user/bin/ 
 user@remote.host.comThis e-mail address is being protected from spambots. You need JavaScript enabled to view it
 :bin/rsync --progress -avze ssh --delete 

/home/user/local/data/ 
 user@remote.host.comThis e-mail address is being protected from spambots. You need JavaScript enabled to view it
 :local/data/rsync --progress -avze ssh --delete

/home/user/.tomboy/ 
 user@remote.host.comThis e-mail address is being protected from spambots. You need JavaScript enabled to view it
 :/.tomboy/

Use the --progress option if you're going to be running rsync interactively. If not, there's no need for it.
If you look at the rsync man page, you can easily be confused. However, after a little practice with rsync, you'll find that it's not hard to set up rsync jobs that will help you prepare for the day that your disk drive craps out and you need access to your data right away.

Example Xen HVM DomU

#
# Windows 2003 STD - System Centre Configuration Manager
#

import os, re
arch = os.uname()[4]
if re.search('64', arch):
    arch_libdir = 'lib64'
else:
    arch_libdir = 'lib'

kernel = "/usr/lib/xen-3.2-1/boot/hvmloader"

builder='hvm'

memory = 1024
shadow_memory = 8
name = "sccm"
vif = [ 'type=ioemu, bridge=eth0, model=rtl8139' ]
# dhcp = 'dhcp'
disk =  [
        'phy:/dev/datastore/sccm-system,hda,w'
        ,'phy:/dev/datastore/sccm-data,hdb,w'
        #, 'file:/media/iso/sccm_2007_sp2.iso,hdc:cdrom,r'
        ]

device_model = '/usr/' + arch_libdir + '/xen-3.2-1/bin/qemu-dm'
acpi=1
apic=1
localtime=1

# boot on floppy (a), hard disk (c) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot="dc"

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vncunused=1
vncdisplay=3
stdvga=0
serial='pty'
usbdevice='tablet'

xenBackup - the source

here's the source for the backup script. please feel free to use, modify, plagiarize, mock, torture or hack up any of this bash code as your mood takes you.

#!/bin/bash
#
#   Copyright John Quinn, 2008
#
#   This program is free software: you can redistribute it and/or modify
#   it under the terms of the GNU General Public License as published by
#   the Free Software Foundation, either version 3 of the License, or
#   (at your option) any later version.
#
#   This program is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#   GNU General Public License for more details.
#
#   You should have received a copy of the GNU General Public License
#   along with this program.  If not, see .

#
# xenBackup - Backup Xen Domains
#
#             Version:    1.0:     Created:  John D Quinn, http://www.johnandcailin.com/john
#

# initialize our variables
domains="null"                           # the list of domains to backup
allDomains="null"                        # backup all domains?
targetLocation="/tmp"                    # the default backup target directory
mountPoint="/mnt/xen"                    # the mount point to use to mount disk areas
xenDiskArea="/dev/skx-vg"                # the LVM volume group to use
shutdownDomains=false                    # don't shutdown domains by default
quiet=false                              # keep the chatter down
backupEngine=tar                         # the default backup engine
rsyncExe=/usr/bin/rsync                  # rsync executable
rdiffbackupExe=/usr/bin/rdiff-backup     # rdiff-backup executable
tarExe=/usr/bin/tar                      # tar executable
xmExe=/usr/sbin/xm                       # xm executable
purgeAge="null"                          # age at which to purge increments
globalBackupResult=0                     # success status of overall job

# settings for logging (syslog)
loggerArgs=""                            # what extra arguments to the logger to use
loggerTag="xenBackup"                    # the tag for our log statements
loggerFacility="local3"                  # the syslog facility to log to

# trap user exit and cleanup
trap 'cleanup;exit 1' 1 2

cleanup()
{
   ${logDebug} "Cleaning up"
   cd / ; umount ${mountPoint}

   # restart the domain
   if test ${shutdownDomains} = "true"
   then
      ${logDebug} "Restarting domain"
      ${xmExe} create ${domain}.cfg > /dev/null
   fi
}

# function to print a usage message and bail
usageAndBail()
{
   cat << EOT
Usage: xenBackup [OPTION]...
Backup xen domains to a target area. different backup engines may be specified to
produce a tarfile, an exact mirror of the disk area or a mirror with incremental backup.

   -d      backup only the specified DOMAINs (comma seperated list)
   -t      target LOCATION for the backup e.g. /tmp or root@www.example.com:/tmp
           (not used for tar engine)
   -a      backup all domains
   -s      shutdown domains before backup (and restart them afterwards)
   -q      run in quiet mode, output still goes to syslog
   -e      backup ENGINE to use, either tar, rsync or rdiff-backup
   -p      purge increments older than TIME_SPEC. this option only applies
           to rdiff-backup, e.g. 3W for 3 weeks. see "man rdiff-backup" for
           more information

Example 1
   Backup all domains to the /tmp directgory
   $ xenBackup -a -t /tmp

Example 2
   Backup domain: "wiki" using rsync to directory /var/xenImages on machine backupServer,
   $ xenBackup -e rsync -d wiki -t root@backupServer:/var/xenImages

Example 3
   Backup domains "domainOne" and "domainTwo" using rdiff-backup purging old increments older than 5 days
   $ xenBackup -e rdiff-backup -d "domainOne, domainTwo" -p 5D

EOT

   exit 1;
}

# parse the command line arguments
while getopts p:e:qsad:t:h o
do     case "$o" in
        q)     quiet="true";;
        s)     shutdownDomains="true";;
        a)     allDomains="true";;
        d)     domains="$OPTARG";;
        t)     targetLocation="$OPTARG";;
        e)     backupEngine="$OPTARG";;
        p)     purgeAge="$OPTARG";;
        h)     usageAndBail;;
        [?])   usageAndBail
       esac
done

# if quiet don't output logging to standard error
if test ${quiet} = "false"
then
   loggerArgs="-s"
fi

# setup logging subsystem. using syslog via logger
logCritical="logger -t ${loggerTag} ${loggerArgs} -p ${loggerFacility}.crit"
logWarning="logger -t ${loggerTag} ${loggerArgs} -p ${loggerFacility}.warning"
logDebug="logger -t ${loggerTag} ${loggerArgs} -p ${loggerFacility}.debug"

# make sure only root can run our script
test $(id -u) = 0 || { ${logCritical} "This script must be run as root"; exit 1; }

# make sure that the guest manager is available
test -x ${xmExe} || { ${logCritical} "xen guest manager (${xmExe}) not found"; exit 1; }

# assemble the list of domains to backup
if test ${allDomains} = "true"
then
   domainList=`${xmExe} list | cut -f1 -d" " | egrep -v "Name|Domain-0"`
else
   # make sure we've got some domains specified
   if test "${domains}" = "null"
   then
      usageAndBail
   fi

   # create the domain list by mapping commas to spaces
   domainList=`echo ${domains} | tr -d " " | tr , " "`
fi

# function to do a "rdiff-backup" of domain
backupDomainUsingrdiff-backup ()
{
   domain=$1
   test -x ${rdiffbackupExe} || { ${logCritical} "rdiff-backup executable (${rdiffbackupExe}) not found"; exit 1; }

   if test ${quiet} = "false"
   then
      verbosity="3"
   else
      verbosity="0"
   fi

   targetSubDir=${targetLocation}/${domain}.rdiff-backup.mirror

   # make the targetSubDir if it doesn't already exist
   mkdir ${targetSubDir} > /dev/null 2>&1
   ${logDebug} "backing up domain ${domain} to ${targetSubDir} using rdiff-backup"

   # rdiff-backup to the target directory
   ${rdiffbackupExe} --verbosity ${verbosity} ${mountPoint}/ ${targetSubDir}
   backupResult=$?

   # purge old increments
   if test ${purgeAge} != "null"
   then
      # purge old increments
      ${logDebug} "purging increments older than ${purgeAge} from ${targetSubDir}"
      ${rdiffbackupExe} --verbosity ${verbosity} --force --remove-older-than ${purgeAge} ${targetSubDir}
   fi

   return ${backupResult}
}

# function to do a "rsync" backup of domain
backupDomainUsingrsync ()
{
   domain=$1
   test -x ${rsyncExe} || { ${logCritical} "rsync executable (${rsyncExe}) not found"; exit 1; }

   targetSubDir=${targetLocation}/${domain}.rsync.mirror

   # make the targetSubDir if it doesn't already exist
   mkdir ${targetSubDir} > /dev/null 2>&1
   ${logDebug} "backing up domain ${domain} to ${targetSubDir} using rsync"

   # rsync to the target directory
   ${rsyncExe} -essh -avz --delete ${mountPoint}/ ${targetSubDir}
   backupResult=$?

   return ${backupResult}
}

# function to a "tar" backup of domain
backupDomainUsingtar ()
{
   domain=$1

   # make sure we can write to the target directory
   test -w ${targetLocation} || { ${logCritical} "target directory (${targetLocation}) is not writeable"; exit 1; }

   targetFile=${targetLocation}/${domain}.`date '+%d%b%y'`.$$.tar.gz
   ${logDebug} "backing up domain ${domain} to ${targetFile} using tar"

   # tar to the target directory
   cd ${mountPoint}

   ${tarExe} pcfz ${targetFile} * > /dev/null
   backupResult=$?

   return ${backupResult}
}

# backup the specified domains
for domain in ${domainList}
do
   ${logDebug} "backing up domain: ${domain}"

   # make sure that the domain is shutdown if required
   if test ${shutdownDomains} = "true"
   then
      ${logDebug} "shutting down domain ${domain}"
      ${xmExe} shutdown -w ${domain} > /dev/null
   fi

   # unmount mount point if already mounted
   umount ${mountPoint} > /dev/null 2>&1

   # mount the xen disk read-only
   xenDisk=${xenDiskArea}/${domain}-disk
   test -r ${xenDisk} || { ${logCritical} "xen disk area not readable. are you sure that the domain \"${domain}\" exists?"; exit 1; }
   ${logDebug} "Mounting ${xenDisk} read-only"
   mount -r ${xenDisk} ${mountPoint} || { ${logCritical} "mount failed, does mount point (${mountPoint}) exist?"; exit 1; }

   # do the backup according to the chosen backup engine
   backupDomainUsing${backupEngine} ${domain}

   # make sure that the backup was successful
   if test $? -ne 0
   then
      ${logCritical} "FAILURE: error backing up domain ${domain}"
      globalBackupResult=1
   else
      ${logDebug} "SUCCESS: domain ${domain} backed up"
   fi
     
   # clean up
   cleanup;
done

if test ${globalBackupResult} -eq 0
then
   ${logDebug} "SUCCESS: backup of all domains completed successfully"
else
   ${logCritical} "FAILURE: backup completed with some failures"
fi

exit ${globalBackupResult}

 

backing up your xen domains

backups are boring, but we all know how important they are. backups can also be quite powerful when working with xen virtualization, since xen allows for convenient back-up and restore of entire systems.
i've recently been working on a flexible, general-purpose script enabling incremental backups of complete xen guests, optimized for secure, distributed environments; xenBackup. if you're working with xen, you might find it useful.
the xenBackup script leverages open-source components like ssh, rsync, and rdiff-backup to create a simple, efficient and functional solution.
all code and configurations have been tested on debian etch but should be useful for other *nix flavors with subtle modifications. if you're unfamiliar with xen, you might consider starting with an earlier how-to on setting up xen on your debian etch box

a general approach

the approach you take to backups obviously depends on what your guests are doing. let's consider one of the more difficult cases, backing up a xen guest with an application server and a database running on it. ideally, you'd typically:

• take regular backups of the database.
• take a regular incremental backup of the entire machine.
• write the backups onto a different server on your network, and hopefully to a different geographical location too.
• do all of this without any interruption of your service.

in this article we'll discuss a simple way of doing this.

the xenBackup script

the xenBackup script, which i've included at the end of this article, helps implement a xen backup strategy. it automates the backup of single or multiple xen guests using one of three backup methods, tar, rsync or rdiff-backup. the usage message for xenBackup is as follows:

Usage: xenBackup [OPTION]...
Backup xen domains to a target area. different backup engines may be specified to
produce a tarfile, an exact mirror of the disk area or a mirror with incremental backup.

   -d      backup only the specified DOMAIN
   -t      target LOCATION for the backup e.g. /tmp or root@www.example.com:/tmp
           (not used for tar engine)
   -a      backup all domains
   -s      shutdown domains before backup (and restart them afterwards)
   -q      run in quiet mode
   -e      backup ENGINE to use, either tar, rsync or rdiff-backup
   -p      purge increments older than TIME_SPEC. this option only applies
           to rdiff-backup, e.g. 3W for 3 weeks. see "man rdiff-backup" for
           more information

to illustrate how it could be used, let's consider a typical scenario.

scenario: a single xen server with multiple xen guests

consider a xen server with multiple guests running on it, where the database on each guest backs up locally using a database specific backup technique e.g. a regularly scheduled hot backup writing to the local file system.
xenBackup could be used to periodically backup each of the local guests from the dom0. this is safe to do on a running server since the database backup does not rely on datafile consistency, but instead on the hot backups.
alternatively, the hot backup could be avoided if each of the guests was cleanly shutdown before the backup. xenBackup supports both these modes of operation but the former is recommended.
the xenBackup command on dom0 to incrementally backup all guests to /var/backup would simply be:

$ sudo xenBackup -a -e rdiff-backup -t /var/backup

this arrangement is shown in the diagram above. additionally, this backup could be periodically pulled from another backup server using rsync over ssh. this backup server could be located on or off-site.
this could be simplified by writing the backup directly onto another server in a single xenBackup command. this is arguably less secure since you need to push the backup rather than pull it, but could be done with:

$ sudo xenBackup -a -e rdiff-backup -t root@backupserver:/var/backup

running xenBackup on multiple dom0's the following arrangement can easily be achieved:

the backups

one of the great things about xen is that the backup allows you to reconstitute a fully working xen guest from the backup area, simply with a command like:

$ sudo xen-create-image --copy=/var/backup/mymachine.rdiff-backup.mirror --ip=192.168.1.10 --hostname=mymachine

if rdiff-backup is used as the backup engine, the xen guest can easily be restored to a historical state, to as far back as increments are kept (controlled by the xenBackup purge flag, -p). see man rdiff-backup for more information on using --restore-as-of on your backup directory.

dependencies

the xenBackup script has dependencies on rsync and rdiff-backup, if you choose to use those engines. if you do, you should install those packages:

$ sudo apt-get install rsync rdiff-backup

automation

to automate your backups, consider adding a cron entry to automatically run xenBackup on your backup server. typically you should do this at a quiet time. an example cron entry is:

00 1 * * * /usr/bin/xenBackup -q -a -t /var/backup -e rdiff-backup

you should consider adding the backup server's identity file to the authorized keys of the backup user on machines to push backups to. to allow the automation of encrypted, automated backups to be pushed over ssh. read up on ssh-copy-id and ssh-keygen for more information. give very careful consideration to security when determining the user to use and what machines can access what.

a word on syslog

xenBackup logs all backup output to syslog's local3 facility. all xenBackup's log output is available in the main syslog log, /var/log/syslog. in addition, a dedicated xenBackup log can be created by adding the following to your /etc/syslog.conf file:

# xenBackup logging: log all local3's messages to /var/log/xenBackup
local3.*                        /var/log/xenBackup

if you'd like to be informed about critical backup problems by email, please refer to my earlier blog how to setup real-time email-notification for critical syslog events.