Install TKLBAM on rescue system

Got it to work with

echo "deb http://archive.turnkeylinux.org/debian stretch main“ > /etc/apt/sources.list.d/archive.turnkeylinux.org.list
apt-get update
apt-get -o Dpkg::Options::="--force-overwrite" --allow-unauthenticated install tklbam

I can now download the latest backup with

tklbam restore <ID> --raw-download=/tklbam-dump

But since I am in the rescue system, the paths don't match. Is there a way I can restore a particular source path to a given target path, i.e. "/etc" to "mnt/etc"?

As of v16.0, each repo ('buster', 'buster-testing' & 'buster-security') have their own key. By default, all 3 are added to all TurnKey appliances, but we use the Debian "best practice" method of writing each key to it's own keyring file in /usr/share/keyrings and each sources.list file line explicitly notes the keyfile. I.e.:

# grep -r turnkey /etc/apt/sources.list.d/
/etc/apt/sources.list.d/turnkey-testing.list.disabled:deb [signed-by=/usr/share/keyrings/tkl-buster-testing.gpg] http://archive.turnkeylinux.org/debian buster-testing main
/etc/apt/sources.list.d/sources.list:deb [signed-by=/usr/share/keyrings/tkl-buster-main.gpg] http://archive.turnkeylinux.org/debian buster main
/etc/apt/sources.list.d/security.sources.list:deb [signed-by=/usr/share/keyrings/tkl-buster-security.gpg] http://archive.turnkeylinux.org/debian buster-security main

You can find all 3 keys (in ascii-armoured format) in common/overlays/bootstrap_apt/usr/share/keyrings/. If you wish to install the key to it's own keyring as we do, do it like this:

wget https://raw.githubusercontent.com/turnkeylinux/common/master/overlays/bootstrap_apt/usr/share/keyrings/tkl-buster-main.asc \
    | apt-key --keyring /usr/share/keyrings/tkl-buster-main.gpg add -

But you'll need to add the path to the sources.list line as per my example above. If you're happy to skip the additional security (and don't want to include the keyring path in the sources.list), you could instead write it to a keyring file in the /etc/apt/trusted.gpg.d/ dir:

wget https://raw.githubusercontent.com/turnkeylinux/common/master/overlays/bootstrap_apt/usr/share/keyrings/tkl-buster-main.asc \
    | apt-key --keyring /etc/apt/trusted.gpg.d/tkl-buster-main.gpg add -

Or even directly to the default keyring...:

wget https://raw.githubusercontent.com/turnkeylinux/common/master/overlays/bootstrap_apt/usr/share/keyrings/tkl-buster-main.asc \
    | apt-key add -

We haven't done a very good job of maintaining the "non-TurnKey" install of TKLBAM. Although on a Debian system, the only issues you should hit are missing dependencies. In this case the one missing is 'turnkey-pylib' (install via apt).

I'll open a bug to note that there is a missing dependency and we'll hopefully fix that relatively soon.

The initial issue you had was because you don't have the right key file. Probably the easiest way to get that is just download it directly from our GitHub repo (FWIW that's how it gets into all the TurnKey servers). Something like this should do the trick:

URL=https://github.com/turnkeylinux/common/raw/master/overlays/turnkey.d/apt
FILE=etc/apt/trusted.gpg.d/turnkey.gpg
wget $URL/$FILE -O /$FILE

You'll need to run apt update again, then install turnkey-pylib, i.e.:

apt update
apt install turnkey-pylib

If you get any further errors, please let me know.

I have also tried to run TKLBAM in the chrooted mount point, but that resulted in the following error:

root@rescue / # tklbam restore 46
Traceback (most recent call last):
  File "/usr/bin/tklbam", line 46, in <module>
    CliWrapper.main()
  File "/usr/lib/tklbam/cliwrapper.py", line 88, in main
    commands[command].main()
  File "/usr/lib/tklbam/cmd_restore.py", line 483, in main
    trap = UnitedStdTrap(usepty=True, transparent=(False if silent else True), tee=log_fh)
  File "/usr/lib/python2.7/dist-packages/stdtrap.py", line 331, in __init__
    self.stdout_splice = Splicer(sys.stdout.fileno(), usepty, transparent, tee)
  File "/usr/lib/python2.7/dist-packages/stdtrap.py", line 220, in __init__
    vals = self._splice(spliced_fd, usepty, transparent, tee)
  File "/usr/lib/python2.7/dist-packages/stdtrap.py", line 117, in _splice
    r, w = os.openpty()
OSError: [Errno 2] No such file or directory

In fact, "/usr/lib/python2.7/dist-packages/stdtrap.py" doesn't exist. Reinstalling TKLBAM in the chrooted environment also didn't help.

Any idea?

Thanks, Jeremy, I'll try that tonight. Thankfully, the machine in question is not a production server, so I am not under pressure.

Running the existing TKLBAM installation in a chroot jail is much preferrable, however, if that doesn't work out and I have to use a newly installed TKLBAM in the "parent" rescue system - how would I proceed to restore a particular source path to a different target path, i.e. "/etc" to "mnt/etc"? Is there an (undocumented) CLI option to do that or alternatively a workaround to achieve that?

Unfortunately, installing turnkey-pylib doesn't seem to help:

root@rescue / # apt-get install turnkey-pylib
Reading package lists... Done
Building dependency tree
Reading state information... Done
turnkey-pylib is already the newest version (0.5+45+gc201a49).
turnkey-pylib set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 13 not upgraded.
root@rescue / # apt-get install --reinstall turnkey-pylib
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 13 not upgraded.
Need to get 0 B/40.7 kB of archives.
After this operation, 0 B of additional disk space will be used.
dpkg-preconfigure: unable to re-open stdin: No such file or directory
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (2: No such file or directory)
(Reading database ... 101215 files and directories currently installed.)
Preparing to unpack .../turnkey-pylib_0.5+45+gc201a49_amd64.deb ...
Unpacking turnkey-pylib (0.5+45+gc201a49) over (0.5+45+gc201a49) ...
Setting up turnkey-pylib (0.5+45+gc201a49) ...
root@rescue / # tklbam restore 46
Traceback (most recent call last):
  File "/usr/bin/tklbam", line 46, in <module>
    CliWrapper.main()
  File "/usr/lib/tklbam/cliwrapper.py", line 88, in main
    commands[command].main()
  File "/usr/lib/tklbam/cmd_restore.py", line 483, in main
    trap = UnitedStdTrap(usepty=True, transparent=(False if silent else True), tee=log_fh)
  File "/usr/lib/python2.7/dist-packages/stdtrap.py", line 331, in __init__
    self.stdout_splice = Splicer(sys.stdout.fileno(), usepty, transparent, tee)
  File "/usr/lib/python2.7/dist-packages/stdtrap.py", line 220, in __init__
    vals = self._splice(spliced_fd, usepty, transparent, tee)
  File "/usr/lib/python2.7/dist-packages/stdtrap.py", line 117, in _splice
    r, w = os.openpty()
OSError: [Errno 2] No such file or directory

... the error must lie somewhere else.

Sorry, in retrospect, I probably should have looked a little more closely at the issue you had reported. In my rush, I just looked at your last post and made a guess. I hadn't even considered that you may not have completely set up the chroot!

FWIW, (as you may now be aware) other than under the simplest of cases, you should generally mount /dev, /proc and usually /sys too. In my experience you can usually get away without mounting /dev/pts although if you do mount it, you will avoid a range of error/warning messages (they can be ignored in my experience, but still nicer not to have them).

Glad to hear you got there in the end. Sorry that my previous response wasn't a little more useful!

(PS I added a couple of tags to your OP that hopefully might help others find this thread in the future).

Ok, the problem was a different one entirely. tklbam-pylib is installed as a dependency, so you can close that bug. The problem was that in the chroot jail, needed file descriptors were not available. Once i mounted them from the rescue system,

mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc

"tklbam restore" worked.

I've opened an issue (feature request) to improve the TKLBAM docs to cover disaster recovery restore within a chroot. So thanks for the suggestion.

Also just a minor correction in terms. FWIW what you set up was a 'chroot', not a 'chroot jail'. A chroot (change root) is simply a part of a filesystem, that is treated as if it were the root filesystem (i.e. '/'). In the context that you set it up, it's useful for repairs, development, etc. Under those circumstance, it's usually a complete OS filesystem.

A 'chroot jail' uses a chroot, but it's more than that. It also locks a limited user within the chroot (hence the 'jail' part). It's often used to enhance security of particular applications (e.g. Postfix runs within a chroot jail), or to allow a limited user access to some particular files, but nothing else (e.g. an SFTP user chroot jail). Rarely would a 'chroot jail' contain a full OS filesystem. Although it may contain a few specific OS files that the user/application requires, e.g. to support use of LDAP authentication, Postfix chroot includes dev/random and dev/urandom. It should be noted though, that whilst a chroot jail enhances security, it's not a silver bullet. Depending on circumstance (and knowledge), it may be possible to break out of a chroot.

FWIW containers (such as Docker or LXC) are essentially just a chroot, albeit on steroids. They leverage a range of kernel features to lock down the chroot much more intensively than is possible under normal circumstance, as well as providing features such as networking, etc (which aren't possible/practical).

Don't worry, you couldn't know that I was completely ignorant about chroot jails!

Maybe it would be worth adding a small addition to the documentation how to use TKLBAM for desaster recovery like in my case. 

Thanks for your as always excellent support.