Bug#850509: missing systemd targets

[Hans Grobler]

Package: ceph
Version: 10.2.5-3

Dear Maintainer,

A number of systemd target files are missing, for example ceph-mon.target and 
ceph-osd.target. See http://tracker.ceph.com/issues/15573 
 for a similar upstream bug. Please 
include these so that auto-start can be properly configured and make the Debian 
packages consistent with the official documentation (e.g. 
http://docs.ceph.com/docs/master/rados/operations/operating/ 
).

Bug#840383: ceph: Mon crash on startup

[Hans Grobler]

Dear Maintainer,

I have since updated to 10.2.5-3 without major issues. This was done offline 
directly from 0.80.11-1. The Jewel monitors had no issues with my Firefly 
monitor databases... so 0.80.1-11 still seems suspect. However given that Jewel 
is now available, I now consider this bug to be irrelevant.

Regards,
-- Hans 

> Dear Maintainer,  
>  
> After an upgrade from 0.80.11-1, Ceph monitor start up results in  
> the crash seen below. The crash is repeatable / consistent and as a  
> result it is not possible to start the monitor with 0.80.11-1.1. OSDs  
> however start without problems with 0.80.11-1.1.  
>  
> Attempting to create a new monitor results in a similar crash on startup.  
> Reverting back to 0.80.11-1 allows the Ceph monitor to start as normal  
> (with the pre-upgrade leveldb).  

I tried to reproduce this in a clean environment but failed. So this  
certainly does not affect all users. I also uploaded a new upstream  
version (10.2.5) a few days ago, which is currently sitting in NEW. It  
would be nice if you could test this version once it's available in  
unstable. If you are eager to test, I can also provide you the  
debs.  

To be able to reproduce this I would need at least the commands you used  
to get the traces below and maybe also your /var/lib/ceph/mon/XXX  
directory to get the exact same monitor database. I suspect your  
database might have gotten corrupt somehow.  

But still thanks for testing and I would really appreciate if you could  
test the new upstream package.  

Gaudenz  

Bug#840383: ceph: Mon crash on startup

[Hans Grobler]

Package: ceph
Version: 0.80.11-1.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After an upgrade from 0.80.11-1, Ceph monitor start up results in
the crash seen below. The crash is repeatable / consistent and as a
result it is not possible to start the monitor with 0.80.11-1.1. OSDs
however start without problems with 0.80.11-1.1. 

Attempting to create a new monitor results in a similar crash on startup. 
Reverting back to 0.80.11-1 allows the Ceph monitor to start as normal 
(with the pre-upgrade leveldb).


2016-10-11 06:35:54.781406 7f0d7abe57c0 -1 *** Caught signal (Aborted) **
in thread 7f0d7abe57c0

ceph version 0.80.11 (8424145d49264624a3b0a204aedb127835161070)
1: (()+0x4c7812) [0x55a47ae33812]
2: (()+0x11100) [0x7f0d7a300100]
3: (gsignal()+0xcf) [0x7f0d78929fdf]
4: (abort()+0x16a) [0x7f0d7892b40a]
5: (()+0x23275) [0x7f0d7a78c275]
6: (()+0x170af) [0x7f0d7a7800af]
7: (operator delete[](void*)+0x25d) [0x7f0d7a7a361d]
8: (LevelDBStore::do_open(std::ostream&, bool)+0x69c) [0x55a47addf0ac]
9: (main()+0xbc0) [0x55a47aabc120]
10: (__libc_start_main()+0xf1) [0x7f0d789172b1]
11: (_start()+0x2a) [0x55a47aacb98a]
NOTE: a copy of the executable, or `objdump -rdS ` is needed to 
interpret this.

--- begin dump of recent events ---
  -12> 2016-10-11 06:35:54.776111 7f0d7abe57c0  5 asok(0x55a47cac2160) 
register_command perfcounters_dump hook 0x55a47ca96020
  -11> 2016-10-11 06:35:54.776183 7f0d7abe57c0  5 asok(0x55a47cac2160) 
register_command 1 hook 0x55a47ca96020
  -10> 2016-10-11 06:35:54.776212 7f0d7abe57c0  5 asok(0x55a47cac2160) 
register_command perf dump hook 0x55a47ca96020
   -9> 2016-10-11 06:35:54.776218 7f0d7abe57c0  5 asok(0x55a47cac2160) 
register_command perfcounters_schema hook 0x55a47ca96020
   -8> 2016-10-11 06:35:54.776224 7f0d7abe57c0  5 asok(0x55a47cac2160) 
register_command 2 hook 0x55a47ca96020
   -7> 2016-10-11 06:35:54.776228 7f0d7abe57c0  5 asok(0x55a47cac2160) 
register_command perf schema hook 0x55a47ca96020
   -6> 2016-10-11 06:35:54.776233 7f0d7abe57c0  5 asok(0x55a47cac2160) 
register_command config show hook 0x55a47ca96020
   -5> 2016-10-11 06:35:54.776238 7f0d7abe57c0  5 asok(0x55a47cac2160) 
register_command config set hook 0x55a47ca96020
   -4> 2016-10-11 06:35:54.776243 7f0d7abe57c0  5 asok(0x55a47cac2160) 
register_command config get hook 0x55a47ca96020
   -3> 2016-10-11 06:35:54.776248 7f0d7abe57c0  5 asok(0x55a47cac2160) 
register_command log flush hook 0x55a47ca96020
   -2> 2016-10-11 06:35:54.776261 7f0d7abe57c0  5 asok(0x55a47cac2160) 
register_command log dump hook 0x55a47ca96020
   -1> 2016-10-11 06:35:54.776269 7f0d7abe57c0  5 asok(0x55a47cac2160) 
register_command log reopen hook 0x55a47ca96020
0> 2016-10-11 06:35:54.781406 7f0d7abe57c0 -1 *** Caught signal (Aborted) **
in thread 7f0d7abe57c0

ceph version 0.80.11 (8424145d49264624a3b0a204aedb127835161070)
1: (()+0x4c7812) [0x55a47ae33812]
2: (()+0x11100) [0x7f0d7a300100]
3: (gsignal()+0xcf) [0x7f0d78929fdf]
4: (abort()+0x16a) [0x7f0d7892b40a]
5: (()+0x23275) [0x7f0d7a78c275]
6: (()+0x170af) [0x7f0d7a7800af]
7: (operator delete[](void*)+0x25d) [0x7f0d7a7a361d]
8: (LevelDBStore::do_open(std::ostream&, bool)+0x69c) [0x55a47addf0ac]
9: (main()+0xbc0) [0x55a47aabc120]
10: (__libc_start_main()+0xf1) [0x7f0d789172b1]
11: (_start()+0x2a) [0x55a47aacb98a]
NOTE: a copy of the executable, or `objdump -rdS ` is needed to 
interpret this.

--- logging levels ---
  0/ 5 none
  0/ 1 lockdep
  0/ 1 context
  1/ 1 crush
  1/ 5 mds
  1/ 5 mds_balancer
  1/ 5 mds_locker
  1/ 5 mds_log
  1/ 5 mds_log_expire
  1/ 5 mds_migrator
  0/ 1 buffer
  0/ 1 timer
  0/ 1 filer
  0/ 1 striper
  0/ 1 objecter
  0/ 5 rados
  0/ 5 rbd
  0/ 5 journaler
  0/ 5 objectcacher
  0/ 5 client
  0/ 5 osd
  0/ 5 optracker
  0/ 5 objclass
  1/ 3 filestore
  1/ 3 keyvaluestore
  1/ 3 journal
  0/ 5 ms
  1/ 5 mon
  0/10 monc
  1/ 5 paxos
  0/ 5 tp
  1/ 5 auth
  1/ 5 crypto
  1/ 1 finisher
  1/ 5 heartbeatmap
  1/ 5 perfcounter
  1/ 5 rgw
  1/10 civetweb
  1/ 5 javaclient
  1/ 5 asok
  1/ 1 throttle
 -2/-2 (syslog threshold)
 -1/-1 (stderr threshold)
 max_recent 1
 max_new 1000
--- end dump of recent events ---


-- System Information:
Debian Release: stretch/sid
 APT prefers testing
 APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#480111: openafs-dbserver: VLDB changes not being sync'ed to vldb.DB0

[Hans Grobler]

Subject: openafs-dbserver: VLDB changes not being sync'ed to vldb.DB0
Package: openafs-dbserver
Version: 1.4.7~pre3.dfsg1-1
Severity: critical
Justification: breaks the whole system

*** Please type your report below this line ***

Recent vlserver's fail to write VLDB changes to the
/var/lib/openafs/db/vldb.DB0 file on non sync-sites. The effect is that,
whilst the in-memory VLDB is correct, the version on disk is not correct
except on the sync site. If all vlserver's for a cell are restarted *at
the same time*, all recent changes to the VLDB are lost.

The problem is reproducible:
- Stop, with bos, all 3 vlserver's (all three are running the version
  below).
- Remove /var/lib/openafs/db/vldb* on all db servers.
- Restart, with bos, all 3 vlserver's. Empty vldb.DB0 files are
  created on all servers. The vlservers show no errors in logs.
- Wait for quorum to be established (check via udebug, recovery
  state 1f).
- Run 'vos listvldb' to check that no volumes are registered.
- Run 'vos syncvldb' for each fileserver in cell. 
- udebug on sync site shows DB version incrementing + recovery state 1f.
- 'vos listvldb' now shows all volumes in cell correctly and all
  clients can successfully access cell volumes.
- Wait 1 or more hours.
- The vldb.DB0 file has zero size on non sync-site and timestamp when
  vlserver was started. On sync site it has grown and has timestamp of
  last syncvldb operation.
- Restart all vlservers. The vlservers show no errors in logs.
- Wait for quorum to be established (check via udebug) + recovery
  state 1f.
- 'vos listvldb' shows no volumes. 
- Redoing the syncvldb allows the clients to again access volumes.

This problem was also seen with i686 dbserver on testing (before
upgrade to amd64 testing) and seems to have begun somewhere after
openafs 1.4.2. Initially the problem was seen with a VLDB that had
worked correctly for 2+ years. At some point (1.4.6?) recently changes
stopped being written to the vldb.DB0 (but no errors were logged) and
the above procedure was attempted in order begin with a clean slate.
The effect however remains and thus cannot be linked to a corrupt
vldb.DB0. Testing with a backup of the original VLDB also shows this
problem. vldb_check seems satisfied that the vldb.DB0 in all cases 
not corrupted. 

From the above it appears that:
- the vldb.DB0 file is not being updated on non-sync sites
- when a restart occurs, only the sync site has a recent vldb.DB0
- but is outvoted by the previously non-sync sites and
- recent changes are discarded

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (300, 'unstable'), (80, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.25-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages openafs-dbserver depends on:
ii  libc6 2.7-10 GNU C Library: Shared
libraries
ii  openafs-client1.4.7~pre3.dfsg1-1 AFS distributed filesystem
client 
ii  openafs-fileserver1.4.7~pre3.dfsg1-1 AFS distributed filesystem
file se
ii  perl  5.8.8-12   Larry Wall's Practical
Extraction 

openafs-dbserver recommends no packages.

-- no debconf information





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

Bug#480111: openafs-dbserver: VLDB changes not being sync'ed to vldb.DB0

[Hans Grobler]

On Thu, 2008-05-08 at 10:33 -0700, Russ Allbery wrote:
 Hans Grobler [EMAIL PROTECTED] writes:
 
  Subject: openafs-dbserver: VLDB changes not being sync'ed to vldb.DB0
  Package: openafs-dbserver
  Version: 1.4.7~pre3.dfsg1-1
  Severity: critical
  Justification: breaks the whole system
 
  Recent vlserver's fail to write VLDB changes to the
  /var/lib/openafs/db/vldb.DB0 file on non sync-sites. The effect is that,
  whilst the in-memory VLDB is correct, the version on disk is not correct
  except on the sync site. If all vlserver's for a cell are restarted *at
  the same time*, all recent changes to the VLDB are lost.
 
 There was a significant fix to Ubik between 1.4.7pre3 and 1.4.7.  Could
 you try with the 1.4.7 packages in Debian unstable and see if that fixes
 the problem?  In particular, I think this is fixed by
 STABLE14-ubik-recovery-swap-in-new-fd-20080428, which was one of the final
 changes right before the 1.4.7 release.

I can confirm that 1.4.7 fixes this serious bug. With 1.4.7 the empty
vldb.DB0 files created start with size 16 bytes, whereas previously they
were 0 size... which correlates with a fd problem as hinted at in the
Changelog.

Regards,
-- Hans




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

Bug#448175: libqt4-ruby1.8: require 'Qt' failures

[Hans Grobler]

Package: libqt4-ruby1.8
Version: 1.4.9-5
Severity: normal

- Installed the Ruby Qt binding the first time. Most aspects work correctly.
- All examples fail to work due to require 'Qt', which doesn't
  exist (only Qt3.rb and Qt4.rb are installed by the package).
- The installed /usr/bin/rbqtapi also fails for the same reason.

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

Kernel: Linux 2.6.22-2-686 (SMP w/4 CPU cores)
Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libqt4-ruby1.8 depends on:
ii  libruby1.81.8.6.36-3 Libraries necessary to run Ruby 1.
ii  libsmokeqt4-1 1.4.9-5Smoke library for Qt4
ii  ruby  1.8.2-1An interpreter of object-oriented 
ii  ruby1.8   1.8.6.36-3 Interpreter of object-oriented scr

libqt4-ruby1.8 recommends no packages.

-- no debconf information



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

Bug#411982: [php-maint] Bug#411982: php5 makes a segmentation fault when php5-curl

[Hans Grobler]

On Sun, 2007-03-11 at 19:26 +0100, sean finney wrote:
 hrm... i can't reproduce this, even when i set up an etch chroot with
 everything in your dpkg output installed (minus a few non-debian
 packages that were probablly not related).  how about your pam/libnss
 configuration?  also, it's a major pain to get moodle set up to test
 this, could you provide a smaller self-contained script that also
 exhibits this behaviour?  perhaps a small script that uses curl/ssl or
 maybe postgres features just enough to tickle the bug?

I have updated to the latest packages (including those of php5) and the
segfault remains. On my system, only the moodle cron script triggers
this bug. Other test scripts do not produce this. However, I have not
tried with php-postgres included, although that does seem to be needed
given that the moodle script accesses a postgresql database.

 fwiw, these are the packages i could not/did not install in the test
 chroot.  besides the linux-image stuff, the dell stuff, and some local
 configuration-looking packages, i saw some older packages no longer
 available in etch.  you might want to see what's in those packages, if
 any of them have shared libraries could you share their contents?

I have removed all unnecessary packages and the problem remains. The
remaining packages are unrelated and do not show up in the shared
library dependency list of the core file produced. 

Regards,
-- Hans




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

Bug#411982: [php-maint] Bug#411982: php5 makes a segmentation fault when php5-curl

[Hans Grobler]

On Sun, 2007-03-11 at 10:58 +0100, sean finney wrote:
 correct, there are no changes in the pending version of php that affect
 curl, but my thought was that perhaps the problem is a transient one
 resulting from building against a bad version of some library, which
 might be fix by a simple rebuild.  however, i can't reproduce the
 problem you're having by installing the old version of
 php5/libcurl3/libssl0.9.8, so i'm not sure where to go from here.  i'll
 see if anyone else has ideas.  in the meantime, could you send me the
 full output of dpkg -l | grep ^ii, so i can see if it's some other
 seemingly unrelated package that's doing it?

See attached. I vaguely remember seeing this problem when this was a
sarge machine as well. As another test, I removed the php5-curl module
and now the moodle script runs without problems. So the problem is
triggered by the curl module as suspected. One thing to mention is that
I'm using Kerberos... and since libcurl links against libkrb5, it might
be that libcurl contains Kerberos related bugs... ?

However, after adding the debugging libraries, no Kerberos calls appear
in the backtrace (see below).

Regards,
-- Hans

(gdb) bt
#0  0xf74932f0 in ?? ()
#1  0xf7bb8fa5 in CRYPTO_lock (mode=9, type=1, file=0xf7c9ca13 err.c,
line=353) at cryptlib.c:489
#2  0xf7c24f4f in int_err_del () at err.c:353
#3  0xf7c2677a in ERR_free_strings () at err.c:672
#4  0xf7974c47 in Curl_ossl_cleanup () at ../../../lib/ssluse.c:580
#5  0xf7985b80 in Curl_ssl_cleanup () at ../../../lib/sslgen.c:185
#6  0xf797dd9f in curl_global_cleanup () at ../../../lib/easy.c:294
#7  0xf79936b7 in zm_shutdown_curl () from /usr/lib/php5/20060613
+lfs/curl.so
#8  0x082a436e in module_destructor ()
#9  0x082aa5a8 in zend_hash_quick_find ()
#10 0x082aa847 in zend_hash_graceful_reverse_destroy ()
#11 0x082a09cc in zend_shutdown ()
#12 0x0825b885 in php_module_shutdown ()
#13 0x0832ed18 in main ()



dpkg.list.bz2
Description: application/bzip

Bug#411982: [php-maint] Bug#411982: php5 makes a segmentation fault when php5-curl

[Hans Grobler]

Hi Sean,

On Sat, 2007-03-10 at 18:30 +0100, sean finney wrote:
 hi hans,
 
 i'm still unable to reproduce this problem.  can you give me:
 
 - your list of installed/configured php extensions (php.ini and conf.d/*.ini)
 - package versions for libssl*, libcurl*, libssl*
 
 and maybe we can take things from there.  also, could you check to see
 if this problem is in the latest version of the php packages?  if
 you're using etch a new version was recently uploaded to
 testing-proposed-updates that contains security fixes you'll want anyways :)

Yes, I'm running the latest Etch with all updates installed. I see there
is a new version that is pending and I should have that installed the
moment it becomes available on our local archive (however, it does not
appear that the update affects curl). Below and attached is the current
information requested.

Regards,
-- Hans

libcurl3   7.15.5-1
libssl-dev 0.9.8c-4  
libssl0.9.80.9.8c-4  
php5   5.2.0-8 
php5-cli   5.2.0-8 
php5-common5.2.0-8 
php5-curl  5.2.0-8 
php5-dev   5.2.0-8 
php5-gd5.2.0-8 
php5-mcrypt5.2.0-8 
php5-mysql 5.2.0-8 
php5-pgsql 5.2.0-8 
php5-xsl   5.2.0-8 














etcphp5.tar.bz2
Description: application/bzip-compressed-tar

Bug#411982: php5 makes a segmentation fault when php5-curl

[Hans Grobler]

Subject: php5: Segmentation fault in CURL module
Package: php5
Version: 5.2.0-8
Severity: important

*** Please type your report below this line ***

I have encountered a similar problem. In my case, the bug was triggered
by the moodle cron script. Note the cron script completes, the segfault
happens whilst the php5 interpreter is terminating. It appears there is
a bug in the curl module, see attached backtrace:

Core was generated by `/usr/bin/php
-f /usr/share/moodle/admin/cron.php'.
Program terminated with signal 11, Segmentation fault.
#0  0xf74672f0 in ?? ()
(gdb) bt
#0  0xf74672f0 in ?? ()
#1  0xf7b8cfa5 in CRYPTO_lock ()
from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#2  0xf7bf8f4f in ERR_set_implementation ()
from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#3  0xf7bfa77a in ERR_free_strings ()
from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#4  0xf7948c47 in curl_slist_free_all () from /usr/lib/libcurl.so.3
#5  0xf7959b80 in curl_getdate () from /usr/lib/libcurl.so.3
#6  0xf7951d9f in curl_global_cleanup () from /usr/lib/libcurl.so.3
#7  0xf79676b7 in zm_shutdown_curl () from /usr/lib/php5/20060613
+lfs/curl.so
#8  0x082a436e in module_destructor ()
#9  0x082aa5a8 in zend_hash_quick_find ()
#10 0x082aa847 in zend_hash_graceful_reverse_destroy ()
#11 0x082a09cc in zend_shutdown ()
#12 0x0825b885 in php_module_shutdown ()
#13 0x0832ed18 in main ()

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-amd64
Locale: LANG=en_ZA, LC_CTYPE=en_ZA (charmap=ISO-8859-1)

Versions of packages php5 depends on:
ii  libapache2-mod-php5   5.2.0-8server-side, HTML-embedded
scripti
ii  php5-common   5.2.0-8Common files for packages
built fr

php5 recommends no packages.

-- no debconf information
 



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

Bug#411982: Most likely related to bug #395996

[Hans Grobler]

I see now that there is another similar bug registered, #395996, which
is marked as unreproducible. That bug includes a more detailed backtrace
and clearly indicates a locking problem in the CURL module.



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

Bug#403192: libpam-krb5: retain_after_close option ignored when SSH using gssapi

[Hans Grobler]

Dist:Etch (4.0)
Package: libpam-krb5
Version: 2.6-1

When logging into a system using SSH and authenticating via gssapi-with-mic, the
retain_after_close option to libpam-krb5 is ignored and the ticket
cache is destroyed upon logout.

However, when logging into a system using SSH and standard password
authentication, the retain_after_close option works as expected and the
ticket cache is not destroyed upon logout.

Since the retain_after_close is essential when submitting long-running jobs
(i.e. nohup ./job ), its rather problematic that this does not work with
gssapi logins.


This message and attachments are subject to a disclaimer. Please refer
to www.it.up.ac.za/documentation/governance/disclaimer/ for full
details. / Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule
onderhewig. Volledige besonderhede is by
www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.



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

Bug#403192: libpam-krb5: retain_after_close option ignored when SSH using gssapi

[Hans Grobler]

On Fri, 2006-12-15 at 08:53 -0800, Russ Allbery wrote:
 With gssapi-with-mic, PAM doesn't obtain the tickets and therefore also
 doesn't attempt to destroy them.  sshd itself is responsible for both.  My
 guess is that you're looking for the sshd_config option:
 
 GSSAPICleanupCredentials no
 
 The default is yes.  Could you try setting this in your sshd_config and
 see if it resolves your issue?

I have performed the recommended change and confirmed that the GSSAPI
obtained credentials are now correctly retained. Russ, thanks for the
hint. (FWIW: your pam-afs-session module works correctly in this
configuration and now both krb5 and afs credentials are retained).

Regards,
-- Hans



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

Bug#394097: libapache2-mod-auth-pam: doesnt work with Apache 2.1

[Hans Grobler]

I have also had problems after an upgrade to Etch. The recommended additions of
AuthPAM_FallThrough off and AuthBasicAuthoritative off however do not work
in my case. My setup makes use of LDAP and Kerberos and as far as I know the
PAM configuration is correct (for example: I can successfully SSH with both
LDAP/Kerberos and local accounts).

Regards,
-- Hans

This message and attachments are subject to a disclaimer. Please refer
to www.it.up.ac.za/documentation/governance/disclaimer/ for full
details. / Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule
onderhewig. Volledige besonderhede is by
www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.



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

Bug#396045: openafs-modules-source: aklog -setpag no longer works

[Hans Grobler]

I have encountered the same problem (breakage of libpam-openafs-session) after
upgrading to 1.4.2-2. However, for some reason downgrading the kernel module to
1.4.2~fc4-3 did not help...

Regards,
-- Hans

This message and attachments are subject to a disclaimer. Please refer
to www.it.up.ac.za/documentation/governance/disclaimer/ for full
details. / Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule
onderhewig. Volledige besonderhede is by
www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.



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

Bug#396045: openafs-modules-source: aklog -setpag no longer works

[Hans Grobler]

Upon further investigation, I can confirm Arne's report. With everything
else remaining constant (all other openafs packages at 1.4.2-2 and
kernel 2.6.17-2-686), reverting to the 1.4.2~fc4-3 openafs module does
fix the problem. The symptoms seen correspond to recent -setpag reports
on OpenAFS-devel list as reported in OpenAFS and OpenSSH, PAM, tokens.

Regards,
-- Hans



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