Bug#925141: Should rdma-core be a dependency of ibverbs-providers or libverb1
On Tue, Mar 26, 2019 at 02:51:25PM +0100, Thomas Monjalon wrote: > 26/03/2019 10:21, Christian Ehrhardt: > > > > > > > > rdma-core configures modprobe for ib/rdma modules, installs some > > > > helper daemons and installs some udev rules. It certainly makes > > > > administration of the server an easier task, but it isn't *required* > > > > when configuring a Debian server for rdma and user-space ibverbs. > > > > > > I didn't think it is required for mlx5 as the ethernet driver > > > autoloads the rdma modules itself.. > > > > Below is the log that I got from Mellanox (thanks Alaa and Thomas. > > To me the messages related to ib_uverbs seem interesting. > > > > @Jason - this is triggered by DPDK. In regard to the autoloading - did > > you refer to DPDKs net_mlx5 or the kernels net_mlx5 in e.g. > > mlx5_core.ko? > > I only found [1] which does not seem right, can you point at the > > autoloading feature (a commit maybe) that you meant (keep in mind this > > is DPDK 17.11.5)? > > [1]: https://doc.dpdk.org/guides/nics/mlx5.html#compilation-options > > There is no autoloading of kernel drivers when using DPDK. It looks like it is only done if the mlx5 NIC driver detects some kind of RDMA mode.. > > @Allaa/Thomas - due to the messages in the log, could you try if > > instead of installing rdma-core just doing the modprobe would be > > enough to resolve the problem? > > $ modprobe ib_uverbs # instead of the apt install > > Yes, manual modprobe partially replaces rdma-core packages. > > These are the files we identified as required from the rdma-core packages: > /etc/modprobe.d/mlx4.conf > /etc/rdma/modules/rdma.conf > /lib/udev/rules.d/90-rdma-hw-modules.rules > /lib/systemd/system/rdma-hw.target > > The first file (mlx4.conf) is a template helping to get the right config > by commenting out a line. > The others files are for autoloading of the kernel drivers. > > I think you should include the rdma-core package when using DPDK. > It can be a dependency of the DPDK package, or a dependency of libibverbs. > Does it make sense to install libibverbs without rdma-core configuration? Many rdma drivers do properly autoload and don't need the udev magic. I have a long term plan to avoid needing this, but nobody is working on it right now. Jason
Bug#925141: Should rdma-core be a dependency of ibverbs-providers or libverb1
On Thu, Mar 21, 2019 at 01:26:04PM -0500, Brian Smith wrote: > On Thu, Mar 21, 2019 at 3:51 AM Christian Ehrhardt > wrote: > > > > > ibverbs is provided by rdma-core project. > > > Is it a separate package in your case? > > > > No it is part of the same src package. > > > > > Yes, you need libmlx4, libmlx5 and libibverbs. > > > It is described in the doc: > > > http://doc.dpdk.org/guides/nics/mlx5.html#prerequisites > > > > Well that is the problem, we fulfill that prereq already. > > libmlx4, libmlx5 and libibverbs are installed by dependencies already > > and thought all the time that would be good enough. > > > > But we got told that we also need the package rdma-core [1] itself to > > be installed to be useful. > > That was a discussion with the subject "Please help us to verify DPDK > > 17.11.5 for Ubuntu 18.04/18.10" with Mellanox test people. > > Fortunately I keep you on CC on those - so maybe you can find it > > somewhere in your inbox and contact the other Mellanox people on that > > thread. > > After that you might help to translate their request into our terms please? > > > > The question is: > > a) what exactly is (binary package) rdma-core [1] needed for in that > > scenario > > b) if (a) would be generally true we wondered why it had to be a dep > > of the DPDK packages and not of e.g. libibverbs1 itself > > That is why we opened this bug for discussions > > > > [1]: https://packages.debian.org/sid/rdma-core > > > > rdma-core configures modprobe for ib/rdma modules, installs some > helper daemons and installs some udev rules. It certainly makes > administration of the server an easier task, but it isn't *required* > when configuring a Debian server for rdma and user-space ibverbs. I didn't think it is required for mlx5 as the ethernet driver autoloads the rdma modules itself.. At least, I wouldn't make rdma-core a hard dependency of dpdk.. At worst that should be in libibverbs, as you say. Jason
Bug#898055: ibverbs-providers is marked Multi-Arch: same but is not coinstallable
On Sun, May 06, 2018 at 05:11:02AM -0400, Francois Gouget wrote: > Package: ibverbs-providers > Version: 17.1-2 > Severity: normal > > Dear Maintainer, > > Trying to install the amd64 and i386 versions of this package results in the > following error: > > # apt-get install ibverbs-providers:amd64 ibverbs-providers:i386 > [...] > Unpacking ibverbs-providers:i386 (17.1-1) ... > Processing triggers for libc-bin (2.27-3) ... > dpkg: dependency problems prevent configuration of ibverbs-providers:i386: > ibverbs-providers:amd64 (17.1-1) breaks libcxgb3-1 and is installed. > ibverbs-providers:i386 (17.1-1) provides libcxgb3-1. > ibverbs-providers:amd64 (17.1-1) breaks libipathverbs1 and is installed. > ibverbs-providers:i386 (17.1-1) provides libipathverbs1. > ibverbs-providers:amd64 (17.1-1) breaks libmlx4-1 and is installed. > ibverbs-providers:i386 (17.1-1) provides libmlx4-1. > ibverbs-providers:amd64 (17.1-1) breaks libmlx5-1 and is installed. > ibverbs-providers:i386 (17.1-1) provides libmlx5-1. > ibverbs-providers:amd64 (17.1-1) breaks libmthca1 and is installed. > ibverbs-providers:i386 (17.1-1) provides libmthca1. > ibverbs-providers:amd64 (17.1-1) breaks libnes1 and is installed. > ibverbs-providers:i386 (17.1-1) provides libnes1. > > dpkg: error processing package ibverbs-providers:i386 (--configure): > dependency problems - leaving unconfigured > Errors were encountered while processing: > ibverbs-providers:i386 > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > So the source of the issue seems to be that ibverbs-providers: > * Provides a bunch of virtual packages > * Breaks + Replaces these virtual packages They are not virtual packages, but obsolete real packages that this package has replaced. > Apt seems to consider that this means ibverbs-providers:amd64 breaks > ibverbs-providers:i386 through the virtual packages which prevents them from > being > coinstalled. Curiously, this isn't apt complaining, but dpkg. This indicates there is a apt bug, as it should never invoke dpkg in a way where it fails like this. > Note that, based on 7.6.2, the usual pattern for virtual packages would be > Provides + Conflicts + Replaces: Well, that would still cause problems as Conflicts/Provides will still fail. I think the correct solution is this text: If a relationship field has a version number attached, only real packages will be considered to see whether the relationship is satisfied (or the prohibition violated, for a conflict or breakage). In other words, if a version number is specified, this is a request to ignore all Provides for that package name and consider only real packages. The package manager will assume that a package providing that virtual package is not of the "right" version. A Provides field may not contain version numbers, and the version number of the concrete package which provides a particular virtual package will not be considered when considering a dependency on or conflict with the virtual package name.[52] Ie add a version to the breaks so that dpkg will ignore the Provides when matching it. This should allow multiple packages to provide at once.. At least it suggests that is how Conflicts will work, and I don't recall off hand :) Jason
Bug#894995: rdma-core: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
On Thu, Apr 19, 2018 at 02:00:18PM +0200, Benjamin Drung wrote: > > I applied the same fix as for many other arches, which is to add the > > arch to the > > list of NO_COHERENT_DMA_ARCHS in debian/rules. > > > > I am not sure if support could be added at a later date, but for the > > time being, > > seems to be the best way to get it working -- I don't know enough > > details of the > > architecture or the assembly language to get the necessary > > incantations in > > place. > > RISC-V has a FENCE instruction and the A extension (which is part of > the G instruction set) provides atomic memory operations. So the > architecture should provide coherent DMA support. To enable support, > util/udma_barrier.h needs to be adjusted. I am including > linux-r...@vger.kernel.org in the loop for help. You can't tell from the instruction set if a chip is DMA coherent or not. It depends how the cache's are designed, and if they have a 'snoop controller' or otherwise. Generally if *any* DMA coherent implementations exist then we should add the fences, otherwise better to just not compile the drivers that have no chance of working. Jason
Bug#881814: Processed: libibverbs-dev no longer ships infiniband/driver.h
> libibverbs-dev > src:librdmacm > src:libcxgb3 > src:libmlx4 > src:libipathverbs > src:libmlx5 > src:libibcm > src:libmthca > src:libnes These are now all part of rdma-core. These packages should be removed from unstable and all other release suites that have rdma-core. It is an error to attempt to build them against rdma-core. > src:libfabric This is has been fixed in libfabric upstream, look for patches from me. Jason
Bug#881731: rdma-core: FTBFS on armhf and mips*: missing providers that need coherent DMA
On Tue, Nov 14, 2017 at 03:41:13PM -0500, Don Dutile wrote: > On 11/14/2017 02:08 PM, Jason Gunthorpe wrote: > >>However, it would of course be better to teach udma_barrier.h about > >>these architectures. > > > >The issue is that some architectures just can't do cache coherent DMA > >on any implementation. eg m68k > > > >There is no correct udma_barrier.h at all in those cases. > > > >We need to teach debian to follow cmake and exclude the missing > >installables in these cases.. > > > >Or do not build at all on these arch's.. > > > >Jason > Jason: > Why am I being cc'd on this debian bug? You were not cc'd... The linux-rdma mailing list has been subscribed to the debian bug feed for rdma-core :\ Unclear if this is a good idea or not, but for now I think being supportive of Benjamin is a good call as he has done so much work to get the packages accepted. You can probably filter and discard messages with these two headers together: List-ID: X-Debian-PR-Package: src:rdma-core Jason
Bug#881731: rdma-core: FTBFS on armhf and mips*: missing providers that need coherent DMA
> However, it would of course be better to teach udma_barrier.h about > these architectures. The issue is that some architectures just can't do cache coherent DMA on any implementation. eg m68k There is no correct udma_barrier.h at all in those cases. We need to teach debian to follow cmake and exclude the missing installables in these cases.. Or do not build at all on these arch's.. Jason
Bug#854217: [Pkg-ofed-devel] Bug#854217: Bug#854217: mark libibverbs1 Multi-Arch: same
On Mon, Feb 06, 2017 at 06:45:15PM +0100, Helmut Grohne wrote: > That's hard to answer without more insight into those packages than I > have. In general, it is desirable to mark shared library packages, debug > packages and development packages Multi-Arch: same, but such a marking > is not always correct and an incorrect marking causes much harm. > > I have 3 suggestions: > * Try to follow https://wiki.debian.org/Multiarch/Implementation. > * Upload those packages to Debian unstable (after stretch) and follow >the "multiarch hinter" results on https://tracker.debian.org/source package>. > * Upload those packages to Debian (e.g. experimental) and ask some >multiarchy person (e.g. me) for help. The design of the rdma-core stuff was done with multi-arch in mind, I believe the following should be OK: Package: libibcm1 Package: libibcm1-dbg Package: libibcm-dev Package: libibumad3 Package: libibumad3-dbg Package: libibumad-dev Package: libibverbs1 Package: libibverbs1-dbg Package: libibverbs-dev Package: librdmacm1 Package: librdmacm1-dbg Package: librdmacm-dev We have no arch specific headers, provide no install scripts (aside from what dh produces) and do not use .pc or .la files. ibverbs-providers needs some fixing however.. Jason
Bug#854217: [Pkg-ofed-devel] Bug#854217: Bug#854217: mark libibverbs1 Multi-Arch: same
On Mon, Feb 06, 2017 at 11:36:11AM +0100, Benjamin Drung wrote: > > maintainer scripts, so marking them Multi-Arch: same is correct as > > well. > > The attached patch adds all of those markings. Please consider > > applying > > it after stretch is released. > > Thanks for the patch. Since the source package libibverbs will > (probably) replaced by rdma-core after the stretch release, I created a > pull request for rdma-core: > https://github.com/linux-rdma/rdma-core/pull/75 Should these tags be applied to the other rdma-core libraries? Jason
Bug#774533: Fixed..
FWIW, this was fixed in upstream commit 441f0e0d84082eb498e620327ebf4de509052d15 So ever since 2.2.17.rc1 Jason
Bug#793921: tftpd-hpa: IPv6 address cannonization breaks IPv4
On Wed, Jul 29, 2015 at 05:34:00PM +0930, Ron wrote: This commit: tftp: convert IPv6-mapped IPv4 addresses to IPv4 If we receive IPv4 addresses mapped to IPv6, convert them back to IPv4 so that mapping scripts which use \i behave sanely. Signed-off-by: H. Peter Anvin h...@zytor.com Totally breaks IPv4 support when tftpd is used with an IPv6 listening socket (eg when invoked from systemd) I think I can see a couple of ways this might start to wind down a rathole of workaround upon workaround for various network configurations I haven't seen a followup from HPA, so I wanted to quickly comment on this point.. (like if the machine is only listening on an IPv6 socket, will local policy even allow it to send from an IPv4 one etc.) IPv4 running in a IPv6 socket is indistinguishable at the policy/firewall/etc level from proper IPv4, there should be no downside to receiving a connect on a IPv6 listening socket and then switching to an IPv4 socket for further communication. It's also not clear to me that croaking with an assert is the ideal response here, but logging a warning at least would definitely be helpful. That can be changed. However, if the assert triggers it indicates a logic flaw of some kind in the normalization code. Jason -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793921: tftpd-hpa: IPv6 address cannonization breaks IPv4
Package: tftpd-hpa
Version: 5.2+20140608-3
Severity: important
This commit:
tftp: convert IPv6-mapped IPv4 addresses to IPv4
If we receive IPv4 addresses mapped to IPv6, convert them back to IPv4
so that mapping scripts which use \i behave sanely.
Signed-off-by: H. Peter Anvin h...@zytor.com
Totally breaks IPv4 support when tftpd is used with an IPv6 listening socket
(eg when invoked from systemd)
The issue is that the tftpd caller assumes that 'from' and 'myaddr' have the
same AF, however the above patch only cannonizes 'myaddr'. Ultimately this
results in the daemon attempting to use a socket with two address families and
fails:
recvmsg(0, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(34500),
inet_pton(AF_INET6, :::10.0.0.192, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, msg_iov(1)=[{\0\1pxelinux.0\0netascii\0, 65468}],
msg_controllen=40, {cmsg_len=36, cmsg_level=SOL_IPV6, cmsg_type=, ...},
msg_flags=0}, 0) = 22
[..]
[pid 3757] socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 0
[..]
[pid 3757] bind(0, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(10.0.0.2)}, 16) = 0
[pid 3757] connect(0, {sa_family=AF_INET6, sin6_port=htons(34500),
inet_pton(AF_INET6, :::10.0.0.192, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = -1 EAFNOSUPPORT (Address family not supported by
protocol)
[pid 3757] sendto(3, 27Jul 28 15:32:20 tftpd[3757]: connect: Address family
not supported by protocol, 82, MSG_NOSIGNAL, NULL, 0) = 82
This makes the daemon utterly unusable.
Suggest this tested patch:
--- ../x/tftp-hpa-5.2+20140608/tftpd/recvfrom.c 2014-07-29 20:31:34.0
-0600
+++ tftpd/recvfrom.c2015-07-28 15:42:12.533074001 -0600
@@ -24,6 +24,8 @@
#include machine/param.h /* Needed on some versions of FreeBSD */
#endif
+#include assert.h
+
#if defined(HAVE_RECVMSG) defined(HAVE_MSGHDR_MSG_CONTROL)
#include sys/uio.h
@@ -253,6 +255,8 @@
}
#endif
normalize_ip6_compat(myaddr);
+ normalize_ip6_compat((union sock_addr *)from);
+ assert(from-sa_family == myaddr-sa.sa_family);
}
#endif
}
-- System Information:
Debian Release: 8.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.18.17 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages tftpd-hpa depends on:
ii adduser3.113+nmu3
ii debconf [debconf-2.0] 1.5.56
ii libc6 2.19-18
ii libwrap0 7.6.q-25
tftpd-hpa recommends no packages.
Versions of packages tftpd-hpa suggests:
pn pxelinux none
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774514: winbind crashes when a user with an expired password logs in
Package: winbind Version: 2:4.1.13+dfsg-2 Severity: important Pretty simple, if the password has expired in AD then at login a winbind process begins looping with 100% CPU and all of winbind becomes unusable, which basically crashes the OS since nss hangs. Further, 'systemctl restart winbindd' doesn't actually kill the looping winbind (!?! I thought systemd gurenteed that?) a kill -9 is needed to recover from this. gdb says the backtrace is: #0 0x7f7b059013cf in krb5_get_init_creds_password () from /usr/lib/x86_64-linux-gnu/libkrb5.so.26 #1 0x7f7b0797f969 in kerberos_kinit_password_ext () from /usr/lib/x86_64-linux-gnu/samba/libgse.so.0 #2 0x7f7b0b995959 in kerberos_return_pac () #3 0x7f7b0b9bb530 in winbindd_dual_pam_auth () #4 0x7f7b0b9cfcec in ?? () #5 0x7f7b04e402cb in ?? () from /usr/lib/x86_64-linux-gnu/libtevent.so.0 #6 0x7f7b04e3e797 in ?? () from /usr/lib/x86_64-linux-gnu/libtevent.so.0 #7 0x7f7b04e3af9d in _tevent_loop_once () from /usr/lib/x86_64-linux-gnu/libtevent.so.0 #8 0x7f7b0b9d2068 in ?? () #9 0x7f7b0b9d2765 in ?? () #10 0x7f7b04e3b7c4 in tevent_common_loop_immediate () from /usr/lib/x86_64-linux-gnu/libtevent.so.0 #11 0x7f7b04e4008e in ?? () from /usr/lib/x86_64-linux-gnu/libtevent.so.0 #12 0x7f7b04e3e797 in ?? () from /usr/lib/x86_64-linux-gnu/libtevent.so.0 #13 0x7f7b04e3af9d in _tevent_loop_once () from /usr/lib/x86_64-linux-gnu/libtevent.so.0 #14 0x7f7b0b994fac in main () The internet has a few notes about something that sounds very similar: https://bugzilla.samba.org/show_bug.cgi?id=8747 The prompter only returns the password once, so the Kerberos library sees that the entered passwords don't match. MIT Kerberos only tries again three times, but Heimdal loops forever (in init_creds_pw.c). The above is a backport from Samba 4 - and the Samba 4 fix is included in Debian's version: http://anonscm.debian.org/cgit/pkg-samba/samba.git/commit/?id=10989431e533bd60de242dbd78c4b62c4ace7812 However, for some reason, Samba 4 has two copies of that function, one in source4/auth/kerberos/kerberos.c (addressed by above) and one here: http://anonscm.debian.org/cgit/pkg-samba/samba.git/tree/source3/libads/kerberos.c Looking at the backtrace we can see winbind calls kerberos_kinit_password_ext, which is only present in source3/libads/kerberos.c which seems to strongly suggest it is this bug. At the very least it doesn't make alot of sense to apply 10989431 to only one of the two locations in the source tree. Jason -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739768: Confirm
I am seeing this bug too, and I can confirm it is fixed in Ubuntu's
version. They have been shipping with this fix in trusty which works
in my environment. The latest patch from the upstream bug might be
better, but I haven't tried it.
For whatever reason upstream remains typically silent on the bug
report and proposed patch..
Here is the fix ubuntu is shipping:
--- samba-4.1.6+dfsg.orig/source3/librpc/crypto/gse_krb5.c 2014-04-29
16:05:42.045043324 -0500
+++ samba-4.1.6+dfsg/source3/librpc/crypto/gse_krb5.c 2014-04-29
16:05:42.041043324 -0500
@@ -414,6 +414,10 @@ static krb5_error_code fill_mem_keytab_f
if (ret) {
DEBUG(1, (__location__ : krb5_kt_start_seq_get failed (%s)\n,
error_message(ret)));
+ if (keytab) {
+ krb5_kt_close(krbctx, keytab);
+ keytab = NULL;
+ }
goto out;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774533: LAYOUT=imapdir is broken
Package: dovecot-core
Version: 1:2.2.13-11
mail_location = maildir:[..]:LAYOUT=imapdir is broken, the symptom is dovecot
returning this to the client when requesting any mailbox beyond INBOX:
Character not allowed in mailbox name: '
Which is actually trying to say Character not allowed in mailbox name: '\0',
but since the %c is not escaped it ends up with the truncated string.
This patch fixes it:
diff --git a/src/lib-storage/list/mailbox-list-maildir.c
b/src/lib-storage/list/mailbox-list-maildir.c
index c99a2900a6d6..ae5f35d955ac 100644
--- a/src/lib-storage/list/mailbox-list-maildir.c
+++ b/src/lib-storage/list/mailbox-list-maildir.c
@@ -46,6 +46,7 @@ static struct mailbox_list *imapdir_list_alloc(void)
list = p_new(pool, struct maildir_mailbox_list, 1);
list-list = imapdir_mailbox_list;
list-list.pool = pool;
+ list-sep = '.';
list-global_temp_prefix = IMAPDIR_GLOBAL_TEMP_PREFIX;
list-temp_prefix = p_strconcat(pool, list-global_temp_prefix,
Analysis:
I noticed this while upgrading a dovecot install from 1.2.15 (squeeze) to
2.2.13 (jessie).
This upstream commit
author Timo Sirainen t...@iki.fi
Thu Jan 20 20:59:07 2011 +0200 (2011-01-20)
changeset 12586 a2780b694b2d
parent 12585b748c622e896
child 12587 c3a258ee96c4
lib-storage: mailbox_alloc() now takes a virtual mailbox name and other
related API changes.
All storage_name - vname conversions now go through the same two
mailbox_list methods. This has many benefits, such as:
* listescape plugin is now much simpler and bugfree
* allows changing lib-storage API to use UTF-8 mailbox names in future
* allows creation of mailbox aliases plugin
Restructed the _alloc functions to move the hierarchy_sep from the initializer
into the _alloc call itself:
@@ -29,6 +30,7 @@ static struct mailbox_list *maildir_list_alloc(void)
list = p_new(pool, struct maildir_mailbox_list, 1);
list-list = maildir_mailbox_list;
list-list.pool = pool;
+ list-sep = '.';
list-global_temp_prefix = MAILDIR_GLOBAL_TEMP_PREFIX;
list-temp_prefix = p_strconcat(pool, list-global_temp_prefix,
[..]
struct mailbox_list maildir_mailbox_list = {
.name = MAILBOX_LIST_NAME_MAILDIRPLUSPLUS,
- .hierarchy_sep = '.',
.props = MAILBOX_LIST_PROP_NO_MAILDIR_NAME |
MAILBOX_LIST_PROP_NO_ALT_DIR |
MAILBOX_LIST_PROP_NO_NOSELECT,
[..]
struct mailbox_list imapdir_mailbox_list = {
.name = MAILBOX_LIST_NAME_IMAPDIR,
- .hierarchy_sep = '.',
.props = MAILBOX_LIST_PROP_NO_MAILDIR_NAME |
MAILBOX_LIST_PROP_NO_ALT_DIR |
MAILBOX_LIST_PROP_NO_NOSELECT,
Noting that heierarchy_sep was removed from maildir_mailbox_list and
imapdir_mailbox_list but only added to maildir_list_alloc(), and not
imapdir_list_alloc(). This ultimately results in
mailbox_list_get_hierarchy_sep() returning '\0' and mailbox_verify_name()
failing everything (all strings contain '\0' according to strchr).
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774263: dovecot winbind integration does not work
Package: dovecot-core
Version: 1:2.2.13-11
If the directions on the wikki are followed and dovecot is configured
with:
auth_use_winbind = yes
auth_mechanisms = plain gssapi gss-spnego login ntlm
Then the 'ntlm' method does not work. (for reference this mechanism
calls the samba ntlm_auth helper program)
This works fine in squeeze so I investigated the source of the
problem.
With a high enough log level this obscure message will come out:
Dec 30 20:30:21 quartz dovecot[8439]: auth: Error: Login for user
[]\[jgg]@[wakko] failed due to [Reading winbind reply failed!]
Dec 30 20:30:21 quartz dovecot[8439]: auth: Error:
../auth/ntlmssp/ntlmssp_server.c:454: Checking NTLMSSP password for \jgg
failed: NT_STATUS_UNSUCCESSFUL
Dec 30 20:30:21 quartz dovecot[8439]: auth: Error: GENSEC login failed:
NT_STATUS_UNSUCCESSFUL
Dec 30 20:30:21 quartz dovecot[8439]: auth: Error: winbind: ntlm_auth exited
with exit code 0
Noting the failure code is 'Reading winbind reply failed!'
After investigating some more I figured out that dovecot is now
calling ntlm_auth as user dovecot (1.2 used user root), and for some
reason ntlm_auth in jessie requires access to the priviledged pipe (ie
/var/lib/samba/winbindd_privileged/pipe). Typically this is root-only.
So it doesn't work, and fails obtusely.
I am surprised/dismayed that samba requires priviledge to validate
NTLM, but at least in jessie (2:4.1.13+dfsg-2) it does, perhaps that
is another bug. But, knowing what to look for, it is easy to see:
As root:
$ ntlm_auth --diagnostics --username=jgg
Password:
Wrong Password (0xc06a)
Wrong Password (0xc06a)
As a user:
$ ntlm_auth --diagnostics --username=jgg
Password:
Reading winbind reply failed! (0xc001)
Test LM failed!
Reading winbind reply failed! (0xc001)
Test LM and NTLM failed!
Reading winbind reply failed! (0xc001)
Test NTLM failed!
Reading winbind reply failed! (0xc001)
Test NTLM in LM failed!
Reading winbind reply failed! (0xc001)
Test NTLM in both failed!
Reading winbind reply failed! (0xc001)
Test NTLMv2 failed!
Reading winbind reply failed! (0xc001)
Test NTLMv2 and LMv2 failed!
Reading winbind reply failed! (0xc001)
Test LMv2 failed!
Reading winbind reply failed! (0xc001)
Test NTLMv2 and LMv2, LMv2 broken failed!
Reading winbind reply failed! (0xc001)
Reading winbind reply failed! (0xc001)
Test NTLM and LM, LM broken failed!
Reading winbind reply failed! (0xc001)
Reading winbind reply failed! (0xc001)
Test Plaintext failed!
Reading winbind reply failed! (0xc001)
Test Plaintext LM broken failed!
Reading winbind reply failed! (0xc001)
Reading winbind reply failed! (0xc001)
Test Plaintext NT only failed!
Reading winbind reply failed! (0xc001)
Test Plaintext LM only failed!
So, the fix on the dovecot side is to revert to the dovecot 1.2
behavior and invoke ntlm_auth as root, simply done as a config
change:
service auth {
user = root
}
At a minimum this should be documented in the config comments around
'auth_use_winbind', probably should be on the wikki and ideally
dovecot would default to root if winbind is enabled, since it doesn't
work at all otherwise..
Jason
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773313: systemd tmpfiles errantly auto-cleans PrivateTmp /var/tmp
Package: systemd
Version: 215-7
Severity: important
The debian systemd package is erasing temporary files under the
PrivateTmp=yes directories in /var/tmp/ (ie
/var/tmp/systemd-private-%b-bar/tmp/foo), this breaks deamons that
expect that /var/tmp is not cleaned.
This is being caused by a conflict between a debian patch and a
systemd bug. Since the intent of the debian patch was to diable
cleaning /var/tmp files I recommend cherry picking the trivial systemd
upstream patch into jessie.
The Debian specific patch
debian/patches/Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-defaul.patch:
--- a/tmpfiles.d/tmp.conf
+++ b/tmpfiles.d/tmp.conf
@@ -8,8 +8,8 @@
# See tmpfiles.d(5) for details
# Clear tmp directories separately, to make them easier to override
-d /tmp 1777 root root 10d
-d /var/tmp 1777 root root 30d
+D /tmp 1777 root root -
+#d /var/tmp 1777 root root 30d
Removes the entry for /var/tmp, however it leaves the ignores later in
the file:
# Exclude namespace mountpoints created with PrivateTmp=yes
x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-*/tmp
x /var/tmp/systemd-private-%b-*
X /var/tmp/systemd-private-%b-*/tmp
Having an X line without a aged parent directory triggers a systemd
bug which is already fixed in upstream. Removing the four lines above
would also avoid the bug.
http://cgit.freedesktop.org/systemd/systemd/commit/src/tmpfiles/tmpfiles.c?id=9ed2a35e93f4a9e82585f860f54cdcbbdf3e1f86
From 9ed2a35e93f4a9e82585f860f54cdcbbdf3e1f86 Mon Sep 17 00:00:00 2001
From: Richard Weinberger rich...@nod.at
Date: Tue, 9 Sep 2014 11:09:37 +0200
Subject: systemd-tmpfiles: Fix IGNORE_DIRECTORY_PATH age handling
If one has a config like:
d /tmp 1777 root root -
X /tmp/important_mount
All files below /tmp/important_mount will be deleted as the
/tmp/important_mount item will spuriously inherit a max age of 0
from /tmp.
/tmp has a max age of 0 but age_set is (of course) false.
This affects also the PrivateTmp feature of systemd.
All tmp files of such services will be deleted unconditionally
and can cause service failures and data loss.
Fix this by checking -age_set in the IGNORE_DIRECTORY_PATH logic.
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index f9830c4..7eafd6b 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1576,7 +1576,7 @@ static int read_config_file(const char *fn, bool
ignore_enoent) {
candidate_item = j;
}
-if (candidate_item) {
+if (candidate_item candidate_item-age_set) {
i-age = candidate_item-age;
i-age_set = true;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
