> "SI" == Stephen Ingram writes:
SI> I did turn it off just to see what happened, but it was not
SI> the problem. Nice though, because I learned how to relabel a volume
SI> to get back in the good graces of SELinux.
Well, just using setenforce doesn't disable selinux; it just disables
I recently upgraded a CentOS 7 Cyrus 2.4.17 system with Murder and Kerberos
and ran into lots of issues with the new packages. What's really puzzling
though is although I used to be able to use a SASL minimum layer of 256
(I'm using TLS with GSSAPI for auth), I now must use 1 for the front-ends
Jason-
That came up clean for my latest config, but it did highlight problems when
I didn't have the auth working. Thank you so much as this is a great search
command to help sleuth out those SELinux issues. I did turn it off just to
see what happened, but it was not the problem. Nice though,
If you suspect selinux, please do 'ausearch -m avc -ts today' and see what
you get. You may also wish to do 'setenforce 0' and try again, just to
make sure.
I can provide some basic help with selinux if that's needed.
- J<
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info:
Well, I finally figured out how to turn up the logging. Alas, the logging
inside cyrus tells me less than postfix. How can that be?
Jun 1 17:58:56 imap lmtp[20994]: connection from mx.x.x [10.0.13.69]
Jun 1 17:58:56 imap lmtp[20994]: SSL_accept() incomplete -> wait
Jun 1 17:58:56 imap
On 06/01/18 18:03 +0200, Jean-Christophe Delaye wrote:
I'm trying to complete setup Cyrus Murder : 1 frontend with mupdate and
1 backend (initial config).
# telnet imap1 imap
Trying 192.168.106.208...
Connected to imap1.eurecom.fr.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 LITERAL+
Patrick-
My thought too, but nothing but success entries for all of the cyrus
commands. Is there a way to increase logging on the frontend? I seem to be
getting details on the backends, but not the frontend. That might help
diagnose this. Ken asked for cyrus logs, but I don't really have
Anything in /var/log/audit/audit.log ?
On June 1, 2018 2:29:06 PM ADT, Stephen Ingram wrote:
>Patrick-
>
>I'm also trying to get more debugging about he system I/O error, but
>never
>see it in the cyrus logs, only in the postfix logs.
>
>Steve
>
>On Fri, Jun 1, 2018 at 9:37 AM, Patrick Boutilier
Patrick-
I'm also trying to get more debugging about he system I/O error, but never
see it in the cyrus logs, only in the postfix logs.
Steve
On Fri, Jun 1, 2018 at 9:37 AM, Patrick Boutilier
wrote:
> On 06/01/2018 01:31 PM, Stephen Ingram wrote:
>
>> Patrick-
>>
>> Actually, nothing. I've
Ken-
Here is the only entry in the cyrus logs I can see from that postfix server:
Jun 1 17:01:19 imap lmtp[12597]: starttls: TLSv1.2 with cipher
DHE-RSA-AES256-GCM-SHA384 (256/256 bits new) authenticated as x.x.x
Jun 1 17:01:19 imap lmtp[12597]: login: x.x.x [10.0.13.69] smtp/x.x.x
GSSAPI+TLS
Ken-
That could be. I noticed that the SELinux policy updated on the server as
well and Redhat might have changed something that is not allowing Cyrus to
write there?? It is able to write the Kerberos credential cache there
though. I thought it wrote everything else to /var/lib/imap.
I don't see
Ken-
That all appears to be working correctly. Here's a cut from the Postfix
debug with addresses obfuscated:
Jun 1 16:48:52 mx postfix/lmtp[18136]: send attr offset = 682
Jun 1 16:48:52 mx postfix/lmtp[18136]: send attr dsn_orig_rcpt =
rfc822;x...@x.com
Jun 1 16:48:52 mx postfix/lmtp[18136]:
OTH, my guess is that Cyrus is failing to create the tmpfile to stage
the message. Is /tmp (or its equivalent) full, or not writeable?
Without something from the Cyrus syslog, this will be hard to diagnose.
On 06/01/2018 12:51 PM, Stephen Ingram wrote:
Ken-
That all appears to be working
On 06/01/2018 01:31 PM, Stephen Ingram wrote:
Patrick-
Actually, nothing. I've got everything piped into /var/log/maillog and
not too much there either beyond the actual error message.
Hmmm... Usually when I have seen the System I/O error the log entry also
records what the actual
On 6/1/18 12:21 PM, Stephen Ingram wrote:
I'm receiving a 451 4.3.0 System I/O error (in reply to end of DATA
command) error from Postfix when trying to deliver to cyrus-imap and
not really sure why. I'm on CentOS 7 (2.4.17-8) after downgrading from
current version. I'm using Kerberos GSSAPI
Patrick-
Actually, nothing. I've got everything piped into /var/log/maillog and not
too much there either beyond the actual error message.
Steve
On Fri, Jun 1, 2018 at 9:23 AM, Patrick Boutilier
wrote:
> On 06/01/2018 01:21 PM, Stephen Ingram wrote:
>
>> I'm receiving a 451 4.3.0 System I/O
On 06/01/2018 01:21 PM, Stephen Ingram wrote:
I'm receiving a 451 4.3.0 System I/O error (in reply to end of DATA
command) error from Postfix when trying to deliver to cyrus-imap and not
really sure why. I'm on CentOS 7 (2.4.17-8) after downgrading from
current version. I'm using Kerberos
I'm receiving a 451 4.3.0 System I/O error (in reply to end of DATA
command) error from Postfix when trying to deliver to cyrus-imap and not
really sure why. I'm on CentOS 7 (2.4.17-8) after downgrading from current
version. I'm using Kerberos GSSAPI to connect to the front end, but
authentication
Dear all,
I'm trying to complete setup Cyrus Murder : 1 frontend with mupdate and
1 backend (initial config).
Machines are running Solaris 11.3 (for ZFS, HA clustering and zone
capabilities), SASL 2.1.27(rc8) and Cyrus 3.0.7.
Services seems running fine on both master/frontend (hostname
19 matches
Mail list logo
