Bug#600589: hostapd+bridge doesn't work if hostapd is not run as a daemon in squeeze

2010-10-23 Thread FEJES Jozsef
So basically, if I do bridge first, then run hostapd as a daemon, it 
used to work, but with a newer kernel it doesn't, because the bridge 
needs wlan0 to be in master mode already, which is the job of hostapd. 
If I do hostapd first via /etc/network/interfaces, then the bridge from 
the same file, then everything starts up without an error, but I can't 
do WPA, only after I restart hostapd.


I found a workaround for the first case: "iwconfig wlan0 mode master" 
doesn't work, but "pre-up iw dev wlan0 set type __ap" does the job. It 
sets the card to master mode, then the bridge can be set up, then 
hostapd starts as a daemon and everything is working fine again.


So now the real problem remains, the second case: if hostapd is run from 
/etc/network/interfaces and I set up a bridge in the same file, then 
hostapd either doesn't receive EAPOL responses or sends the EAPOL 
requests to the wrong place and I get EAPOL timeouts in the syslog. 
Bottom line: no WPA.


Check this interfaces file:

iface eth0 inet manual
iface wlan0 inet manual
  hostapd /etc/hostapd/hostapd.conf
iface br0 inet static
  bridge-ports eth0 wlan0

I'm guessing what it does is this: bring up eth0, then run hostapd in 
the pre-up stage, then bring up wlan0, then bring up the bridge. The 
problem could be that hostapd doesn't see the bridge when it starts up, 
or some property of the bridge or wlan0 changes after it started up.


I grabbed myself a hostapd source code, so if you could give some 
pointers where to look, I'd be glad to help. How do I debug where it 
sends EAPOL requests? How do I debug where it expects EAPOL responses from?




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



Bug#600629: Acknowledgement (can't set apn)

2010-10-20 Thread FEJES Jozsef
I fixed the variable name ($c=>$x) and also noticed that a double 
quotation mark is missing and it was sending "send $x" literally to the 
modem. So the correct APN setting is:


send "AT+CGDCONT=1,\"IP\",\""
send $x
send "\"^m"



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



Bug#600629: can't set apn

2010-10-18 Thread FEJES Jozsef

Package: comgt
Version: 0.32-2

Setting APN doesn't work because of a typo ($c vs. $x). Could you please 
provide a package I can test before you notify upstream? I have to say 
I'm very surprised noone bothered to report it yet, comgt's scripting 
language is so much better than chat's, doesn't anyone use this feature?


Log:
j...@wicklow:~$ COMGTAPN=internet comgt -d /dev/ttyUSB1 -v APN
...
comgt 20:11:11 -> @0109 let $x=$env("COMGTAPN")
...
comgt 20:11:11 -> @0218 send "AT+CGDCONT=1,\"IP\",\"
comgt 20:11:13 -> @0279 waitfor 20 "OK","ERR"
...
comgt 20:11:13 -> @0394 print "ERROR entering APN
ERROR entering APN
comgt 20:11:13 -> @0426 print "The COMGTAPN env variable is not set
The COMGTAPN env variable is not set
comgt 20:11:13 -> @0476 exit 1



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



Bug#600589: hostapd+bridge doesn't work if hostapd is not run as a daemon in squeeze

2010-10-18 Thread FEJES Jozsef
Package: hostapd
Version: 0.6.10-2

I'm using a very common setup: I want to bridge eth0 + wlan0 (b43
wireless card). When I run hostapd as a daemon, it works fine. But
when I run it from /etc/network/interfaces with the hostapd stanza, it
doesn't work.

Symptoms: in the syslog I see that there's an association and a few
seconds later a "deauthenticated due to a local deauth request"
message. With an increased log level I see an "EAPOL-key timeout"
message. If I do "ifdown wlan0" then "ifup wlan0" then it starts
working.

Why it matters: I upgraded to a 2.6.35 custom kernel. When the
networking is being set up, I get a not supported error, it can't add
wlan0 to the bridge. I read that it happens because with newer
kernels, the wifi adapter needs to be in master mode already. I can't
do that with a "pre-up iwconfig wlan0 mode master" line because it
says "Set Mode" (8B06) : SET failed on device wlan0 ; Invalid
argument". The only way I know to put the card into master mode is if
I run hostapd. I suspect one might say that custom kernels are not
supported, but running hostapd in non-daemon mode sure is. With a .32
kernel the easy workaround is to run it as a daemon mode, but it
doesn't apply with .35, and it should be fixed sooner or later.

It seems to me that hostapd only works if it is run after the bridge
is set up. My old config worked because networking was set up before
hostapd was run, the bridge was already working when hostapd started.
With the new kernel, I can't do the bridge first because of the not
supported error. So hostapd is run first, it puts the card into master
mode, then the bridge is brought up, and it doesn't work, then I can
restart hostapd with ifdown-ifup, and then it works, because it starts
after the bridge.

If there was a way to put the card into master mode without hostapd,
then I could run hostapd as a daemon with the newer kernel, too,
however the bug would still be there. But I can't setup master mode
with iwconfig, how does hostapd do it anyway?

And why doesn't it work if it is started before the bridge is created?



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



Bug#594572: gdm3: nt domain users (from a perfectly working winbind) don't appear in the logon screen user list

2010-08-28 Thread FEJES Jozsef

I observed the same behavior with LDAP, and I think this is intentional.
If there are too many users, as is generally the case with remote NSS
modules, it is useless to list them all. However, once a user has logged
on, it should appear since it is part of the recent users list. If it
does not, that would indeed be a bug.

Cheers,


Is there an all user list and a recent user list? Anyways I can't see 
any users on the login screen. I remember seeing an Ubuntu 8.x with all 
the domain users on the login screen, maybe pointless, but it's still 
better, and there's infinite room with a scrollbar. At least recently 
logged in users should appear in this list, but the best would be if 
either everyone appearad, or everyone who's ever logged in, or it should 
be configurable.




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



Bug#594572: gdm3: nt domain users (from a perfectly working winbind) don't appear in the logon screen user list

2010-08-27 Thread Fejes Jozsef
Package: gdm3
Version: 2.30.2-4
Severity: normal

Default Debian install with Gnome, Samba, Winbind. I joined an NT domain, set up
Samba and Winbind, included Winbind in PAM and nsswitch.conf, it's all good.
Winbind is configured to use the default domain so I can login with the name
'fejes.jozsef'. Winbind can also enumerate all users and groups. However, no
domain users appear on the login screen's user list, only local users. Since
PAM and nsswitch.conf are all fine, domain users should appear in GDM just like
local users from passwd.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gdm3 depends on:
ii  adduser 3.112add and remove users and groups
ii  debconf [debconf-2.0]   1.5.35   Debian configuration management sy
ii  gconf2  2.28.1-3 GNOME configuration database syste
ii  gnome-session [x-sessio 2.30.2-1 The GNOME Session Manager - GNOME 
ii  gnome-session-bin   2.30.2-1 The GNOME Session Manager - Minima
ii  gnome-terminal [x-termi 2.30.2-1 The GNOME terminal emulator applic
ii  libart-2.0-22.3.21-1 Library of functions for 2D graphi
ii  libatk1.0-0 1.30.0-1 The ATK accessibility toolkit
ii  libattr11:2.4.44-2   Extended attribute shared library
ii  libaudit0   1.7.13-1+b2  Dynamic library for security audit
ii  libbonobo2-02.24.3-1 Bonobo CORBA interfaces library
ii  libbonoboui2-0  2.24.3-1 The Bonobo UI library
ii  libc6   2.11.2-2 Embedded GNU C Library: Shared lib
ii  libcairo2   1.8.10-4 The Cairo 2D vector graphics libra
ii  libcanberra-gtk00.24-1   Gtk+ helper for playing widget eve
ii  libcanberra00.24-1   a simple abstract interface for pl
ii  libdbus-1-3 1.2.24-3 simple interprocess messaging syst
ii  libdbus-glib-1-20.88-2   simple interprocess messaging syst
ii  libdevkit-power-gobject 1:0.9.5-1abstraction for power management -
ii  libfontconfig1  2.8.0-2.1generic font configuration library
ii  libfreetype62.4.2-1  FreeType 2 font engine, shared lib
ii  libgconf2-4 2.28.1-3 GNOME configuration database syste
ii  libglib2.0-02.24.1-1 The GLib library of C routines
ii  libgnome2-0 2.30.0-1 The GNOME library - runtime files
ii  libgnomecanvas2-0   2.30.1-1 A powerful object-oriented display
ii  libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface 
ii  liborbit2   1:2.14.18-0.1libraries for ORBit2 - a CORBA ORB
ii  libpam-modules  1.1.1-4  Pluggable Authentication Modules f
ii  libpam-runtime  1.1.1-4  Runtime support for the PAM librar
ii  libpam0g1.1.1-4  Pluggable Authentication Modules l
ii  libpanel-applet2-0  2.30.2-1 library for GNOME Panel applets
ii  libpango1.0-0   1.28.1-1 Layout and rendering of internatio
ii  libpolkit-gobject-1-0   0.96-2   PolicyKit Authorization API
ii  libpolkit-gtk-1-0   0.96-2   PolicyKit GTK+ API
ii  libpopt01.16-1   lib for parsing cmdline parameters
ii  librsvg2-common 2.26.3-1 SAX-based renderer library for SVG
ii  libselinux1 2.0.96-1 SELinux runtime shared libraries
ii  libwrap07.6.q-19 Wietse Venema's TCP wrappers libra
ii  libx11-62:1.3.3-3X11 client-side library
ii  libxau6 1:1.0.6-1X11 authorisation library
ii  libxdmcp6   1:1.0.3-2X11 Display Manager Control Protoc
ii  libxklavier16   5.0-2X Keyboard Extension high-level AP
ii  libxml2 2.7.7.dfsg-4 GNOME XML library
ii  lsb-base3.2-23.1 Linux Standard Base 3.2 init scrip
ii  metacity [x-window-mana 1:2.30.1-2   lightweight GTK+ window manager
ii  policykit-1-gnome   0.96-2   GNOME authentication agent for Pol
ii  twm [x-window-manager]  1:1.0.4-2Tab window manager
ii  upower  0.9.5-1  abstraction for power management
ii  xterm [x-terminal-emula 261-1X terminal emulator
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages gdm3 recommends:
ii  at-spi1.30.1-2   Assistive Technology Service Provi
ii  gnome-icon-theme  2.30.3-1   GNOME Desktop icon theme
ii  gnome-power-manager   2.30.1-1   power management tool for the GNOM
ii  gno

Bug#580286: Do not install update-mot.d stuff

2010-08-15 Thread FEJES Jozsef

On 2010.08.15. 19:33, Julian Andres Klode wrote:

On So, 2010-08-15 at 19:18 +0200, FEJES Jozsef wrote:

Hi!
How can I still display update-notifier stuff in my motd?

You should not, but you can copy the following files from the source
package to /etc/update-motd.d:
   * debian/20-cpu-checker
   * debian/90-updates-available
   * debian/98-reboot-required

But they will be removed again on each upgrade of
update-notifier-common.


Ok, I'll find another way then. Or maybe you're right, it doesn't 
generally belong to a motd but it was pretty handy on a single-user 
server. It just made me sad to see how the fixing of a bug could lead to 
the loss of a useful feature. It works in Ubuntu and someone mentioned 
above how they did it, I know copying ideas is not always the best way 
but it seems better than just deleting stuff.




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



Bug#580286: Do not install update-mot.d stuff

2010-08-15 Thread FEJES Jozsef

Hi!
How can I still display update-notifier stuff in my motd?



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



Bug#570700: admin menus don't work if root is disabled

2010-02-22 Thread FEJES Jozsef
>> Maybe d-i can set a debconf value that gksu would use to choose the
>> default, but this might fall afoul of the 'Debconf is not a registry'
>> policy.
>
> It's already an alternative, and AFAIK it is already set by the
> installer when you choose to install in sudo mode.
>

I installed Debian squeeze from a netinst CD without a root password,
without Gnome. I installed Gnome some time after finishing the
installation, and gksu wasn't set up for sudo mode, it didn't ask me
IIRC. So you're saying that the installer CD would have set this up
automatically if I had chosen to install Gnome then?



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



Bug#570700: admin menus don't work if root is disabled

2010-02-22 Thread FEJES Jozsef
> Maybe d-i can set a debconf value that gksu would use to choose the
> default, but this might fall afoul of the 'Debconf is not a registry'
> policy.

It doesn't have to be a debconf setting, gksu can just check at install
time if there is a root password or not, and if there isn't, it should pick
sudo. Seems like a sensible default and doesn't bother the user with
a debconf question, or it could be a low priority warning or something.



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



Bug#570700: admin menus don't work if root is disabled

2010-02-21 Thread FEJES Jozsef

Hello Jozsef,
You need to configure GNOME/gksu to use sudo. This is necessary in any case
since some GNOME programs use gksu directly, and not su-to-root.
For that, you have to change the gconf key /apps/gksu/sudo-mode.


Thank you, that worked. Could this be a default then, in case someone 
else installs Debian without a root password? Sudo was installed and 
configured automatically IIRC, it also just works in Ubuntu. So this is 
a wishlist priority instead.




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



Bug#570700: admin menus don't work if root is disabled

2010-02-20 Thread FEJES Jozsef
Package: menu
Version: 2.1.43
Severity: important

When I installed my system, I intentionally didn't specify a root password,
which seemed to be a supported installation option. I created a normal user and
I can use sudo just fine. But Gnome menus like System->Administration->Synaptic
don't work: they ask for the root password, which doesn't exist, so I can never
authenticate. I see that these menus invoke su-to-root -X, which has a variable
named SU_TO_ROOT_X, but it doesn't support sudo or gksudo. Other menu items work
like this so this should be fixed in the su-to-root script.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages menu depends on:
ii  dpkg  1.15.5.6   Debian package management system
ii  install-info  4.13a.dfsg.1-5 Manage installed documentation in 
ii  libc6 2.10.2-2   GNU C Library: Shared libraries
ii  libgcc1   1:4.4.2-9  GCC support library
ii  libstdc++64.4.2-9The GNU Standard C++ Library v3

menu recommends no packages.

Versions of packages menu suggests:
ii  gksu  2.0.2-2+b1 graphical frontend to su

-- no debconf information



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



Bug#567924: periodic hook script

2010-02-01 Thread FEJES Jozsef
Package: apt
Version: 0.7.25
Severity: wishlist

I'd like to do stuff with apt periodically. APT::Periodic is awesome
because it is bundled with apt. It does cleaning, updating,
downloading, and maybe unattended-updates, but that's all, which is a
limitation. There are packages like apticron or cron-apt, my problem
with them is that they reimplement some part of the apt periodic
functionality (and they know more than what I need). I came upon a
good idea here: https://wiki.ubuntu.com/AutomaticUpdates . They
haven't implemented it, I wish I knew why. Anyway.

I propose a configuration value named APT::Periodic::Post-Run-Hook. It
would obsolete the APT::Periodic::Unattended-Upgrade variable. It
would be a list of shell scripts which the daily cron script would
invoke after it finishes. In the first version, the cron script would
know about both configurations, and it would first run
unattended-upgrades if needed, then any shell scripts the user
provided. It doesn't affect any documentation, the man refers to the
header of the cron script, so it's a very simple procedure really.
This way I could specify my own simple script to run after apt's
periodic stuff. Now the really cool part is that the package
unattended-upgrades could be modified as well. Currently it puts a
file in /etc/apt which sets Unattended-Upgrade to 1, it could be
changed to add itself to the Post-Run-Hook list. (If I understand
correctly, the members of a list option can be specified in multiple
commands, as in X::Y::List { "1"; }; then some time later X::Y::List {
"2"; }; and then it would contain both values, right?) This also
solves an invisible dependecy problem: the Unattended-Upgrade option
requires another package to be installed, whereas Post-Run-Hook
doesn't. And maybe sometime later even cron-apt and apticron would
make use of this Post-Run-Hook thing, they most certainly could, and
then the duplicated functionality in those packages would be
eliminated as well. It just sounds perfect to me.

If you, the maintainer, thinks that it would be nice, too, I would be
more than happy to write a patch myself, I believe I wouldn't make any
mess, we're only talking about a simple cron script with a clean
interface after all.



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



Bug#563797: (nincs tárgy)

2010-01-16 Thread FEJES Jozsef
I'm using squeeze and upgraded mc yesterday, 
/usr/share/mc/filehighlight.ini is still missing from 
mc_4.7.0-1_i386.deb. If this is a known bug, how could this have made it 
to squeeze?




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



Bug#517967: Re: Bug#517967: please integrate with pam-auth-update

2010-01-10 Thread FEJES Jozsef

This should do it:

/usr/share/pam-configs/passwdqc

  Name: passwdqc password strength checking
  Default: yes
  Priority: 1024
  Conflicts: cracklib [maybe?]
  Password-Type: Primary
  Password:
requisite   pam_passwdqc.so min=disabled,10,6,4,3 
similar=deny enforce=users ask_oldauthtok check_oldauthtok

I don't know if the options passed in this example are sensible defaults for
the package to ship, I leave that to the maintainer to determine.  But
regardless of which options are used, I don't see anything here that would
make it incompatible with the framework.  Note also that users editing the
module arguments in /etc/pam.d/common-password should Just Work™ - this
isn't documented, I was still thinking through what the policy should be for
per-module debconf questions to let modules hook in more completely.



Manually editing /etc/pam.d/common-password is not the perfect solution. 
If pam_unix is the only password profile selected, then use_authtok is 
not specified for it (/usr/share/pam-configs/unix only specifies that 
option if it's not the initial module). So if I want to make passwdqc 
work without pam-auth-update, then I first have to add it to the 
beginning of common-password and then I have to modify the 
pam-auth-update reserved area to add use_authtok to pam_unix which is 
quite ugly, compared to how simple it would be to provide a 
pam-auth-update profile for passwdqc.


About the contents of that pam-config file. I think that no 
configuration should be specified at all, given how passwdqc is 
security-related, it comes with sensible (if not overly secure) 
defaults. So I think that an option-less, debconf-question-less 
pam-config for passwdqc would just work fine and it would increase 
usability of this package for average users a lot. This file would be 
marked as a config file so advanced users could hand-edit this one 
instead of common-password and dpkg could handle that too. Seems to me 
as a clean and simple to implement solution. And pam-auth-update is just 
an awesome idea so I, for one, would really love to see this happen in 
the debian package.



--
[ FEJES Jozsef ]
http://joco.name



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



Bug#564516: dhcp3-client: weird conflict with samba/resolvconf when shutting down

2010-01-09 Thread Fejes Jozsef
Package: dhcp3-client
Version: 3.1.3-2
Severity: normal

Hi!

Basically, I see 3 problems: ifdown eth1 seems to kill and restart dhclient for 
some reason, 
dhclient seems to be killed before deconfiguring interfaces, and during 
shutdown dhclient 
reloads samba but it's already stopped and it should't even try to call 
invoke-rc.d at this 
time.

Additional versions: samba 2:3.4.3-2, resolvconf 1.45, dnsmasq 2.51-1, ifupdown 
0.6.9. All 
affected packages are default installs, eth1 is the uplink ("iface eth1 inet 
dhcp"), eth0 is 
a lan with dnsmasq and samba on it. I'm using the dependency based init system. 
When 
starting up, /etc/resolv.conf is empty, then when eth1 comes up, it is the DNS 
of my ISP, 
then when dnsmasq comes up, it becomes 127.0.0.1 and dnsmasq will use the ISP's 
DNS, all 
thanks to resolvconf's magic.

The first weird thing is that when I do "ifdown eth1", it starts with some 
warning:

=
There is already a pid file /var/run/dhclient.eth1.pid with pid 4260
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.3
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/00:04:e2:9f:9e:0f
Sending on   LPF/eth1/00:04:e2:9f:9e:0f
Sending on   Socket/fallback
DHCPRELEASE on eth1 to 192.168.1.1 port 67
Reloading /etc/samba/smb.conf: smbd only.
r...@wicklow:~#
=

Also notice that samba is automatically reloaded. Now the real problem comes 
when shutting 
down, looks like multiple problems: dhclient is killed before ifdown-ing, hence 
the stale 
warning, then the samba reloading kicks in, which seems to happen at the wrong 
time:

=
...
Saving the system clock.
Deconfiguring network interfaces...There is already a pid file 
/var/run/dhclient.eth1.pid 1410
removed stale PID file
Internet Systems Consortium DHCP Client V3.1.3
...
DHCPRELEASE on eth1 to 192.168.1.1 port 67
invoke-rc.d: 
invoke-rc.d: WARNING: invoke-rc.d called during shutdown sequence
invoke-rc.d: enabling safe mode: initscript policy layer disabled
invoke-rc.d: 
Reloading /etc/samba/smb.conf: smbd onlyNo process in pidfile 
'/var/run/samba/smbd.pid' found
running: none killed.
.
done.
Cleaning up ifupdown...
Deactivating swap...done.
...
=

Also note that it all doesn't seem dangerous, just very ugly, but still, 
something is 
definitely wrong here.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dhcp3-client depends on:
ii  debconf [debconf-2.0] 1.5.28 Debian configuration management sy
ii  debianutils   3.2.2  Miscellaneous utilities specific t
ii  dhcp3-common  3.1.3-2common files used by all the dhcp3
ii  libc6 2.10.2-2   GNU C Library: Shared libraries

dhcp3-client recommends no packages.

Versions of packages dhcp3-client suggests:
pn  avahi-autoipd  (no description available)
ii  resolvconf1.45   name server information handler

-- debconf information:
  dhcp3-client/dhclient-needs-restarting:
  dhcp3-client/dhclient-script_moved:



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



Bug#517967: Re: Bug#517967: please integrate with pam-auth-update

2010-01-09 Thread FEJES Jozsef

This should do it:

/usr/share/pam-configs/passwdqc

  Name: passwdqc password strength checking
  Default: yes
  Priority: 1024
  Conflicts: cracklib [maybe?]
  Password-Type: Primary
  Password:
requisite   pam_passwdqc.so min=disabled,10,6,4,3 
similar=deny enforce=users ask_oldauthtok check_oldauthtok

I don't know if the options passed in this example are sensible defaults for
the package to ship, I leave that to the maintainer to determine.  But
regardless of which options are used, I don't see anything here that would
make it incompatible with the framework.  Note also that users editing the
module arguments in /etc/pam.d/common-password should Just Work™ - this
isn't documented, I was still thinking through what the policy should be for
per-module debconf questions to let modules hook in more completely.



Manually editing /etc/pam.d/common-password is not the perfect solution.
If pam_unix is the only password profile selected, then use_authtok is
not specified for it (/usr/share/pam-configs/unix only specifies that
option if it's not the initial module). So if I want to make passwdqc
work without pam-auth-update, then I first have to add it to the
beginning of common-password and then I have to modify the
pam-auth-update reserved area to add use_authtok to pam_unix which is
quite ugly, compared to how simple it would be to provide a
pam-auth-update profile for passwdqc.

About the contents of that pam-config file. I think that no
configuration should be specified at all, given how passwdqc is
security-related, it comes with sensible (if not overly secure)
defaults. So I think that an option-less, debconf-question-less
pam-config for passwdqc would just work fine and it would increase
usability of this package for average users a lot. This file would be
marked as a config file so advanced users could hand-edit this one
instead of common-password and dpkg could handle that too. Seems to me
as a clean and simple to implement solution. And pam-auth-update is just
an awesome idea so I, for one, would really love to see this happen in
the debian package.


--
[ FEJES Jozsef ]
http://joco.name



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