Hello friends of Citadel!

I have Citadel running since a few years as my main mail server and I'm totally satisfied with it.
This morning I experienced another reason to be totally satisfied:
Yesterday the disk in my server broke and the mail server was - obviously - offline. I didn't have time until this morning to restore the server, but after the server was restored a few minutes later a bulk of emails came in from the time when the server was offline.
It's totally cool that I didn't lose any emails - but how is that possible?
Where is the email queue that held the emails back? Or do incoming emails just get stuck in port 25 (or 587) in the event of a server failure?
I have a Mikrotik Router just for info, but I don't believe that the Router is the cause for that effect. Does anybody know why incoming emails are kept back in such an event?

Thank you,
have a nice day!

Hello friends of Citadel!


I have Citadel running since a few years as my main mail server and
I'm totally satisfied with it.
This morning I experienced another reason to be totally satisfied:
Yesterday the disk in my server broke and the mail server was -
obviously - offline. I didn't have time until this morning to restore
the server, but after the server was restored a few minutes later a
bulk of emails came in from the time when the server was offline.
It's totally cool that I didn't lose any emails - but how is that
possible?
Where is the email queue that held the emails back? Or do incoming
emails just get stuck in port 25 (or 587) in the event of a server
failure?
I have a Mikrotik Router just for info, but I don't believe that the
Router is the cause for that effect. Does anybody know why incoming
emails are kept back in such an event?

Thank you,
have a nice day!

Thank you Marisa for the really quick answer!

That makes a lot of sense. Interestingly some of those mails were sent from a different server of mine (Monitoring) via Exim4. That means that Exim4 has such a queue implemented, I never thought about that :)
I have to research that and then I should be able to see the queue on the Monitoring Server.
Once again thanks!

Haha well, the mail queue for Exim4 was not very hard to find - now all of this makes sense to me!

But I want to ask another theoretical question that I have in my mind since years.
I think it's strange that it is just not possible to find the answer for this online even though mail servers are common and the technology is not new - still the knowledge is very hard to find.
On my Router I redirect port 25 to 587 to prevent SMTP hijacking because the server is exposed to the internet. Since then I didn't have any problems with bots using my SMTP for sending spam mails because on port 587 they have to authenticate.
Once I tried to add a rule that only my trusted IPs can use port 25. Unfortunately then I didn't receive any emails from other people anymore because it seems like the whole world is using port 25 to send emails and not 587.
So I never found a better solution for this than redirecting port 25 to 587 - how are you guys handling this?

Thank you and have a nice day!

 Any client can connect to, but should still have to authenticate to send on port 25. If not you are basically running an open relay...

Tue Oct 20 2020 08:20:39 AM EDT from attikus @ Uncensored Subject: Port 25

Haha well, the mail queue for Exim4 was not very hard to find - now all of this makes sense to me!

 

But I want to ask another theoretical question that I have in my mind since years.
I think it's strange that it is just not possible to find the answer for this online even though mail servers are common and the technology is not new - still the knowledge is very hard to find.
On my Router I redirect port 25 to 587 to prevent SMTP hijacking because the server is exposed to the internet. Since then I didn't have any problems with bots using my SMTP for sending spam mails because on port 587 they have to authenticate.
Once I tried to add a rule that only my trusted IPs can use port 25. Unfortunately then I didn't receive any emails from other people anymore because it seems like the whole world is using port 25 to send emails and not 587.
So I never found a better solution for this than redirecting port 25 to 587 - how are you guys handling this?

Thank you and have a nice day!

The database on my 8.24 node has gotten too big to manage. Is there a way to compact it so that it only contains the records that exist without all the deleted records?

There is the undocumented option c_shrink_db_files which calls the berkley db compact function.

I would image you could set it with something like..

./sendcommand CONF PUTVAL|c_shrink_db_files|1

Although you'd certainly be taking on your own risk....

It appears to still be hooked up.. see citadel/modules/expire/serv_expire.c

   if ( (!server_shutting_down) && (CtdlGetConfigInt("c_shrink_db_files") != 0) )
      {
      cdb_compact();             // Shrink the DB files on disk
      }


But personally, I would be making some serious copies of that database, or setup a test box before I messed around with it. 

See also https://www.citadel.org/disk_space.html

Tue Oct 20 2020 12:00:25 PM EDT from platonov @ Uncensored Subject: how to compact database that has lots of deleted records?

The database on my 8.24 node has gotten too big to manage. Is there a way to compact it so that it only contains the records that exist without all the deleted records?

 

Doing some testing.. You'll definitely want to put quotes around the command.

/usr/local/citadel/sendcommand "CONF PUTVAL|c_shrink_db_files|1"

It does not show up with..

./sendcommand "CONF GET"

To read the value that's in there..

./sendcommand "CONF GETVAL|c_shrink_db_files"

Also

./sendcommand "CONF LISTVAL"

or 

./sendcommand "CONF LISTVAL" | grep shrink

I'll see if I can trigger a nightly cleanup on my dev box and let everyone know how it goes.. 

 

Thanx a lot for your info and efforts. Appreciated indeed.

Tue Oct 20 2020 13:45:05 EDT from warbaby @ Uncensored Subject: Using c_shrink_db_files to compact the database..

Doing some testing.. You'll definitely want to put quotes around the command.

/usr/local/citadel/sendcommand "CONF PUTVAL|c_shrink_db_files|1"

It does not show up with..

./sendcommand "CONF GET"

To read the value that's in there..

./sendcommand "CONF GETVAL|c_shrink_db_files"

Also

./sendcommand "CONF LISTVAL"

or 

./sendcommand "CONF LISTVAL" | grep shrink

I'll see if I can trigger a nightly cleanup on my dev box and let everyone know how it goes.. 

 

Since there are a few people out there hoping for a full procedure to use c_db_shrink_files, and get their database under control, it became a DOCUMENTATION PROJECT.

I wrote my notes in markdown (instead of email), and pandoc'd it to Latex...

This can also be pandoc'ed to a "web page".. re, our 'markdown -> html -> tex -> pdf" conversation in Citadel News.

Here are the documents.  I did a little more editing on the Latex, but all can be easily automated.. [mainly typeface and hypreref link colors. .]

Assume, "How to" as the prefix for these titles and file names..[to reduce character count for SEO in the url]

eg:

siteroot/how-to/automatically-compact-citadel-database-files-using-c_shrink_db_files

Take care, and keep those Citadel boxes running..

We've got a world to save from Gmail!

automatically-compact-citadel-database-files-with-c_shrink_db_files.html (text/html, 19106 bytes) [View| Download]

thank you for this detailed answer!

is there a way in citadel to force authentication on port 25? because how I understand it, citadel drops unauthenticated mails that claims to be from my domains but if a hijacker uses any different domain he can use it as a relay. so forced authentication on port 25 should do the job.

Tue Oct 20 2020 23:10:29 EDT from IGnatius T Foobar @ Uncensored Subject: Re: Port 25

Once I tried to add a rule that only my trusted IPs can use port 25.
Unfortunately then I didn't receive any emails from other people
anymore because it seems like the whole world is using port 25 to
send emails and not 587.
So I never found a better solution for this than redirecting port 25
to 587 - how are you guys handling this?

Incoming email from the rest of the Internet uses port 25. The service on port 25 is an MTA (Mail Transport Agent) and it is universally used for sending email from site to site. There is no way around this.

Port 587 is the same service, but configured as an MSA (Mail Submission Agent).
An MSA is only used for the site's own users to submit mail into the system.
In a typical configuration, 587 requires authentication, but bypasses the spam filters because the users are trusted.

In a Citadel system, we also enforce the following rules:

1. If a connection is *not* authenticated, we do not accept mail that claims to be from our own domain(s), because it is obviously forged.

2. If a connection *is* authenticated, we ensure that the From: line in the message either is, or is changed to, a valid address for the user who authenticated.

So that's pretty much as far as we can go -- port 587 for SMTP from your own users' email clients, port 25 for the rest of the world to send mail to your site.

Well, yesterday I tried to do /usr/local/citadel/ctdlmigrate to xfer database from 8.24 to 9.29 node.

I was able to make it work and it did xfer the data to the new node. And, Subject: headers were magically working correctly. I did verify quite a bit of records and everything looked just fine. Does it mean it is a configuration issue?

Unfortunately, ctdlmigrate did not fully succeed and it bombed out with an error msg:

*** Citadel migration was unsuccessful. ***

Here are last few lines.

- - - - - - - - - - - - - - - - -

root@45.79.97.253:/usr/local/citadel/keys/ /usr/local/citadel/keys/
receiving incremental file list

sent 20 bytes  received 85 bytes  210.00 bytes/sec
total size is 5,286  speedup is 50.34
false
false

 *** Citadel migration was unsuccessful. ***

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

And the real bummer is that everything seemed to work just fine with imported data until you restart the citserver.

At that point, here's the status:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

$ sudo service citadel status
● citadel.service - Citadel Server
     Loaded: loaded (/etc/systemd/system/citadel.service; enabled; vendor preset                                                                                                                                   : enabled)
     Active: failed (Result: exit-code) since Tue 2020-10-20 20:42:41 UTC; 2s ag                                                                                                                                   o
    Process: 1507 ExecStart=/usr/local/citadel/citserver (code=exited, status=10                                                                                                                                   5)
   Main PID: 1507 (code=exited, status=105)

Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Scheduled restart job, resta                                                                                                                                   rt counter is at 5.
Oct 20 20:42:41 UbuToo systemd[1]: Stopped Citadel Server.
Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Start request repeated too q                                                                                                                                   uickly.
Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Failed with result 'exit-cod                                                                                                                                   e'.
Oct 20 20:42:41 UbuToo systemd[1]: Failed to start Citadel Server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

What can be done to fix this issue? I was thinking of doing a database recover kind of thing.

Tue Oct 20 2020 23:12:29 EDT from IGnatius T Foobar @ Uncensored Subject: Re: Is there a problem of incorrect displaying of Subject: header?

What I am seeing on 9.17 is incorrect displaying or not displaying at all

of

Subject: header in RSS feed rooms.

I have noticed this on occasion as well. It's got to be a buffer size issue somewhere but so far I haven't been able to figure out where it is. We'll keep looking.

Unfortunately when you do any of those ./sendcommand "CONF GETVAL|c_shrink_db_files" on Cit 8.24 you get an error msg:

./sendcommand "CONF GETVAL|c_shrink_db_files"
sendcommand: started (pid=18230) connecting to Citadel server at /usr/local/citadel/citadel-admin.socket
200 antimatrix Citadel server ADMIN CONNECTION ready.
CONF GETVAL|c_shrink_db_files
512 Illegal option(s) specified.
sendcommand: processing ended.

./sendcommand "CONF LISTVAL"
sendcommand: started (pid=18232) connecting to Citadel server at /usr/local/citadel/citadel-admin.socket
200 antimatrix Citadel server ADMIN CONNECTION ready.
CONF LISTVAL
512 Illegal option(s) specified.

Tue Oct 20 2020 17:17:57 EDT from platonov @ Uncensored Subject: Re: Using c_shrink_db_files to compact the database..

Thanx a lot for your info and efforts. Appreciated indeed.

Tue Oct 20 2020 13:45:05 EDT from warbaby @ Uncensored Subject: Using c_shrink_db_files to compact the database..

Doing some testing.. You'll definitely want to put quotes around the command.

/usr/local/citadel/sendcommand "CONF PUTVAL|c_shrink_db_files|1"

It does not show up with..

./sendcommand "CONF GET"

To read the value that's in there..

./sendcommand "CONF GETVAL|c_shrink_db_files"

Also

./sendcommand "CONF LISTVAL"

or 

./sendcommand "CONF LISTVAL" | grep shrink

I'll see if I can trigger a nightly cleanup on my dev box and let everyone know how it goes.. 

 

 

Well, what I have noticed is that the Subject: headers get chopped off not because of size issue, but because of non-ASCII delimeter characters, such as backquotes long dashes and non-ASCII character in general. In combination with the fact that in the migrated version of the database to 9.29 node ALL Subject: headers worked correctly, I wonder if this has something to do with some configurable parameter. The program code is the same. So, it is probably not in the source code, but in data somewhere...

Tue Oct 20 2020 23:12:29 EDT from IGnatius T Foobar @ Uncensored Subject: Re: Is there a problem of incorrect displaying of Subject: header?

What I am seeing on 9.17 is incorrect displaying or not displaying at all

of

Subject: header in RSS feed rooms.

I have noticed this on occasion as well. It's got to be a buffer size issue somewhere but so far I haven't been able to figure out where it is. We'll keep looking.

I just remembered something that might be significant as far as *** Citadel migration was unsuccessful. *** msg.

(We are talking about Cit v. 8.24 here)

I have one bad room that does not have a room name and when you click on it it looks like a single blank character as name. So, I wonder if this could be the reason the migration process bombs out after all rooms have been migrated OK, and, secondly, is there a way to delete that room? May be moving all the other rooms on that floor to some other floor and the deleting the entire floor?

Wed Oct 21 2020 08:41:59 EDT from platonov @ Uncensored Subject: Re: Is there a problem of incorrect displaying of Subject: header?

Well, yesterday I tried to do /usr/local/citadel/ctdlmigrate to xfer database from 8.24 to 9.29 node.

I was able to make it work and it did xfer the data to the new node. And, Subject: headers were magically working correctly. I did verify quite a bit of records and everything looked just fine. Does it mean it is a configuration issue?

Unfortunately, ctdlmigrate did not fully succeed and it bombed out with an error msg:

*** Citadel migration was unsuccessful. ***

Here are last few lines.

- - - - - - - - - - - - - - - - -

root@45.79.97.253:/usr/local/citadel/keys/ /usr/local/citadel/keys/
receiving incremental file list

sent 20 bytes  received 85 bytes  210.00 bytes/sec
total size is 5,286  speedup is 50.34
false
false

 *** Citadel migration was unsuccessful. ***

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

And the real bummer is that everything seemed to work just fine with imported data until you restart the citserver.

At that point, here's the status:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

$ sudo service citadel status
● citadel.service - Citadel Server
     Loaded: loaded (/etc/systemd/system/citadel.service; enabled; vendor preset                                                                                                                                   : enabled)
     Active: failed (Result: exit-code) since Tue 2020-10-20 20:42:41 UTC; 2s ag                                                                                                                                   o
    Process: 1507 ExecStart=/usr/local/citadel/citserver (code=exited, status=10                                                                                                                                   5)
   Main PID: 1507 (code=exited, status=105)

Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Scheduled restart job, resta                                                                                                                                   rt counter is at 5.
Oct 20 20:42:41 UbuToo systemd[1]: Stopped Citadel Server.
Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Start request repeated too q                                                                                                                                   uickly.
Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Failed with result 'exit-cod                                                                                                                                   e'.
Oct 20 20:42:41 UbuToo systemd[1]: Failed to start Citadel Server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

What can be done to fix this issue? I was thinking of doing a database recover kind of thing.

Tue Oct 20 2020 23:12:29 EDT from IGnatius T Foobar @ Uncensored Subject: Re: Is there a problem of incorrect displaying of Subject: header?

What I am seeing on 9.17 is incorrect displaying or not displaying at all

of

Subject: header in RSS feed rooms.

I have noticed this on occasion as well. It's got to be a buffer size issue somewhere but so far I haven't been able to figure out where it is. We'll keep looking.

 

Tue Oct 20 2020 23:12:29 EDT from IGnatius T Foobar @ Uncensored Subject: Re: Is there a problem of incorrect displaying of Subject: header?

What I am seeing on 9.17 is incorrect displaying or not displaying at all

of

Subject: header in RSS feed rooms.

I have noticed this on occasion as well. It's got to be a buffer size issue somewhere but so far I haven't been able to figure out where it is. We'll keep looking.

As far as "It's got to be a buffer size issue", I doubt that one. Because the Subject: header gets chopped off when there is non-ASCII character, delimiter, etc. Or it may have to do something with character sets or some special processing of Subject: header if there is any.

Well, yesterday I tried to do /usr/local/citadel/ctdlmigrate to xfer database from 8.24 to 9.29 node.

I was able to make it work and it did xfer the data to the new node. And the kicker is, the Subject: headers were magically working correctly. Not a single one was trimmed down. I did verify quite a bit of records and everything looked just fine. Does it mean that truncation of Subject header is a configuration issue?

Unfortunately, ctdlmigrate did not fully succeed and it bombed out with error msg:

*** Citadel migration was unsuccessful. ***

Here are last few lines.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

root@12.34.56.78:/usr/local/citadel/keys/ /usr/local/citadel/keys/
receiving incremental file list

sent 20 bytes  received 85 bytes  210.00 bytes/sec
total size is 5,286  speedup is 50.34
false
false

 *** Citadel migration was unsuccessful. ***

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

But database did transfer OK, except when you try to restart citserver you get the error status:

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

sudo service citadel status
● citadel.service - Citadel Server
     Loaded: loaded (/etc/systemd/system/citadel.service; enabled; vendor preset : enabled)
     Active: failed (Result: exit-code) since Tue 2020-10-20 20:42:41 UTC; 2s ago
    Process: 1507 ExecStart=/usr/local/citadel/citserver (code=exited, status=10                                                                                                                                   5)
   Main PID: 1507 (code=exited, status=105)

Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Scheduled restart job, restart counter is at 5.
Oct 20 20:42:41 UbuToo systemd[1]: Stopped Citadel Server.
Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Start request repeated too quickly.
Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Failed with result 'exit-code'.
Oct 20 20:42:41 UbuToo systemd[1]: Failed to start Citadel Server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
And the real bummer is that everything seemed to work just fine with imported data until you restart the citserver.

What can be done to fix the issue of not being able to start citserver and keep the migrated data? I was thinking of doing a database recover kind of thing. Is there a chance that it gets fixed?

As far as *** Citadel migration was unsuccessful. *** msg.

(We are talking about Citadel 8.24 here)

I have one room that does not have a room name and when you click on it on the desktop it looks like a single blank character as a name. So, I wonder if this could be the reason the migration process bombs out after all rooms have been migrated OK.

Secondly, is there a way to delete that room? May be moving all the other rooms on that floor to some other floor and the deleting the entire floor?

If you want to break this out into another thread about Citadel Keys, if it is in fact the issue, it may not be a bad idea..

What I'm seeing is likely rsync failing on the two key files citadel.key and citadel.csr They are chmod 600 owned by root:staff or citadel:root

Your migration may be successful except for that.  Are you using letsencrypt?  you can just copy the files from live/ .. (can't link, wrong owner permissions)

If you're not using let's encrypt, try to recreate your self-signed keys, check the contents of everything in /usr/local/citadel/keys and (same on webcit/keys. for webcit I just use a link to citadel/keys)..

Also, if using letsencrypt, use fullchain.pem .. not sure if its still an issue but, there some browsers were throwing errors  if you didn't include the whole chain.

# mv-certs-to-citadel.sh

#!/bin/bash
if [[ $# -eq 0 ]] ; then
    echo 'I need a domain related to a cert in /etc/letsencrypt/live';
    echo "Like one of these";
    echo "`ls -alh /etc/letsencrypt/live`";
    exit 0
   fi

DOMAIN=$1;
CIT_CERT_DIR="/usr/local/citadel/keys"; # Citadel Server
WEB_CERT_DIR="/usr/local/webcit/keys"; # Webcit
cp "/etc/letsencrypt/live/$DOMAIN/fullchain.pem" "$CIT_CERT_DIR/citadel.cer"
cp "/etc/letsencrypt/live/$DOMAIN/privkey.pem" "$CIT_CERT_DIR/citadel.key"
cp "/etc/letsencrypt/live/$DOMAIN/fullchain.pem" "$WEB_CERT_DIR/citadel.cer"
cp "/etc/letsencrypt/live/$DOMAIN/privkey.pem" "$WEB_CERT_DIR/citadel.key"
chown -R citadel:root "$CIT_CERT_DIR"
chown -R citadel:root "$WEB_CERT_DIR"

Wed Oct 21 2020 08:41:59 AM EDT from platonov @ Uncensored Subject: Re: Is there a problem of incorrect displaying of Subject: header?

Well, yesterday I tried to do /usr/local/citadel/ctdlmigrate to xfer database from 8.24 to 9.29 node.

I was able to make it work and it did xfer the data to the new node. And, Subject: headers were magically working correctly. I did verify quite a bit of records and everything looked just fine. Does it mean it is a configuration issue?

Unfortunately, ctdlmigrate did not fully succeed and it bombed out with an error msg:

*** Citadel migration was unsuccessful. ***

Here are last few lines.

- - - - - - - - - - - - - - - - -

root@45.79.97.253:/usr/local/citadel/keys/ /usr/local/citadel/keys/
receiving incremental file list

sent 20 bytes  received 85 bytes  210.00 bytes/sec
total size is 5,286  speedup is 50.34
false
false

 *** Citadel migration was unsuccessful. ***

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

And the real bummer is that everything seemed to work just fine with imported data until you restart the citserver.

At that point, here's the status:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

$ sudo service citadel status
● citadel.service - Citadel Server
     Loaded: loaded (/etc/systemd/system/citadel.service; enabled; vendor preset                                                                                                                                   : enabled)
     Active: failed (Result: exit-code) since Tue 2020-10-20 20:42:41 UTC; 2s ag                                                                                                                                   o
    Process: 1507 ExecStart=/usr/local/citadel/citserver (code=exited, status=10                                                                                                                                   5)
   Main PID: 1507 (code=exited, status=105)

Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Scheduled restart job, resta                                                                                                                                   rt counter is at 5.
Oct 20 20:42:41 UbuToo systemd[1]: Stopped Citadel Server.
Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Start request repeated too q                                                                                                                                   uickly.
Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Failed with result 'exit-cod                                                                                                                                   e'.
Oct 20 20:42:41 UbuToo systemd[1]: Failed to start Citadel Server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

What can be done to fix this issue? I was thinking of doing a database recover kind of thing.

Tue Oct 20 2020 23:12:29 EDT from IGnatius T Foobar @ Uncensored Subject: Re: Is there a problem of incorrect displaying of Subject: header?

What I am seeing on 9.17 is incorrect displaying or not displaying at all

of

Subject: header in RSS feed rooms.

I have noticed this on occasion as well. It's got to be a buffer size issue somewhere but so far I haven't been able to figure out where it is. We'll keep looking.

 

I am going to verify that ctdlmigrate bombs out because of these key files. I'll just move them temporarily out of /usr/local/citadel path and try to migrate again.

I'd like to know why citserver does not start properly if this is an issue with these key files. I am not worried about whether migration is not totally complete as I only need the messages that I know did migrate OK.

Wed Oct 21 2020 12:20:43 EDT from warbaby @ Uncensored Subject: Re: Is there a problem of incorrect displaying of Subject: header?

If you want to break this out into another thread about Citadel Keys, if it is in fact the issue, it may not be a bad idea..

What I'm seeing is likely rsync failing on the two key files citadel.key and citadel.csr They are chmod 600 owned by root:staff or citadel:root

Your migration may be successful except for that.  Are you using letsencrypt?  you can just copy the files from live/ .. (can't link, wrong owner permissions)

If you're not using let's encrypt, try to recreate your self-signed keys, check the contents of everything in /usr/local/citadel/keys and (same on webcit/keys. for webcit I just use a link to citadel/keys)..

Also, if using letsencrypt, use fullchain.pem .. not sure if its still an issue but, there some browsers were throwing errors  if you didn't include the whole chain.

# mv-certs-to-citadel.sh

#!/bin/bash
if [[ $# -eq 0 ]] ; then
    echo 'I need a domain related to a cert in /etc/letsencrypt/live';
    echo "Like one of these";
    echo "`ls -alh /etc/letsencrypt/live`";
    exit 0
   fi

DOMAIN=$1;
CIT_CERT_DIR="/usr/local/citadel/keys"; # Citadel Server
WEB_CERT_DIR="/usr/local/webcit/keys"; # Webcit
cp "/etc/letsencrypt/live/$DOMAIN/fullchain.pem" "$CIT_CERT_DIR/citadel.cer"
cp "/etc/letsencrypt/live/$DOMAIN/privkey.pem" "$CIT_CERT_DIR/citadel.key"
cp "/etc/letsencrypt/live/$DOMAIN/fullchain.pem" "$WEB_CERT_DIR/citadel.cer"
cp "/etc/letsencrypt/live/$DOMAIN/privkey.pem" "$WEB_CERT_DIR/citadel.key"
chown -R citadel:root "$CIT_CERT_DIR"
chown -R citadel:root "$WEB_CERT_DIR"

Wed Oct 21 2020 08:41:59 AM EDT from platonov @ Uncensored Subject: Re: Is there a problem of incorrect displaying of Subject: header?

Well, yesterday I tried to do /usr/local/citadel/ctdlmigrate to xfer database from 8.24 to 9.29 node.

I was able to make it work and it did xfer the data to the new node. And, Subject: headers were magically working correctly. I did verify quite a bit of records and everything looked just fine. Does it mean it is a configuration issue?

Unfortunately, ctdlmigrate did not fully succeed and it bombed out with an error msg:

*** Citadel migration was unsuccessful. ***

Here are last few lines.

- - - - - - - - - - - - - - - - -

root@12.34.56.78:/usr/local/citadel/keys/ /usr/local/citadel/keys/
receiving incremental file list

sent 20 bytes  received 85 bytes  210.00 bytes/sec
total size is 5,286  speedup is 50.34
false
false

 *** Citadel migration was unsuccessful. ***

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

And the real bummer is that everything seemed to work just fine with imported data until you restart the citserver.

At that point, here's the status:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

$ sudo service citadel status
● citadel.service - Citadel Server
     Loaded: loaded (/etc/systemd/system/citadel.service; enabled; vendor preset : enabled)
     Active: failed (Result: exit-code) since Tue 2020-10-20 20:42:41 UTC; 2s ago
    Process: 1507 ExecStart=/usr/local/citadel/citserver (code=exited, status=105)
   Main PID: 1507 (code=exited, status=105)

Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Scheduled restart job, restart counter is at 5.
Oct 20 20:42:41 UbuToo systemd[1]: Stopped Citadel Server.
Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Start request repeated too quickly.
Oct 20 20:42:41 UbuToo systemd[1]: citadel.service: Failed with result 'exit-code'.
Oct 20 20:42:41 UbuToo systemd[1]: Failed to start Citadel Server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

What can be done to fix this issue? I was thinking of doing a database recover kind of thing.

Tue Oct 20 2020 23:12:29 EDT from IGnatius T Foobar @ Uncensored Subject: Re: Is there a problem of incorrect displaying of Subject: header?

What I am seeing on 9.17 is incorrect displaying or not displaying at all

of

Subject: header in RSS feed rooms.

I have noticed this on occasion as well. It's got to be a buffer size issue somewhere but so far I haven't been able to figure out where it is. We'll keep looking.