You are here
Christian - Sun, 2019/05/05 - 20:43
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:
Tags:
Got it to work with
Got it to work with
I can now download the latest backup with
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"?
Alternative: run in chrooted mount point
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 directoryIn fact, "/usr/lib/python2.7/dist-packages/stdtrap.py" doesn't exist. Reinstalling TKLBAM in the chrooted environment also didn't help.
Any idea?
Looks like a missing dependency (plus you'll need the key file)
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:
You'll need to run apt update again, then install turnkey-pylib, i.e.:
If you get any further errors, please let me know.
Things have changed in v16.0
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.:
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 -Restore a path to a different path
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
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/usr/lib/python2.7/dist-packages/stdtrap.py does exist...
... the error must lie somewhere else.
Ok, the problem was a different one entirely.
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,
"tklbam restore" worked.
Ah ha! I probably should of thought of that sooner!
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).
As always, much appreciated!
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.
Great suggestion! And a minor correction in terms
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