Language:
switch to room list switch to menu My folders
Go to page: First ... 12 13 14 15 [16] 17 18 19 20 ... Last
[#] Tue Oct 20 2020 11:55:50 EDT from warbaby

Subject: Re: Port 25

[Reply] [ReplyQuoted] [Headers] [Print]

 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!



 



[#] Tue Oct 20 2020 12:00:25 EDT from platonov

Subject: how to compact database that has lots of deleted records?

[Reply] [ReplyQuoted] [Headers] [Print]

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?

 



[#] Tue Oct 20 2020 13:31:00 EDT from warbaby

Subject: Re: how to compact database that has lots of deleted records?

[Reply] [ReplyQuoted] [Headers] [Print]

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?

 



 



[#] Tue Oct 20 2020 13:45:05 EDT from warbaby

Subject: Using c_shrink_db_files to compact the database..

[Reply] [ReplyQuoted] [Headers] [Print]

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..

 


[#] Tue Oct 20 2020 17:17:57 EDT from platonov

Subject: Re: Using c_shrink_db_files to compact the database..

[Reply] [ReplyQuoted] [Headers] [Print]

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..

 


 



[#] Tue Oct 20 2020 22:07:43 EDT from warbaby

Subject: How to auto compact db files [Tutorial] and a Proof of Concept...

[Reply] [ReplyQuoted] [Headers] [Print]

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]
set-auto-purger-time-to-run.png (image/png, 127810 bytes) [ View | Download ]
automatically-compact-citadel-database-files-with-c_shrink_db_files.tex (text/x-tex, 22897 bytes) [ View | Download ]
automatically-compact-citadel-database-files-with-c_shrink_db_files.pdf (application/pdf, 453039 bytes) [ View | Download ]
automatically-compact-citadel-database-files-with-c_shrink_db_files.md (text/markdown, 17467 bytes) [ View | Download ]
[#] Tue Oct 20 2020 23:10:29 EDT from IGnatius T Foobar

Subject: Re: Port 25

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Tue Oct 20 2020 23:12:29 EDT from IGnatius T Foobar

Subject: Re: Is there a problem of incorrect displaying of Subject: header?

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Wed Oct 21 2020 04:05:46 EDT from attikus

Subject: Re: Port 25

[Reply] [ReplyQuoted] [Headers] [Print]

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.

 



[#] Wed Oct 21 2020 08:41:59 EDT from platonov

Subject: Re: Is there a problem of incorrect displaying of Subject: header?

[Reply] [ReplyQuoted] [Headers] [Print]

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.

 



[#] Wed Oct 21 2020 08:48:40 EDT from platonov

Subject: Re: Using c_shrink_db_files to compact the database..

[Reply] [ReplyQuoted] [Headers] [Print]

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..

 


 



 



[#] Wed Oct 21 2020 09:19:01 EDT from platonov

Subject: Re: Is there a problem of incorrect displaying of Subject: header?

[Reply] [ReplyQuoted] [Headers] [Print]

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.

 



[#] Wed Oct 21 2020 09:36:45 EDT from platonov

Subject: Re: Is there a problem of incorrect displaying of Subject: header?

[Reply] [ReplyQuoted] [Headers] [Print]

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.

 



 



[#] Wed Oct 21 2020 11:47:49 EDT from platonov

Subject: Re: Is there a problem of incorrect displaying of Subject: header?

[Reply] [ReplyQuoted] [Headers] [Print]

 

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?




[#] Wed Oct 21 2020 12:20:43 EDT from warbaby

Subject: Re: Is there a problem of incorrect displaying of Subject: header?

[Reply] [ReplyQuoted] [Headers] [Print]

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.

 



 



[#] Wed Oct 21 2020 13:41:21 EDT from platonov

Subject: Re: Ctdlmigrate fails / citserver does not restart properly afterwords

[Reply] [ReplyQuoted] [Headers] [Print]

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.

 



 



 



[#] Wed Oct 21 2020 13:52:26 EDT from platonov

Subject: Re: Ctdlmigrate and Citadel Key files

[Reply] [ReplyQuoted] [Headers] [Print]

I am using letsencrypt and I do have a script that runs "sudo certbot renew" followed by mv-certs-to-citadel.sh below.

But I am not sure I follow why ctdlmigrate does not complete OK just because of a couple of key files.

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@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.

 



 



 



[#] Wed Oct 21 2020 14:38:53 EDT from warbaby

Subject: Re: Ctdlmigrate and Citadel Key files

[Reply] [ReplyQuoted] [Headers] [Print]

Because if rsync fails, then you'll get that message.

But it's right at the very end of the process..

So, you'll have to interpret the meaning.  [It would be good to have ctdlmigrate actually echo out the full commands..but even without that.. it's obvious from "receiving incremental file list"]

check messages/

check keys/

You should have your answer right there.

ctdlmigrate.c 247-275

 

      if (!strncasecmp(buf, "files|", 6)) {
         snprintf(cmd, sizeof cmd, "rsync -va --rsh='ssh -S %s' %s@%s:%s/ %s/",
            socket_path, remote_user, remote_host, &buf[6], ctdl_file_dir);
      }
      else if (!strncasecmp(buf, "messages|", 9)) {
         snprintf(cmd, sizeof cmd, "rsync -va --rsh='ssh -S %s' %s@%s:%s/ %s/",
            socket_path, remote_user, remote_host, &buf[9], ctdl_message_dir);
      }
      else if (!strncasecmp(buf, "keys|", 5)) {
         snprintf(cmd, sizeof cmd, "rsync -va --rsh='ssh -S %s' %s@%s:%s/ %s/",
            socket_path, remote_user, remote_host, &buf[5], ctdl_key_dir);
      }
      else {
         strcpy(cmd, "false");   /* cheap and sleazy way to throw an error */
      }
      printf("%s\n", cmd);
      cmdexit = system(cmd);
      if (cmdexit != 0) {
         exitcode += cmdexit;
      }
   }
   pclose(sourcefp);

THEEND:  if (exitcode == 0) {
      printf("\n\n *** Citadel migration was successful! *** \n\n");
   }
   else {
      printf("\n\n *** Citadel migration was unsuccessful. *** \n\n");
   }


Wed Oct 21 2020 01:52:26 PM EDT from platonov @ Uncensored Subject: Re: Ctdlmigrate and Citadel Key files

I am using letsencrypt and I do have a script that runs "sudo certbot renew" followed by mv-certs-to-citadel.sh below.

But I am not sure I follow why ctdlmigrate does not complete OK just because of a couple of key files.

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@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.

 



 



 



 



[#] Wed Oct 21 2020 15:17:00 EDT from warbaby

Subject: Re: Ctdlmigrate and Citadel Key files

[Reply] [ReplyQuoted] [Headers] [Print]

Just continue on this point ..

/usr/local/citadel/files is file attachments, I'm fairly certain, for those rooms marked as file upload rooms.  I have occasionally seen files in mine.  Whether a file is stored internally (such as an imap attachment) or put in this directory depends on things I'm too lazy to look up right now.. but I'm inferring, direct uploads through webcit to a 'file upload room', is the main criteria.

/usr/local/citadel/messages has nothing to do with actual messages.. it's probably not even used anymore.  Mine has nothing in it. It was probably more like what is in text client messages ^nodename login/out templates. It's listed as ^bbsdir .. even so, trivially easy to copy even if permissions need to be modified..

/usr/local/citadel/keys < - keys obviously.. and keys are usually very tightly clamped down.. But also, often particular to a specific host.  In my mind, keys don't specifically need to be copied, they might be, or they might be recreated on the new system.  ctlmigrate is just trying to make it easy for you.  But if it did work, it might not actually be correct, because keys can overlap hostnames, and the new system might not have all the same domains, subdomains as the old, so that is kind of moot anyway.  I think the goal is to move all your email messages, and accounts, not to predict every situation that anyone could ever be in.

If I recall correctly, there was something of a catch 22 with citadel migrate..  You needed to be root, but couldn't be root in order to do one particular thing (sorry, it's been a few years since I've used it..)

Therefore, I'd say, that your migration was successful.   Sometime in the future we might add a little logic around "keys" or some verbiage about permissions..

"Your migration was successful but don't forget you must recreate your keys!"

or just bail out early on..

"You have to change permission on blah first, please run chmod ..."

or just dumb it down. "don't forget to examine the directories /files and /messages and /keys you may need to move those by hand"..

Sounds kind of odd for a "migration utility" to  become dumber, but may be the best choice considering many unknown factors out there.

Maybe the first step should be to chmod/chown all the files on the source system temporarily..

IN ANY CASE YOUR MIGRATION PROBABLY WORKED!

   rv += create_dir(ctdl_message_dir   , S_IRUSR|S_IWUSR|S_IXUSR, UID, -1);

   help_subst(buffer, "^bbsdir", ctdl_message_dir);

 

Wed Oct 21 2020 02:38:53 PM EDT from warbaby @ Uncensored Subject: Re: Ctdlmigrate and Citadel Key files

Because if rsync fails, then you'll get that message.

But it's right at the very end of the process..

So, you'll have to interpret the meaning.  [It would be good to have ctdlmigrate actually echo out the full commands..but even without that.. it's obvious from "receiving incremental file list"]

check messages/

check keys/

You should have your answer right there.

ctdlmigrate.c 247-275

 

      if (!strncasecmp(buf, "files|", 6)) {
         snprintf(cmd, sizeof cmd, "rsync -va --rsh='ssh -S %s' %s@%s:%s/ %s/",
            socket_path, remote_user, remote_host, &buf[6], ctdl_file_dir);
      }
      else if (!strncasecmp(buf, "messages|", 9)) {
         snprintf(cmd, sizeof cmd, "rsync -va --rsh='ssh -S %s' %s@%s:%s/ %s/",
            socket_path, remote_user, remote_host, &buf[9], ctdl_message_dir);
      }
      else if (!strncasecmp(buf, "keys|", 5)) {
         snprintf(cmd, sizeof cmd, "rsync -va --rsh='ssh -S %s' %s@%s:%s/ %s/",
            socket_path, remote_user, remote_host, &buf[5], ctdl_key_dir);
      }
      else {
         strcpy(cmd, "false");   /* cheap and sleazy way to throw an error */
      }
      printf("%s\n", cmd);
      cmdexit = system(cmd);
      if (cmdexit != 0) {
         exitcode += cmdexit;
      }
   }
   pclose(sourcefp);

THEEND:  if (exitcode == 0) {
      printf("\n\n *** Citadel migration was successful! *** \n\n");
   }
   else {
      printf("\n\n *** Citadel migration was unsuccessful. *** \n\n");
   }


Wed Oct 21 2020 01:52:26 PM EDT from platonov @ Uncensored Subject: Re: Ctdlmigrate and Citadel Key files

I am using letsencrypt and I do have a script that runs "sudo certbot renew" followed by mv-certs-to-citadel.sh below.

But I am not sure I follow why ctdlmigrate does not complete OK just because of a couple of key files.

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@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.

 



 



 



 



 



[#] Wed Oct 21 2020 15:24:31 EDT from platonov

Subject: Re: Ctdlmigrate and Citadel Key files

[Reply] [ReplyQuoted] [Headers] [Print]

I tried to move out the Citadel keys from /usr/local/citadel/keys to /usr/local/citadel/keys/bak and then rerun ctdlmigrate. This is the output of it now:

rsync -va --rsh='ssh -S /tmp/ctdl.5fbe.579478fe' root@12.34.56.78:/usr/local/citadel/messages// /usr/local/citadel/messages//
receiving incremental file list
./
aideopt
changepw
dotopt
entermsg
entopt
goodbye
hello
help
mainmenu
newuser
readopt
register
roomaccess
unlisted

sent 293 bytes  received 6,154 bytes  12,894.00 bytes/sec
total size is 5,328  speedup is 0.83
false
rsync -va --rsh='ssh -S /tmp/ctdl.5fbe.579478fe' root@12.34.56.78:/usr/local/citadel/keys/ /usr/local/citadel/keys/
receiving incremental file list
./
citadel.cer
citadel.key

sent 95 bytes  received 5,464 bytes  11,118.00 bytes/sec
total size is 5,286  speedup is 0.95
false
false

 *** Citadel migration was unsuccessful. ***

Shutting down the socket connection...

Exit request sent.

===============================================================
Moving out the Keys files did not help.
We still get the same error.

$ 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 Wed 2020-10-21 18:17:03 UTC; 2min 44s ago
    Process: 24630 ExecStart=/usr/local/citadel/citserver (code=exited, status=105)
   Main PID: 24630 (code=exited, status=105)

Oct 21 18:17:03 UbuToo systemd[1]: citadel.service: Scheduled restart job, restart counter is at 6.
Oct 21 18:17:03 UbuToo systemd[1]: Stopped Citadel Server.
Oct 21 18:17:03 UbuToo systemd[1]: citadel.service: Start request repeated too quickly.
Oct 21 18:17:03 UbuToo systemd[1]: citadel.service: Failed with result 'exit-code'.
Oct 21 18:17:03 UbuToo systemd[1]: Failed to start Citadel Server.

I wonder what those status msgs mean, like "Start request repeated too quickly" and "Scheduled restart job, restart counter is at 6".

From what it looks to me is some kind of a database damage, or maybe some incompatibility creeping through between cit 8.24 and 9.29 versions.

Do you think it makes sense to try to recover the database?

Basically, when I restore the original database files Citadel runs just fine. But when I use the files produced after migration then we get the citadel start problem.

What would be the "right" course of action here? Looks like there is no way to compact the 8.24 database and it is over 50 Gigs now and about thousands of times bigger than actual data records are. So, about the only option I have is to make the migrated version work, which is beginning to look pretty nasty.

Wed Oct 21 2020 14:38:53 EDT from warbaby @ Uncensored Subject: Re: Ctdlmigrate and Citadel Key files

Because if rsync fails, then you'll get that message.

But it's right at the very end of the process..

So, you'll have to interpret the meaning.  [It would be good to have ctdlmigrate actually echo out the full commands..but even without that.. it's obvious from "receiving incremental file list"]

check messages/

check keys/

You should have your answer right there.

ctdlmigrate.c 247-275

 

      if (!strncasecmp(buf, "files|", 6)) {
         snprintf(cmd, sizeof cmd, "rsync -va --rsh='ssh -S %s' %s@%s:%s/ %s/",
            socket_path, remote_user, remote_host, &buf[6], ctdl_file_dir);
      }
      else if (!strncasecmp(buf, "messages|", 9)) {
         snprintf(cmd, sizeof cmd, "rsync -va --rsh='ssh -S %s' %s@%s:%s/ %s/",
            socket_path, remote_user, remote_host, &buf[9], ctdl_message_dir);
      }
      else if (!strncasecmp(buf, "keys|", 5)) {
         snprintf(cmd, sizeof cmd, "rsync -va --rsh='ssh -S %s' %s@%s:%s/ %s/",
            socket_path, remote_user, remote_host, &buf[5], ctdl_key_dir);
      }
      else {
         strcpy(cmd, "false");   /* cheap and sleazy way to throw an error */
      }
      printf("%s\n", cmd);
      cmdexit = system(cmd);
      if (cmdexit != 0) {
         exitcode += cmdexit;
      }
   }
   pclose(sourcefp);

THEEND:  if (exitcode == 0) {
      printf("\n\n *** Citadel migration was successful! *** \n\n");
   }
   else {
      printf("\n\n *** Citadel migration was unsuccessful. *** \n\n");
   }


Wed Oct 21 2020 01:52:26 PM EDT from platonov @ Uncensored Subject: Re: Ctdlmigrate and Citadel Key files

I am using letsencrypt and I do have a script that runs "sudo certbot renew" followed by mv-certs-to-citadel.sh below.

But I am not sure I follow why ctdlmigrate does not complete OK just because of a couple of key files.

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@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.

 



 



 



 



 



Go to page: First ... 12 13 14 15 [16] 17 18 19 20 ... Last