Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cryptsetup pw dict files missing #679

Closed
thepulze opened this issue Oct 29, 2015 · 10 comments
Closed

cryptsetup pw dict files missing #679

thepulze opened this issue Oct 29, 2015 · 10 comments
Assignees
Labels
bug The code does not do what it is meant to do fixed / solved / done
Milestone

Comments

@thepulze
Copy link

Using Relax-and-Recover 1.17.2, restore of a CentOS 7.1.1503 system with crypto sw raid partition.

Restore process crashed because of missing pw dictionary files, used for pw quality check. Manually copying pw files to /usr/share/cracklib fixes the problem - resuming script execution worked afterwards.

Log:

+++ echo -e 'Please enter the password for vm-01(/dev/mapper/vg0-vm):'
+++ cryptsetup luksFormat -q --cipher aes-xts-plain64 --hash sha1 --uuid 9177bf34-a4b6-445c-8d02-ab39a06f4637 /dev/mapper/vg0-vm
/usr/share/cracklib/pw_dict.pwd.gz: No such file or directory
Password quality check failed:
The password fails the dictionary check - error loading dictionary
2015-10-29 19:10:21 An error occurred during layout recreation.

@gdha gdha added the bug The code does not do what it is meant to do label Nov 1, 2015
@gdha gdha added this to the Rear v1.18 milestone Nov 1, 2015
@gdha gdha self-assigned this Nov 1, 2015
@gdha
Copy link
Member

gdha commented Nov 2, 2015

@thepulze I am trying to understand what the easiest way is to identify if crypted devices are in use:

  1. presence of /etc/crypttab file ?
  2. non-empty output of sudo dmsetup ls --target crypt ?
  3. the presence of lsmod | grep dm-crypt ?
  4. use cryptsetup -v isLuks <device> exit code ?
  5. output of blkid -p <device> ?

We are thinking of making some kind of prep phase script which could be used to identify, and make sure that are desired executables, libraries and configuration files are copied to the rescue image.

@gdha
Copy link
Member

gdha commented Feb 22, 2016

Due to no fb close this issue

@gdha gdha closed this as completed Feb 22, 2016
@tastle73
Copy link

@gdha We have run into this same problem. I am happy to be a tester.

ReaR seems to be detecting that a luks volume is there just fine on its own and it would rebuild the luks partitions at rescue if not for the dictionary error. In fact, if you just add --force-password to the cryptsetup command in the rebuild script it will.

However, it is not pulling all the password quality dictionaries needed for cryptsetup to run. I tried adding different libraries to the default conf file LIBS section but couldn't get it to work.

@gdha
Copy link
Member

gdha commented Feb 23, 2016

@tastle73 perhaps with the help of strace you could try to find out what it really wants.

@tastle73
Copy link

I'm all ears. How could I do this?

@gdha
Copy link
Member

gdha commented Feb 23, 2016

Edit in script diskrestore.sh that is created during the recover phase and add the strace before the cryptsetup command (use the menu to edit the diskrestore.sh script), e.g.

$ strace cryptsetup 
execve("/usr/sbin/cryptsetup", ["cryptsetup"], [/* 52 vars */]) = 0
brk(0)                                  = 0x1f2e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fca4643a000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=89701, ...}) = 0
mmap(NULL, 89701, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fca46424000
close(3)                                = 0
and so on...

@gdha gdha reopened this Feb 23, 2016
@tastle73
Copy link

Just so you're aware, I ran ldd against cryptsetup while trying to fix it and found that it needed libpwquality.so.1 So I added that

[root@rj ~]# ldd which cryptsetup
linux-vdso.so.1 => (0x00007ffca6d06000)
libcryptsetup.so.4 => /lib64/libcryptsetup.so.4 (0x00007f55ee327000)
libpopt.so.0 => /lib64/libpopt.so.0 (0x00007f55ee11d000)
libpwquality.so.1 => /lib64/libpwquality.so.1 (0x00007f55edf16000)
libc.so.6 => /lib64/libc.so.6 (0x00007f55edb55000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f55ed950000)
libdevmapper.so.1.02 => /lib64/libdevmapper.so.1.02 (0x00007f55ed6f5000)
libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x00007f55ed474000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f55ed270000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f55ed06a000)
libcrack.so.2 => /lib64/libcrack.so.2 (0x00007f55ece5f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f55ee560000)
librt.so.1 => /lib64/librt.so.1 (0x00007f55ecc57000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f55eca31000)
libsepol.so.1 => /lib64/libsepol.so.1 (0x00007f55ec7ec000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f55ec7d7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f55ec5ba000)
libm.so.6 => /lib64/libm.so.6 (0x00007f55ec2b8000)
libz.so.1 => /lib64/libz.so.1 (0x00007f55ec0a2000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f55ebe40000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f55ebc1b000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f55eba16000)
libdw.so.1 => /lib64/libdw.so.1 (0x00007f55eb7ce000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f55eb5b8000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007f55eb3b3000)
libelf.so.1 => /lib64/libelf.so.1 (0x00007f55eb19c000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f55eaf8c000)

@tastle73
Copy link

I ran strace as instructed and was able to determine what the dependancies are. I added them to default.conf in the COPY_AS_IS variable:

COPY_AS_IS=( /usr/share/cracklib/* /etc/security/pwquality.conf $SHARE_DIR $VAR_DIR )

With this added, LUKS volumes are recreated as expected.

Would you be able to have rear copy these in when LUKS is encountered?

On Feb 23, 2016, at 11:43 AM, gdha notifications@github.com wrote:

Edit in script diskrestore.sh that is created during the recover phase and add the strace before the cryptsetup command (use the menu to edit the diskrestore.sh script), e.g.

$ strace cryptsetup
execve("/usr/sbin/cryptsetup", ["cryptsetup"], [/* 52 vars */]) = 0
brk(0) = 0x1f2e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fca4643a000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=89701, ...}) = 0
mmap(NULL, 89701, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fca46424000
close(3) = 0
and so on...

Reply to this email directly or view it on GitHub #679 (comment).

Thomas Astle
System Administrator

Physician's Computer Company
20 Winooski Falls Way, Suite 7
Winooski, VT 05404
+1 800.722.7708
tom@pcc.com

@gdha
Copy link
Member

gdha commented Mar 4, 2016

@tastle73 thank you - your advise was useful. Committed it for 1.18.

@tastle73
Copy link

tastle73 commented Mar 4, 2016

As a test I did a git pull today and ran make rpm. For some reason mdadm was missing at restore time. Copying it in from another system worked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The code does not do what it is meant to do fixed / solved / done
Projects
None yet
Development

No branches or pull requests

3 participants