because one of the servers
is connected to my LAN via a VPN link (so it's encrypted). But I still
want to know what I'm supposed to do in order for a TLS layer to happen.
Rich Wales
ri...@richw.org
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu
, by the way,
so that isn't an option here.
Rich Wales
ri...@richw.org
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
-- but this is probably a
wish list item and not a critical bug fix issue.
Rich Wales
ri...@richw.org
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
simply saying failure:
prot layer failure.
This worked fine before I upgraded to Cyrus 2.3.14. Is something
known to be broken in 2.3.14? Has anyone else out there ever seen
anything like this? What should I try next? I'm stuck here and
would be very grateful for any help.
--
Rich Wales
, not in the Cyrus code.
But I'm still suspicious of a situation where sieve-connect may have
done something which caused a timsieved process to crash mysteriously
-- something which no client should be able to do to a server process.
But whatever . . . .
--
Rich Wales / ri...@richw.org / ri
) produce more debugging output which might help
pinpoint the problem?
--
Rich Wales / ri...@richw.org / ri...@stanford.edu
Wikipedia: http://en.wikipedia.org/wiki/User:Richwales
Facebook: http://www.new.facebook.com/profile.php?id=206680
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus
, whether I try it
on the server or some other host.
--
Rich Wales / ri...@richw.org / ri...@stanford.edu
Wikipedia: http://en.wikipedia.org/wiki/User:Richwales
Facebook: http://www.new.facebook.com/profile.php?id=206680
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http
LAN to a separate Cyrus server,
instead of delivering it over a Unix-domain socket to Cyrus running on
the same box.
Any suggestions?
--
Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED]
http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales
Cyrus
to /etc/services on the machines
involved to define LMTP (as TCP port 24).
--
Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED]
http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http
Ubuntu box).
--
Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED]
http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales
The difference between theory and practice is that, in theory,
theory and practice are identical -- whereas in practice, they aren't
of
these authentication methods either.
I'm mildly concerned that a future software upgrade might cause these
libraries to reappear. Is there a more reliable way to disable SASL
authentication mechanisms, other than removing files from the library
directory?
--
Rich Wales === Palo Alto, CA, USA
fine. Remember, what I'm trying to do here is to set up
replication going both ways between a pair of servers.
This is 2.3.9, BTW.
Any ideas welcome.
--
Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED]
http://www.richw.org === http://en.wikipedia.org/wiki
with the sync_server on your replica.
OK, that's the answer I needed to hear. If a mailbox list on the
command line is not compatible with rolling replication, then I'll
simply not have a choice but to set up two Cyrus instances if I
want to spread my users across different IMAP servers.
--
Rich
to be delivered on the Cyrus server where he/she will
be reading his/her mail. But I can do that.
--
Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED]
http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales
The difference between theory and practice
though there IS an account named admin
in the sasldb2.db on that machine.
Any ideas what I might be doing wrong here?
--
Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED]
http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales
The difference between theory
or thousands of users; I understand this.
If this idea of doing two-way partial replication with a single Cyrus
instance on each server will in fact work, should I use the same value
for sync_machineid on both servers? Or should they be different?
--
Rich Wales === Palo Alto, CA, USA
this kind of situation
is handled?
--
Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED]
http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales
The difference between theory and practice is that, in theory,
theory and practice are identical -- whereas
this just now, and the change is NOT propagating from the replica
to the master.
What do I need to do in order for changes made on the replica to get
copied over to the master? Or is this simply impossible?
--
Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED]
http
in do_sync(): bailing out! notices in the
/var/log/messages file. Are there some other log files saved somewhere
else? I do have -l and -v specified for the sync_client command.
Should I add any additional options in order to get debugging info?
--
Rich Wales === Palo Alto, CA, USA
Wesley Craig wrote:
The replica sync_server will also log to syslog.
No, sorry, as best I can tell, there isn't anything non-routine in any
of the log files on my replica server.
Do I need to specify any command-line flags to sync_server?
--
Rich Wales === Palo Alto, CA, USA
?
--
Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED]
http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales
The difference between theory and practice is that, in theory,
theory and practice are identical -- whereas in practice, they aren't
.
--
Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED]
http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales
The difference between theory and practice is that, in theory,
theory and practice are identical -- whereas in practice, they aren't.
Cyrus
to upgrade to 2.3.10 in hopes of getting
rid of some problems with the sync code intermittently crashing, but
this is a production system, and I don't feel comfortable upgrading
to 2.3.10 as long as there are unresolved serious bug reports.
--
Rich Wales === Palo Alto, CA, USA
syslog.conf and kicked syslogd, and now I'm seeing those entries in
/var/log/messages.
I'll let the list know if I experience any more sync_client crashes.
Should I be looking for similar syslog messages on my replica server
too (and checking syslog.conf on that system if necessary)?
--
Rich Wales
of error indication
at the times when sync_client bailed out.
Is it possible that something I should be seeing is being filtered out
by syslog.conf? What syslog facility name is used by sync_server?
--
Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED]
http://www.richw.org
, and/or what I can do
to make sure a sync_client stays running on my master server?
--
Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED]
http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales
The difference between theory and practice is that, in theory
else) suggest anything I can do in the meantime
(while I'm still running 2.3.9) to ensure that a sync_client stays
running on my master server, or to start a new one as needed if it
dies?
--
Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED]
http://www.richw.org
, the replica server
will be running, and the Cyrus application will be running, but the
spool directory will be missing.
Is there anything in particular (configuration options, messy kludges,
etc.) that I need to do in a setup like this in order for replication
to work?
--
Rich Wales === Palo
28 matches
Mail list logo