My previous post made use of duply as a wrapper around duplicity, but for some reason everything started going a bit wrong, with the cause being *something* that changed in the Python boto library config, but I couldn't work out what.
The solution was to stop using duply and to use duplicity directly. There are many guides that explain how to setup duplicity to use Amazon S3 storage, so I'll not reproduce that information here (Google is your friend), but it's useful to show the script I use to initiate a backup:
export PASSPHRASE="Add your GPG passphrase here"
export AWS_ACCESS_KEY_ID="Add your AWS access key here"
export AWS_SECRET_ACCESS_KEY="Add your AWS secret access key here"
duplicity -v6 --encrypt-key AddYourGPGkeyHere \
--exclude='**/Junk/*' \
--include='**/Music/*' \
--exclude='**/Documents/temp' \
--include='**/Documents/*' \
--exclude='**/.*' \
--exclude='**/' \
--exclude='**' \
--rsync-options="--size-only" \
/base/dir/to/backup/eg/home/patrick s3://s3-eu-west-1.amazonaws.com/path/to/s3/bucket/or/dir/in/bucket
The above script sets up the authentication variables and then performs a backup of the base directory. I've split the "duplicity" invocation over several lines to make it clearer what's going on.
Note that the final three "exclude" statements will exclude everything from the backup, so it's important to add "include" statements for anything you want backing up.
In the example above, just the "Music" and "Documents" directories in the specified base directory (/base/dir/to/backup/eg/home/patrick) will be backed up, and within the "Documents" directory, the "temp" directory will be excluded.
When deciding what to include or exclude, duplicity will use the first successful include/exclude match, so it's important that the "**/Documents/temp" exclude statement comes before the "**/Documents/*" include statement.
Restoring from backup
Again, there are plenty of guides on the web describing how to do a restore. The only thing to remember is that you will need the three environment variables, shown in the above script, to be setup before performing any duplicity commands. You'll also need to include the "--encrypt-key" argument in the duplicity invocation.
Handy tip
I store my backup script, including all the passphrases and keys, in a LastPass secure note in order that I always have all details needed in the event that some kind of total disaster has occurred.
Sunday, 12 June 2016
Sunday, 17 January 2016
Using Cygwin on Citrix XenApp to host thin-client Unix applications
These three scripts enable Citrix XenApp to be used as a means to host remote Unix applications, avoiding the need to use something like Opentext VDI Desktop and the like.
This enables legacy Unix apps to be run on a centralised X11 infrastructure, with users getting the benefit of being able to access the running Unix app via the bandwidth-efficient Citrix ICA protocol. This has the added benefit that users can disconnect their Citrix session and leave the Unix desktop session application still running until the user wants to re-connect.
The scripts enable a user to run a published Citrix app which starts X11 on the XenApp server, launches a login panel running on the remote Unix server and, following successful login via SSH using the supplied credentials, launches the remote Unix application on the application server, tunnelling the X11 graphics back to the XenApp server.
The entire Unix desktop and Unix application is rendered by the X11 server on the XenApp server, and all graphics then are relayed to the user's Citrix client via Citrix ICA in the usual way.
The script actually runs the remote Xsession on a different Unix server to the Unix application, but you might not need this.
In fact, the scripts are fairly specific to a consulting job from a few years ago, but no doubt will be useful to someone, especially for:
Screenshots
TCL/Expect-driven login window. This, including the surrounding Cygwin window decoration, is what the user sees when they launch the XenApp published app (which simply runs the xxxx.sh script on the XenApp server).
Resulting desktop session, ready to run the application. Again, this is exactly what the user sees, including the surrounding Cygwin window decoration.
This enables legacy Unix apps to be run on a centralised X11 infrastructure, with users getting the benefit of being able to access the running Unix app via the bandwidth-efficient Citrix ICA protocol. This has the added benefit that users can disconnect their Citrix session and leave the Unix desktop session application still running until the user wants to re-connect.
The scripts enable a user to run a published Citrix app which starts X11 on the XenApp server, launches a login panel running on the remote Unix server and, following successful login via SSH using the supplied credentials, launches the remote Unix application on the application server, tunnelling the X11 graphics back to the XenApp server.
The entire Unix desktop and Unix application is rendered by the X11 server on the XenApp server, and all graphics then are relayed to the user's Citrix client via Citrix ICA in the usual way.
The script actually runs the remote Xsession on a different Unix server to the Unix application, but you might not need this.
In fact, the scripts are fairly specific to a consulting job from a few years ago, but no doubt will be useful to someone, especially for:
- Figuring out how to safely and successfully launch and use Cygwin/X11 on XenApp;
- Running an interactive and customised logon panel for a Unix desktop/application session using Expect and Tcl;
- Automating the backend connection from Citrix to the application via SSH.
Screenshots
TCL/Expect-driven login window. This, including the surrounding Cygwin window decoration, is what the user sees when they launch the XenApp published app (which simply runs the xxxx.sh script on the XenApp server).
Resulting desktop session, ready to run the application. Again, this is exactly what the user sees, including the surrounding Cygwin window decoration.
Labels:
aix,
application hosting,
citrix,
cygwin,
expect,
linux,
remote access,
solaris,
ssh,
tcl,
unix,
xenapp
Subscribe to:
Posts (Atom)

