In Part 1
of this series, I delved into the installation of the
. In this, Part 2, I deal with data migration from a standalone system (the system being migrated into the virtual environment) to a newly created DomU (a new virtual machine which is going to replace the stand-alone system).
When it comes to data migration, it can be said that just like any other system admin’s tasks, only your imagination can pose limitations on how you may approach the assignment. This essentially means that your creativity in tackling this task depends on the following:
- Your understanding of the system being migrated and the environment around it.
- The tools that you have on hand.
Depending on the understanding I have, I pondered for a while on how to approach the task. Then, I concluded that I could either migrate the whole stand-alone system (migrate the whole system) as it is; or simply migrate fundamental roles’ related data (migrate only necessary services’ related data).
In the spirit of ad hoc, sloppy hackery, here’s a trick I’ve used in the past for providing myself with an escape route when performing risky remote maintenance without a console. There’s nothing worse than irredeemably disconnecting your remote shell and causing yourself the catastrophe of a visit to the data centre, when you should be in the pub. Here’s a little way of taking out some insurance against the your fat fingers.
Caveat: this is not best practice. The whole reason for adhering to sound strict principles of design is to avoid performing risky procedures which might require this kind of mitigation. Still, it doesn’t hurt to know.
The basic principle of this contrivance is to use the “at” daemon to run a back-out script as a kind of “dead man’s handle”. That is, if your hands come off the controls, this failsafe kicks in and puts things back the way they were – not careening out of control around a sharp bend.
The “at” command
The command at is a relatively unused little tool, despite having been a part of Linux since the beginning, probably. Its more organised uncle, cron, is the one everyone’s familiar with for automating recurring tasks, ad infinitum. But at is for executing one-offs, and so isn’t really an automation tool as such, since you still have to actually type whatever you want it to execute. But it adds a latency to the actual execution of that command and does it later on, when it’s more timely to do so. So it doesn’t save you any work, it just does it later so you don’t have to. You’re down the pub.
So you are busy and your phone rings. In previous versions of Android you could slide the slider to the right and answer the call, or slide it to the left and route the call to voicemail.
Ice Cream Sandwich allows you to go one stage further with the call rejection, slide the slider up and you get a txt icon:
Releasing the slider over this icon then gives the option to send 1 of a set number of pre-defined messages, or you can send a customised message:
Clicking on one of the pre-defined messages will automatically send that message to the called number and send the call to voicemail.
The customised message one, lets you type in a txt before sending it to the called number.
Now you can quickly give the called number, some information on your status rather than just blindly transferring the call to voicemail!
If you have found this article useful, please consider making a microdonation.