Re: Is it safe to wipe: /var/lib/cyrus/lock/

2020-05-11 Thread Michael Menge

Hi,

Quoting Jan Vales :


Hello,

I just stumbled into this directory: /var/lib/cyrus/lock/

It seems to contain many dead things, like .lock-files that - based on
their names - must be older than 2+ years, including .../user/$NAME
where $NAME does not have a mailbox/account anymore.

Is it safe to shut down cyrus and do a
find /var/lib/cyrus/lock/ -mindepth 2 -delete

Its currently cyrus 3.0.13 on debian 10.



/var/lib/cyrus/lock/ and /var/lib/cyrus/proc should be empty after  
shutting down cyrus


You can also use tempfs for these directories,
- it is faster
- reboot will clean up the left over files in case the
  shut down was not clean
- these directories only contain small files





M.MengeTel.: (49) 7071/29-70316
Universität Tübingen   Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung  mail:  
michael.me...@zdv.uni-tuebingen.de

Wächterstraße 76
72074 Tübingen


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Is it safe to wipe: /var/lib/cyrus/lock/

2020-05-11 Thread Jan Vales
Hello,

I just stumbled into this directory: /var/lib/cyrus/lock/

It seems to contain many dead things, like .lock-files that - based on
their names - must be older than 2+ years, including .../user/$NAME
where $NAME does not have a mailbox/account anymore.

Is it safe to shut down cyrus and do a
find /var/lib/cyrus/lock/ -mindepth 2 -delete

Its currently cyrus 3.0.13 on debian 10.

br,
Jan

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


Re: Cyrus IMAP 3.2.0 released

2020-05-11 Thread Marco

Hello Michael,

On 11/05/2020 10:45, Michael Menge has written:

RedHat systems use SELinux by default and SELinux has the habit to
block access to files, sockets, ... Especial if software from
non-Redhat repos is used.


thank you for the hint, I think that this is not my issue.

I disabled SELINUX prior to run Cassandane.

# sestatus
SELinux status: disabled
# getenforce
Disabled

Cheers
Marco





Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


Re: Cyrus IMAP 3.2.0 released

2020-05-11 Thread Michael Menge


Quoting ellie timoney :


Hi Marco,


But it really seems that the LD_PRELOAD or the syslog.so doesn't
work for me.


Thanks for including that detail.  Hopefully someone familiar with  
RedHat can chime in with some insight into the LD_PRELOAD issue!  At  
a guess, "preventing library injection from intercepting syslog  
calls" might be a security default of some sort.




RedHat systems use SELinux by default and SELinux has the habit to
block access to files, sockets, ... Especial if software from
non-Redhat repos is used.

SELinux logs to /var/log/audit/audit.log, but these logs are not easy
to understand, therefor I often use audit2allow to see which SELinux
permissions are missing.

# cat /var/log/audit/audit.log | audit2allow

You can change SELinux temporary to permissive mode so that the log will
indicate all missing permissions and not only the first few.

# setenforce 0


Michael Menge


M.MengeTel.: (49) 7071/29-70316
Universität Tübingen   Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung  mail:  
michael.me...@zdv.uni-tuebingen.de

Wächterstraße 76
72074 Tübingen


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Cyrus IMAP 3.2.0 released

2020-05-11 Thread Marco

Hi Ellie,

 thank you for these feedback.

On 11/05/2020 03:03, ellie timoney has written:


  # This fail on 3.2.0
  # https://github.com/cyrusimap/cyrus-imapd/issues/2332
  Caldav.supports_event


This one should be passing on 3.2.0, the issue above has been closed


Ouch. It still fails with the attached reason.

I didn't tried no more the other failing tests at the moment.

I also realized that the tests which need syslog will fail if they are 
managed by imjournal. They need to be sent directly to syslog socket (I 
had to change the rsyslog conf).


Cheers
Marco


  # https://github.com/cyrusimap/cyrus-imapd/issues/2087
  ImapTest.append-binary
  ImapTest.fetch-binary-mime
  ImapTest.urlauth-binary

  # This one seems to fail randomly on fedora, but in my env always
seems to be successful.
  ImapTest.urlauth2


3.2.0 passes all the imaptest-20190504 tests for me, and I don't skip any.  But 
I don't see urlauth2 or any of the -binary ones in the output, so maybe 
upstream imaptest has removed the bad tests.  (The issue quoted was reported 
for imaptest-20170719)

The rest of these look like about what I'd expect, no surprises. Whew!

Cheers,

ellie

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus



1) Caldav.supports_event
 Boolean assertion failed at 
/usr/share/perl5/vendor_perl/Test/Unit/Exception.pm line 13.

Test::Unit::Exception::throw_new(Test::Unit::Failure=HASH(0x559ed1b95e40), 
"-package", "Cassandane::Cyrus::Caldav", "-file", "Cassandane/Cyrus/Caldav.pm", 
"-line", 3755, "-object", ...) called at 
/usr/share/perl5/vendor_perl/Test/Unit/Assert.pm line 85

Test::Unit::Assert::do_assertion(Cassandane::Cyrus::Caldav=HASH(0x559ed19240f8),
 Test::Unit::Assertion::Boolean=REF(0x559ed1b98730), 
"Cassandane::Cyrus::Caldav", "Cassandane/Cyrus/Caldav.pm", 3755) called at 
/usr/share/perl5/vendor_perl/Test/Unit/Assert.pm line 19

Test::Unit::Assert::assert(Cassandane::Cyrus::Caldav=HASH(0x559ed19240f8), 
JSON::PP::Boolean=SCALAR(0x559ecf538dc0)) called at Cassandane/Cyrus/Caldav.pm 
line 3755

Cassandane::Cyrus::Caldav::test_supports_event(Cassandane::Cyrus::Caldav=HASH(0x559ed19240f8))
 called at /usr/share/perl5/vendor_perl/Test/Unit/TestCase.pm line 75
[...framework calls elided...]

Annotations:
=> Cyrus::TestCase::set_up[115] -- BEGIN test_supports_event 
--
=> Instance::start[659] start main instance for test test_supports_event: 
basedir /root/rpmbuild/BUILD/cyrus-imapd-3.2.0/cassandane/work/0648210101
2020/05/11-08:48:21 Cassandane::Net::SMTPServer (type 
Net::Server::PreForkSimple) starting! pid(31403)
Resolved [localhost]:19100 to [::1]:19100, IPv6
Resolved [localhost]:19100 to [127.0.0.1]:19100, IPv4
Binding to TCP port 19100 on host ::1 with IPv6
Binding to TCP port 19100 on host 127.0.0.1 with IPv4
Group Not Defined.  Defaulting to EGID '12 0'
User Not Defined.  Defaulting to EUID '76'
=> Instance::_start_smtpd[1119] started smtpd as 31403
=> Instance::_find_binary[525] Found binary ctl_cyrusdb in 
/root/rpmbuild/BUILDROOT/cyrus-imapd-3.2.0-1.el8.x86_64/usr/sbin
=> Instance::_find_binary[525] Found binary imapd in 
/root/rpmbuild/BUILDROOT/cyrus-imapd-3.2.0-1.el8.x86_64/usr/libexec/cyrus-imapd
=> Instance::_find_binary[525] Found binary httpd in 
/root/rpmbuild/BUILDROOT/cyrus-imapd-3.2.0-1.el8.x86_64/usr/libexec/cyrus-imapd
=> Instance::_start_notifyd[1151] started notifyd for 
/root/rpmbuild/BUILD/cyrus-imapd-3.2.0/cassandane/work/0648210101 as 31412
=> Instance::_start_master[1153] _start_master: logging to 
/root/rpmbuild/BUILD/cyrus-imapd-3.2.0/cassandane/work/0648210101/conf/master.log
=> Instance::_find_binary[525] Found binary master in 
/root/rpmbuild/BUILDROOT/cyrus-imapd-3.2.0-1.el8.x86_64/usr/libexec/cyrus-imapd
=> Instance::_fork_command[1562] Running: 
"/root/rpmbuild/BUILDROOT/cyrus-imapd-3.2.0-1.el8.x86_64/usr/libexec/cyrus-imapd/master"
 "-C" 
"/root/rpmbuild/BUILD/cyrus-imapd-3.2.0/cassandane/work/0648210101/conf/imapd.conf"
 "-l" "255" "-p" 
"/root/rpmbuild/BUILD/cyrus-imapd-3.2.0/cassandane/work/0648210101/run/master.pid"
 "-d" "-M" 
"/root/rpmbuild/BUILD/cyrus-imapd-3.2.0/cassandane/work/0648210101/conf/cyrus.conf"
 "-L" 
"/root/rpmbuild/BUILD/cyrus-imapd-3.2.0/cassandane/work/0648210101/conf/master.log"
=> Instance::_fork_command[1562] child pid=31415
=> Instance::_fork_command[1562] setting core size limit to 104857600
=> Instance::_start_master[1153] _start_master: waiting for PID file
=> Instance::_start_master[1153] _start_master: PID file present and correct
=> Instance::_start_master[1153] _start_master: PID waiting for services
=> GenericDaemon::_is_listening_af[375] is_listening: service imap is 
listening on 127.0.0.1:19101
=> Util::Wait::timed_wait[909] Waited