Bug#877512: systemd unit for slapd

[Karsten Heymann]

Hi,

any news on this? Having a proper systemd unit for slapd would be quite nice.

Kind regards
Karsten

Bug#887443: ganeti: Syntax error in postinst crypto key upgrade command

[Karsten Heymann]

Package: ganeti
Version: 2.15.2-7+deb9u1
Severity: minor

Dear Maintainer,

in the postinst note informing about how to replace the keys, "RSA"
has to be lower case:


8<
root@debian-grade:~# gnt-cluster renew-crypto --new-ssh-keys
--ssh-key-type=RSA --ssh-key-bits=2048
Usage
=
  gnt-cluster renew-crypto [opts...]

gnt-cluster: error: option --ssh-key-type: invalid choice: 'RSA'
(choose from 'ecdsa', 'rsa', 'dsa')
>8

-- Package-specific info:
Version symlinks:
  /etc/ganeti/share -> /usr/share/ganeti/2.15
  /etc/ganeti/lib -> /usr/lib/ganeti/2.15
Cluster config version: 2.15.2
Address family: IPv4
Enabled hypervisors: kvm
kvm hypervisor parameters:
  acpi=True
  boot_order=disk
  cpu_cores=0
  cpu_mask=all
  cpu_sockets=0
  cpu_threads=0
  disk_aio=threads
  disk_cache=default
  disk_type=paravirtual
  kernel_args=ro
  kernel_path=/boot/vmlinuz-3-kvmU
  kvm_path=/usr/bin/kvm
  migration_bandwidth=32
  migration_downtime=30
  migration_mode=live
  migration_port=8102
  nic_type=paravirtual
  reboot_behavior=reboot
  root_path=/dev/vda1
  security_model=none
  serial_console=True
  serial_speed=38400
  spice_ip_version=0
  spice_playback_compression=True
  spice_tls_ciphers=HIGH:-DES:-3DES:-EXPORT:-DH
  spice_use_tls=False
  spice_use_vdagent=True
  use_chroot=False
  use_localtime=False
  user_shutdown=False
  vhost_net=False
  virtio_net_queues=1
  vnc_tls=False
  vnc_x509_verify=False
  vnet_hdr=True

-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (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 ganeti depends on:
ii  adduser  3.115
ii  ganeti-2.15  2.15.2-7+deb9u1
ii  ganeti-haskell-2.15  2.15.2-7+deb9u1
ii  ganeti-htools-2.15   2.15.2-7+deb9u1
ii  lsb-base 9.20161125
ii  python   2.7.13-2

Versions of packages ganeti recommends:
ii  drbd-utils   8.9.10-2
ii  ganeti-instance-debootstrap  0.16-2.1
ii  ndisc6   1.0.3-3
ii  qemu-kvm 1:2.8+dfsg-6+deb9u3

Versions of packages ganeti suggests:
pn  blktap-dkms  
pn  ganeti-doc   
pn  molly-guard  

-- Configuration Files:
/etc/default/ganeti changed [not included]

-- no debconf information

Bug#868765: freeradius: New upstream version 3.0.15 fixing security critical bugs

[Karsten Heymann]

Package: freeradius
Version: 3.0.12+dfsg-5
Severity: grave
Tags: upstream security
Justification: user security hole

Dear Maintainer,

the freeradius team released version 3.0.15 fixing several important
security issues found by a fuzzing analysis.

See:
http://freeradius.org/press/index.html#3.0.15
http://freeradius.org/security/fuzzer-2017.html

The following issues were found for v3 of freeradius up to 3.0.14:
- CVE-2017-10978. No remote code execution is possible. A denial of
service is possible.
- CVE-2017-10984. Remote code execution is possible. A denial of 
service is possible.
- CVE-2017-10985. No remote code execution is possible. A denial of
service is possible.

The following affect only the DHCP part of freeradius, which is seldomly used:
- CVE-2017-10983. No remote code execution is possible. A denial of
service is possible.
- CVE-2017-10986. No remote code execution is possible. A denial of
service is possible.
- CVE-2017-10987. No remote code execution is possible. A denial of
service is possible.

Please update the package accordingly.

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages freeradius depends on:
ii  freeradius-common  3.0.12+dfsg-5
ii  freeradius-config  3.0.12+dfsg-5
ii  libc6  2.24-11+deb9u1
ii  libcap21:2.25-1
ii  libfreeradius3 3.0.12+dfsg-5
ii  libgdbm3   1.8.3-14
ii  libpam0g   1.1.8-3.6
ii  libpcre3   2:8.39-3
ii  libperl5.245.24.1-3
ii  libpython2.7   2.7.13-2
ii  libreadline7   7.0-3
ii  libsqlite3-0   3.16.2-5
ii  libssl1.1  1.1.0f-3
ii  libtalloc2 2.1.8-1
ii  libwbclient0   2:4.5.8+dfsg-2+deb9u1+b1
ii  lsb-base   9.20161125

Versions of packages freeradius recommends:
pn  freeradius-utils  

Versions of packages freeradius suggests:
pn  freeradius-krb5
pn  freeradius-ldap
pn  freeradius-mysql   
pn  freeradius-postgresql  
pn  snmp   

-- no debconf information

Bug#868761: freeradius: New upstream version 2.2.10 fixing security critical bugs

[Karsten Heymann]

Subject: freeradius: New upstream version 2.2.10 fixing security critical bugs
Package: freeradius
Version: 2.2.5+dfsg-0.2
Justification: user security hole
Severity: grave
Tags: security upstream

The freeradius team released version 2.2.10 fixing several important
security issues found by a fuzzing analysis.

See:
http://freeradius.org/press/index.html#2.2.10
http://freeradius.org/security/fuzzer-2017.html

The following issues were found for v2 of freeradius up to 2.2.9:
- CVE-2017-10978. No remote code execution is possible. A denial of
service is possible.
- CVE-2017-10979. Remote code execution is possible. A denial of
service is possible.

The following affect only the DHCP part of freeradius, which is seldomly used:
- CVE-2017-10980. No remote code execution is possible. A denial of
service is possible.
- CVE-2017-10981. No remote code execution is possible. A denial of
service is possible.
- CVE-2017-10982. No remote code execution is possible. A denial of
service is possible.
- CVE-2017-10983. No remote code execution is possible. A denial of
service is possible.

I'm not sure what's the best way to proceed. As I assume updating the
package in oldstable to 2.2.10 is not a realistic option, my guess
would be that at least CVE-2017-10978 and CVE-2017-10979 should be
fixed in the code via backporting the relevant fixes. This is even
more critical as there is no backport of freeradius 3 in jessie, and
it is not possible to create or update backports for oldstable.

-- System Information:
Debian Release: 8.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages freeradius depends on:
ii  adduser3.113+nmu3
ii  ca-certificates20141019+deb8u3
ii  freeradius-common  2.2.5+dfsg-0.2
ii  libc6  2.19-18+deb8u10
ii  libfreeradius2 2.2.5+dfsg-0.2
ii  libgdbm3   1.8.3-13.1
ii  libltdl7   2.4.2-1.11+b1
ii  libpam0g   1.1.8-3.1+deb8u2
ii  libperl5.205.20.2-3+deb8u7
ii  libpython2.7   2.7.9-2+deb8u1
ii  libssl1.0.01.0.1t-1+deb8u6
ii  lsb-base   4.1+Debian13+nmu1
ii  ssl-cert   1.0.35

Versions of packages freeradius recommends:
ii  freeradius-utils  2.2.5+dfsg-0.2

Versions of packages freeradius suggests:
pn  freeradius-krb5
ii  freeradius-ldap2.2.5+dfsg-0.2
ii  freeradius-mysql   2.2.5+dfsg-0.2
pn  freeradius-postgresql  

-- Configuration Files:
/etc/freeradius/clients.conf changed [not included]
/etc/freeradius/eap.conf changed [not included]
/etc/freeradius/ldap.attrmap changed [not included]
/etc/freeradius/modules/ldap changed [not included]
/etc/freeradius/modules/pap changed [not included]
/etc/freeradius/sites-available/control-socket changed [not included]
/etc/freeradius/sites-available/default changed [not included]
/etc/freeradius/sites-available/inner-tunnel changed [not included]
/etc/freeradius/sql.conf changed [not included]
/etc/freeradius/users changed [not included]

-- no debconf information

Bug#864719: [Pkg-openldap-devel] Bug#864719: Bug#864719: Bug#864719: slapd: fails to configure when olcSuffix contains a backslash-escaped umlaut

[Karsten Heymann]

Some thoughts about the bug report (sorry for the borked first version
of this mail):

1. There is already code in openldap that maps dn's to paths in the
cn=config backend when it writes the config tree to the file system in
/etc/ldap/slapd.d. Maybe that code or at least its escaping logic can
be reused.
2. Wouldn't it be enough to use the database *number* to uniquely name
the database backup? This would remove the whole problem.
3. In order to use the basedn as a file name that can be safely used
in shell script, what about a whitelist approach that replaces or
encodes any character that is not a (ascii) letter, number, dash or
underscrore with something safe/sane? Seems a better way than the
approach where only certain "bad" characters are replaced. Unicode is
huge, and using a whitelist of known good characters seems a more
defensive approach, especially when prefixed with the database number.
So "o=|\/|y Über Company" would become something like
"db2-yberCompany".

Feedback appreciated.

Bug#864719: [Pkg-openldap-devel] Bug#864719: Bug#864719: Bug#864719: slapd: fails to configure when olcSuffix contains a backslash-escaped umlaut

[Karsten Heymann]

Hi guys,

please allow me to add some thoughts to this bug report:

1. Is there any way to re-use the way dn's are mapped to paths by the
cn=config backend for this purpose?

2017-06-14 12:59 GMT+02:00 Thorsten Glaser :
> On Tue, 13 Jun 2017, Ryan Tandy wrote:
>
>>> Hi Thorsten, thanks for reporting this.
>
> You’re welcome.
>
>>> (But I'm curious: how did you wind up with the escaped form on wheezy?  For
>>> me, slapd via ldapmodify and slapadd both write it in base64.)
>
> I’ve first set up the test server, then, in order to reproduce another
> bug mich later, we got an actual LDIF from the customer, so I had to
> change the base DN and import a partial tree of theirs. I used the DN
> as it was written in their LDIF.
>
> This is also the reason the base DN doesn’t match the domain debconf.
>
>> For the backslashes case, the attached ought to do. Would you be willing to
>> test it? It should apply to /var/lib/dpkg/info/slapd.postinst.
>
> The patch works as-is, however, as a shell author and informed about
> writing portable shell scripts, I’m a tad concerned about the use of
> the accent gravis form of command substitution, especially as it can
> *not* be quoted both inside and outside (which is not the case here,
> but someone might decide to do that in the future).
>
> Therefore I’m urging you to change the last addition to…
> +   grep "olcDbDirectory:" $(grep -Fl "olcSuffix: $1" 
> ${SLAPD_CONF}/cn\=config/olcDatabase*.ldif) | cut -d: -f 2 | sed 's/^  *//g'
> … or possibly, quoting, just to be safe:
> +   grep "olcDbDirectory:" "$(grep -Fl "olcSuffix: $1" 
> "${SLAPD_CONF}/cn\=config/olcDatabase*.ldif")" | cut -d: -f 2 | sed 's/^  
> *//g'
>
> (Side note, I cringe every time I see such grep|cut|sed thingies,
> this can almost certainly be done with just sed¹.)
>
>> Still thinking about the base64 case. Since we use the suffix to name files
>> and directories for backup and restore, I guess it's most robust to just use
>> the base64 directly - even if it's not quite as nice for showing to users.
>
> Remember that that can span multiple lines (although this is also true
> for the non-base64 base). I usually just read LDIF line by line in my
> shell scripts concatenating as needed, but for quick, I’ve found this
> useful:
>
> cat² x.ldif | tr '\n' '\001' | sed $'s/\001 //g' | tr '\001' '\n' >y
>
> Note that $'…' needs a shell supporting this ksh93ism / recent addition
> to POSIX (i.e. ksh93, GNU bash, mksh, zsh, but not dash). For this
> purpose it’s commonly accepted to change the shebang of the maintainer
> script to #!/bin/bash (which is still Essential currently). Another
> option would be to embed the control character directly into the script.
> (Actually, perhaps GNU sed can handle 's/\001 //g' just fine? I’m more
> used to BSD sed which honours the standard more.)
>
> bye,
> //mirabilos
>
> ① I’m thinking of something along the lines of:
>
>   sed --posix -n '/^olcDbDirectory: *\([^ ].*\)$/s//\1/p' "$(grep -Fl 
> "olcSuffix: $1" "${SLAPD_CONF}/cn\=config/olcDatabase*.ldif")"
>
>   I think this fully replaces that line of yours.
>
> ② Not a useless use of cat but an example.
>
> --
> tarent solutions GmbH
> Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
> Tel: +49 228 54881-393 • Fax: +49 228 54881-235
> HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
>
> ___
> Pkg-openldap-devel mailing list
> pkg-openldap-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-openldap-devel

Bug#689025: Most probably a rsyslog configuration problem

[Karsten Heymann]

Hi,

this may be not an openldap, but a rsyslog configuration problem. We
experienced this problem as well with other services (mainly mail
servers) logging to rsyslog via tcp syslog when the remote loghost was
not responding. To the bug reporter: Have you configured a (disk,
memory or combined) queue in rsyslog? As described in
http://www.rsyslog.com/doc/queues.html, this is the recommended setup
to deal with such outages. If no, this bug can probably be closed.

Best
Karsten


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

Bug#592465: cacti: New upstream version available

[Karsten Heymann]

Package: cacti
Version: 0.8.7e-4
Severity: wishlist

Hi,

there's a new stable release 0.8.7g available:

http://www.cacti.net/release_notes_0_8_7g.php

Yours
Karsten
-- System Information:
Debian Release: 5.0.5
  APT prefers stable
  APT policy: (600, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.18-6-xen-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash



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

Bug#578599: python-django-extensions: Should build-depend on python (= 2.5.4-1~)

[Karsten Heymann]

Package: python-django-extensions
Version: 0.4.2pre+git200911182050
Severity: normal

Hi,

trying to build the package on lenny (while creating a backport) fails
with

$ LC_ALL=C debuild
debian/rules:3: /usr/share/python/python.mk: No such file or directory
dh --with quilt /usr/share/python/python.mk
dh: Unknown sequence /usr/share/python/python.mk (choose from: binary 
binary-arch binary-indep build clean install)
make: *** [/usr/share/python/python.mk] Error 1

This seems to be due to a missing build-dependency to python
(= 2.5.4-1~) which is the first version containing python.mk (according
to the changelog).

Yours
Karsten
-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (600, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.18-6-xen-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash



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

Bug#450642: dh-make-perl: Do not create a -1 Debian revision by default.

[Karsten Heymann]

tag 450642 - unreproducible wontfix
thanks


David,

your example does not apply if the package is put into a local
repository. Changing the default Package revision (or at least be able
to configure it, see #387135) would IMO certainly make sense.

Yours
Karsten



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

Bug#450642: dh-make-perl: Do not create a -1 Debian revision by default.

[Karsten Heymann]

gregor herrmann schrieb:
 On Thu, 11 Mar 2010 09:38:49 +0100, Karsten Heymann wrote:
 Changing the default Package revision (or at least be able
 to configure it, see #387135) would IMO certainly make sense.
 
 It seems we can merge these two bug reports, right?

Yes, #387135 is a superset of this one.

Yours
Karsten



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

Bug#387135: Please reconsider wontfix decision

[Karsten Heymann]

Hi,

I strongly opt to reconsider applying this patch. Let me provide an use
case: In our company, we often package CPAN packages that are not (yet)
in debian. We always give the initial package the version
CPANVERSION-1~bc.1 so if the package should be added to debian later,
the version of our package will always be lower than the version in the
debian repository. Having to parse the CPAN version and construct the
version number manually is at least clumsy.

Yours
Karsten



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

Bug#569973: New upstream version 1.4b9 available

[Karsten Heymann]

Package: ndoutils
Version: 1.4b7-11

There is a new upstream version 1.4b9 of ndoutils available at
http://sourceforge.net/projects/nagios/files/.

Yours
Karsten



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87iq9yv9rb@ara.blue-cable.net

Bug#539712: otrs2: New upstream version available: 2.4.2

[Karsten Heymann]

Package: otrs2
Version: 2.2.7-2~local.1
Severity: wishlist

Hi,

there is a new major upstream version 2.4.2 of otrs available at
http://otrs.org/releases/2.4.2/.

Yours
Karsten
-- System Information:
Debian Release: 4.0
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-fza-028stab051.1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages otrs2 depends on:
ii  adduser   3.102  Add and remove users and groups
ii  apache2   2.2.3-4+etch10 Next generation, scalable, extenda
ii  apache2-mpm-worker [httpd 2.2.3-4+etch10 High speed threaded model for Apac
ii  dbconfig-common   1.8.29+etch1   common framework for packaging dat
ii  debconf   1.5.11etch2Debian configuration management sy
ii  libauthen-sasl-perl   2.10-1 Authen::SASL - SASL Authentication
ii  libcrypt-passwdmd5-perl   1.3-8  interoperable MD5-based crypt() fo
ii  libdate-pcalc-perl1.2-2  Perl module for Gregorian calendar
ii  libdbi-perl   1.53-1etch1Perl5 database interface by Tim Bu
ii  libemail-valid-perl   0.179-1Check validity of Internet email a
ii  libio-stringy-perl2.110-2Perl5 modules for IO from scalars 
ii  libmailtools-perl 1.74-1 Manipulate email in perl programs
ii  libmime-perl  5.420-0.1  Perl5 modules for MIME-compliant m
ii  libtext-diff-perl 0.35-2 Perform diffs on files and record 
ii  libxml-parser-perl2.34-4.2   Perl module for parsing XML files
ii  perl  5.8.8-7etch6   Larry Wall's Practical Extraction 
ii  ucf   2.0020 Update Configuration File: preserv

Versions of packages otrs2 recommends:
ii  aspell  0.60.4-4 GNU Aspell spell-checker
ii  libapache2-mod-perl22.0.2-2.4Integration of perl with the Apach
ii  libdbd-mysql-perl   3.0008-1 A Perl5 database interface to the 
ii  libdbd-pg-perl  1.49-2+etch1 a PostgreSQL interface for Perl 5 
ii  libgd-graph-perl1.43.08-2.1  Graph Plotting Module for Perl 5
ii  libgd-text-perl 0.86-3.1 Text utilities for use with GD
pn  postgresql-8.2 | mysql-serv none   (no description available)
ii  procmail3.22-16  Versatile e-mail processor

-- debconf-show failed



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

Bug#484424: Bug is not fixed in Version 3.1.1-3

[Karsten Heymann]

Hello

the changelog claims this bug to be closed, but the package still
shows this behaviour:

$ grep /var/lib/dhcp dhcp3-3.1.1/debian/patches/dhcp-3.1.0-ldap-code.dpatch 
+#define _PATH_DHCPD_DB/var/lib/dhcpd/dhcpd.leases
$ head -1 dhcp3-3.1.1/debian/changelog
dhcp3 (3.1.1-3) unstable; urgency=low

$ grep dhcp /var/log/syslog
Oct 10 14:08:08 lenny dhcpd: Internet Systems Consortium DHCP Server V3.1.1
Oct 10 14:08:08 lenny dhcpd: Copyright 2004-2008 Internet Systems Consortium.
Oct 10 14:08:08 lenny dhcpd: All rights reserved.
Oct 10 14:08:08 lenny dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
Oct 10 14:08:08 lenny dhcpd: Can't open lease database 
/var/lib/dhcpd/dhcpd.leases: No such file or directory --
Oct 10 14:08:08 lenny dhcpd:   check for failed database rewrite attempt!
Oct 10 14:08:08 lenny dhcpd: Please read the dhcpd.leases manual page if you
Oct 10 14:08:08 lenny dhcpd: don't know what to do about this.


Yours
Karsten

-- 
Karsten Heymann



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#500025: rancid-core: tmp patch does not always delete temporary directory

[Karsten Heymann]

Package: rancid-core
Version: 2.3.2~a8-2~bc.1
Severity: normal
Tags: patch


In line 74 of 06_tmp_security.dpatch, `rm -f' is run on the directory
$MYTMPDIR, which fails due to the missing `-r' parameter to rm.

74  +rm -f $MYTMPDIR $DIR/routers.single $DIR/routers.failed

should be

74  +rm -fr $MYTMPDIR $DIR/routers.single $DIR/routers.failed

(note: the bug report is done from an unchanged backport for etch, but
that shouldn't change the bug behaviour.)

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages rancid-core depends on:
ii  adduser3.102 Add and remove users and groups
ii  cvs1:1.12.13-8   Concurrent Versions System
ii  debconf [debconf-2.0]  1.5.11etch2   Debian configuration management sy
ii  expect 5.43.0-8  A program that can automate intera
ii  iputils-ping [ping]3:20020927-6  Tools to test the reachability of 
ii  libc6  2.3.6.ds1-13etch7 GNU C Library: Shared libraries
ii  openssh-client 1:4.3p2-9etch3Secure shell client, an rlogin/rsh
ii  passwd 1:4.0.18.1-7  change and administer password and
ii  perl   5.8.8-7etch3  Larry Wall's Practical Extraction 
ii  subversion 1.4.2dfsg1-2  Advanced version control system

rancid-core recommends no packages.

-- debconf information:
* rancid/damn_upgrade:
* rancid/warning:
* rancid/go_on: true



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#482025: openssh-client: Hashed keys by ssh-keyscan are not accepted by ssh client.

[Karsten Heymann]

Package: openssh-client
Version: 1:4.3p2-9etch2
Severity: normal

Hi,

while trying to preseed my known_hosts file with keys of our servers, i
stumbled upon that

  ssh-keyscan -t rsa,dsa $TARGET,$TARGET_IP  ~/.ssh/known_hosts 
  ssh $TARGET

  (WARNING: overwrites ~/.ssh/known_hosts, use a dedicated test user!)

works just fine (don't need to confirm the hostkey of $TARGET any
more), but when creating the recommended hashed hostkeynames with 

  ssh-keyscan -H -t rsa,dsa $TARGET,$TARGET_IP  ~/.ssh/known_hosts 
  ssh $TARGET

I'm still asked by ssh to confirm the hostkey. So there seems
to be some problem with the hashing algorithm in ssh-keyscan.

Yours
Karsten


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages openssh-client depends on:
ii  add 3.102Add and remove users and groups
ii  deb 1.5.11etch1  Debian configuration management sy
ii  dpk 1.13.25  package maintenance system for Deb
ii  lib 2.3.6.ds1-13etch5GNU C Library: Shared libraries
ii  lib 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 common error description library
ii  lib 2.9.cvs.20050518-2.2 BSD editline and history libraries
ii  lib 1.4.4-7etch5 MIT Kerberos runtime libraries
ii  lib 5.5-5Shared libraries for terminal hand
ii  lib 0.9.8c-4etch3SSL shared libraries
ii  pas 1:4.0.18.1-7 change and administer password and
ii  zli 1:1.2.3-13   compression library - runtime

openssh-client recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#453286: cacti-cactid: new upstream version available

[Karsten Heymann]

Package: cacti-cactid
Severity: minor

Hello,

there is a new upstream version of cactid available, in which is has been 
renamed to spine by upstream:

http://cacti.net/spine_download.php

Bug taggeg as minor, not whishlist, as cacti 0.8.7 (already in unstable/testing)
probably won't work with cactid so an update would be nice.

Thanks,
Karsten

-- 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.18-5-xen-686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#416253: gs-esp should have lower alternatives score than gs-gpl

[Karsten Heymann]

Package: gs-esp
Version: 8.15.3.dfsg.1-1

The gs-esp-Package in etch is much older (8.15) than gs-gpl (8.54), but it
gets the /usr/bin/gs link because of it's higher alternatives score (60
compared to 20 for gs-gpl). I think that's a bug.

Yours
Karsten

Bug#380714: lyx: helvetica font used in User Guide export can't find font against texlive distribution

[Karsten Heymann]

Marc J. Driftmeyer schrieb:

Package: lyx
Version: 1.4.2-2
Severity: minor

User Guide exports to pdflatex fine and upon not finding helvetica
attempts to substitute a suitable font in Acrobat 7 but fails to meet
this need.


This is most likey caused by a misconfigured TeX. All current TeX 
distributions should embed all fonts used in the document into the pdf, 
even the standard postscript fonts. Anything else is a bug in your TeX 
distribution or the result of a broken installation. In any case, this 
behaviour has nothing to do with LyX.


Yours
Karsten


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#380714: lyx: helvetica font used in User Guide export can't find font against texlive distribution

[Karsten Heymann]

Hi Marc,

you really should avoid TOFU. Thanks.

Marc J. Driftmeyer schrieb:

Acrobat attempts to substitute for a suitable font.


It really shouldn't have to. All files created by pdftex *should*
include any used font inside the pdf, be it the lmodern font family or
those standard postscript fonts. You can controll it with the pdffonts
command, it should output something like

[EMAIL PROTECTED]:~/temp$ pdffonts testlmodern.pdf
name type emb sub uni object ID
  --- --- --- -
ETWFKE+LMRoman10-Regular Type 1   yes yes no   6  0
DUJNAJ+LMSans10-Regular  Type 1   yes yes no   9  0
CILUZO+LMTypewriter10-RegularType 1   yes yes no  12  0

for a file with the lmodern fonts in use and

[EMAIL PROTECTED]:~/temp$ pdffonts testpsfonts.pdf
name type emb sub uni object ID
  --- --- --- -
PDEAGN+NimbusRomNo9L-ReguType 1   yes yes no   6  0
JVYZPK+NimbusSanL-Regu   Type 1   yes yes no   9  0
YPCUAQ+NimbusMonL-Regu   Type 1   yes yes no  12  0

with the Nimbus-Copies of the standard Postscript fonts bundled with TeX.

For testing you can use the following LaTeX code:

\documentclass{article}
\usepackage[T1]{fontenc}
\IfFileExists{lmodern.sty}{\usepackage{lmodern}}{%
\usepackage[scaled=0.92]{helvet}
\usepackage{mathptmx}
\usepackage{courier} }
\begin{document}
\noindent
\textrm{Roman font}\\
\textsf{Sansserif font}\\
\texttt{Typewriter font}
\end{document}

put it in testfont.tex and run 'pdflatex testfont'. The outout should 
end with

...
(/usr/share/texmf/tex/latex/lm/lmodern.sty) (./testfont1.aux)
(/usr/share/texmf/tex/latex/lm/t1lmr.fd)
(/usr/share/texmf/tex/latex/lm/t1lmss.fd)
(/usr/share/texmf/tex/latex/lm/t1lmtt.fd) 
[1{/var/lib/texmf/fonts/map/pdftex/up
dmap/pdftex.map}] (./testfont1.aux) 
){/usr/share/texmf/fonts/enc/dvips/lm/cork-

lm.enc}/usr/share/texmf/fonts/type1/public/lm/lmtt10.pfb/usr/share/texmf/fon
ts/type1/public/lm/lmss10.pfb/usr/share/texmf/fonts/type1/public/lm/lmr10.pfb

Output written on testfont1.pdf (1 page, 28852 bytes).
Transcript written on testfont1.log.


The issue is with this code:

% set fonts for nicer pdf view 
\IfFileExists{lmodern.sty}{\usepackage{lmodern}}{% 
\usepackage[scaled=0.92]{helvet} \usepackage{mathptmx} 
\usepackage{courier} }


The code is perfectly fine.


TexLive puts lmodern.sty under /usr/share/texmf/tex/latex/lm


Yes, that means \IfFileExists{lmodern.sty} will find it and only
\usepackage{lmodern} will be executed, not the other \usepackage's.


Tetex-base puts lmodern.sty under the same pathway. You can rule out
it being an improperly installed tex distribution or you can deduce
both the tetex and texlive distributions from Debian are broken
against what LyX expects to find lmodern.sty.


Sorry again, the place is fine. What happens afterwards seems to be broken.

Interestingly, if I remove the 
\IfFileExists{lmodern.sty}{\usepackage{lmodern}}{%}


and leave:

\usepackage{lmodern} \usepackage[scaled=0.92]{helvet} 
\usepackage{mathptmx} \usepackage{courier}


That means that first lmodern is loaded for roman, sansserif, typewriter
and math fonts and afterwars all these settings are overwritten to use
Times for Roman and math, Helvetica for Sansserif and Courier for
Typewriter. So nothing regarding lmodern is left and the lmodern bug is 
not triggered.


the User Guide export to pdf via pdflatex works flawlessly. The 
offending area is the code for \IfFileExists.


Sorry no, your lmodern-Installation is broken (which isn't too unlikely,
there have been some problems with it in the past). Please file a bug
against the lmodern package. With lyx everything is fine. (But thanks
alot for investigating this issue so deeply, opensource software lives
from participation!)

Yours,
Karsten


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]