Bad date/time on Cyrus

[filieski]

I am not able to get this plugin to work with Cyrus.
First, I had an issue where the 'rake discourse_nntp_bridge:assign_newsgroups' would not recognize newsgroups (cyrus shared folders). I figured that it's because Cyrus is case sensitive so I had to remove the .downcase off of this line

The next error I get is "Job exception: Bad date/time". I found no discrepancy between the date and time of the Cyrus and Discourse servers.
Here's the full backtrace from Discourses /logs

/var/www/discourse/plugins/discourse-nntp-bridge/gems/2.5.1/gems/thoughtafter-nntp-1.0.0.3/lib/nntp.rb:867:in `check_response'
/var/www/discourse/plugins/discourse-nntp-bridge/gems/2.5.1/gems/thoughtafter-nntp-1.0.0.3/lib/nntp.rb:836:in `shortcmd'
/var/www/discourse/plugins/discourse-nntp-bridge/gems/2.5.1/gems/thoughtafter-nntp-1.0.0.3/lib/nntp.rb:819:in `io_longcmd'
/var/www/discourse/plugins/discourse-nntp-bridge/gems/2.5.1/gems/thoughtafter-nntp-1.0.0.3/lib/nntp.rb:814:in `longcmd'
/var/www/discourse/plugins/discourse-nntp-bridge/gems/2.5.1/gems/thoughtafter-nntp-1.0.0.3/lib/nntp.rb:616:in `newnews'
/var/www/discourse/plugins/discourse-nntp-bridge/lib/discourse_nntp_bridge/server.rb:15:in `message_ids'
/var/www/discourse/plugins/discourse-nntp-bridge/lib/discourse_nntp_bridge/newsgroup_importer.rb:24:in `sync!'
/var/www/discourse/plugins/discourse-nntp-bridge/app/jobs/regular/nntp_bridge_importer.rb:10:in `execute'
/var/www/discourse/app/jobs/base.rb:137:in `block (2 levels) in perform'
/usr/local/lib/ruby/gems/2.5.0/gems/rails_multisite-2.0.4/lib/rails_multisite/connection_management.rb:63:in `with_connection'
/var/www/discourse/app/jobs/base.rb:127:in `block in perform'
/var/www/discourse/app/jobs/base.rb:123:in `each'
/var/www/discourse/app/jobs/base.rb:123:in `perform'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:187:in `execute_job'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:169:in `block (2 levels) in process'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/middleware/chain.rb:128:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:81:in `call'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/middleware/chain.rb:130:in `block in invoke'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/middleware/chain.rb:133:in `invoke'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:168:in `block in process'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:139:in `block (6 levels) in dispatch'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/job_retry.rb:98:in `local'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:138:in `block (5 levels) in dispatch'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq.rb:36:in `block in <module:Sidekiq>'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:134:in `block (4 levels) in dispatch'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:199:in `stats'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:129:in `block (3 levels) in dispatch'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/job_logger.rb:8:in `call'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:128:in `block (2 levels) in dispatch'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/job_retry.rb:73:in `global'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:127:in `block in dispatch'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/logging.rb:48:in `with_context'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/logging.rb:42:in `with_job_hash_context'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:126:in `dispatch'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:167:in `process'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:85:in `process_one'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:73:in `run'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/util.rb:16:in `watchdog'
/usr/local/lib/ruby/gems/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/util.rb:25:in `block in safe_thread'

Did anyone get this plugin working with Cyrus?

[sman591]

@filieski Thanks for reporting! Could you provide what Ruby and Discourse versions you’re running?

[filieski]

Discourse:
v2.2.0.beta3 +4

Ruby:
$ ruby -v
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]

Cyrus NNTPd:
2.5.10-3

[sman591]

Thank you! Just dug through the Cyrus source and NNTP RFC.

The “Bad date/time” error is coming as a response from the Cyrus server, due to this plugin sending an unknown value for the time zone (000000 instead of GMT or no value at all) to the NEWNEWS command.

Could you try changing this line in server.rb?

nntp.newnews(wildmat, '19700101', '000000')[1].uniq.map{ |message_id| message_id[1..-2] }

To

nntp.newnews(wildmat, '19700101', 'GMT')[1].uniq.map{ |message_id| message_id[1..-2] }

(If that doesn’t work, try the empty string, or omit the third argument to nntp.newnews)

Reference: https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/nntpd.c
https://tools.ietf.org/html/rfc3977#section-7.3

[filieski]

Actually according to the RFC and the Cyrus code, I should replace it to

nntp.newnews(wildmat, '19700101', '000000 GMT')[1].uniq.map{ |message_id| message_id[1..-2] }

Now it seems like it's working but I still don't get messages.
I dumped the network traffic on port 119 and I get the following:

NEWNEWS shared.zTest.uncateg 19700101 000000 GMT
230 List of new articles follows:
.

Which might be an issue on my end. I haven't tested enough.
Thanks for proposed fix. I am still testing and I will let you know soon.

[sman591]

@filieski Did you end up with a fix here?