Re: BIND DNS problem after upgrading from Wheezy to Squeeze

[Bernhard Schmidt]

Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:
> Le 29/12/2017 à 18:27, Andrew W a écrit :
>> 
>> On 27/12/2017 13:18, Bernhard Schmidt wrote:
>>> Current BIND9 defaults to doing DNSSEC verification. DNSSEC needs large
>>> packets. You might have an issue with UDP fragments being dropped at
>>> your firewall/NAT Gateway?
>>>
>> Thanks for this tip. Looking into it I discovered TCP seems to be 
>> recommened for DNSSEC so Ive enabled TCP port 53  and so far not had a 
>> problem!
>
> AFAIK TCP is just a fall-back transport to work around UDP packet size 
> issues. Compared to UDP, TCP transport for DNS wastes system and network 
> resources.

Yes and no. For a single query, UDP is indeed more efficient. You can
have long-standing TCP connections though (multiple queries through the
same TCP channel, sometimes used between Client and Resolver, optionally
with TLS), UDP > 1400 Bytes (Fragments) is often blocked by Firewalls or
misconfigured links, and due to the possibility of spoofing in UDP
(reflexive DDoS) some authoritative servers force clients to use TCP
(i.e. RRL or DNS COOKIE).

IOW, if you block TCP outbound for your resolver, you are asking for
trouble.

Bernhard

Re: BIND DNS problem after upgrading from Wheezy to Squeeze

[Bernhard Schmidt]

Andrew Wood  wrote:

Hi,

> I have a server which acts as a DNS server for our LAN. All our internal 
> servers have A records on it using a .local domain and it forwards all 
> other requests out to the root servers using the in built list provided 
> with BIND. All clients on the LAN have this machine set as their only 
> DNS server.
>
>
> It has worked fine for 6 years under Wheezy but I have just upgraded it 
> to Stretch. I did an upgrade to Jessie first, rebooted checked 
> everything was OK, and then immediately upgraded to Stretch.
>
> Since then we keep getting intermittent DNS lookup failures for various 
> domains on the internet, which will typically work if you click the 
> refresh button in the browser a few times.
>
> BIND seems to just log to syslog/systemd it doesnt appear to be 
> configured to use its own log. If I run journalctl -xe | grep "named" I 
> can get the log entries but none of them relate to the failed DNS 
> lookup. If I do it immediately after a failure has occured nothing is 
> logged so Im at a bit of a loss to work out what might be wrong.
>
>
> Does anyone have any ideas please?

Current BIND9 defaults to doing DNSSEC verification. DNSSEC needs large
packets. You might have an issue with UDP fragments being dropped at
your firewall/NAT Gateway?

https://www.dns-oarc.net/oarc/services/replysizetest

You can try to set 

edns-udp-size 1200;

in your options {} block if you see issues there.

Bernhard

Re: router solutions based on Debian?

[Bernhard Schmidt]

Daniel Pocock  wrote:

Hi Daniel,

> My ISP is upgrading my connection to gigabit on Friday and I suspect my
> current router may struggle with it.
>
> My existing router runs OpenWRT but I've found the firewall and IPsec
> setup is a little bit constrained in that environment and it is tempting
> to move to a router running a full OS.
>
> I've seen a lot of discussions about making DIY routers running a free
> OS like Debian, FreeBSD or OpenBSD and I was tempted to go with
> something like that running Shorewall, strongSwan, DHCP and DNS.  Maybe
> it will also do wifi or maybe the existing router will be a bridge to wifi.
>
> Can anybody share any comments or links about this topic?
>
> - quiet (fanless), low-power and low cost hardware suitable for Gigabit
> routing and maybe use as a NAS too.  It would also be useful to have
> fibre support in the router and avoid using a media convertor.
>
> - are there any live builds or other out-of-the-box solutions that
> address this use case particularly well?

My recommendation if you basically want a fanless mini PC is the PC
Engines APU (2C4 for example). Quadcore 1GHz amd64 with AES-NI, 4 GB
RAM, 3 GE ports, USB 3.0 external. I recommend using a M2 SSD for boot
media. With PSU and case it starts around 220 EUR. Debian works out of
the box.

You can also have a look at the Ubiquiti EdgeRouter line. There are
models with SFP slot available, even the small models are supposed to be
able to support GE throughput and are < 100 EUR. They are MIPS Cavium
boards with a custom kernel, but you can get a rootshell and there is a
Debian (I think Wheezy at the moment) userland on it. I don't think you
can get the hardware to be fully-free running a vanilla Debian, so YMMV.

Best Regards,
Bernhard

Re: initramfs broken on Jessie upgrade

[Bernhard Schmidt]

Bernhard Schmidt be...@birkenwald.de wrote:

 This is reproducible. To fix it it is enough to boot into the Wheezy
 kernel (even with init=/bin/sh), then reboot. It apparently does
 something to the root-fs (fsck?) which allows the Jessie kernel to boot.

Ben Hutchings had the right idea in Bug#783620.

Apparently the reboot leaves the filesystem in an unclean state. The new
initramfs is written in the journal, but not on-disk yet. Grub2 doesn't
read the journal, so it finds a corrupted initramfs. A boot with the old
kernel replays the log and the initrd can be read.

It is still unclear why the reboot is unclean at all. A sync before
reboot should help.

Bernhard




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mi7d7k$gem$1...@ger.gmane.org

Re: Mysql Access Problems after Jessie Upgrade

[Bernhard Schmidt]

Alan Chandler a...@chandlerfamily.org.uk wrote:

Hi,

 Do you have /etc/hosts.allow / hosts.deny non-standard?

 Both appear empty (other than comments)


 So I added a line

 ALL: 127.0.0. 192.168.0.

 to /etc/hosts.allow

 and everything started working again

 Not sure if I need to include the 127.0.0 to allow connections from 
 localhost but at least it appears to work

Weird, I wasn't aware of libwrap blocking anything by default.

Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mi7ivq$hlm$1...@ger.gmane.org

Re: Mysql Access Problems after Jessie Upgrade

[Bernhard Schmidt]

Alan Chandler a...@chandlerfamily.org.uk wrote:

Hi Alan,

 Today I am having database connection problems.

 Using mysql client to connect to my server owl.home

   mysql --host=owl.home --user=mythtv --password=XX mythconverg
 ERROR 2013 (HY000): Lost connection to MySQL server at 'reading 
 authorization packet', system error: 0

Not using mysql myself, but this error seems familiar. I have seen it
when a Percona upgrade suddenly started using libwrap (hosts.allow) and
it was hit by our standard DENY all block.

At least mysql-server-core-5.5 in Jessie is linked against libwrap0.

Do you see error messages connecting in /var/log/auth.log? 

Do you have /etc/hosts.allow / hosts.deny non-standard? 

Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mi5r71$vel$1...@ger.gmane.org

Re: initramfs broken on Jessie upgrade

[Bernhard Schmidt]

Bernhard Schmidt be...@birkenwald.de wrote:

Hi,

 Since I could not find anything secret in the initrd I have uploaded
 both images

 http://users.birkenwald.de/~berni/volatile/783620_initrd_ok
 http://users.birkenwald.de/~berni/volatile/783620_initrd_broken

 It is _not_ caused by the initrd per se, I have just rebooted the system
 and edited the grub commands to load the .broken initrd, and it came up
 fine.

 I will make a snapshot in the broken state the next time it happens,
 maybe something else is broken. Except for update-initramfs I did not
 run any command, but the system was fully booted on the Wheezy kernel,
 maybe something else triggered a fix.

 I hope to upgrade a few more systems today, maybe I can reproduce it.

Got another system with the symptoms and managed to get a snapshot.

It is really extremely weird. The kernel output is

List of all partitions:
No filesystem could mount root, tried:
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)

This is reproducible. To fix it it is enough to boot into the Wheezy
kernel (even with init=/bin/sh), then reboot. It apparently does
something to the root-fs (fsck?) which allows the Jessie kernel to boot.

I have asked our Windows guys to make a screencast, it is uploaded here.

http://users.birkenwald.de/~berni/volatile/783620.mkv

We still have the snapshot available, if you have an idea please drop me
a note.

Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mhqdo5$37k$1...@ger.gmane.org

Re: initramfs broken on Jessie upgrade

[Bernhard Schmidt]

Don Armstrong d...@debian.org wrote:

Hi Don,

 has anyone observed something similar to
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783620 on their
 Upgrade from Wheezy to Jessie? I'm still trying to figure out what's
 happening, and I don't really know where to look.
 
 I was unable to attach the screenshot so far (mail is accepted but
 never makes it to the BTS), I've put the screenshot here:
 
 http://users.birkenwald.de/~berni/volatile/783620.png

 Could you run something like this on the initrds?

 diff -u ( zcat workinginitrd) ( zcat brokeninitrd);

 It's possible that something has corrupted the initrds in some subtle
 way, or some part of the cpio archive has been truncated which causes as
 issue for the kernel but is ignored by cpio.

lxmhs63:/boot$ diff -u ( zcat initrd.img-3.16.0-4-amd64 ) (
zcat initrd.img-3.16.0-4-amd64.broken )
Binary files /dev/fd/63 and /dev/fd/62 differ

with -a it outputs a lot of difference in binary, I can't figure out
anything there.

Since I could not find anything secret in the initrd I have uploaded
both images

http://users.birkenwald.de/~berni/volatile/783620_initrd_ok
http://users.birkenwald.de/~berni/volatile/783620_initrd_broken

Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mhpsrl$11l$2...@ger.gmane.org

Re: initramfs broken on Jessie upgrade

[Bernhard Schmidt]

Bernhard Schmidt be...@birkenwald.de wrote:
 Don Armstrong d...@debian.org wrote:

 Hi Don,

 has anyone observed something similar to
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783620 on their
 Upgrade from Wheezy to Jessie? I'm still trying to figure out what's
 happening, and I don't really know where to look.
 
 I was unable to attach the screenshot so far (mail is accepted but
 never makes it to the BTS), I've put the screenshot here:
 
 http://users.birkenwald.de/~berni/volatile/783620.png

 Could you run something like this on the initrds?

 diff -u ( zcat workinginitrd) ( zcat brokeninitrd);

 It's possible that something has corrupted the initrds in some subtle
 way, or some part of the cpio archive has been truncated which causes as
 issue for the kernel but is ignored by cpio.

 lxmhs63:/boot$ diff -u ( zcat initrd.img-3.16.0-4-amd64 ) (
 zcat initrd.img-3.16.0-4-amd64.broken )
 Binary files /dev/fd/63 and /dev/fd/62 differ

 with -a it outputs a lot of difference in binary, I can't figure out
 anything there.

 Since I could not find anything secret in the initrd I have uploaded
 both images

 http://users.birkenwald.de/~berni/volatile/783620_initrd_ok
 http://users.birkenwald.de/~berni/volatile/783620_initrd_broken

It is _not_ caused by the initrd per se, I have just rebooted the system
and edited the grub commands to load the .broken initrd, and it came up
fine.

I will make a snapshot in the broken state the next time it happens,
maybe something else is broken. Except for update-initramfs I did not
run any command, but the system was fully booted on the Wheezy kernel,
maybe something else triggered a fix.

I hope to upgrade a few more systems today, maybe I can reproduce it.

Best Regards,
Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mhptd4$g21$1...@ger.gmane.org

Re: initramfs broken on Jessie upgrade

[Bernhard Schmidt]

Michael Biebl bi...@debian.org wrote:

Hi Michael,

 has anyone observed something similar to
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D783620 on their
 Upgrade from Wheezy to Jessie? I'm still trying to figure out what's
 happening, and I don't really know where to look.
=20
 I was unable to attach the screenshot so far (mail is accepted but
 never makes it to the BTS), I've put the screenshot here:
=20
 http://users.birkenwald.de/~berni/volatile/783620.png
=20
 ---snip---
 Dear Maintainer,
=20
 I have a hard time wrapping my head around this bug, feel free to assig=
 n
 somewhere else.
=20
 We have started upgrading some of our production VMs to Jessie. The
 testsystems worked fine, but I have hit the following bug for the secon=
 d
 time on a production VM now.
=20
 - dist-upgrade works flawlessly
 - on first boot into Jessie I get an immediate (1s) kernel-panic (see
   attached screenshot) about being unable to find the root fs.

 Did you run into
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D783297 maybe?

No, no cryptsetup on that box and BUSYBOX=y is set anyway.

Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mhpsfo$11l$1...@ger.gmane.org

initramfs broken on Jessie upgrade

[Bernhard Schmidt]

Hi,

has anyone observed something similar to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783620 on their
Upgrade from Wheezy to Jessie? I'm still trying to figure out what's
happening, and I don't really know where to look.

I was unable to attach the screenshot so far (mail is accepted but
never makes it to the BTS), I've put the screenshot here:

http://users.birkenwald.de/~berni/volatile/783620.png

---snip---
Dear Maintainer,

I have a hard time wrapping my head around this bug, feel free to assign
somewhere else.

We have started upgrading some of our production VMs to Jessie. The
testsystems worked fine, but I have hit the following bug for the second
time on a production VM now.

- dist-upgrade works flawlessly
- on first boot into Jessie I get an immediate (1s) kernel-panic (see
  attached screenshot) about being unable to find the root fs.
  Unfortunately I'm unable to get the full boot log, since I don't have
  a serial console there and kernel messages scroll by too fast.
- To fix the issue I have to boot into the old Wheezy kernel
  (3.2.0-4-amd64) in grub and regenerate the initrd for the Jessie
  kernel

# update-initramfs -k 3.16.0-4-amd64 -u

  Then it works fine.

Now comes the interesting part ... I have saved the broken initrd for
later analysis

The compressed size is marginally different (broken being 3k smaller)

-rw-r--r--  1 root root 14339199 Apr 28 13:59 initrd.img-3.16.0-4-amd64
-rw-r--r--  1 root root 14338898 Apr 28 13:58 initrd.img-3.16.0-4-amd64.broken

The uncompressed size is the same

root@lxmhs63:/tmp# zcat /boot/initrd.img-3.16.0-4-amd64.broken  
initrd.img-3.16.0-4-amd64.broken
root@lxmhs63:/tmp# zcat /boot/initrd.img-3.16.0-4-amd64  
/tmp/initrd.img-3.16.0-4-amd64
root@lxmhs63:/tmp# ls -la /tmp/initrd.img-3.16.0-4-amd64*
-rw-r--r-- 1 root root 45304832 Apr 28 14:44 /tmp/initrd.img-3.16.0-4-amd64
-rw-r--r-- 1 root root 45304832 Apr 28 14:44 
/tmp/initrd.img-3.16.0-4-amd64.broken

The checksum is different

root@lxmhs63:/tmp# md5sum /tmp/initrd.img-3.16.0-4-amd64*
7b24aa901b697dc5dfdbad03bd199072  /tmp/initrd.img-3.16.0-4-amd64
5e467c0a49afa4ddae315cc6e818d7ac  /tmp/initrd.img-3.16.0-4-amd64.broken

Now comes the puzzling part ... the _content_ of the initrd is exactly
the same

root@lxmhs63:/tmp# mkdir broken  cd broken  cpio -id  
../initrd.img-3.16.0-4-amd64.broken
88486 blocks
root@lxmhs63:/tmp/broken# cd ..
root@lxmhs63:/tmp# mkdir ok  cd ok  cpio -id  ../initrd.img-3.16.0-4-amd64
88486 blocks
root@lxmhs63:/tmp/ok# cd ..
root@lxmhs63:/tmp# diff -urN broken ok

I will try to capture a screenlog on the next upgrades, maybe there is
something interesting in there. 
snip

Best Regards,
Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mhomrq$f44$1...@ger.gmane.org

Re: TSM does not work with Jessie (was: Debugging segfaults in commercial software on Jessie)

[Bernhard Schmidt]

Bernhard Schmidt be...@birkenwald.de wrote:

Hi,

 Our TSM guy found the bugreport.
 http://www-01.ibm.com/support/docview.wss?uid=swg1IC92662myns=aparmynp=DO

 IC92662: TSM CLIENT CAN CRASH WITH CERTAIN NODENAMES ON LINUX
 DISTRIBUTIONS IF USING GLIBC 2.16 OR HIGHER IN THE FUTURE

In case someone stumbles across this posting, the problem has been fixed
in TSM client 6.4.1.7.

Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/li89b6$nod$1...@ger.gmane.org

Citrix Receiver 13 on amd64-multiarch

[Bernhard Schmidt]

Heya,

maybe someone has a great idea for this problem.

Citrix has released a new receiver (basically the client for their
terminalserver solution) for Linux.

http://www.citrix.com/downloads/citrix-receiver/linux/receiver-for-linux-130.html

The amd64 variant is basically i386 plus dependencies on ia32-libs (not
in Jessie/Testing) and nspluginwrapper (not in Wheezy+), so no go.

The i386 variant worked fine (after some massaging) in Version 12.1.0
on a multi-arch enabled Jessie box, but cannot be installed in 13.0. The
reason:

icaclient:i386 depends on libwebkit-1.0-2 (squeeze-only) | libwebkitgtk-1.0-0
  libwebkitgtk-1.0-0:i386 depends on libenchant1c2a:i386
libenchant1c2a:i386 depends on libaspell15:i386
  libaspell15:i386 and libaspell15:amd64 are not co-installable (not
  multi-arch, see Bug#667592

The latter bug does not look like it is going to be resolved soon, which
is quite unfortunate. 

Does anyone have better experience with Citrix?

I did a few more tests, including installation of the binaries from the
.tgz in /opt and porting over nspluginwrapper from Ubuntu, but all I get
is a segfaulting wfica when it should connect.

Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/lbjcop$c1e$1...@ger.gmane.org

Re: Debugging segfaults in commercial software on Jessie

[Bernhard Schmidt]

Bernhard Schmidt be...@birkenwald.de wrote:

Hi,

 The weird thing is, my colleague running sid on his desktop has the same
 problem. My desktop, running Jessie, does _not_ have the same problem.
 The VM in question, also running Jessie, does have this problem. 

 Interesting... Perhaps there are differences in the package versions?
 Subtle ones?  I'd say run a dpkg -l | grep '^ii' on both (or all 3)
 systems and diff the output... It's bound to flag *something* up,
 unfortunately most of it is probably insignificant. But there could be
 a gold nugget in there.

 
 I compared strace on both sides and there is no notable difference (more
 filesystems on my desktop, but nothing extraordinary). Library versions
 are the same. I adjusted environment variables to be the same, no
 difference. 

 Ah. You've been there already.

 Just to report back, so far my attempts have been unsuccessful. I've
 compared the package lists on all three systems. It was quite messy
 since two of them are vastly differently managed work desktops, and I
 could not find any clues in there. I also fiddled some more with
 environment variables, but no go.

 I'll keep trying.

Found something. Backtrace:

(gdb) bt
#0  0x00685ad6 in psCreateCryptoKey(unsigned char*, char*) ()
#1  0x008f58fb in psPasswordFile::readPassword(unsigned char,
char*, char*, char const*, unsigned char*, bool) ()
#2  0x006bbcc8 in PasswordFile::getPassword(unsigned char,
char*, unsigned int*, char*, char const*, unsigned char*, bool) ()
#3  0x006b3261 in pswdFGetPassword(Sess_o*) ()
#4  0x005ede47 in scPswdEncrypt(Sess_o*, unsigned char*,
unsigned int, unsigned char*, unsigned int*, unsigned char) ()

More googling revealed https://bugzilla.redhat.com/show_bug.cgi?id=1030142

I'll try to open a case with IBM.

Best Regards,
Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/l6v2kh$1se$1...@ger.gmane.org

TSM does not work with Jessie (was: Debugging segfaults in commercial software on Jessie)

[Bernhard Schmidt]

Bernhard Schmidt be...@birkenwald.de wrote:

Hi,

[ IBM TSM client segfaults on some Jessie boxes ]

 The weird thing is, my colleague running sid on his desktop has the same
 problem. My desktop, running Jessie, does _not_ have the same problem.
 The VM in question, also running Jessie, does have this problem. 

 Interesting... Perhaps there are differences in the package versions?
 Subtle ones?  I'd say run a dpkg -l | grep '^ii' on both (or all 3)
 systems and diff the output... It's bound to flag *something* up,
 unfortunately most of it is probably insignificant. But there could be
 a gold nugget in there.

 
 I compared strace on both sides and there is no notable difference (more
 filesystems on my desktop, but nothing extraordinary). Library versions
 are the same. I adjusted environment variables to be the same, no
 difference. 

 Ah. You've been there already.

 Just to report back, so far my attempts have been unsuccessful. I've
 compared the package lists on all three systems. It was quite messy
 since two of them are vastly differently managed work desktops, and I
 could not find any clues in there. I also fiddled some more with
 environment variables, but no go.

 I'll keep trying.

 Found something. Backtrace:

 (gdb) bt
 #0  0x00685ad6 in psCreateCryptoKey(unsigned char*, char*) ()
 #1  0x008f58fb in psPasswordFile::readPassword(unsigned char,
 char*, char*, char const*, unsigned char*, bool) ()
 #2  0x006bbcc8 in PasswordFile::getPassword(unsigned char,
 char*, unsigned int*, char*, char const*, unsigned char*, bool) ()
 #3  0x006b3261 in pswdFGetPassword(Sess_o*) ()
 #4  0x005ede47 in scPswdEncrypt(Sess_o*, unsigned char*,
 unsigned int, unsigned char*, unsigned int*, unsigned char) ()

 More googling revealed https://bugzilla.redhat.com/show_bug.cgi?id=1030142

 I'll try to open a case with IBM.

Our TSM guy found the bugreport.
http://www-01.ibm.com/support/docview.wss?uid=swg1IC92662myns=aparmynp=DO

IC92662: TSM CLIENT CAN CRASH WITH CERTAIN NODENAMES ON LINUX
DISTRIBUTIONS IF USING GLIBC 2.16 OR HIGHER IN THE FUTURE

APAR status

Closed as program error.

Error description

A code defect has been detected in the
TSM Linux x86 client. While it does not manifest
today in any currently-supported Linux distributions,
here would be the symptom:
When PASSWORDACCESS is set to GENERATE, TSM Linux client
could crash when trying to read or write the password file.

This will happen when installed glibc is version 2.16 or higher,
and only with certain node names. It is not possible to
identify the node name pattern triggering the issue. The
crash can occur on short and long names, with and without
non-alpha characters. However, when the failing combination
of characters is used as the node name, the problem is
consistently recreatable.

One class of node names known to trigger the issue are the
names of 3 symbols or less. For example, ABC, F35, R2 etc.

An example of a longer node name is LINUX-123456

Since currently-supported RedHet and SuSE distributions
do not yet support this Glibc level, there is no current
error. However, this APAR is being opened to address
the potential future issue when that Glibc level is
supported.

Local fix

One of the following workarounds can be used:

1. Downgrade glibc to version 2.15 or lower, if possible.

2. Change the node name. In most cases, adding, deleting or
   modifying a single character is sufficient.

3. Set PASSWORDACCESS to PROMPT and add PASSWORD option to
   your dsm.sys options file. Make sure to restrict file
   system access to dsm.sys so non-authorized users can't
   see the node password.

Problem summary


* USERS AFFECTED: All clients versions 6.3 and 6.4 running *
* on Linux platforms with glibc version 2.16   *
* or higher.   *

* PROBLEM DESCRIPTION: See ERROR DESCRIPTION.  *

* RECOMMENDATION: Apply fixing level when available. This  *
* problem is currently projected to be fixed   *
* in levels 6.3.2 and 6.4.2. Note that until   *
* these levels are available, this *
* information is subject to change at the  *
* discretion of IBM.   *

*

Problem conclusion

The problem has been fixed so that it no longer occurs.

Best Regards,
Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact

Re: Debugging segfaults in commercial software on Jessie

[Bernhard Schmidt]

Karl E. Jorgensen k...@jorgensen.org.uk wrote:

Hi,

 The weird thing is, my colleague running sid on his desktop has the same
 problem. My desktop, running Jessie, does _not_ have the same problem.
 The VM in question, also running Jessie, does have this problem. 

 Interesting... Perhaps there are differences in the package versions?
 Subtle ones?  I'd say run a dpkg -l | grep '^ii' on both (or all 3)
 systems and diff the output... It's bound to flag *something* up,
 unfortunately most of it is probably insignificant. But there could be
 a gold nugget in there.

 
 I compared strace on both sides and there is no notable difference (more
 filesystems on my desktop, but nothing extraordinary). Library versions
 are the same. I adjusted environment variables to be the same, no
 difference. 

 Ah. You've been there already.

Just to report back, so far my attempts have been unsuccessful. I've
compared the package lists on all three systems. It was quite messy
since two of them are vastly differently managed work desktops, and I
could not find any clues in there. I also fiddled some more with
environment variables, but no go.

I'll keep trying.

Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/l6tr3i$8j3$1...@ger.gmane.org

Debugging segfaults in commercial software on Jessie

[Bernhard Schmidt]

Hi,

I'm a bit at a loss here, maybe someone has an idea how to look.

We run a commercial software called IBM Tivoli Storage Manager (TSM) for
Backup purposes. It is quite an ugly beast, but it works just fine on
Wheezy.

When upgrading to Jessie, it produces a segfault on most systems

root@lxmhs70:~# dsmc q fi
IBM Tivoli Storage Manager
Command Line Backup-Archive Client Interface
  Client Version 6, Release 4, Level 0.7  
  Client date/time: 11/19/2013 10:57:01
(c) Copyright by IBM Corporation and other(s) 1990, 2013. All Rights
Reserved.

Node Name: LXMHS70
Aborted

The weird thing is, my colleague running sid on his desktop has the same
problem. My desktop, running Jessie, does _not_ have the same problem.
The VM in question, also running Jessie, does have this problem. 

I compared strace on both sides and there is no notable difference (more
filesystems on my desktop, but nothing extraordinary). Library versions
are the same. I adjusted environment variables to be the same, no
difference. 

My colleague fixed it by using an older libc, using this method
(http://www.debian-administration.org/users/lee/weblog/30) and the
following packages

libc6_2.13-38_amd64.deb
libgcc1_4.7.2-5_amd64.deb
libstdc++6_4.7.2-5_amd64.deb
libtinfo5_5.9-10_amd64.deb

but as I said, it works for me just fine.

Does anyone have an idea how to debug this? I don't want to open a bug
report right now on either side because its commercial software on a
non-stable distribution version.

Best Regards,
Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/l6fdlu$123$1...@ger.gmane.org

Re: Preseeding german keyboard layout in Wheezy

[Bernhard Schmidt]

Bernhard Schmidt be...@birkenwald.de wrote:

 I'm currently trying to streamline our Debian deployment using
 preseeding and I'm having issues setting a German keyboard layout. I use
 Wheezy daily 20121114 at the moment.

 Goals:
 - installer should be English
 - the country should be set to Germany (so timezone is okay)
 - default locale of the installed system should be English (so program
   messages are not translated)
 - the keyboard should be set to German layout

 I can successfully set that configuration using a full manual
 installation but I seem to be missing some setting when using preseed
 commands.

 I use the following boot options:
 debian-installer/language=en debian-installer/country=DE
 debian-installer/locale=en_US.UTF-8 keymap=de

 The keymap question is not asked anymore (it is when I remove setting
 keymap=), but the keymap is still English. I also tried
 keyboard-configuration/xkb-keymap=de without success

FYI if anyone cares, apparently you need BOTH keymap=de and
debian-installer/keymap=de . I've opened bug #693956 for that.

Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/k8ktht$mt5$1...@ger.gmane.org

Preseeding german keyboard layout in Wheezy

[Bernhard Schmidt]

Hi,

I'm currently trying to streamline our Debian deployment using
preseeding and I'm having issues setting a German keyboard layout. I use
Wheezy daily 20121114 at the moment.

Goals:
- installer should be English
- the country should be set to Germany (so timezone is okay)
- default locale of the installed system should be English (so program
  messages are not translated)
- the keyboard should be set to German layout

I can successfully set that configuration using a full manual
installation but I seem to be missing some setting when using preseed
commands.

I use the following boot options:
debian-installer/language=en debian-installer/country=DE
debian-installer/locale=en_US.UTF-8 keymap=de

The keymap question is not asked anymore (it is when I remove setting
keymap=), but the keymap is still English. I also tried
keyboard-configuration/xkb-keymap=de without success

Any ideas what I'm doing wrong? I've seen Bug #693493 but I'm already
using the new option, so I'm at a loss here.

Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/k8inl9$ssn$1...@ger.gmane.org

Checking for kernel freshness

[Bernhard Schmidt]

Hi,

the company I work for has a script on SLES/SuSE, that checks the
following three kernel versions

- latest version available in the repository
- version installed in /boot and thus likely to be loaded on next boot
- version running

and warns (and/or fixes) if there is a mismatch. I've been trying to
think of a way to do the same, but failed so far.

Latest version available in the repository is easy enough, just check
for the version the metapackage depends on (or, even easier, check for
updates of the kernel package). 

Checking for the version in /boot is semi-easy (check the package
version installed and hope the user did not fiddle with grub), too.

The hard part seems to be matching the running kernel against the
version installed. I cannot figure out a good way so far. Nothing in the
running kernel seems to show the Debian version (i.e.
2.6.32-41squeeze2), thus I cannot compare it. It is printed in the
bootup messages

[0.00] Linux version 2.6.32-5-amd64 (Debian 2.6.32-39squeeze1)
(da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Jan
9 20:49:59 UTC 2012

but that might be long gone when I check. I could not find this version
string in /proc or /sys yet.

Any idea how to solve that?

Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jm6u5o$rmm$1...@dough.gmane.org

Re: Checking for kernel freshness

[Bernhard Schmidt]

Bob Proulx b...@proulx.com wrote:

 The hard part seems to be matching the running kernel against the
 version installed. I cannot figure out a good way so far. Nothing in the
 running kernel seems to show the Debian version (i.e.
 2.6.32-41squeeze2), thus I cannot compare it. It is printed in the
 bootup messages

 Try this:

   $ cat /proc/version
   Linux version 2.6.32-5-686 (Debian 2.6.32-41squeeze2) (da...@debian.org) 
 (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Mar 26 05:20:33 UTC 2012

God damnit. I was looking in /proc/sys/kernel and /sys/kernel, but not
in /proc/version. Thanks! :-(

Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jm6vdr$72t$1...@dough.gmane.org

Re: Checking for kernel freshness

[Bernhard Schmidt]

keith km3...@gmail.com wrote:
 Bernhard Schmidt wrote:
 The hard part seems to be matching the running kernel against the
 version installed. I cannot figure out a good way so far. Nothing in the
 running kernel seems to show the Debian version (i.e.
 2.6.32-41squeeze2), thus I cannot compare it. It is printed in the
 bootup messages

 [0.00] Linux version 2.6.32-5-amd64 (Debian 2.6.32-39squeeze1)
 (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Jan
 9 20:49:59 UTC 2012

 but that might be long gone when I check. I could not find this version
 string in /proc or /sys yet.

 Any idea how to solve that?

 Doesn't 'uname -a' give you that...

No.

$ uname -a
Linux ping 2.6.32-5-amd64 #1 SMP Mon Jan 9 20:49:59 UTC 2012 x86_64
GNU/Linux

The Squeeze kernel has been 2.6.32-5 since release, that doesn't tell
you anything about the actual kernel build you are running. Well, except
you start looking at the build date, but that's so ugly ...

Fortunately there is /proc/version ...

Thanks for everyone involved, I'm off writing checkscripts.

Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jm76kf$46r$1...@dough.gmane.org

Re: aptitude vs. apt-get/dpkg purge

[Bernhard Schmidt]

Andrei POPESCU andreimpope...@gmail.com wrote:

Hello,

 I have not seen an explicit bug for it, but the 816 open bugs on
 aptitude are somewhat hard to browse. Is this a known issue or
 works-as-designed?
 I can only confirm your findings, still looking for a workaround.

I have reported bug #648313 for this.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648313

Best Regards,
Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/j9gm65$ott$1...@dough.gmane.org

aptitude vs. apt-get/dpkg purge

[Bernhard Schmidt]

Hi,

I have a weird problem where my google foo is failing me (although I
guess it has been seen more than once before).

Long story short, I have a configuration management software (puppet)
that purges selective packages on each run (among others os-prober). It
is (by default) using apt for this task.

When I execute aptitude interactively on one of those handled servers
after that, it always wants to reinstall os-prober. It does not show so
in the listing, but it says 'Will use 193 kB of disk space' and shows
os-prober in the 'Packages to be installed' block after pressing 'g'. I
have to deselect it there manually with '-' or ':' to get rid of it
forever.

It seems to be related with the Apt::Install-Recommends setting, if I
set that to False the behaviour is gone. But I like recommends for now.

It is easily reproducible on both Squeeze and Wheezy:

# apt-get install os-prober
# aptitude
(see that there is nothing to do)
# apt-get purge os-prober
# aptitude
(see that it wants to install os-prober)

I have not seen an explicit bug for it, but the 816 open bugs on
aptitude are somewhat hard to browse. Is this a known issue or
works-as-designed?

Thanks,
Bernhard


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/j9esqi$43d$1...@dough.gmane.org