Bug#433187: linux-2.6 - [sparc64-smp] produces unkillable processes
Bernd Zeimetz wrote: Hi, We (David Miller and I) are already working on this. We finally got some info dump from a debugging patched kernel and I expect we will have a fix within the next 3/4 weeks. From our first look it seems like a futex bug and some users have reported that the latest 2.6.23-rcX do not show this behavior. Clearly we also want to figure out a fix for .22. Last night an Ultrasparc II machine here shot itself again, it was running fine for days with a .22 kernel which has was patched with the diff from 179c85ea53bef807621f335767e41e23f86f01df Seems this doesn't fix the problem completely, but it is not as bad as before, it just takes much longer to produce hanging processes. Behaviour is still much worse on Ultrasparc III machines like lebrun.d.o and another machine here. Last kernel I've tried was 2.6.23-rc6-git7. Since 179c85ea53bef807621f335767e41e23f86f01df behaviour became better, the processes are only dead, before that patch the machine was pretty much frozen and didn't even react on stop+a anymore. Is there any new patch we can give a try? No, not yet. I passed all the info to David a couple of days ago including Bastian simple test case of running dpkg-query a few tons of times in a raw so that should speed up the fix. Unfortunately we depend on David to have time to look at it so we just need to be a bit patience. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433187: linux-2.6 - [sparc64-smp] produces unkillable processes
Josip Rodin wrote: On Tue, Sep 04, 2007 at 06:16:05AM +0200, Fabio Massimo Di Nitto wrote: #433187 is the bug that has killed the buildds on lebrun and spontini, right? AIUC, yes. at least i can reproduce that on my buildd. Hi guys, We (David Miller and I) are already working on this. We finally got some info dump from a debugging patched kernel and I expect we will have a fix within the next 3/4 weeks. From our first look it seems like a futex bug and some users have reported that the latest 2.6.23-rcX do not show this behavior. Clearly we also want to figure out a fix for .22. Fabio I should mention that lebrun.d.o is still dead since the last attempt (ssh unresponsive since 2007-08-30 ~21:25), when it was running a 2.6.22.5 with one davem patch applied (one line in kernel/futex_compat.c). If you need something more done to lebrun, such as kicking it back to life, just tell me... If you have console access, it would be good to get a processor dump by break + p. anyway we were able to reproduce the problem by doing some fancy building on Niagara and that already isolate the problems to a more generic bit of the code rather than CPU specific. I personally have no say on how buildds should be managed.. i guess it's up to you guys if you want to kick it back. If you do so just make sure you can grab CPU register dumps from console. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433187: linux-2.6 - [sparc64-smp] produces unkillable processes
Josip Rodin wrote: On Tue, Sep 04, 2007 at 10:17:33AM +0200, Fabio Massimo Di Nitto wrote: I should mention that lebrun.d.o is still dead since the last attempt (ssh unresponsive since 2007-08-30 ~21:25), when it was running a 2.6.22.5 with one davem patch applied (one line in kernel/futex_compat.c). If you need something more done to lebrun, such as kicking it back to life, just tell me... If you have console access, it would be good to get a processor dump by break + p. If you do so just make sure you can grab CPU register dumps from console. At this point I'm not sure if it would be possible to see them even if I plugged the monitor into the VGA port, because I redirected output to rsc-console. sigh Probably not in this dead session, but you can always plug monitor and keyboard, change OBP defaults to use them and boot the machine.. let the buildd run again until the process will get stucked and then get the dump. While i believe that we already have enough info, I am pretty sure that some more won't hurt. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433187: linux-2.6 - [sparc64-smp] produces unkillable processes
Martin Zobel-Helas wrote: Hi, On Tue Sep 04, 2007 at 10:17:33 +0200, Fabio Massimo Di Nitto wrote: Josip Rodin wrote: On Tue, Sep 04, 2007 at 06:16:05AM +0200, Fabio Massimo Di Nitto wrote: #433187 is the bug that has killed the buildds on lebrun and spontini, right? AIUC, yes. at least i can reproduce that on my buildd. Hi guys, We (David Miller and I) are already working on this. We finally got some info dump from a debugging patched kernel and I expect we will have a fix within the next 3/4 weeks. From our first look it seems like a futex bug and some users have reported that the latest 2.6.23-rcX do not show this behavior. Clearly we also want to figure out a fix for .22. Fabio I should mention that lebrun.d.o is still dead since the last attempt (ssh unresponsive since 2007-08-30 ~21:25), when it was running a 2.6.22.5 with one davem patch applied (one line in kernel/futex_compat.c). If you need something more done to lebrun, such as kicking it back to life, just tell me... If you have console access, it would be good to get a processor dump by break + p. I can easily reproduce that with my Sparc Ultra60 here, which is running as buildd for experimental. The machines has the very same problem. I will try that tonight. It is also worth checking with .23-rcX since it has been reported to be working. Best you fetch me on IRC, nick zobel on IRCnet, OFTC and freenode. Unlikely to be around at night. Wife, kid, etc.. If we can get the patch down to something which can also be applied to a plain Etch kernel, i would also speak with Dann if he as Etch Kernel Maintainer would be willing to accept the patch for the next point release kernel. I (as stable release manager) would be willing to accept it, if Dann is supporting this. I see no problem with this, assuming it is isolated enough. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433187: linux-2.6 - [sparc64-smp] produces unkillable processes
Bastian Blank wrote: On Tue, Sep 04, 2007 at 10:17:33AM +0200, Fabio Massimo Di Nitto wrote: anyway we were able to reproduce the problem by doing some fancy building on Niagara and that already isolate the problems to a more generic bit of the code rather than CPU specific. I'm able to reproduce it with something like: for i in $(seq 0 1); do (dpkg-query python2.5-minimal /dev/null ); done But with 2.6.23-rc4 this dies with the niagara problem but the futex one. What Niagara problem? Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433187: linux-2.6 - [sparc64-smp] produces unkillable processes
Bastian Blank wrote: On Tue, Sep 04, 2007 at 11:07:32AM +0200, Fabio Massimo Di Nitto wrote: Bastian Blank wrote: But with 2.6.23-rc4 this dies with the niagara problem but the futex one. What Niagara problem? It dies on a T2000 within 30 minutes, depending on the load. You said this is a Niagara-only problem. I was not able to build a kernel on it before it crashed. Bastian I said that we were able to reproduce it on Niagara, and that excludes cpu specific code from where to look for this bug. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433187: linux-2.6 - [sparc64-smp] produces unkillable processes
Martin Zobel-Helas wrote: Hi, On Tue Sep 04, 2007 at 00:09:53 +0200, Josip Rodin wrote: Hi, #433187 is the bug that has killed the buildds on lebrun and spontini, right? AIUC, yes. at least i can reproduce that on my buildd. Greetings Martin Hi guys, We (David Miller and I) are already working on this. We finally got some info dump from a debugging patched kernel and I expect we will have a fix within the next 3/4 weeks. From our first look it seems like a futex bug and some users have reported that the latest 2.6.23-rcX do not show this behavior. Clearly we also want to figure out a fix for .22. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433667: Please OK licence change for silo-installer udeb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frans Pop wrote: (Contributors to silo-installer BCC'ed.) We were recently alerted to the fact that the source for silo-installer udeb did not include a copyright file. After checking with Ben Collins, the original author, I have added a copyright statement as in [1] in the D-I SVN repository (gpl version 2 or later; text consistent with other copyright files in the installer). As this can be considered a licence change and as you have contributed to silo-installer in the past, please OK this licence change by replying to [EMAIL PROTECTED] with a short statement of your agreement. Thanks in advance, Frans Pop [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=433667 http://svn.debian.org/wsvn/d-i/trunk/packages/arch/sparc/silo-installer/debian/copyright?op=filerev=48452sc=0 You have my full agreement/support/everything you need to make this right. Fabio - -- I'm going to make him an offer he can't refuse. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnlwbhCzbekR3nhgRAgGEAJ9D97J7uE+lAc0tw6AxCdIWAPe5mwCcDcss Ka2nHiNOArNc0wVkCIKBLFA= =Ztfx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396023: LVM removal will not work properly with the applied patch
Hi guys, I had a long conversation with Frans on IRC about this bug and the applied patch. I am seeing different issues such as: 1) take a fresh disk with no lvm 2) install using automatic lvm setup and it will work 3) install on it again this time not using lvm and it will work 4) install again this time using lvm and it will fail The problem is that at #4 the disk has no partitions type LVM but the lvm metadata from #2 are still there. pvscan still works but all other lvm operations will correctly report that there is an error. Basically #3 did not wipe the disk properly. I did dig into it and found out that partman-auto wipe_disk depends on dmsetup-udeb, but this depends is not declared. Usage of dmsetup requires you to make sure that either dm-mod module is loaded or built-in the kernel. this check is not done and dmsetup invokations will fail. In order to trigger the code to run dm_wipe_lvm the lv/vg needs to be enabled or dmsetup deps will simply not find them. dm_wipe_lvm uses a set of shared functions calls to lvm but i don't think a dependency has been expressed to guarantee that they are available. I have different ideas on how to approach the problem but in one way or another they might hit other kinds of installations (Colin Watson mentioned low-mem as one of them). My suggestion is: - Make partman-auto depends on the proper bits that it is actually using. - Add code to modprobe/verify that dm-mod is available. - Fix dm_wipe_lvm to not require dmsetup to detect the volumes and use lvm2 tools instead (I am not happy to execute vgchanges if we can avoid it). Any other suggestion is welcome. Fabio PS CC me on reply. -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429117: please update/request removal of your package
Gerfried Fuchs wrote: Package: libapache-mod-auth-radius Severity: serious Version: 1.5.7-6 Hi there! Due to the recent removal of apache (including it's accompanied packages of apache-common, apache-dbg, apache-dev, apache-doc, apache-perl and apache-ssl) and libapache-mod-perl your package most propably isn't able to get installed or built anymore. These are the problems your package currently has: libapache-mod-auth-radius (dependency): apache-common (= 1.3.28-1) Please either send the ftp team a removal request for your package if it isn't able to work with apache2, or update it to build (only) packages for apache2. Thanks in advance, Hi, perfect! finally 1.x is dead.. go ahead and remove it right away. Thanks Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#191055: nss cache in mozilla does not expire
Mike Hommey wrote: On Mon, Apr 28, 2003 at 10:48:28AM +0200, Fabio Massimo Di Nitto [EMAIL PROTECTED] wrote: Package: mozilla-browser Version: 2:1.3-4 Severity: important Hi all, the problem is farly simple. open mozilla. access the server. change the ip/dns entry on server. reaccess the server. mozilla keeps accessing the old one even after 3/4 days. The nss cache should expire otherwise please remove the cache feature because it is extremely annoying that users have to restart mozilla to be sure they are accessing the correct web site. Without considering that there might be some security issues involved in this behaviour since a crafted attack might let users access a fake server. Were you by any chance using nscd ? Mike No, never used nscd. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#191055: nss cache in mozilla does not expire
Mike Hommey wrote: Okay, I could reproduce half of the problem, but things evolved a few months after you filed your bug, according to upstream CVS. They changed their DNS service so that it would only cache DNS entries for 60 seconds (which you can change if you set the network.dnsCacheExpiration preference to another value) for 20 entries max (changeable with network.dnsCacheEntries). I think this is enough for this bug to be closed. If not, I could set these 2 preferences to 0 to disable DNS caching. Mike Go ahead and close it. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414926: libpam-radius-auth : [INTL:pt] Portuguese translation for debconf messages
Traduz - Portuguese Translation Team wrote: Package: libpam-radius-auth Version: 1.3.16-4.3 Tags: l10n, patch Severity: wishlist Portuguese translation for libpam-radius-auth's debconf messages. Translator: Ricardo Silva ardoric _at_ gmail.com Feel free to use it. For translation updates please contact 'Last Translator' or the Portuguese Translation Team traduz _at_ debianpt.org. guys please go ahead and upload the translations. I absolutely don't mind people to do that without my permission. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410536: libpam-radius-auth: [INTL:de] initial German debconf translation
Helge Kreutzmann wrote: Package: libpam-radius-auth Version: 1.3.16-4.2 Severity: wishlist Tags: patch l10n Please find the initial German debconf translation for libpam-radius-auth attached. Please go ahead and upload. I don't mind direct NMU for translations. Thanks Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#172962: #172962: xfree86: want IPv6 support
Brice Goglin wrote: Hi, A couple years ago, you both reported a bug to the Debian BTS about IPv6 support in the XFree86 server. It was suppose to work with Xorg. Did you actually get it to work nowadays. If so, I will close this bug. Brice go ahead and close. it works with Xorg. Fabio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405445: libpam-radius-auth: [INTL:es] Spanish po-debconf translation
Hi guys, Javier Ruano wrote: Package: libpam-radius-auth Priority: minor Tags: patch l10n Attached is the first spanish translation for this package's templates. Javi. Don't wait for me, just NMU the package and get the translation in. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387659: libpam-radius-auth 1.3.16-4.1 NMU diff
Christine Spang wrote: Package: libpam-radius-auth Version: 1.3.16-4.1 Severity: important Tags: patch Hey, The NMU diff file for libpam-radius-auth 1.3.16-4.1 is attached here. Thanks! Hi Christine, thanks for the wonderful job. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379498: libpam-radius-auth: FTBFS: bashisms
Julien Danjou wrote:
Package: libpam-radius-auth
Version: 1.3.16-4
Severity: important
Hello,
There was a problem while autobuilding your package:
Automatic build of libpam-radius-auth_1.3.16-4 on avidan by sbuild/i386 0.49
Build started at 20060723-1917
**
...
dh_testdir
# Add here commands to compile the package.
(\
echo -E 'CC=gcc';\
echo -E 'CFLAGS=-g -Wall -fPIC
-DCONF_FILE=\\\/etc/pam_radius_auth.conf\\\';\
echo -E 'LDFLAGS=';\
echo -E 'if [ ${DEB_BUILD_OPTIONS#*noopt} != $DEB_BUILD_OPTIONS
]; then';\
echo -E 'CFLAGS=$CFLAGS -O0';\
echo -E 'else';\
echo -E 'CFLAGS=$CFLAGS -O2';\
echo -E 'fi';\
echo -E 'case $DEB_HOST_GNU_CPU in';\
echo -E 'hppa|m68k|mips|powerpc|s390|sparc|sparc64|sheb)';\
echo -E 'CFLAGS=$CFLAGS -DHIGHFIRST ;;';\
echo -E 'esac';\
echo -E 'make CFLAGS=$CFLAGS LDFLAGS=$LDFLAGS CC=$CC') |
/bin/sh
/bin/sh: -E: not found
/bin/sh: -E: not found
/bin/sh: -E: not found
/bin/sh: -E: not found
/bin/sh: -E: not found
/bin/sh: -E: not found
/bin/sh: -E: not found
/bin/sh: -E: not found
/bin/sh: -E: not found
/bin/sh: Syntax error: ) unexpected
make: *** [build-stamp] Error 2
**
Build finished at 20060723-1917
FAILED [dpkg-buildpackage died]
Use printf.
Thanks for the report, go ahead and NMU with a fix :)
Fabio
--
I'm going to make him an offer he can't refuse.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368225: please don't!
Toni Mueller wrote: Hello, I'd say that making a LAMP package that includes a lot of PHP stuff and not much else is sort of hijacking a good name for a bad purpose. If anything, packages like lamp-python (best language) lamp-perl (original definition of LAMP) lamp-php (in order of decreasing preference) should be created, but I'd also argue that replacing MySQL with PostgreSQL is a Good Thing (TM) in many cases. In any case, I think that also probably libapache-mod-chroot should be included and configured in any standard Apache install, and that the BTS probably isn't the best place to discuss such policy questions... What about creating a source called lamp that will create all these little tiny lamp-* packages (arch: all) that can be updated as you like indipendently from apache and leave apache on its own? Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368225: please don't!
Thom May wrote: I don't see there's any benefit in doing this _at all_, to be honest. It'll just turn into a whine fest when people don't get exactly what they want installed, and it then just becomes an unmaintainable mess. -Thom That's exactly why i don't want it in apache, and somebody can do it externally and take the blame ;) Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361214: test git
Hi guys, I strongly suggest to give .17 from git a shot. David did push hell of a lot of smp fixes together with the Niagara support into mainline. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350683: FTBFS: wrong dependency on libapr1-dev
Roberto Pariset wrote: Package: apr-util Version: 1.2.2-3 Severity: important Justification: fails to build from source Hi, apr-util seems to FTBFS on everything but i386 because dependencies cannot be satisfied: E: Couldn't find package libapr1-dev. Maybe you should replace libapr1-dev with either libapr0 or libapr1.0. Thanks, Roberto Did you actually consider to build apr before apr-util? Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351621: xfree86-driver-synaptics: Default configuration inadequate, mouse move way to slowly ...
Raphael Hertzog wrote: On Mon, 06 Feb 2006, Mattia Dongili wrote: Hello! As I said, customizing the MaxSpeed/MinSpeed/AccelFactor helps (I discovered this by reading the synaptics manual page) so this README certainly gives a working config. Oh, actually it seems they are affected by this same bug(?) but never reported here (who knows about upstream...). https://launchpad.net/distros/ubuntu/dapper/+source/xserver-xorg-input-synaptics/+bugs Indeed ! I CC fabbione that he can explain what Ubuntu has decided to do for this bug. I am already subscribed to the launchpad bug and debian-x. There is no need to CC me. IMO it can't ... the driver should auto-detect the kind of Touchpad and adjust the default values of the resolution stuff so that it works out of the box on *any* hardware. The touchpad information are stored in /sys/class/input and it is theoretically possible to gather them and create a table to identify what touchpad needs what. The major issue that we did encounter across time is that there is no winner. No matter what config you ship, synaptic breaks for one person or another. I agree with you tho that upstream could start investigating the option to create default settings on input ID base. that will take anyway quite sometime to stabilize in the code. For 0.14.3 that we are shipping in dapper, I will either add a big fat readme or new configs will be created with the MaxSpeed/etc. setting ready to be uncommented. I see no otherway in a short term to get this fixed properly. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289868: NMU?
Olaf van der Spek wrote: Fabio Massimo Di Nitto wrote: David N. Welton wrote: Olaf van der Spek wrote: Hi, Do you mind if a NMU is done to fix this issue? No, go ahead - thanks! Perhaps waiting an answer from the maintainer would be better. Aren't you one of the maintainers? Yes. and the comment was not directed to you. David is not one of the maintainers and allowing NMU's for apache is not exactly polite without waiting an answer from the maintainers. I've been waiting for 1 year and 16 days already and this is not the only bug. Like some other bugs.. debian is based on volunteers that works in their spare time.. and so on... and so on.. stuff happens when it is possible, As Adam already said it is in his tree/queue for the next upload. He said so at 2005-11-25. At 2006-01-16 he uploaded 2.0.55-4 which did not contain a fix. That's because we are working on 2.2 as i am writing and 2.0 will be obsoleted sometime during next week Fabio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289868: NMU?
David N. Welton wrote: Fabio Massimo Di Nitto wrote: David N. Welton wrote: Olaf van der Spek wrote: Hi, Do you mind if a NMU is done to fix this issue? No, go ahead - thanks! Perhaps waiting an answer from the maintainer would be better. As Adam already said it is in his tree/queue for the next upload. Uhrm... oops. I thought this was one of mine - didn't realize it was addressed to debian-apache. Sorry. eheh no problem :) nobody is going to die ;) fabio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289868: NMU?
Olaf van der Spek wrote: There are five maintainers listed in the maintainers field. Are you saying that none of them had time to post a reply that none of them have time to work on most of the bugs for the past/next year? Since i don't dig into the other 4 maintainer private lifes and I can only speak fr myself, yes, I had no time to look at apache for a while with a house to finish and a pregnant wife that can barely stand up (common pregnancy symptomps) and needs baby sitting more than apache. fabio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289868: NMU?
Olaf van der Spek wrote: Fabio Massimo Di Nitto wrote: Olaf van der Spek wrote: There are five maintainers listed in the maintainers field. Are you saying that none of them had time to post a reply that none of them have time to work on most of the bugs for the past/next year? Since i don't dig into the other 4 maintainer private lifes and I can only speak fr myself, yes, I had no time to look at apache for a while with a house to finish and a pregnant wife that can barely stand up (common pregnancy symptomps) and needs baby sitting more than apache. I understand you have no time, and that's no problem, but wouldn't you notify other project members of that so they know? they do know. Fabio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289868: NMU?
David N. Welton wrote: Olaf van der Spek wrote: Hi, Do you mind if a NMU is done to fix this issue? No, go ahead - thanks! Perhaps waiting an answer from the maintainer would be better. As Adam already said it is in his tree/queue for the next upload. Thanks Fabio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327741: it's more interesting than it looks like.
Hi, apparently there are plenty of files like that one with more desperate notes/copyrights in them. grep You are not allowed to change this file * -ril | wc -l shows at least 33 files with such statement. Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304785: Include /etc/apache/conf.d/*.conf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 severity 304785 wishlist stop Piotr Roszatycki wrote: Package: apache Version: 1.3.33-4 Severity: important Please convert Include /etc/apache/conf.d to the: Include /etc/apache/conf.d/*.conf The files in this directory are handled by dpkg and i.e. ucf so there are problems after upgrades. Well perhaps a bit of explanation of the problem would help. Given that changing the default would simply make apache unuseable for several users that relies on the actual behaviour... Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCX9njhCzbekR3nhgRAtuNAJ49hLqdu6mbidpD3qKsZ4KCIPpl6QCfYKOS CbwkRK0C/YSV4j4REO6mQhg= =lSXc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293220: libpam-radius-auth: Could use better integration with PAM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Leo, Leo Costela wrote: | Package: libpam-radius-auth | Version: 1.3.16-3 | Severity: wishlist | | I just got the idea that libpam-radius could use some debconf questions | (taking the least intrusive path) about automatic integration with PAM, | for example, you could provide three options: Thanks for the really nice suggestion, but there are some reasons why i didn't implement it. PAM is a very delicate subsystem and i am sure you can understand why. Implementing a debconf configurator involves more problems than you think (to do it properly) and it introduces another, if not several, level of (possible) failure. Login/auth business is really up to the sysadmin and even a single detail or error in a semi-automatic configurator can expose/compromise the box. I am willing to review and accept (heavily tested) patches, but not to implement it from scratch. Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCAHaMhCzbekR3nhgRAhiQAJ43zwVH0vv+Loj6Mafe06mi91KM/QCggDbE 6uQtw1yYXMqayGLa5PSgW18= =Ie8H -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292122: /etc/apache-ssl/httpd.conf is modified without questions on upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bjørn Mork wrote: | Package: apache-ssl | Version: 1.3.33-3 | Severity: important | | When I just upgraded apache-ssl, the postinst script did these modifications | without asking me: This is sounds quite impossible because apache uses debconf via ucf to ask if it is allowed to modify configurations or not and the level of interaction is decided by the user via dpkg-reconfigure debconf. If you have set it to non-interactive than of course things do not get asked. Please let me know if i missed something and if you can kindly check the above values. Thanks Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9gphhCzbekR3nhgRAjCtAJsGJxKuoGSZixTgfGl4GjRmrOFrgwCggLpY MV9x6ADi2z3cDVjwdWBNXYU= =5ttB -END PGP SIGNATURE-
Bug#292122: /etc/apache-ssl/httpd.conf is modified without questions on upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bjørn Mork wrote: | Fabio Massimo Di Nitto [EMAIL PROTECTED] writes: | | |Bjørn Mork wrote: || Package: apache-ssl || Version: 1.3.33-3 || Severity: important || || When I just upgraded apache-ssl, the postinst script did these modifications || without asking me: | |This is sounds quite impossible because apache uses debconf via ucf to ask if it is |allowed to modify configurations or not and the level of interaction is decided |by the user via dpkg-reconfigure debconf. | |If you have set it to non-interactive than of course things do not get asked. | | | I don't think I have, but I have been wrong once before ;-) Can't | find any evidence of it though: | they look ok... | Anything else I should check? If you can efford to do a test break it would be great if you can rever the changes to the old config and do: dpkg-reconfigure apache-ssl and see if for some reason it happens again. Thanks Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9hUchCzbekR3nhgRAq2bAJ4kh9eegmSk1v1TGP6xn5g61ZBKuQCghMb9 pW1cWHjFHvwlVyypWKansjc= =IRPA -END PGP SIGNATURE-
Bug#292122: /etc/apache-ssl/httpd.conf is modified without questions on upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bjørn Mork wrote: | Fabio Massimo Di Nitto [EMAIL PROTECTED] writes: | |Bjørn Mork wrote: | || Anything else I should check? | |If you can efford to do a test break it would be great if you can rever the changes |to the old config and do: | |dpkg-reconfigure apache-ssl | |and see if for some reason it happens again. | | | No, that didn't provoke it. I got the questions I already had | answered but /etc/apache-ssl/httpd.conf was not changed. That | includes the | | Include /etc/apache-ssl/conf.d | | which was not added either this time. | | Then I tried downgrading to 1.3.33-2 and upgrading again, but that | didn't change the config either. | | Hmm, seems I can't reproduce the error so it should probably be | archived as a bogus report. Please feel free to do so if you like. | | I am still wondering how the file got changed, though... | | | Bjørn Ah hold on.. one more test please.. i forgot about the md5sum check. Put the old config in place and edit (very carefully!) /var/lib/ucf/hashfile with the proper md5sum for /etc/apache-ssl/httpd.conf and test the upgrade again. Thanks Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9h8whCzbekR3nhgRAn9JAJ9CA8RrtJyZXtiADCHUGo8q1JNeAACbBp+5 d8FmBY0hv6af8SfdwQrpucM= =dvn7 -END PGP SIGNATURE-
Bug#292122: /etc/apache-ssl/httpd.conf is modified without questions on upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bjørn Mork wrote: | Fabio Massimo Di Nitto [EMAIL PROTECTED] writes: | | |Ah hold on.. one more test please.. i forgot about the md5sum check. | |Put the old config in place and edit (very carefully!) /var/lib/ucf/hashfile |with the proper md5sum for /etc/apache-ssl/httpd.conf |and test the upgrade again. | | | | Yup, that's it: | | canardo:/etc/apache-ssl# md5sum -vc /var/lib/ucf/hashfile | /etc/logrotate.d/clamav-daemon FAILED | /etc/clamav/clamav.confmd5sum: can't open /etc/clamav/clamav.conf | /etc/papersize OK | /etc/nagios/checkcommands.cfg FAILED | /etc/clamav/freshclam.conf OK | /etc/clamav/clamd.conf OK | /etc/fonts/local.conf OK | /etc/apache-ssl/modules.conf OK | /etc/sensors.conf OK | /etc/apache-ssl/httpd.conf OK | md5sum: 2 of 9 file(s) failed MD5 check | canardo:/etc/apache-ssl# grep Port httpd.conf | Port 80 | SSLCacheServerPort /var/run/gcache_port | canardo:/etc/apache-ssl# apt-get dist-upgrade | Reading Package Lists... Done | Building Dependency Tree... Done | Calculating Upgrade... Done | The following packages will be upgraded: | apache-common apache-ssl apache-utils | 3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. | Need to get 0B/1599kB of archives. | After unpacking 0B of additional disk space will be used. | Do you want to continue? [Y/n] | Preconfiguring packages ... | (Reading database ... 61097 files and directories currently installed.) | Preparing to replace apache-utils 1.3.33-2 (using .../apache-utils_1.3.33-3_i386.deb) ... | Unpacking replacement apache-utils ... | Preparing to replace apache-common 1.3.33-2 (using .../apache-common_1.3.33-3_i386.deb) ... | Unpacking replacement apache-common ... | Preparing to replace apache-ssl 1.3.33-2 (using .../apache-ssl_1.3.33-3_i386.deb) ... | Stopping web server: apache-ssl. | Stopping web server: apache-sslNo process in pidfile `/var/run/apache-ssl.pid' found running; none killed. | . | Unpacking replacement apache-ssl ... | Setting up apache-utils (1.3.33-3) ... | Setting up apache-common (1.3.33-3) ... | | Setting up apache-ssl (1.3.33-3) ... | Replacing config file /etc/apache-ssl/httpd.conf with new version | Starting web server: apache-ssl[Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] NameVirtualHost www.mork.no:80 has no VirtualHosts | . | | canardo:/etc/apache-ssl# grep Port httpd.conf | Port 443 | SSLCacheServerPort /var/run/gcache_port | | | Bjørn All right, i know remember exactly what the problem was/is. Basically older versions of apache-ssl had some problems to work properly with the default port != 443 and that was somehow hardencoded in the config manager for the port. We need to relax it and make it configurable as the other apache flavours. Thanks Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9iXVhCzbekR3nhgRAra9AJ44glG+5S2hCvC+FMWzjRYZfw5KmgCgjuz3 6fTA42Y1MLY7uRt+sL/m7hk= =kA29 -END PGP SIGNATURE-
Bug#291944: apache daemon segfaults on start
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JpL wrote: | Package: apache | Version: 1.3.33-3 | Severity: grave | Justification: renders package unusable | | | Unclear if this is a package mismatch issue or whether something more | serious is going on. Can provide an strace on request. | It would be more important if you start providing your configurations. Are you using php4? or other external modules? If so, disabling them, does apache start? Mind to check if you updated it properly? Fabio -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9JkghCzbekR3nhgRAjxFAJ9/9CoGFwcVcB0IbvQYNcellN+GbwCglYpx DDK2sIpZxU20fxiZVcgKTdA= =Snvb -END PGP SIGNATURE- -- 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
-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 :(
Thanks
Fabio
- --
Self-Service law:
The last available dish of the food you have decided to eat, will be
inevitably taken from the person in front of you.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB7jsxhCzbekR3nhgRAnBYAJwO79mSwhCkB1Ar+rnMhX4yE3vrFgCeKiUL
EWbgejw2dAn+7dUAlz7Es1Q=
=JNVv
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291312: apache 1.3.33-2 i386 2GB file size limit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tag 291312 wishlist tag 291312 upstream tag 291312 wontfix merge 291312 156972 thanks JOZJAN.net wrote: | Package: apache | Version: 1.3.33-2 i386 | | I tryed download 3GB file from my webserver but it returned wrong filesize. | It looks like int overflow. | | GET /wrz/December.DVD.rar HTTP/1.0 | Host: jozjan.net | | HTTP/1.1 200 OK | Date: Wed, 19 Jan 2005 23:50:41 GMT | Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-2 | Last-Modified: Wed, 19 Jan 2005 01:42:50 GMT | ETag: a3668-bf632f96-41edbb1a | Accept-Ranges: bytes | Content-Length: -1084018794 | Connection: close | Content-Type: application/rar | | I suggest that the Content-Length should be changed from 32b int into 64b. It cannot be done. Upstream doesn't support it for apache1.3 and it has been fixed already in apache2. Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7z+ChCzbekR3nhgRAhc1AJ9BrNfdtdc82Nnsz2y/A2p3Z3+5QQCdESco ss7VhZ1GLuMDnuUrD+4sKEY= =m0Nm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289976: [exposed@lss.hr: Apache mod_auth_radius remote integer overflow]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Schulze wrote:
| Fabio Massimo Di Nitto wrote:
|
|The package was not released with woody. I am working right now to check sid.
|
|
| What about the attached patch?
|
| Regards,
|
| Joey
|
|
|
|
|
| --- mod_auth_radius.c~2003-03-24 20:16:15.0 +0100
| +++ mod_auth_radius.c 2005-01-13 13:01:42.0 +0100
| @@ -971,8 +971,11 @@ find_attribute(radius_packet_t *packet,
|}
|return attr;
| }
| -#define radcpy(STRING, ATTR) {memcpy(STRING, ATTR-data, ATTR-length - 2); \
| - (STRING)[ATTR-length - 2] = 0;}
| +#define radcpy(STRING, ATTR) do { \
| + unsigned char len = ATTR-length; \
| + if (len = 2) len-=2; \
| + memcpy(STRING, ATTR-data, len); \
| + (STRING)[len] = 0;} until (0)
|
|
| /* authentication module utility functions */
I did talk with upstream that is working on a fix and will release soon.
The patch looks ok, but i am going to give one or two days to upstream
before going with this fix.
Thanks
Fabio
- --
Self-Service law:
The last available dish of the food you have decided to eat, will be
inevitably taken from the person in front of you.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB5pj4hCzbekR3nhgRAhkcAJ9MwDSSoUZSrks7aDIr9d0eVTKIJgCgkOkg
FUGMSXeh6IcD2k7yCi0YgEk=
=iRx+
-END PGP SIGNATURE-
--
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. this is weird.. i am using it at home and i would have noticed, but i will look into it.. | 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). yes i understand. | If I had any skills at all, I'd try to be less of a brute, but I'm no | developer. don't worry. your bug at least is cluefull :) | | 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. i will check again what happens here and let you know. | | Unless I'm running my Radius server on the same host, this keeps me from | using radius authentication. agreed. Thanks Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB45YWhCzbekR3nhgRAl59AKCfINxjvXt+hX+Gr59Jdn7PgAPJKwCfSm2d 4ntsshNiiCDUfI7/hEtRkXg= =xAUK -END PGP SIGNATURE- -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. | |this is weird.. i am using it at home and i would have noticed, but i |will look into it.. | | | Let me know if there's anything I can do to help. Test something, change the | config, whatever. I'm running a proof of concept setup here, so I can break | anything I want :) Thanks i will! I think i will be able to work on it sometimes during the next weekend. Fabio PS please keep the bug in CC. It helps to keep track of the progresses in the BTS. - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB45gdhCzbekR3nhgRAkJaAKCL4bYkDxZR40fFFCu20oo5nSA0WwCfc3mZ HAHiI7U0m459BaFUZPz0LBw= =2Y9G -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
