Bug#482170: log level 'packet' stops slapd from starting
Package: slapd Version: 2.3.30-5+etch1 Severity: normal The slapd.conf man files explains that log levels can be set in slapd.conf in various ways. One way is to list the names of the different levels eg. 'conns' or 'args'. When specifying 'packet' as log level, slapd fails to start, and loudly complains that log level 'packet' is not known. Note that specifying the log level via its integer value (2) does work. I'm not sure whether the man file is incorrect (and packet is not a correct log level name) or it's an issue in slapd. Whatever the root cause, adjusting the log level after having RTFM shouln't cause slapd to stop functioning. To reproduce this issue, alter yout slapd.conf to have the following log level: loglevel packet And restart slapd. Here's whay my syslog says: May 21 10:26:56 sketch slapd[16595]: @(#) $OpenLDAP: slapd 2.3.30 (Apr 5 2008 12:05:19) $ [EMAIL PROTECTED]:/build/buildd/openldap2.3-2.3.30/debian/build/servers/slapd May 21 10:26:57 sketch slapd[16595]: /etc/ldap/slapd.conf: line 25: loglevel unknown level packet May 21 10:26:57 sketch slapd[16595]: slapd stopped. -- 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-xen Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages slapd depends on: ii adduser3.102 Add and remove users and groups ii coreutils 5.97-5.3 The GNU core utilities ii debconf [debconf-2.0] 1.5.11etch1 Debian configuration management sy ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libdb4.2 4.2.52+dfsg-2 Berkeley v4.2 Database Libraries [ ii libiodbc2 3.52.4-5 iODBC Driver Manager ii libldap-2.3-0 2.3.30-5+etch1OpenLDAP libraries ii libltdl3 1.5.22-4 A system independent dlopen wrappe ii libperl5.8 5.8.8-7etch3 Shared Perl library ii libsasl2-2 2.1.22.dfsg1-8Authentication abstraction library ii libslp11.2.1-6.2 OpenSLP libraries ii libssl0.9.80.9.8c-4etch3 SSL shared libraries ii libwrap0 7.6.dbs-13Wietse Venema's TCP wrappers libra ii perl [libmime-base64-p 5.8.8-7etch3 Larry Wall's Practical Extraction ii psmisc 22.3-1Utilities that use the proc filesy Versions of packages slapd recommends: ii libsasl2-modules 2.1.22.dfsg1-8 Pluggable Authentication Modules f -- debconf information: slapd/allow_ldap_v2: false slapd/password_mismatch: slapd/fix_directory: true slapd/invalid_config: true shared/organization: nodomain slapd/upgrade_slapcat_failure: slapd/no_configuration: false slapd/migrate_ldbm_to_bdb: true slapd/move_old_database: true slapd/upgrade_slapadd_failure: slapd/suffix_change: false slapd/slave_databases_require_updateref: slapd/dump_database_destdir: /var/backups/slapd-VERSION slapd/autoconf_modules: true slapd/purge_database: false slapd/domain: nodomain slapd/backend: BDB slapd/dump_database: when needed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429929: Typo (repeated words) in /etc/dnsmasq.conf
Package: dnsmasq Version: 2.35-1 Severity: minor Tags: patch In the dnsmasq config file (/etc/dnsmasq.conf) some words are repeated. Several typo bugs exist, but I found none of them covering this. I've checked the latest version in unstable, but it still contains the double words. The patch is included, it's self-explanatory (assuming that's a real word :) ) -- 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-4-686 Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8) Versions of packages dnsmasq depends on: ii adduser 3.102Add and remove users and groups ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libdbus-1-3 1.0.2-1 simple interprocess messaging syst ii netbase 4.29 Basic TCP/IP networking system dnsmasq recommends no packages. -- no debconf information --- dnsmasq.conf.dist 2007-06-21 11:53:18.0 +0200 +++ dnsmasq.conf2007-06-21 11:53:59.0 +0200 @@ -204,7 +204,7 @@ # run dnsmasq --help dhcp to get a list. # Note that all the common settings, such as netmask and # broadcast address, DNS server and default route, are given -# sane defaults by dnsmasq. You very likely will not need any +# sane defaults by dnsmasq. You very likely will not need # any dhcp-options. If you use Windows clients and Samba, there # are some options which are recommended, they are detailed at the # end of this section. @@ -333,7 +333,7 @@ # whether it has a record of the lease or not. This avoids long timeouts # when a machine wakes up on a new network. DO NOT enable this if there's # the slighest chance that you might end up accidentally configuring a DHCP -# server for your campus/company accidentally. The ISC server uses the same +# server for your campus/company accidentally. The ISC server uses # the same option, and this URL provides more information: # http://www.isc.org/index.pl?/sw/dhcp/authoritative.php #dhcp-authoritative
Bug#289818: libpam-radius-auth: Sends out 127.0.0.1 as NAS-IP-Address
On Wed, 2005-01-19 at 11:49 +0100, Fabio Massimo Di Nitto wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fabio Massimo Di Nitto wrote:
| Joost De Cock wrote:
| | On Tuesday 11 January 2005 10:02, you shoved this in my mailbox:
| |
| |Joost De Cock wrote:
| || Package: libpam-radius-auth
| || Version: 1.3.16-2
| || Severity: important
| ||
| ||
| || I'm trying to set up Radius authentication on a stock Debian Sarge
| || installation.
| || The PAM Radius module sends out the loopback IP address as the 'NAS IP
| || Address' Radius Attribute. The RFC has the following to say about this
| || attribute:
| ||
| || This Attribute indicates the identifying IP Address of the NAS
| || which is requesting authentication of the user, and SHOULD
| || be unique to the NAS within the scope of the RADIUS
| || server.
| ||
| || So our Radius server (a vasco) responds with 'cannot lookup client
| || details' since that 127.0.0.1 address doesn't make sense.
Hi Joost,
I am checking the code right now and there are a couple of misterious things
that i would like to check together with you.
The ipaddr definition starts a bit up in the code:
~ gethostname(hostname, sizeof(hostname) - 1);
then a bit later:
~ if ((conf-server-ip.s_addr == ntohl(0x7f01)) || (!hostname[0])) {
~ipaddr = 0x7f01;
so what we should check is:
a) what is the result of hostname on your machine? you can check that on any
shell.
if it returns localhost than it is clear why the lib is sending 127.0.0.1 as
NAS IP
and the machine needs to properly resolv the hostname. Perhaps it is a
misconfiguration
in /etc/hosts or in the dns.
b) can you try defining the client_id= option in the config file? and set it
to your ip?
~ do not use hostname here since apparently the code doesn't try to resolve
it.
I never realized how hugly is this code :(
Here's the output from hostname and the contents of /etc/hosts:
eddie:~# hostname
eddie
eddie:~# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost eddie
I've changed the config file as follows:
eddie:~# cat /etc/pam.d/common-auth
auth sufficient /lib/security/pam_radius_auth.so debug
client-id=10.100.1.223
authrequiredpam_unix.so nullok_secure
accountsufficient /lib/security/pam_radius_auth.so
to no avail, I can still see the Radius request being sent out with the
NAS IP Address set to 127.0.0.1 and as a result, the Radius server sends
an access reject.
Let me know if there's more I can do :-/
joost
DISCLAIMER
This e-mail and any attached files are confidential and may be legally
privileged. If you are not the addressee, any disclosure, reproduction,
copying, distribution, or other dissemination or use of this communication is
strictly prohibited. If you have received this transmission in error please
notify A.S.T.R.I.D. nv/sa immediately and then delete this e-mail.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289818: libpam-radius-auth: Sends out 127.0.0.1 as NAS-IP-Address
On Wed, 2005-01-19 at 13:13 +0100, Fabio Massimo Di Nitto wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joost De Cock wrote: | On Wed, 2005-01-19 at 11:49 +0100, Fabio Massimo Di Nitto wrote: | | eddie:~# hostname | eddie | eddie:~# cat /etc/hosts | 127.0.0.1 localhost.localdomain localhost eddie ermh... hostname eddie would resolv as 127.0.0.1 try this: 127.0.0.1 localhost.localdomain localhost 10.100.1.223eddie | | I've changed the config file as follows: | eddie:~# cat /etc/pam.d/common-auth | auth sufficient /lib/security/pam_radius_auth.so debug | client-id=10.100.1.223 | authrequiredpam_unix.so nullok_secure | | accountsufficient /lib/security/pam_radius_auth.so | end the client_id= needs to go or should go in /etc/pam_radius_auth.conf Please can you test both the changes, one at a time? Oh boy, this is going to haunt me for the rest of my live. I changed the hosts file as you suggested and guess what, it works. I changed it back and added the client_id parameter, but that didn't seem to make a difference. So yes, it works when adding the ip address to the hostfile, and yes I'm a complete ass (guilty as charged). I'll go glue my shattered ego together now ;) I'm really sorry to bother you like this. I just didn't realize he was resolving the host name (C is like german to me, I understand enough to realize I don't get any of it). kind regards, joost DISCLAIMER This e-mail and any attached files are confidential and may be legally privileged. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify A.S.T.R.I.D. nv/sa immediately and then delete this e-mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
