[Bug 997217] Re: salsauthd maxes cpu
** Changed in: cyrus-sasl2 (Ubuntu Xenial) Importance: Undecided => High ** Changed in: cyrus-sasl2 (Ubuntu Xenial) Assignee: (unassigned) => Andreas Hasenack (ahasenack) ** Changed in: cyrus-sasl2 (Ubuntu Trusty) Importance: Undecided => High ** Changed in: cyrus-sasl2 (Ubuntu Trusty) Assignee: (unassigned) => Andreas Hasenack (ahasenack) -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/997217 Title: salsauthd maxes cpu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/997217/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 997217] Re: salsauthd maxes cpu
I reproduced the problem in xenial by timing a "testsaslauthd" call with a "service dovecot stop" one (dovecot being my test imap server on localhost). This is good enough for an SRU test case, thanks all. -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/997217 Title: salsauthd maxes cpu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/997217/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 997217] Re: salsauthd maxes cpu
The patch 0034 mentioned in comment #10 is applied in the xenial package
2.1.26.dfsg1-14build1, so what Roberto hit could be a different issue
requiring a different fix.
Might have been this:
cyrus-sasl2 (2.1.26.dfsg1-15) unstable; urgency=medium
* Add fix for auth_rimap infinite loop (hang) when IMAP server closes
connection (Closes: #815208)
Patch is
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=815208;filename=auth_rimap_socket_closed.patch;msg=5:
--- a/saslauthd/auth_rimap.c
+++ b/saslauthd/auth_rimap.c
@@ -494,7 +494,7 @@
while( select (fds, , NULL, NULL, ) >0 ) {
if ( FD_ISSET(s, ) ) {
ret = read(s, rbuf+rc, sizeof(rbuf)-rc);
- if ( ret<0 ) {
+ if ( ret<=0 ) {
rc = ret;
break;
} else {
@@ -607,7 +607,7 @@
while( select (fds, , NULL, NULL, ) >0 ) {
if ( FD_ISSET(s, ) ) {
ret = read(s, rbuf+rc, sizeof(rbuf)-rc);
- if ( ret<0 ) {
+ if ( ret<=0 ) {
rc = ret;
break;
} else {
** Also affects: cyrus-sasl2 (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: cyrus-sasl2 (Ubuntu Precise)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to cyrus-sasl2 in Ubuntu.
https://bugs.launchpad.net/bugs/997217
Title:
salsauthd maxes cpu
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/997217/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 997217] Re: salsauthd maxes cpu
Trusty has 0034-fix_dovecot_authentication.patch, but it lacks the above fix as well. ** Also affects: cyrus-sasl2 (Ubuntu Trusty) Importance: Undecided Status: New ** Tags removed: precise ** Tags added: server-next ** Changed in: cyrus-sasl2 (Ubuntu Trusty) Status: New => Triaged ** Changed in: cyrus-sasl2 (Ubuntu Xenial) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/997217 Title: salsauthd maxes cpu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/997217/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1783183] Re: apparmor profile denied for kerberos client keytab and credential cache files
** Description changed:
[Impact]
When using syncrepl replication with openldap, the consumer needs to
authenticate to the provider in order to perform the searches and fetch the
data. When this authentication is a simple bind, a simple username/password
pair is used and that can be easily supplied in a configuration file.
When one wants to use a stronger authentication mechanism, like gssapi
(kerberos), the authentication is based on keytab files and tickets. The
consumer needs to obtain a ticket from the KDC, and use that ticket to
authenticate itself with the provider.
For users, it's a simple matter of running kinit(1) and providing a
password. For services, the solution is to extract the key from the KDC
and store it in a local keytab file, which is then used by the service
to obtain the TGT.
Problem is this TGT expires, and needs to be renewed periodically.
Solutions have popped up for that issue, the most famous one being
kstart (https://www.eyrie.org/~eagle/software/kstart/), but since the
MIT kerberos 1.11 release, there is a simpler way.
Via the default_client_keytab_name krb5.conf(5) option, one can specify
the default location of a keytab file per local user. The kerberos
library will then automatically use that file to obtain the TGT, and
proceed as usual from there.
The default value of that setting is /etc/krb5/user//client.keytab.
Turns out the openldap slapd apparmor profile doesn't account for that,
and blocks attempts to read that file. It also blocks reading the TGT
that is obtained and stored in /tmp/krb5cc_, resulting in such
DENIED errors in the logs:
apparmor="DENIED" operation="open" profile="/usr/sbin/slapd"
name="/etc/krb5/user/389/client.keytab" pid=19080 comm="slapd"
requested_mask="r" denied_mask="r" fsuid=389 ouid=389
apparmor="DENIED" operation="file_lock" profile="/usr/sbin/slapd"
name="/tmp/krb5cc_389" pid=19080 comm="slapd" requested_mask="k"
denied_mask="k" fsuid=389 ouid=389
Since the slapd apparmor is enabled by default, this blocks the usage of
this very helpful feature. Also considering that kerberos/gssapi errors
are usually hard to debug, it might take a while for an admin to figure
out what is going on.
The fix is to update the apparmor profile and allow access to those
files. Unfortunately there are no rich globbing rules for paths in an
apparmor profile, nothing like @{uid} of the current process yet, or a
regexp rule like [0-9]+, so the rules have to be a bit accomodating. For
this bug, I came up with these two new lines:
/etc/krb5/user/*/client.keytab kr,
owner /tmp/krb5cc_* rwk,
One could relax the first one perhaps into something like /etc/krb5/**,
but the above works with the default settings.
[Test Case]
Setting up openldap replication via gssapi can be complicated, so I wrote
some scripts to help.
- setup-kdc.sh: sets up the KDC server
- setup-provider.sh: sets up the openldap provider
- setup-consumer.sh: sets up the openldap consumer
The scripts expect LXD containers to be used, that have a working DNS
setup for a ".lxd" domain. In other words, if you do:
lxc launch ubuntu-daily:bionic bionic-provider
The script expects the container to be reachable via "bionic-
provider.lxd". That is the default behavior of LXD, and changing the
scripts to work in a more generic case was deemed not worth it.
So here we go. Here are the steps for a cosmic test, just replace
"cosmic" with the name of the ubuntu release you are testing.
= KDC =
* launch the KDC container and copy the setup-kdc.sh script into it:
lxc launch ubuntu-daily:cosmic cosmic-kdc
lxc file push ./setup-kdc.sh cosmic-kdc/root/
* Enter the container and run the setup-kdc.sh script:
lxc exec cosmic-kdc bash
bash ./setup-kdc.sh
* The script will show two prompts: one from debconf, with just an "ok"
option, so hit ENTER there. The second prompt will be for a password.
Use any one you like, it won't be needed again.
* The KDC is setup, you can exit the container.
= PROVIDER =
* launch the provider and copy the setup-provider.sh script into it:
lxc launch ubuntu-daily:cosmic cosmic-provider
lxc file push ./setup-provider.sh cosmic-provider/root/
* Enter the container and run the setup-provider.sh script:
lxc exec cosmic-provider bash
bash ./setup-provider.sh
* Leave a tail on the slapd logs, we will come back to this later:
tail -f /var/log/syslog|grep slapd
-
= CONSUMER =
* launch the consumer and copy the setup-consumer.sh script into it:
lxc launch ubuntu-daily:cosmic cosmic-consumer
lxc file push ./setup-consumer.sh cosmic-consumer/root/
* Enter the container and run the setup-consumer.sh script:
lxc exec cosmic-consumer bash
bash ./setup-consumer.sh
* On the provider's log tail, you should soon see a connection and immediate
disconnection like
[Bug 1783183] Re: apparmor profile denied for kerberos client keytab and credential cache files
** Attachment added: "setup-consumer.sh" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1783183/+attachment/5204631/+files/setup-consumer.sh -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1783183 Title: apparmor profile denied for kerberos client keytab and credential cache files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1783183/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1783183] Re: apparmor profile denied for kerberos client keytab and credential cache files
** Attachment added: "setup-provider.sh" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1783183/+attachment/5204630/+files/setup-provider.sh -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1783183 Title: apparmor profile denied for kerberos client keytab and credential cache files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1783183/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1783183] Re: apparmor profile denied for kerberos client keytab and credential cache files
** Description changed:
[Impact]
When using syncrepl replication with openldap, the consumer needs to
authenticate to the provider in order to perform the searches and fetch the
data. When this authentication is a simple bind, a simple username/password
pair is used and that can be easily supplied in a configuration file.
When one wants to use a stronger authentication mechanism, like gssapi
(kerberos), the authentication is based on keytab files and tickets. The
consumer needs to obtain a ticket from the KDC, and use that ticket to
authenticate itself with the provider.
For users, it's a simple matter of running kinit(1) and providing a
password. For services, the solution is to extract the key from the KDC
and store it in a local keytab file, which is then used by the service
to obtain the TGT.
Problem is this TGT expires, and needs to be renewed periodically.
Solutions have popped up for that issue, the most famous one being
kstart (https://www.eyrie.org/~eagle/software/kstart/), but since the
MIT kerberos 1.11 release, there is a simpler way.
Via the default_client_keytab_name krb5.conf(5) option, one can specify
the default location of a keytab file per local user. The kerberos
library will then automatically use that file to obtain the TGT, and
proceed as usual from there.
The default value of that setting is /etc/krb5/user//client.keytab.
Turns out the openldap slapd apparmor profile doesn't account for that,
and blocks attempts to read that file. It also blocks reading the TGT
that is obtained and stored in /tmp/krb5cc_, resulting in such
DENIED errors in the logs:
apparmor="DENIED" operation="open" profile="/usr/sbin/slapd"
name="/etc/krb5/user/389/client.keytab" pid=19080 comm="slapd"
requested_mask="r" denied_mask="r" fsuid=389 ouid=389
apparmor="DENIED" operation="file_lock" profile="/usr/sbin/slapd"
name="/tmp/krb5cc_389" pid=19080 comm="slapd" requested_mask="k"
denied_mask="k" fsuid=389 ouid=389
Since the slapd apparmor is enabled by default, this blocks the usage of
this very helpful feature. Also considering that kerberos/gssapi errors
are usually hard to debug, it might take a while for an admin to figure
out what is going on.
The fix is to update the apparmor profile and allow access to those
files. Unfortunately there are no rich globbing rules for paths in an
apparmor profile, nothing like @{uid} of the current process yet, or a
regexp rule like [0-9]+, so the rules have to be a bit accomodating. For
this bug, I came up with these two new lines:
- /etc/krb5/user/*/client.keytab kr,
- owner /tmp/krb5cc_* rwk,
+ /etc/krb5/user/*/client.keytab kr,
+ owner /tmp/krb5cc_* rwk,
One could relax the first one perhaps into something like /etc/krb5/**,
but the above works with the default settings.
+ [Test Case]
+ Setting up openldap replication via gssapi can be complicated, so I wrote
some scripts to help.
+ - setup-kdc.sh: sets up the KDC server
+ - setup-provider.sh: sets up the openldap provider
+ - setup-consumer.sh: sets up the openldap consumer
- [Test Case]
+ The scripts expect LXD containers to be used, that have a working DNS
+ setup for a ".lxd" domain. In other words, if you do:
- * detailed instructions how to reproduce the bug
+ lxc launch ubuntu-daily:bionic bionic-provider
- * these should allow someone who is not familiar with the affected
- package to reproduce the bug and verify that the updated package fixes
- the problem.
+ The script expects the container to be reachable via "bionic-
+ provider.lxd". That is the default behavior of LXD, and changing the
+ scripts to work in a more generic case was deemed not worth it.
+
+ So here we go. Here are the steps for a cosmic test, just replace
+ "cosmic" with the name of the ubuntu release you are testing.
+
+ = KDC =
+
+ * launch the KDC container and copy the setup-kdc.sh script into it:
+ lxc launch ubuntu-daily:cosmic cosmic-kdc
+ lxc file push ./setup-kdc.sh cosmic-kdc/root/
+
+ * Enter the container and run the setup-kdc.sh script:
+ lxc exec cosmic-kdc bash
+ bash ./setup-kdc.sh
+
+ * The script will show two prompts: one from debconf, with just an "ok"
+ option, so hit ENTER there. The second prompt will be for a password.
+ Use any one you like, it won't be needed again.
+
+ * The KDC is setup, you can exit the container.
+
+ = PROVIDER =
+ * launch the provider and copy the setup-provider.sh script into it:
+ lxc launch ubuntu-daily:cosmic cosmic-provider
+ lxc file push ./setup-provider.sh cosmic-provider/root/
+
+ * Enter the container and run the setup-provider.sh script:
+ lxc exec cosmic-provider bash
+ bash ./setup-provider.sh
+
+ * Leave a tail on the slapd logs, we will come back to this later:
+ tail -f /var/log/syslog|grep slapd
+
+
+ = CONSUMER =
+ * launch the consumer and copy the setup-consumer.sh script into it:
+ lxc launch ubuntu-daily:cosmic
[Bug 1783183] Re: apparmor profile denied for kerberos client keytab and credential cache files
** Description changed:
[Impact]
+ When using syncrepl replication with openldap, the consumer needs to
authenticate to the provider in order to perform the searches and fetch the
data. When this authentication is a simple bind, a simple username/password
pair is used and that can be easily supplied in a configuration file.
- * An explanation of the effects of the bug on users and
+ When one wants to use a stronger authentication mechanism, like gssapi
+ (kerberos), the authentication is based on keytab files and tickets. The
+ consumer needs to obtain a ticket from the KDC, and use that ticket to
+ authenticate itself with the provider.
- * justification for backporting the fix to the stable release.
+ For users, it's a simple matter of running kinit(1) and providing a
+ password. For services, the solution is to extract the key from the KDC
+ and store it in a local keytab file, which is then used by the service
+ to obtain the TGT.
- * In addition, it is helpful, but not required, to include an
-explanation of how the upload fixes this bug.
+ Problem is this TGT expires, and needs to be renewed periodically.
+ Solutions have popped up for that issue, the most famous one being
+ kstart (https://www.eyrie.org/~eagle/software/kstart/), but since the
+ MIT kerberos 1.11 release, there is a simpler way.
+
+ Via the default_client_keytab_name krb5.conf(5) option, one can specify
+ the default location of a keytab file per local user. The kerberos
+ library will then automatically use that file to obtain the TGT, and
+ proceed as usual from there.
+
+ The default value of that setting is /etc/krb5/user//client.keytab.
+
+ Turns out the openldap slapd apparmor profile doesn't account for that,
+ and blocks attempts to read that file. It also blocks reading the TGT
+ that is obtained and stored in /tmp/krb5cc_, resulting in such
+ DENIED errors in the logs:
+
+ apparmor="DENIED" operation="open" profile="/usr/sbin/slapd"
+ name="/etc/krb5/user/389/client.keytab" pid=19080 comm="slapd"
+ requested_mask="r" denied_mask="r" fsuid=389 ouid=389
+
+ apparmor="DENIED" operation="file_lock" profile="/usr/sbin/slapd"
+ name="/tmp/krb5cc_389" pid=19080 comm="slapd" requested_mask="k"
+ denied_mask="k" fsuid=389 ouid=389
+
+ Since the slapd apparmor is enabled by default, this blocks the usage of
+ this very helpful feature. Also considering that kerberos/gssapi errors
+ are usually hard to debug, it might take a while for an admin to figure
+ out what is going on.
+
+ The fix is to update the apparmor profile and allow access to those
+ files. Unfortunately there are no rich globbing rules for paths in an
+ apparmor profile, nothing like @{uid} of the current process yet, or a
+ regexp rule like [0-9]+, so the rules have to be a bit accomodating. For
+ this bug, I came up with these two new lines:
+
+ /etc/krb5/user/*/client.keytab kr,
+ owner /tmp/krb5cc_* rwk,
+
+ One could relax the first one perhaps into something like /etc/krb5/**,
+ but the above works with the default settings.
+
[Test Case]
- * detailed instructions how to reproduce the bug
+ * detailed instructions how to reproduce the bug
- * these should allow someone who is not familiar with the affected
-package to reproduce the bug and verify that the updated package fixes
-the problem.
+ * these should allow someone who is not familiar with the affected
+ package to reproduce the bug and verify that the updated package fixes
+ the problem.
[Regression Potential]
- * discussion of how regressions are most likely to manifest as a result
+ * discussion of how regressions are most likely to manifest as a result
of this change.
- * It is assumed that any SRU candidate patch is well-tested before
-upload and has a low overall risk of regression, but it's important
-to make the effort to think about what ''could'' happen in the
-event of a regression.
+ * It is assumed that any SRU candidate patch is well-tested before
+ upload and has a low overall risk of regression, but it's important
+ to make the effort to think about what ''could'' happen in the
+ event of a regression.
- * This both shows the SRU team that the risks have been considered,
-and provides guidance to testers in regression-testing the SRU.
+ * This both shows the SRU team that the risks have been considered,
+ and provides guidance to testers in regression-testing the SRU.
[Other Info]
-
- * Anything else you think is useful to include
- * Anticipate questions from users, SRU, +1 maintenance, security teams and
the Technical Board
- * and address these questions in advance
+ * Anything else you think is useful to include
+ * Anticipate questions from users, SRU, +1 maintenance, security teams and
the Technical Board
+ * and address these questions in advance
[Original Description]
Can we get /etc/krb5/** and /tmp/krb5cc_* added with the appropriate
[Bug 1783183] Re: apparmor profile denied for kerberos client keytab and credential cache files
** Description changed: + [Impact] + + * An explanation of the effects of the bug on users and + + * justification for backporting the fix to the stable release. + + * In addition, it is helpful, but not required, to include an +explanation of how the upload fixes this bug. + + [Test Case] + + * detailed instructions how to reproduce the bug + + * these should allow someone who is not familiar with the affected +package to reproduce the bug and verify that the updated package fixes +the problem. + + [Regression Potential] + + * discussion of how regressions are most likely to manifest as a result + of this change. + + * It is assumed that any SRU candidate patch is well-tested before +upload and has a low overall risk of regression, but it's important +to make the effort to think about what ''could'' happen in the +event of a regression. + + * This both shows the SRU team that the risks have been considered, +and provides guidance to testers in regression-testing the SRU. + + [Other Info] + + * Anything else you think is useful to include + * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board + * and address these questions in advance + + + [Original Description] + Can we get /etc/krb5/** and /tmp/krb5cc_* added with the appropriate permissions to the slapd apparmor profile? I'm getting the following kinds of errors: apparmor="DENIED" operation="open" profile="/usr/sbin/slapd" name="/etc/krb5/user/389/client.keytab" pid=19080 comm="slapd" requested_mask="r" denied_mask="r" fsuid=389 ouid=389 apparmor="DENIED" operation="file_lock" profile="/usr/sbin/slapd" name="/tmp/krb5cc_389" pid=19080 comm="slapd" requested_mask="k" denied_mask="k" fsuid=389 ouid=389 -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1783183 Title: apparmor profile denied for kerberos client keytab and credential cache files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1783183/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1799185] Re: spamd running with virtual-config-dir mkdir error
Confirmed. Steps to reproduce it, for others who, like me, are not familiar with spamassassin: Start the daemon as root, with the given options plus debug: spamd -d --pidfile=/var/run/spamd.pid -c -x --virtual-config-dir=/var/lib/spamassassin/vconfig/%u/ --allow-tell -u debian-spamd -g debian-spamd --max-children=5 --min-children=3 --max-spare=3 -D Get some spam message from your spam folder. The raw message (in gmail, select "show original"). Copy it into a file, say spam.txt. Run "tail -f /var/log/mail.log" in one terminal Run spamc on that file as a regular user in another terminal: spamc < spam.txt Watch the log file and look for the error: Oct 23 14:41:45 cosmic-spamassassin spamd[10067]: config: using "/var/lib/spamassassin/vconfig/ubuntu/" for user state dir Oct 23 14:41:45 cosmic-spamassassin spamd[10067]: config: mkdir /var/lib/spamassassin/vconfig/ubuntu/ failed: Insecure dependency in mkdir while running with -T switch at /usr/share/perl/5.26/File/Path.pm line 1 77, line 2. Also note that /var/lib/spamassassin/vconfig/ubuntu isn't created. Edit /usr/sbin/spamd and remove "-T" from the shebang. Repeat the above steps. No error, and the directory will be created this time. -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to spamassassin in Ubuntu. https://bugs.launchpad.net/bugs/1799185 Title: spamd running with virtual-config-dir mkdir error To manage notifications about this bug go to: https://bugs.launchpad.net/spamassassin/+bug/1799185/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1799185] Re: spamd running with virtual-config-dir mkdir error
This is confirmed for cosmic, btw, and the upcoming DD one too. ** Changed in: spamassassin (Ubuntu) Status: New => Triaged ** Changed in: spamassassin (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to spamassassin in Ubuntu. https://bugs.launchpad.net/bugs/1799185 Title: spamd running with virtual-config-dir mkdir error To manage notifications about this bug go to: https://bugs.launchpad.net/spamassassin/+bug/1799185/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1799185] Re: spamd running with virtual-config-dir mkdir error
** Bug watch added: bz.apache.org/SpamAssassin/ #7646 https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7646 ** Also affects: spamassassin via https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7646 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to spamassassin in Ubuntu. https://bugs.launchpad.net/bugs/1799185 Title: spamd running with virtual-config-dir mkdir error To manage notifications about this bug go to: https://bugs.launchpad.net/spamassassin/+bug/1799185/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1796863] Re: Upgrade to version 3.4.2 for Bionic
** Changed in: spamassassin (Ubuntu) Status: New => Triaged ** Changed in: spamassassin (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to spamassassin in Ubuntu. https://bugs.launchpad.net/bugs/1796863 Title: Upgrade to version 3.4.2 for Bionic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/spamassassin/+bug/1796863/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1769440] Re: freeipa server install fails - named-pkcs11 fails to run
It's this one: bind9 (1:9.11.3+dfsg-1ubuntu1.3) bionic; urgency=medium [ Karl Stenerud ] * d/p/skip-rtld-deepbind-for-dyndb.diff: fix named-pkcs11 crashing on startup. Thanks to Petr Menšík (LP: #1769440) -- Andreas Hasenack Wed, 10 Oct 2018 14:33:34 -0300 It's still in the unapproved queue: https://launchpad.net/ubuntu/bionic/+queue?queue_state=1_text=bind9 -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1769440 Title: freeipa server install fails - named-pkcs11 fails to run To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1769440/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
