Bug#995396: hdparm udev rule does not trigger for device node names which are four letters or longer
There is another place that needs to be fixed: 95hdparm-apm The line "for dev in /dev/sd? /dev/hd? ; do" should also be changed to "for dev in /dev/sd*[!0-9] ; do" TIA, Andy -- Andreas Ley, SCC, Karlsruhe Institute of Technology (KIT), D-76128 Karlsruhe E-Mail: andreas@kit.edu, Phone: +49 721 608 46341, Fax: +49 721 32550
Bug#934940: Depends: misses libscalar-list-utils-perl
Package: libtemplate-perl Version: 2.24-1.2+b3 Severity: minor Dear Maintainer, IMHO debian/control Depends: line misses libscalar-list-utils-perl since Template/Service.pm contains "use Scalar::Util 'blessed';" -- System Information: Debian Release: 9.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libtemplate-perl depends on: ii libappconfig-perl 1.66-2 ii libc6 2.24-11+deb9u4 ii perl5.24.1-3+deb9u5 ii perl-base [perlapi-5.24.1] 5.24.1-3+deb9u5 libtemplate-perl recommends no packages. Versions of packages libtemplate-perl suggests: pn libtemplate-perl-doc pn libtemplate-plugin-gd-perl pn libtemplate-plugin-xml-perl -- no debconf information
Bug#913234: shibboleth-sp2-utils: systemd service does not warn if certs not accessible as _shibd (like init.d did)
> I can see the problem, but I'm not sure how to improve on this. We > don't want to support running shibd as root, so we added the warning to I'm totally with you here! > prod admins to migrate under jessie. It seems you didn't use a big enough cattle prod here ;-) Without the explicit systemd service, it still runs seamlessly as root... > There was a NEWS entry as well. I had something in mind like the warning mails I get for behaviour changes from unattended upgrades... Since I don't do dist-upgrades, but clean re-installs to get rid of no-longer-needed stuff on my servers, it seems I have to improve my reading and include all the NEWS* files for all the packages... > Systemd can't really provide a fallback to root anyway. Now we're > nearing the buster freeze already; I think the best thing to do would be > decoding the error codes so that the daemon prints human readable error > messages (for example "permission denied" in this case). Would you find > that a valid fix? However, this wouldn't help current stretch users > (who must have already solved this) nor future upgrades to buster. > Still, it would be a slight improvement upstream, I guess. Yes, this might help - and now that I'm better aware of the NEWS* files, perhaps an entry in a shibboleth-sp2-utils (where _this_ change really happend) NEWS file, like, "now we have a systemd service, now you not only SHOULD change to _shibd, now you MUST" or anything more prominent. You're right, you did document the change, and it's the ignorant admins out there that have a problem, so everything should be fine, but now that you know of these admins, perhaps you stumble upon a bigger prod - if not, ok, it's us admins that have to learn the hard way ;-) Thanks for your time, for the work that you put in these packages and for dealing with people like me :) Bye, Andy -- Andreas Ley, SCC, Karlsruhe Institute of Technology (KIT), D-76128 Karlsruhe E-Mail: andreas@kit.edu, Telephone: +49 721 608 46341, Fax: +49 721 32550 "It's 106 ms to Chicago, we've got a full disk of GIFs, half a meg of hypertext, it's dark, and we're wearing sunglasses." "Click it." -- Christopher Davis
Bug#913234: shibboleth-sp2-utils: systemd service does not warn if certs not accessible as _shibd (like init.d did)
Package: shibboleth-sp2-utils
Version: 2.6.0+dfsg1-4+deb9u1
Severity: minor
Dear Maintainer,
* What led up to the situation?
Migrated shibboleth x.509 keys (root owned, mode 400) from a jessie system to
stretch.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Did not realize there now is a _shibd user that needs to access the keys since
on jessie, shibd automatically runs as root in such a situation.
* What was the outcome of this action?
/var/log/shibboleth/shibd.log lists:
2018-11-08 08:30:59 ERROR OpenSSL : error code: 33558541 in bss_file.c, line 406
2018-11-08 08:30:59 ERROR OpenSSL : error data: fopen('.../conf/ssl/sp.key','r')
2018-11-08 08:30:59 ERROR OpenSSL : error code: 537346050 in bss_file.c, line
408
* What outcome did you expect instead?
Either the same logic as on jessie or a more prominent hint for the admin to
adapt to the new situation.
* What caused the problem?
On jessie, there is no explict systemd service file but one is generated from
/etc/init.d/shibd as /run/systemd/generator.late/shibd.service
so the whole init.d logic is also available to systemd. This logic has been
amended by debian/patches/Improve-shibd-init-script.patch's
prepare_environment() which runs shibd in test mode, looks for the error above
and then automatically disables running as $DAEMON_USER
The associated warning is easily overseen as the logs are noisy and everything
is fine.
On stretch, there is a /lib/systemd/system/shibd.service which misses both the
automatism and the warning.
-- System Information:
Debian Release: 9.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages shibboleth-sp2-utils depends on:
ii adduser 3.115
ii init-system-helpers 1.48
ii libc62.24-11+deb9u3
ii libfcgi0ldbl 2.4.0-8.4+b1
ii libgcc1 1:6.3.0-18+deb9u1
ii liblog4shib1v5 1.0.9-3
ii libsaml9 2.6.0-4+deb9u1
ii libshibsp-plugins2.6.0+dfsg1-4+deb9u1
ii libshibsp7 2.6.0+dfsg1-4+deb9u1
ii libstdc++6 6.3.0-18+deb9u1
ii libsystemd0 232-25+deb9u4
ii libxerces-c3.1 3.1.4+debian-2+deb9u1
ii libxmltooling7 1.6.0-4+deb9u1
ii lsb-base 9.20161125
Versions of packages shibboleth-sp2-utils recommends:
ii openssl 1.1.0f-3+deb9u2
shibboleth-sp2-utils suggests no packages.
-- debconf-show failed
Bug#447595: closed by Paul Slootman <[EMAIL PROTECTED]> (Re: Bug#447595: rsync writes zeros to destination files on nfs volum
>There is: http://bugs.debian.org/ is the main page, >http://bugs.debian.org/447595 shows the log of this specific bug. Good to know - when I reported my problem to kernel.org, I got a reply with the URL to the report's page - there was no such URL in the debian answer. Dumb of me not to look for myself, but may I suggest that the URL gets added to the standard reply template? Would help the ignorant people :) >There's no log of your response there either, so unfortunately it seems >that your message was lost somewhere :-( Ok, but since the problem is solved, no need to worry about that. Thanks for your cooperation and the work you do! Hope not to (need to) hear from you any more :) Merry christmas! Bye, Andy -- Andreas Ley, Rechenzentrum, Universitaet Karlsruhe, D-76128 Karlsruhe, Germany [EMAIL PROTECTED], Phone: +49 721 608 6341, Fax: +49 721 32550 "If you spend more on coffee than on IT security, you will be hacked. What's more, you deserve to be hacked." -- White House cybersec. adviser Richard Clarke -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447595: closed by Paul Slootman <[EMAIL PROTECTED]> (Re: Bug#447595: rsync writes zeros to destination files on nfs volumes)
>As I didn't receive any feedback for almost 2 months, I'm now closing >this bug report. In fact, I did send feedback (on Mon, 22 Oct 2007 18:50:21 +0200 (CES)), but didn't receive any answer, so I guessed you classified the problem as non-debian related and silently discared it (AFAIK there's no web page where I could've looked up the status of the bug). I later found out, that other applications also show this bug, filed it as a kernel bug (http://bugzilla.kernel.org/show_bug.cgi?id=9315) and got told, that this was a known problem, with an existing but for several weeks unreleased patch. So yes, the bug should be closed, but with a "solved" state. Thanks for your support! Bye, Andy -- Andreas Ley, Rechenzentrum, Universitaet Karlsruhe, D-76128 Karlsruhe, Germany [EMAIL PROTECTED], Phone: +49 721 608 6341, Fax: +49 721 32550 "So that's 2 T-1s and a newsfeedwould you like clues with that?" -- Hillary Gorman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447595: rsync writes zeros to destination files on nfs volumes
Package: rsync Version: 2.6.9-2etch1 Severity: grave Justification: causes non-serious data loss At least when syncing the 2007-10-20T13:49:53 version of security.debian.org::debian-security/dists/etch/updates/main/binary-i386/Packages.gz on etch (2.6.9-2etch1) or sarge (2.6.4-6) to an nfs destination, rsync writes zeroes from 4c00 to 4fff in the destination file. Local destinations work fine, as does rsync on woody (2.5.5-0.6). Other source files haven't been tested yet. The same applies to a self-compiled (on woody) 2.6.9 with sources from rsync.samba.org - works on woody, fails on sarge and etch. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23.1 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages rsync depends on: ii libacl12.2.41-1 Access control list shared library ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries ii libpopt0 1.10-3lib for parsing cmdline parameters ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip rsync recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
