Christian's picture

Hi,

I have installed TKLBAM on a docker host which is itself not a TKL appliance. Now I have a problem with this machine and can access it only via a rescue system which can mount the drives but doesn't let me run the TKLBAM binaries directly. In order to restore data, I need to install it on the rescue system, which is a Debian 9 (Stretch) OS.

I used the instructions here: https://www.turnkeylinux.org/faq/which-turnkey-appliances-are-supported

but this resulted in error messages:

root@rescue / # wget -O - -q \
> https://raw.github.com/turnkeylinux/tklbam/master/contrib/ez-apt-install.sh \
> | PACKAGE=tklbam /bin/bash
+ apt-key adv --keyserver pgpkeys.mit.edu --recv-keys A16EB94D
Executing: /tmp/apt-key-gpghome.E3h1eF1kmP/gpg.1.sh --keyserver pgpkeys.mit.edu --recv-keys A16EB94D
gpg: keyserver receive failed: No data

Added http://archive.turnkeylinux.org/debian package source to /etc/apt/sources.list.d/archive.turnkeylinux.org.list
+ apt-get update
E: Malformed entry 1 in list file /etc/apt/sources.list.d/archive.turnkeylinux.org.list (Component)
E: The list of sources could not be read.
+ tty
+ apt-get install tklbam
E: Malformed entry 1 in list file /etc/apt/sources.list.d/archive.turnkeylinux.org.list (Component)

After correcting the sources.list entry to

deb http://archive.turnkeylinux.org/debian stretch main

I got this:

dpkg: error processing archive /tmp/apt-dpkg-install-sazaNO/08-tklbam-duplicity_0.6.18-2turnkey+28+g6495c80_amd64.deb (--unpack):
 trying to overwrite '/usr/bin/duplicity', which is also in package duplicity 0.7.11-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Selecting previously unselected package tklbam-python-boto.
Preparing to unpack .../09-tklbam-python-boto_2.3.0-2turnkey+13+g29b88e1_all.deb ...
Unpacking tklbam-python-boto (2.3.0-2turnkey+13+g29b88e1) ...
Selecting previously unselected package tklbam.
Preparing to unpack .../10-tklbam_1.4.1+37+g8117cd6_all.deb ...
Unpacking tklbam (1.4.1+37+g8117cd6) ...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-sazaNO/08-tklbam-duplicity_0.6.18-2turnkey+28+g6495c80_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

and this

W: GPG error: http://archive.turnkeylinux.org/debian stretch Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 85C25E95A16EB94D
W: The repository 'http://archive.turnkeylinux.org/debian stretch Release' is not signed.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.
N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'http://archive.turnkeylinux.org/debian stretch InRelease' doesn't support architecture 'i386'

Is there a newer version of the install file that works with Debian 9 and doesn't raise these errors?

Thanks.

 

 

Forum: 
Christian's picture

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"?

Christian's picture

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?

Jeremy Davis's picture

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.

Christian's picture

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?

Christian's picture

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
Christian's picture

... the error must lie somewhere else.

Christian's picture

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.

Jeremy Davis's picture

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).

Christian's picture

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.

Jeremy Davis's picture

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).

Add new comment