Public bug reported:
Binary package hint: dovecot-common
The dovecot package include *a* sieve plugin (CMU sieve), but not
dovecot's own sieve plugin:
r...@severn:/usr/lib/dovecot/modules/lda# ls -l|grep -i sieve
-rw-r--r-- 1 root root 191910 2009-04-20 02:23 lib90_cmusieve_plugin.a
-rw-r--r--
Public bug reported:
Binary package hint: postfix
I reported a bug to the postfix mailing list regarding an incorrect
interaction between postfix and milters. Wietse created a patch which I
tested, and it works OK. I'd hoped this would be rolled into a new
postfix release, but this seems to be
Thanks. Is there any chance of including this in at least Karmic?
--
Postfix not sending SMFIC_RCPT to milter, libmilter rejecting state transition
https://bugs.launchpad.net/bugs/501364
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
Public bug reported:
I had a couple of systems with jaunty installed, running the openldap
server, configured to use cn=config for configuration. On both
systems, when I upgraded to karmic, something rewrote
/etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif (or perhaps it
was
** Attachment added: /etc/ldap from jaunty
http://launchpadlibrarian.net/39587719/ldap.tar.bz2
--
jaunty - karmic upgrade modifies cn=config DB definition, creates syntax
error, slapd won't start
https://bugs.launchpad.net/bugs/526230
You received this bug notification because you are a
Public bug reported:
Bug 526230 is back.
I had slapd 2.4.21-0ubuntu4 installed, then apt-get dist-upgrade,
which pulled in slapd 2.4.21-0ubuntu5. This modified
/etc/ldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif by adding
duplicate olcAccess lines without any {0} index prefix, causing
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/45859593/Dependencies.txt
--
slapd 2.4.21-0ubuntu5 corrupts olcDatabase={-1}frontend.ldif with duplicate
olcAccess lines (again)
https://bugs.launchpad.net/bugs/571057
You received this bug notification because you are a
Re: the mention of symptoms in comment #12 above: My symptom was that I
could not log in at all, and in existing sessions, sudo wouldn't work
etc. I store user information in LDAP, with just system users in
/etc/passwd etc., so luckily I could still log in as root to fix this.
--
slapd
When you say still log in as root to fix this, did you have to make
additional edits after you got slapd running again (as you mentioned in
your original problem description)? That is, were you locked out just
because slapd wasn't running, and then back to normal again once you got
slapd
Public bug reported:
When I reboot my machine running lucid, slapd often doesn't start at
all. Since my non-system users are all stored in the ldap database via
nss_ldap etc., this means that I can't log in.
Note: This problem is intermittent; it doesn't happen every time by any
means. After
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/48691748/Dependencies.txt
--
slapd sometimes doesn't start in lucid; can't log in if using nss_ldap
https://bugs.launchpad.net/bugs/582627
You received this bug notification because you are a member of Ubuntu
Server Team,
Well, I just rebooted 25 times in a row and couldn't reproduce this
issue any more, although it was happening perhaps 25-50% of the time a
while back (since then, I got hibernate working, so haven't rebooted so
often). I suppose that'll pay me for being lazy about filing the bug; I
should have
This also affects Lucid, and I would guess Precise. I can't quite tell
how to add extra releases in to the list above.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to spamassassin in Ubuntu.
https://bugs.launchpad.net/bugs/1397706
Yes, I'm running lightdm.
$ cat /etc/pam.d/common-session
session [default=1] pam_permit.so
session requisite pam_deny.so
session requiredpam_permit.so
session optionalpam_umask.so
session required
Could you please expand on "Then re-chown your current systemd cgroup"?
I'm not sure exactly how/where cgroups get mounted, so I'm not sure what
path I should chown.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
Switching the linode system to the Ubuntu kernel (booted via pv-grub)
didn't make that system fail. Perhaps the difference is cgroup setup via
ssh vs XFCE/GUI login?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
Public bug reported:
On Ubuntu Xenial pre-release, I see the following, so can't start a
container:
[swarren@sprint ~]$ lxc-create -t download -n t2 -- -d ubuntu -r trusty -a amd64
Using image from local cache
Unpacking the rootfs
---
You just created an Ubuntu container (release=trusty,
I have 2 Xenial systems. They are both fully up-to-date as of 5 minutes
ago. The failing system is a laptop running XFCE GUI, and I'm attempting
to use LXC from a GUI terminal. The other system is a linode that I
access via ssh, and LXC works fine there. I believe I've configured the
two systems
Thanks. The chown solves the issue. I didn't need to make the
modification to the pam config file at all. I do need to do the chown
every time I log in though, with or without the pam change.
FWIW, when I ssh into the working server, the relevant /sys directory is
owned by swarren:swarren without
After updating to the latest packages, this issue is solve. I can lxc-
start, lxc-attach, lxc-stop, and lxc-execute.
I do get some warning/error spew when running lxc-execute though. If
this looks unexpected, I can open a separate bug for it:
$ lxc-execute -n t1 -- /bin/bash
lxc-execute:
20 matches
Mail list logo
