When I use webcit to add an user whoes user name includes dots then I can afterwards successfully log via webcit using the exactly same user name or a user name that replaces dots by underscores. Does webcit translate underscores to dots or dots to underscores? If so, why? Can I change that behaviour?

Thu Jan 07 2021 22:14:09 EST from markus Subject: Cannot add user with underscore in Webcit anymore.

Hello,

in former times I was able to add users with underscores using webcit. With Citadel 930 and Webcit 927 this seems not possible anymore. Why is that? Can I change that?

Regard

Markus

 

Ask the guys here - I was in such full-blown panic mode I was driving them nuts with badly formed questions I'd answer myself a day later.

But... let me think about that. It was from non-like 9xx versions - I made an image of my SD and then upgraded it to the same version, first. It was on Raspbian to Debian. I did enable the root account on the Pi, and I feel like that was a major step forward. I used a combination of ctdlmigrate

 

https://www.citadel.org/how_do_i_move_citadel_to_another_host.html

Rsync failed with permissions issue. I looked at the commands that failed, ran them manually under root on the source machine, and most of them worked. The ones that failed were the /files folder - which it seems like Raspbian even locks root out of that folder. Later I took ownership of it and moved it over. It helped me figure out a lot of what was going on, and going wrong, on the Pi.


Again, there is a spinning / when you run this, I believe. It would just stall out on me. I finally got it to run once, and it spun the whole time.

That is what got me looking at syslog with -f and where I noticed the series of errors as it was importing. The time I saw it was not throwing errors, I can't tell you why.

But after that I was rebuilding and tweaking it and trying to import it from one like Debian machine to another - and I think then I was playing around with ./sendcommand "MIGR export" >exported.xml and I had that file in /


The instructions for that are at:

https://www.citadel.org/system_administration_manual.html


Under

Importing/Exporting your Citadel database

Sorry - I really wish I could be more help. I'll have a look at my history and bookmarks and see if they give me any other insight what I did right. Again, if you read back a dozen or so pages, you'll see my online meltdown where I was describing what I was doing and what was happening. It could help, too.

Thu Jan 07 2021 21:13:43 EST from markus Subject: Re: How to use ctdlmigrate successfully?

I wish you could remember, too :-)

Did you migrate between the same version of citadel on RiP 3b+ and on i5 or at least between the same major numbers like 8xx or 9xx?

Was a password set for your admin-account on citadel of RPi 3b+?

Did you copy any files from RPi 3b+ to i5 except the export of the database on RPi 3b+?

 

Hello,

I'm looking for a solution to sync my calenders and contacts of Thunderbird's Lightning extention to citadel.

On https://www.citadel.org/using_your_citadel_calendar_and_contacts_in_thunderbird.html I found a soultion that I used in former days. The problem is that nowadays "synckolab" is not actively developed anymore. The most recent version is five years old (see https://www.gargan.org/en/Mozilla_Extensions/SyncKolab/CVS_Nightly/ ) and does only work with Thunderbird version 35 or older.

Does somebody know any other solution to sync calenders and contacts to citadel?

Regards

Markus

I have a partial answer for you, but also extend your question so hope that someone else would be able to complete the answer - since I am also trying to use fail2ban with Citadel and it doesn't work as it should:

In previous versions of Citadel, there was an option to add command line parameters that will set the log level. I used to use: 

/usr/local/citadel/citserver -lmail -d -x6

which means using the most verbose logging level and using /var/log/mail.log as the log file (although I think it is the default now, in the past it went only to syslog)

With systemd Citadel is running as a service, so I tried to make this changes to the /etc/systemd/system/citadel.service file but I after the change and restart I am not seeing any difference in the log level. I can verify (with 'ps x | grep citserver') that the command line parameters are sent to citserver, BUT I DO NOT see any difference in the log level at mail.log

Another problem - I can see that some of the Citadel logging data is saved at /var/log/mail.log and some of it is at /var/log/syslog - specifically the login authorization data (bad login attempts, which fail2ban needs to monitor).

That is a problem since fail2ban can only monitor a single log file per 'jail'. Of course I can try and bypass and create 2 fail2ban jails for Citadel but that complicate things quite a bit and it is not supposed to be that way.

Can anyone share further advice on that? Thank you!

 

Thu Jan 07 2021 14:45:00 EST from mkuhn Subject: Citadel log level

Hi,

Happy new year!

I'm running Citadel 930 and Webcit 927, installed with easyinstall on my Odroid C2 (updating config.guess in libcitadel.tar and citadel-easyinstall.tar would be great). 

I would like to change the log level for smtp events to let Fail2ban block IPs (i.e. telnet connects on port 25).  What would I need to do to generate that information in either mail.log or syslog?

Regards.

Michael

 

 

I may have found the solution to the problem I experienced in my previous answer/solution below: The '-d' parameter was originally supposed to cause Citserver to run as a daemon. But possibly with systemd it is not needed anymore, or not supported correctly since in fact it caused citserver to have two instances in memory. I removed the '-d' parameter so the line in /etc/systemd/system/citadel.service is now:

/usr/local/citadel/citserver -lmail -x6

and now I am able to see bad login attempts in /var/log/mail.log so fail2ban mail filter should be able to find it and activate blocking. The bad login attempt error line contains the text "user_ops: bad password specified for" as well as the IP number of the offending machine trying to log in, which can be used in the fail2ban filter. I haven't tested yet with fail2ban, but will do so shortly.

By the way, in case you need, the highest level of logging is X7 (the levels are 0-7, 0 being the minimum and 7 being the maximum)

 

Fri Jan 08 2021 19:47:14 EST from omatnet Subject: Re: Citadel log level

I have a partial answer for you, but also extend your question so hope that someone else would be able to complete the answer - since I am also trying to use fail2ban with Citadel and it doesn't work as it should:

In previous versions of Citadel, there was an option to add command line parameters that will set the log level. I used to use: 

/usr/local/citadel/citserver -lmail -d -x6

which means using the most verbose logging level and using /var/log/mail.log as the log file (although I think it is the default now, in the past it went only to syslog)

With systemd Citadel is running as a service, so I tried to make this changes to the /etc/systemd/system/citadel.service file but I after the change and restart I am not seeing any difference in the log level. I can verify (with 'ps x | grep citserver') that the command line parameters are sent to citserver, BUT I DO NOT see any difference in the log level at mail.log

Another problem - I can see that some of the Citadel logging data is saved at /var/log/mail.log and some of it is at /var/log/syslog - specifically the login authorization data (bad login attempts, which fail2ban needs to monitor).

That is a problem since fail2ban can only monitor a single log file per 'jail'. Of course I can try and bypass and create 2 fail2ban jails for Citadel but that complicate things quite a bit and it is not supposed to be that way.

Can anyone share further advice on that? Thank you!

 

Thu Jan 07 2021 14:45:00 EST from mkuhn Subject: Citadel log level

Hi,

Happy new year!

I'm running Citadel 930 and Webcit 927, installed with easyinstall on my Odroid C2 (updating config.guess in libcitadel.tar and citadel-easyinstall.tar would be great). 

I would like to change the log level for smtp events to let Fail2ban block IPs (i.e. telnet connects on port 25).  What would I need to do to generate that information in either mail.log or syslog?

Regards.

Michael

 

 

 

Thanks a bunch for taking another look at it. I implemented the change to citadel.service and will do some smpt auth testing later today. FYI - there is a failregex sample described in the Citadel Security room here on this bbs

Fri Jan 08 2021 20:22:13 EST from omatnet Subject: Re: Citadel log level

I may have found the solution to the problem I experienced in my previous answer/solution below: The '-d' parameter was originally supposed to cause Citserver to run as a daemon. But possibly with systemd it is not needed anymore, or not supported correctly since in fact it caused citserver to have two instances in memory. I removed the '-d' parameter so the line in /etc/systemd/system/citadel.service is now:

/usr/local/citadel/citserver -lmail -x6

and now I am able to see bad login attempts in /var/log/mail.log so fail2ban mail filter should be able to find it and activate blocking. The bad login attempt error line contains the text "user_ops: bad password specified for" as well as the IP number of the offending machine trying to log in, which can be used in the fail2ban filter. I haven't tested yet with fail2ban, but will do so shortly.

By the way, in case you need, the highest level of logging is X7 (the levels are 0-7, 0 being the minimum and 7 being the maximum)

 

Fri Jan 08 2021 19:47:14 EST from omatnet Subject: Re: Citadel log level

I have a partial answer for you, but also extend your question so hope that someone else would be able to complete the answer - since I am also trying to use fail2ban with Citadel and it doesn't work as it should:

In previous versions of Citadel, there was an option to add command line parameters that will set the log level. I used to use: 

/usr/local/citadel/citserver -lmail -d -x6

which means using the most verbose logging level and using /var/log/mail.log as the log file (although I think it is the default now, in the past it went only to syslog)

With systemd Citadel is running as a service, so I tried to make this changes to the /etc/systemd/system/citadel.service file but I after the change and restart I am not seeing any difference in the log level. I can verify (with 'ps x | grep citserver') that the command line parameters are sent to citserver, BUT I DO NOT see any difference in the log level at mail.log

Another problem - I can see that some of the Citadel logging data is saved at /var/log/mail.log and some of it is at /var/log/syslog - specifically the login authorization data (bad login attempts, which fail2ban needs to monitor).

That is a problem since fail2ban can only monitor a single log file per 'jail'. Of course I can try and bypass and create 2 fail2ban jails for Citadel but that complicate things quite a bit and it is not supposed to be that way.

Can anyone share further advice on that? Thank you!

 

Thu Jan 07 2021 14:45:00 EST from mkuhn Subject: Citadel log level

Hi,

Happy new year!

I'm running Citadel 930 and Webcit 927, installed with easyinstall on my Odroid C2 (updating config.guess in libcitadel.tar and citadel-easyinstall.tar would be great). 

I would like to change the log level for smtp events to let Fail2ban block IPs (i.e. telnet connects on port 25).  What would I need to do to generate that information in either mail.log or syslog?

Regards.

Michael

 

 

 

 

Works

syslog: mail citserver[1467]: citserver[1467]: user_ops: bad password specified for <> Service <SMTP-MTA> Port <port #> Remote <OP address / IP addrress>

mail.log: mail citserver[1467]: user_ops: bad password specified for <> Service <SMTP-MTA> Port <port #> Remote <OP address / IP addrress>

 

Sat Jan 09 2021 08:13:52 EST from Michael Subject: Re: Citadel log level

Thanks a bunch for taking another look at it. I implemented the change to citadel.service and will do some smpt auth testing later today. FYI - there is a failregex sample described in the Citadel Security room here on this bbs

Fri Jan 08 2021 20:22:13 EST from omatnet Subject: Re: Citadel log level

I may have found the solution to the problem I experienced in my previous answer/solution below: The '-d' parameter was originally supposed to cause Citserver to run as a daemon. But possibly with systemd it is not needed anymore, or not supported correctly since in fact it caused citserver to have two instances in memory. I removed the '-d' parameter so the line in /etc/systemd/system/citadel.service is now:

/usr/local/citadel/citserver -lmail -x6

and now I am able to see bad login attempts in /var/log/mail.log so fail2ban mail filter should be able to find it and activate blocking. The bad login attempt error line contains the text "user_ops: bad password specified for" as well as the IP number of the offending machine trying to log in, which can be used in the fail2ban filter. I haven't tested yet with fail2ban, but will do so shortly.

By the way, in case you need, the highest level of logging is X7 (the levels are 0-7, 0 being the minimum and 7 being the maximum)

 

Fri Jan 08 2021 19:47:14 EST from omatnet Subject: Re: Citadel log level

I have a partial answer for you, but also extend your question so hope that someone else would be able to complete the answer - since I am also trying to use fail2ban with Citadel and it doesn't work as it should:

In previous versions of Citadel, there was an option to add command line parameters that will set the log level. I used to use: 

/usr/local/citadel/citserver -lmail -d -x6

which means using the most verbose logging level and using /var/log/mail.log as the log file (although I think it is the default now, in the past it went only to syslog)

With systemd Citadel is running as a service, so I tried to make this changes to the /etc/systemd/system/citadel.service file but I after the change and restart I am not seeing any difference in the log level. I can verify (with 'ps x | grep citserver') that the command line parameters are sent to citserver, BUT I DO NOT see any difference in the log level at mail.log

Another problem - I can see that some of the Citadel logging data is saved at /var/log/mail.log and some of it is at /var/log/syslog - specifically the login authorization data (bad login attempts, which fail2ban needs to monitor).

That is a problem since fail2ban can only monitor a single log file per 'jail'. Of course I can try and bypass and create 2 fail2ban jails for Citadel but that complicate things quite a bit and it is not supposed to be that way.

Can anyone share further advice on that? Thank you!

 

Thu Jan 07 2021 14:45:00 EST from mkuhn Subject: Citadel log level

Hi,

Happy new year!

I'm running Citadel 930 and Webcit 927, installed with easyinstall on my Odroid C2 (updating config.guess in libcitadel.tar and citadel-easyinstall.tar would be great). 

I would like to change the log level for smtp events to let Fail2ban block IPs (i.e. telnet connects on port 25).  What would I need to do to generate that information in either mail.log or syslog?

Regards.

Michael

 

 

 

 

 

Hi Markus,

I looked into calendar synching with Citadel as well a few years ago.  Decided it's not worth the hassle and used my Nextcloud instance instead.  Maybe another route for you too.

Michael

Fri Jan 08 2021 15:58:31 EST from markus Subject: How to sync calenders and contacts without synckolab?

Hello,

I'm looking for a solution to sync my calenders and contacts of Thunderbird's Lightning extention to citadel.

On https://www.citadel.org/using_your_citadel_calendar_and_contacts_in_thunderbird.html I found a soultion that I used in former days. The problem is that nowadays "synckolab" is not actively developed anymore. The most recent version is five years old (see https://www.gargan.org/en/Mozilla_Extensions/SyncKolab/CVS_Nightly/ ) and does only work with Thunderbird version 35 or older.

Does somebody know any other solution to sync calenders and contacts to citadel?

Regards

Markus

 

Hello!

The setup routine of webcite offers the option to start webcit on system start. I cannot see the same option for citadel. Is there a way to start citadel on Debian system start?

Thanks and regards

Markus

Glad I was able to help Michael,

Do have a fail2ban filter file for citadel, something that would be under the 'filter.d'? I wasn't able to find a proper filter that would work for citadel with fail2ban.

If yes, could you please share it? (will save me time instead of building the filter file from scratch).

Thanks!

Sat Jan 09 2021 08:31:26 EST from Michael Subject: Re: Citadel log level

Works

syslog: mail citserver[1467]: citserver[1467]: user_ops: bad password specified for <> Service <SMTP-MTA> Port <port #> Remote <OP address / IP addrress>

mail.log: mail citserver[1467]: user_ops: bad password specified for <> Service <SMTP-MTA> Port <port #> Remote <OP address / IP addrress>

 

Sat Jan 09 2021 08:13:52 EST from Michael Subject: Re: Citadel log level

Thanks a bunch for taking another look at it. I implemented the change to citadel.service and will do some smpt auth testing later today. FYI - there is a failregex sample described in the Citadel Security room here on this bbs

Fri Jan 08 2021 20:22:13 EST from omatnet Subject: Re: Citadel log level

I may have found the solution to the problem I experienced in my previous answer/solution below: The '-d' parameter was originally supposed to cause Citserver to run as a daemon. But possibly with systemd it is not needed anymore, or not supported correctly since in fact it caused citserver to have two instances in memory. I removed the '-d' parameter so the line in /etc/systemd/system/citadel.service is now:

/usr/local/citadel/citserver -lmail -x6

and now I am able to see bad login attempts in /var/log/mail.log so fail2ban mail filter should be able to find it and activate blocking. The bad login attempt error line contains the text "user_ops: bad password specified for" as well as the IP number of the offending machine trying to log in, which can be used in the fail2ban filter. I haven't tested yet with fail2ban, but will do so shortly.

By the way, in case you need, the highest level of logging is X7 (the levels are 0-7, 0 being the minimum and 7 being the maximum)

 

Fri Jan 08 2021 19:47:14 EST from omatnet Subject: Re: Citadel log level

I have a partial answer for you, but also extend your question so hope that someone else would be able to complete the answer - since I am also trying to use fail2ban with Citadel and it doesn't work as it should:

In previous versions of Citadel, there was an option to add command line parameters that will set the log level. I used to use: 

/usr/local/citadel/citserver -lmail -d -x6

which means using the most verbose logging level and using /var/log/mail.log as the log file (although I think it is the default now, in the past it went only to syslog)

With systemd Citadel is running as a service, so I tried to make this changes to the /etc/systemd/system/citadel.service file but I after the change and restart I am not seeing any difference in the log level. I can verify (with 'ps x | grep citserver') that the command line parameters are sent to citserver, BUT I DO NOT see any difference in the log level at mail.log

Another problem - I can see that some of the Citadel logging data is saved at /var/log/mail.log and some of it is at /var/log/syslog - specifically the login authorization data (bad login attempts, which fail2ban needs to monitor).

That is a problem since fail2ban can only monitor a single log file per 'jail'. Of course I can try and bypass and create 2 fail2ban jails for Citadel but that complicate things quite a bit and it is not supposed to be that way.

Can anyone share further advice on that? Thank you!

 

Thu Jan 07 2021 14:45:00 EST from mkuhn Subject: Citadel log level

Hi,

Happy new year!

I'm running Citadel 930 and Webcit 927, installed with easyinstall on my Odroid C2 (updating config.guess in libcitadel.tar and citadel-easyinstall.tar would be great). 

I would like to change the log level for smtp events to let Fail2ban block IPs (i.e. telnet connects on port 25).  What would I need to do to generate that information in either mail.log or syslog?

Regards.

Michael

 

 

 

 

 

 

Well, actually I just noticed that warbaby already posted a 'Quick and dirty fail2ban filter for Citadel' in the Citadel Security room:

http://uncensored.citadel.org/webcit/webcit/dotgoto?room=Citadel%20Security

I'll give it a try. Thanks warbaby!

Sun Jan 10 2021 18:25:58 EST from omatnet Subject: Re: Citadel log level

Glad I was able to help Michael,

Do have a fail2ban filter file for citadel, something that would be under the 'filter.d'? I wasn't able to find a proper filter that would work for citadel with fail2ban.

If yes, could you please share it? (will save me time instead of building the filter file from scratch).

Thanks!

Sat Jan 09 2021 08:31:26 EST from Michael Subject: Re: Citadel log level

Works

syslog: mail citserver[1467]: citserver[1467]: user_ops: bad password specified for <> Service <SMTP-MTA> Port <port #> Remote <OP address / IP addrress>

mail.log: mail citserver[1467]: user_ops: bad password specified for <> Service <SMTP-MTA> Port <port #> Remote <OP address / IP addrress>

 

Sat Jan 09 2021 08:13:52 EST from Michael Subject: Re: Citadel log level

Thanks a bunch for taking another look at it. I implemented the change to citadel.service and will do some smpt auth testing later today. FYI - there is a failregex sample described in the Citadel Security room here on this bbs

Fri Jan 08 2021 20:22:13 EST from omatnet Subject: Re: Citadel log level

I may have found the solution to the problem I experienced in my previous answer/solution below: The '-d' parameter was originally supposed to cause Citserver to run as a daemon. But possibly with systemd it is not needed anymore, or not supported correctly since in fact it caused citserver to have two instances in memory. I removed the '-d' parameter so the line in /etc/systemd/system/citadel.service is now:

/usr/local/citadel/citserver -lmail -x6

and now I am able to see bad login attempts in /var/log/mail.log so fail2ban mail filter should be able to find it and activate blocking. The bad login attempt error line contains the text "user_ops: bad password specified for" as well as the IP number of the offending machine trying to log in, which can be used in the fail2ban filter. I haven't tested yet with fail2ban, but will do so shortly.

By the way, in case you need, the highest level of logging is X7 (the levels are 0-7, 0 being the minimum and 7 being the maximum)

 

Fri Jan 08 2021 19:47:14 EST from omatnet Subject: Re: Citadel log level

I have a partial answer for you, but also extend your question so hope that someone else would be able to complete the answer - since I am also trying to use fail2ban with Citadel and it doesn't work as it should:

In previous versions of Citadel, there was an option to add command line parameters that will set the log level. I used to use: 

/usr/local/citadel/citserver -lmail -d -x6

which means using the most verbose logging level and using /var/log/mail.log as the log file (although I think it is the default now, in the past it went only to syslog)

With systemd Citadel is running as a service, so I tried to make this changes to the /etc/systemd/system/citadel.service file but I after the change and restart I am not seeing any difference in the log level. I can verify (with 'ps x | grep citserver') that the command line parameters are sent to citserver, BUT I DO NOT see any difference in the log level at mail.log

Another problem - I can see that some of the Citadel logging data is saved at /var/log/mail.log and some of it is at /var/log/syslog - specifically the login authorization data (bad login attempts, which fail2ban needs to monitor).

That is a problem since fail2ban can only monitor a single log file per 'jail'. Of course I can try and bypass and create 2 fail2ban jails for Citadel but that complicate things quite a bit and it is not supposed to be that way.

Can anyone share further advice on that? Thank you!

 

Thu Jan 07 2021 14:45:00 EST from mkuhn Subject: Citadel log level

Hi,

Happy new year!

I'm running Citadel 930 and Webcit 927, installed with easyinstall on my Odroid C2 (updating config.guess in libcitadel.tar and citadel-easyinstall.tar would be great). 

I would like to change the log level for smtp events to let Fail2ban block IPs (i.e. telnet connects on port 25).  What would I need to do to generate that information in either mail.log or syslog?

Regards.

Michael

 

 

 

 

 

 

 

My citadel server, which is being used only for email, has degraded to the point that it no longer runs. I can't log into the web interface. My devices can't fetch mail. It is running on an ubuntu server and was configured after easy install.

After it stopped working, I attempted to do an easy install from an updated package. When I ssh into the box I get the following messages:

citserver[3250]: db: cdb_fetch(9): BDB0075 DB_PAGE_NOTFOUND: Requested page not found

I was seeing these messages even before attempting to patch with the latest. Not sure what to do from here.

Hi,

like marcus i noticed that since upgrading to latest easy_install version citadel always appends the From address as an additional TO address which isn't only kind of annoying but also breaks dkim signing via rspamd (which can be mitigated by excluding the TO header from signing).

Anything i can do to help fixing this?

Thank you, ParanoidDelusions, for your kind help. Put I didn't get it done. I think my citadel source system needs an upgrade first. And Ihat's not what I want to do because I would need to upgrade the whole system. Too much can go wrong. So I go the mail user agent way.

Fri Jan 08 2021 00:45:52 EST from ParanoidDelusions Subject: Re: How to use ctdlmigrate successfully?

Ask the guys here - I was in such full-blown panic mode I was driving them nuts with badly formed questions I'd answer myself a day later.

But... let me think about that. It was from non-like 9xx versions - I made an image of my SD and then upgraded it to the same version, first. It was on Raspbian to Debian. I did enable the root account on the Pi, and I feel like that was a major step forward. I used a combination of ctdlmigrate

 

https://www.citadel.org/how_do_i_move_citadel_to_another_host.html

Rsync failed with permissions issue. I looked at the commands that failed, ran them manually under root on the source machine, and most of them worked. The ones that failed were the /files folder - which it seems like Raspbian even locks root out of that folder. Later I took ownership of it and moved it over. It helped me figure out a lot of what was going on, and going wrong, on the Pi.


Again, there is a spinning / when you run this, I believe. It would just stall out on me. I finally got it to run once, and it spun the whole time.

That is what got me looking at syslog with -f and where I noticed the series of errors as it was importing. The time I saw it was not throwing errors, I can't tell you why.

But after that I was rebuilding and tweaking it and trying to import it from one like Debian machine to another - and I think then I was playing around with ./sendcommand "MIGR export" >exported.xml and I had that file in /


The instructions for that are at:

https://www.citadel.org/system_administration_manual.html


Under

Importing/Exporting your Citadel database

Sorry - I really wish I could be more help. I'll have a look at my history and bookmarks and see if they give me any other insight what I did right. Again, if you read back a dozen or so pages, you'll see my online meltdown where I was describing what I was doing and what was happening. It could help, too.

Thu Jan 07 2021 21:13:43 EST from markus Subject: Re: How to use ctdlmigrate successfully?

I wish you could remember, too :-)

Did you migrate between the same version of citadel on RiP 3b+ and on i5 or at least between the same major numbers like 8xx or 9xx?

Was a password set for your admin-account on citadel of RPi 3b+?

Did you copy any files from RPi 3b+ to i5 except the export of the database on RPi 3b+?

 

 

Yes, the base and target system do need to be upgraded to the same version for this to work. I did upgrade the version on the Pi to the version running on IA before doing the migrate. 

You shouldn't need to upgrade the whole system, though. Do you mean the Linux distro, (i.e, apt-get update && apt-get dist-upgrade) or the hardware itself would need to be upgraded?

I'm pretty sure I didn't do a dist-ugprade on the Pi before I upgraded to the most recent version of Citadel. I did make a backup image of the Pi's SD card and tested it first, then did the Citadel Upgrade, then did the Citadel migrate. 

 

 

 

Tue Jan 12 2021 14:09:35 EST from markus Subject: Re: How to use ctdlmigrate successfully?

Thank you, ParanoidDelusions, for your kind help. Put I didn't get it done. I think my citadel source system needs an upgrade first. And Ihat's not what I want to do because I would need to upgrade the whole system. Too much can go wrong. So I go the mail user agent way.

Fri Jan 08 2021 00:45:52 EST from ParanoidDelusions Subject: Re: How to use ctdlmigrate successfully?

Ask the guys here - I was in such full-blown panic mode I was driving them nuts with badly formed questions I'd answer myself a day later.

But... let me think about that. It was from non-like 9xx versions - I made an image of my SD and then upgraded it to the same version, first. It was on Raspbian to Debian. I did enable the root account on the Pi, and I feel like that was a major step forward. I used a combination of ctdlmigrate

 

https://www.citadel.org/how_do_i_move_citadel_to_another_host.html

Rsync failed with permissions issue. I looked at the commands that failed, ran them manually under root on the source machine, and most of them worked. The ones that failed were the /files folder - which it seems like Raspbian even locks root out of that folder. Later I took ownership of it and moved it over. It helped me figure out a lot of what was going on, and going wrong, on the Pi.


Again, there is a spinning / when you run this, I believe. It would just stall out on me. I finally got it to run once, and it spun the whole time.

That is what got me looking at syslog with -f and where I noticed the series of errors as it was importing. The time I saw it was not throwing errors, I can't tell you why.

But after that I was rebuilding and tweaking it and trying to import it from one like Debian machine to another - and I think then I was playing around with ./sendcommand "MIGR export" >exported.xml and I had that file in /


The instructions for that are at:

https://www.citadel.org/system_administration_manual.html


Under

Importing/Exporting your Citadel database

Sorry - I really wish I could be more help. I'll have a look at my history and bookmarks and see if they give me any other insight what I did right. Again, if you read back a dozen or so pages, you'll see my online meltdown where I was describing what I was doing and what was happening. It could help, too.

Thu Jan 07 2021 21:13:43 EST from markus Subject: Re: How to use ctdlmigrate successfully?

I wish you could remember, too :-)

Did you migrate between the same version of citadel on RiP 3b+ and on i5 or at least between the same major numbers like 8xx or 9xx?

Was a password set for your admin-account on citadel of RPi 3b+?

Did you copy any files from RPi 3b+ to i5 except the export of the database on RPi 3b+?

 

 

 

omatnet,

take a look at the attachments.  I am using spamassassin and have the "
Perform RBL checks upon connect instead of after RCPT" option checked (citadel smtp administration tab). My failregex ckecks for smtp auth errors and rbls.

Verify the paths work for you (e.g. path to citadel or your log files)

Let me know if it worked.

Michael

Sun Jan 10 2021 18:25:58 EST from omatnet Subject: Re: Citadel log level

Glad I was able to help Michael,

Do have a fail2ban filter file for citadel, something that would be under the 'filter.d'? I wasn't able to find a proper filter that would work for citadel with fail2ban.

If yes, could you please share it? (will save me time instead of building the filter file from scratch).

Thanks!

Sat Jan 09 2021 08:31:26 EST from Michael Subject: Re: Citadel log level

Works

syslog: mail citserver[1467]: citserver[1467]: user_ops: bad password specified for <> Service <SMTP-MTA> Port <port #> Remote <OP address / IP addrress>

mail.log: mail citserver[1467]: user_ops: bad password specified for <> Service <SMTP-MTA> Port <port #> Remote <OP address / IP addrress>

 

Sat Jan 09 2021 08:13:52 EST from Michael Subject: Re: Citadel log level

Thanks a bunch for taking another look at it. I implemented the change to citadel.service and will do some smpt auth testing later today. FYI - there is a failregex sample described in the Citadel Security room here on this bbs

Fri Jan 08 2021 20:22:13 EST from omatnet Subject: Re: Citadel log level

I may have found the solution to the problem I experienced in my previous answer/solution below: The '-d' parameter was originally supposed to cause Citserver to run as a daemon. But possibly with systemd it is not needed anymore, or not supported correctly since in fact it caused citserver to have two instances in memory. I removed the '-d' parameter so the line in /etc/systemd/system/citadel.service is now:

/usr/local/citadel/citserver -lmail -x6

and now I am able to see bad login attempts in /var/log/mail.log so fail2ban mail filter should be able to find it and activate blocking. The bad login attempt error line contains the text "user_ops: bad password specified for" as well as the IP number of the offending machine trying to log in, which can be used in the fail2ban filter. I haven't tested yet with fail2ban, but will do so shortly.

By the way, in case you need, the highest level of logging is X7 (the levels are 0-7, 0 being the minimum and 7 being the maximum)

 

Fri Jan 08 2021 19:47:14 EST from omatnet Subject: Re: Citadel log level

I have a partial answer for you, but also extend your question so hope that someone else would be able to complete the answer - since I am also trying to use fail2ban with Citadel and it doesn't work as it should:

In previous versions of Citadel, there was an option to add command line parameters that will set the log level. I used to use: 

/usr/local/citadel/citserver -lmail -d -x6

which means using the most verbose logging level and using /var/log/mail.log as the log file (although I think it is the default now, in the past it went only to syslog)

With systemd Citadel is running as a service, so I tried to make this changes to the /etc/systemd/system/citadel.service file but I after the change and restart I am not seeing any difference in the log level. I can verify (with 'ps x | grep citserver') that the command line parameters are sent to citserver, BUT I DO NOT see any difference in the log level at mail.log

Another problem - I can see that some of the Citadel logging data is saved at /var/log/mail.log and some of it is at /var/log/syslog - specifically the login authorization data (bad login attempts, which fail2ban needs to monitor).

That is a problem since fail2ban can only monitor a single log file per 'jail'. Of course I can try and bypass and create 2 fail2ban jails for Citadel but that complicate things quite a bit and it is not supposed to be that way.

Can anyone share further advice on that? Thank you!

 

Thu Jan 07 2021 14:45:00 EST from mkuhn Subject: Citadel log level

Hi,

Happy new year!

I'm running Citadel 930 and Webcit 927, installed with easyinstall on my Odroid C2 (updating config.guess in libcitadel.tar and citadel-easyinstall.tar would be great). 

I would like to change the log level for smtp events to let Fail2ban block IPs (i.e. telnet connects on port 25).  What would I need to do to generate that information in either mail.log or syslog?

Regards.

Michael

 

 

 

 

 

 

 

sendmail-common.conf (application/octet-stream, 2514 bytes) [ View | Download ]
sendmail-whois-ipjailmatches.conf (application/octet-stream, 1438 bytes) [ View | Download ]
sendmail-whois-lines.conf (application/octet-stream, 1775 bytes) [ View | Download ]
sendmail-whois-ipmatches.conf (application/octet-stream, 1414 bytes) [ View | Download ]
sendmail-buffered.conf (application/octet-stream, 3874 bytes) [ View | Download ]
citserver.conf (application/octet-stream, 1166 bytes) [ View | Download ]
sendmail-whois.conf (application/octet-stream, 1337 bytes) [ View | Download ]
jail.conf (application/octet-stream, 436 bytes) [ View | Download ]
sendmail.conf (application/octet-stream, 1174 bytes) [ View | Download ]
sendmail-geoip-lines.conf (application/octet-stream, 2408 bytes) [ View | Download ]
jail.local (application/octet-stream, 963 bytes) [ View | Download ]
fail2ban.conf (application/octet-stream, 3277 bytes) [ View | Download ]
sendmail-whois-matches.conf (application/octet-stream, 1361 bytes) [ View | Download ]

Hello
No email is sent and this error appears
requested action not taken mailbox unavailable or relaying denied

Possible solution to this error !?

Thanks

i can receive emails but can't send and i have the attached error 

(550 (Requested action not taken: mailbox unavailable or relaying denied)

12.PNG (image/png, 21631 bytes) [ View | Download ]

Hello
No email is sent and this error appears
requested action not taken mailbox unavailable or relaying denied

Possible solution to this error !?

Thanks

Thanks Michael,

I also noticed that warbaby posted a 'Quick and dirty fail2ban filter for Citadel' in the Citadel Security room:

http://uncensored.citadel.org/webcit/webcit/dotgoto?room=Citadel%20Security

 

Wed Jan 13 2021 02:04:12 EST from Michael Subject: Re: Citadel log level

omatnet,

take a look at the attachments.  I am using spamassassin and have the "
Perform RBL checks upon connect instead of after RCPT" option checked (citadel smtp administration tab). My failregex ckecks for smtp auth errors and rbls.

Verify the paths work for you (e.g. path to citadel or your log files)

Let me know if it worked.

Michael

Sun Jan 10 2021 18:25:58 EST from omatnet Subject: Re: Citadel log level

Glad I was able to help Michael,

Do have a fail2ban filter file for citadel, something that would be under the 'filter.d'? I wasn't able to find a proper filter that would work for citadel with fail2ban.

If yes, could you please share it? (will save me time instead of building the filter file from scratch).

Thanks!

Sat Jan 09 2021 08:31:26 EST from Michael Subject: Re: Citadel log level

Works

syslog: mail citserver[1467]: citserver[1467]: user_ops: bad password specified for <> Service <SMTP-MTA> Port <port #> Remote <OP address / IP addrress>

mail.log: mail citserver[1467]: user_ops: bad password specified for <> Service <SMTP-MTA> Port <port #> Remote <OP address / IP addrress>

 

Sat Jan 09 2021 08:13:52 EST from Michael Subject: Re: Citadel log level

Thanks a bunch for taking another look at it. I implemented the change to citadel.service and will do some smpt auth testing later today. FYI - there is a failregex sample described in the Citadel Security room here on this bbs

Fri Jan 08 2021 20:22:13 EST from omatnet Subject: Re: Citadel log level

I may have found the solution to the problem I experienced in my previous answer/solution below: The '-d' parameter was originally supposed to cause Citserver to run as a daemon. But possibly with systemd it is not needed anymore, or not supported correctly since in fact it caused citserver to have two instances in memory. I removed the '-d' parameter so the line in /etc/systemd/system/citadel.service is now:

/usr/local/citadel/citserver -lmail -x6

and now I am able to see bad login attempts in /var/log/mail.log so fail2ban mail filter should be able to find it and activate blocking. The bad login attempt error line contains the text "user_ops: bad password specified for" as well as the IP number of the offending machine trying to log in, which can be used in the fail2ban filter. I haven't tested yet with fail2ban, but will do so shortly.

By the way, in case you need, the highest level of logging is X7 (the levels are 0-7, 0 being the minimum and 7 being the maximum)

 

Fri Jan 08 2021 19:47:14 EST from omatnet Subject: Re: Citadel log level

I have a partial answer for you, but also extend your question so hope that someone else would be able to complete the answer - since I am also trying to use fail2ban with Citadel and it doesn't work as it should:

In previous versions of Citadel, there was an option to add command line parameters that will set the log level. I used to use: 

/usr/local/citadel/citserver -lmail -d -x6

which means using the most verbose logging level and using /var/log/mail.log as the log file (although I think it is the default now, in the past it went only to syslog)

With systemd Citadel is running as a service, so I tried to make this changes to the /etc/systemd/system/citadel.service file but I after the change and restart I am not seeing any difference in the log level. I can verify (with 'ps x | grep citserver') that the command line parameters are sent to citserver, BUT I DO NOT see any difference in the log level at mail.log

Another problem - I can see that some of the Citadel logging data is saved at /var/log/mail.log and some of it is at /var/log/syslog - specifically the login authorization data (bad login attempts, which fail2ban needs to monitor).

That is a problem since fail2ban can only monitor a single log file per 'jail'. Of course I can try and bypass and create 2 fail2ban jails for Citadel but that complicate things quite a bit and it is not supposed to be that way.

Can anyone share further advice on that? Thank you!

 

Thu Jan 07 2021 14:45:00 EST from mkuhn Subject: Citadel log level

Hi,

Happy new year!

I'm running Citadel 930 and Webcit 927, installed with easyinstall on my Odroid C2 (updating config.guess in libcitadel.tar and citadel-easyinstall.tar would be great). 

I would like to change the log level for smtp events to let Fail2ban block IPs (i.e. telnet connects on port 25).  What would I need to do to generate that information in either mail.log or syslog?

Regards.

Michael

 

 

 

 

 

 

 

 

sendmail-buffered.conf (application/octet-stream, 3874 bytes) [ View | Download ]
citserver.conf (application/octet-stream, 1166 bytes) [ View | Download ]
sendmail-whois-ipjailmatches.conf (application/octet-stream, 1438 bytes) [ View | Download ]
sendmail.conf (application/octet-stream, 1174 bytes) [ View | Download ]
sendmail-common.conf (application/octet-stream, 2514 bytes) [ View | Download ]
fail2ban.conf (application/octet-stream, 3277 bytes) [ View | Download ]
sendmail-whois-lines.conf (application/octet-stream, 1775 bytes) [ View | Download ]
jail.local (application/octet-stream, 963 bytes) [ View | Download ]
jail.conf (application/octet-stream, 436 bytes) [ View | Download ]
sendmail-geoip-lines.conf (application/octet-stream, 2408 bytes) [ View | Download ]
sendmail-whois.conf (application/octet-stream, 1337 bytes) [ View | Download ]
sendmail-whois-matches.conf (application/octet-stream, 1361 bytes) [ View | Download ]
sendmail-whois-ipmatches.conf (application/octet-stream, 1414 bytes) [ View | Download ]