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: 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 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]
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
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. I've tried an entire day to resolve this, passing it all sorts of parameters, but I couldn't get it to work. I was so sure that the problem was caused by sending out the loopback interface that I downloaded the src package, and hacked the pam_radius_auth.c file with the following line below line 733: ipaddr = 0x0a6401df; Yep, that's right, I just hardcoded 10.100.1.223 since that's my ip address and that's what I want the module to sent out. (I was really losing it at this time). If I had any skills at all, I'd try to be less of a brute, but I'm no developer. After this, I build the .deb package, installed it, and radius authentication works flawlessly (as long as I don't change my IP address) ; ) So, this feels like a bug to me. It shouldn't sent out the loopback address, but the correct address. Unless I'm running my Radius server on the same host, this keeps me from using radius authentication. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-1-386 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages libpam-radius-auth depends on: ii debconf 1.4.30.10Debian configuration management sy ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an ii libpam0g0.76-22 Pluggable Authentication Modules l -- debconf information: libpam-radius-auth/fixperms: true libpam-radius-auth/permnote: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]