|
|
Matthew Palmer <mpalmer@xxxxxxxxxx> writes:
> Thanks anyway for the bug report, though; we might get lucky this time and
> actually nail (one of) these bugs to the wall.
More input:
I installed the puppet client package on another machine but talking
to the same server. I brought up-to-date all of puppet's dependencies
and still it still works. Here is the paired down site.pp file that
I'm now using.
node lycastus {
file { "/etc/issue.net":
mode => "444",
source => "puppet://home.phy.bnl.gov/files/issue.net",
}
}
node minos {
file { "/etc/issue.net":
mode => "444",
source => "puppet://home.phy.bnl.gov/files/issue.net",
}
}
One possible hint is on the system that works ruby is getting linked
to non-TLS versions of libraries:
Working system:
minos:~# ldd `which ruby`
libruby1.8.so.1.8 => /usr/lib/libruby1.8.so.1.8 (0x4002a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x400f7000)
libdl.so.2 => /lib/libdl.so.2 (0x40149000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4014e000)
libm.so.6 => /lib/libm.so.6 (0x4017c000)
libc.so.6 => /lib/libc.so.6 (0x401a2000)
/lib/ld-linux.so.2 (0x40000000)
Failing system:
lycastus:~# ldd `which ruby`
linux-gate.so.1 => (0xffffe000)
libruby1.8.so.1.8 => /usr/lib/libruby1.8.so.1.8 (0xa7eaa000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xa7e98000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xa7e93000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0xa7e65000)
libm.so.6 => /lib/tls/libm.so.6 (0xa7e3f000)
libc.so.6 => /lib/tls/libc.so.6 (0xa7d07000)
/lib/ld-linux.so.2 (0xa7f86000)
Both have the same version of libc6 package installed. I don't know
what makes /lib/tls libraries get picked up over /lib ones. If I did,
the next step would be to try the /lib versions on the failing system
to see if this is the problem.
-Brett.
--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
|
|