Bootstrapping using a FAI based system the current ssl-cert version
1.0.15 hangs during installation:
% ps auxwww
[...]
root 17080 0.1 0.6 10620 8812 ttyp0 S+ 16:05 0:00 /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/ssl-cert.postinst configure
root 17082 0.0 0.0 2724 1288 ttyp0 S+ 16:05 0:00 /bin/sh -e /var/lib/dpkg/info/ssl-cert.postinst configure
root 17089 0.0 0.1 2740 1356 ttyp0 S+ 16:05 0:00 /bin/bash -e /usr/sbin/make-ssl-cert generate-default-snakeoil
root 17093 0.0 0.1 3792 1452 ttyp0 S+ 16:05 0:00 openssl req -config /tmp/tmp.ZkYAg17091 -new -x509 -days 3650 -nodes -out /etc/ssl/certs/ssl-cert-snakeoil.pem -keyout /etc/ssl/private/ssl-cert-snakeoil.key
[...]
Running the openssl command manually brings up:
17145:error:0E065068:configuration file routines:STR_COPY:variable has no value:conf_def.c:629:line 5
The content of /tmp/tmp.ZkYAg17091 is:
#
# SSLeay example configuration file.
#
RANDFILE = $ENV::RANDFILE
[ req ]
default_bits = 1024
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
prompt = no
policy = policy_anything
[ req_distinguished_name ]
commonName = randomname.grml.org
My chroot system (where ssl-cert can't be installed) is named "grml"
using /etc/hostname (but /etc/init.d/hostname.sh doesn't seem to be
executed), which is different from the outer system being
randomname.grml.org (where I'm bootstrapping from and what seems to
be the output of 'hostname -f'). Until now my setup always worked
just fine. Am I doing something wrong and it worked fine until now
just because of random luck or is the "hostname -f" change of
ssl-cert causing unwanted problems? :)
regards,
-mika-
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
| 17145:error:0E065068:configuration file routines:STR_COPY:variable has no value:conf_def.c:629:line 5
Did you first set RANDFILE to /dev/random? Is /dev/random available
in the chroot? What does strac-ing the openssl process show you, and
what does ls -l /proc/$pid_of_openssl/fd show you?
| My chroot system (where ssl-cert can't be installed) is named "grml"
| using /etc/hostname (but /etc/init.d/hostname.sh doesn't seem to be
| executed), which is different from the outer system being
| randomname.grml.org (where I'm bootstrapping from and what seems to
| be the output of 'hostname -f'). Until now my setup always worked
| just fine. Am I doing something wrong and it worked fine until now
| just because of random luck or is the "hostname -f" change of
| ssl-cert causing unwanted problems? :)
I doubt it has anything to do with -f or not -f.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
> | 17145:error:0E065068:configuration file routines:STR_COPY:variable has no value:conf_def.c:629:line 5
> Did you first set RANDFILE to /dev/random?
No (not that I'm aware of).
> Is /dev/random available in the chroot?
Yes:
# ls -la /dev/random
crw-rw-rw- 1 root root 1, 8 Oct 29 22:01 /dev/random
> What does strac-ing the openssl process show you, and
Running it from outside the chroot:
# strace -f -p 31838
Process 31838 attached - interrupt to quit
read(4, "\212\304;\210\204n\361\26", 976) = 8
read(4, "\210\4\266\332\\\272\17\276", 968) = 8
read(4, "\265\265\356\235\375\211\307\305", 960) = 8
read(4, <unfinished ...>
[..]
> what does ls -l /proc/$pid_of_openssl/fd show you?
# ls -l /proc/31838/fd
total 0
lr-x------ 1 root root 64 Feb 14 16:12 0 -> pipe:[777359]
l-wx------ 1 root root 64 Feb 14 16:12 1 -> /dev/null
l-wx------ 1 root root 64 Feb 14 16:12 11 -> pipe:[777314]
l-wx------ 1 root root 64 Feb 14 16:10 2 -> /dev/null
l-wx------ 1 root root 64 Feb 14 16:12 3 -> pipe:[777360]
lr-x------ 1 root root 64 Feb 14 16:12 4 -> /dev/random
I prepared a minimal chroot where you should be able to reproduce
the problem on your own:
http://grml.org/tmp/ssl-cert-chroot.tgz (52M)
Running "apt-get install ssl-cert" inside it hopefully should allow
you to reproduce above problem.
regards,
-mika-