Subject: Re: citadel refuses to start after OpenSuSE upgrade - now with Easyins
Mon Feb 19 2018 16:48:14 EST from bgerum @ Uncensored Subject: Re: citadel refuses to start after OpenSuSE upgrade - cursor still in prog
Sun Feb 04 2018 16:22:10 EST from bgerum @ Uncensored Subject: Re: citadel refuses to start after OpenSuSE upgrade - cursor still in prog
Mon Jan 29 2018 18:34:53 EST from bgerum @ Uncensored Subject: Re: citadel refuses to start after OpenSuSE upgrade - cursor still in prog
Mon Jan 29 2018 13:35:33 EST from IGnatius T Foobar @ Uncensored Subject: Re: citadel refuses to start after OpenSuSE upgrade - cursor still in progthanks for the reply. Unfortunately it seems the last version supplied bythe
homueller SuSE repo which is linked in the citadel.org doku ist 824.
Is there another rpm source?
I'm not aware of another RPM source. You could switch to Easy Install, which works on all distributions, but you'll have to move your data files to another directory first.I used the Easy Install a long time ago, but the RPM version ist much more integrated in the OpenSuSE environment, not only directory-wise but also regarding startscripts, updating etc.
Do you think you could give Mr. homueller a hint there are new citadel versions out there?
Ok, I found another OpenSuSE rpm source:
https://download.opensuse.org/repositories/home:/stefjakobs:/citadel-testing
it does provide citadel-9.01-13.19.x86_64, I installed it although it is compiled for the tumbleweed version of OpenSuSE, not leap which is what i use.
however, my database upgrade problem still remains:
citserver[14575]: Checking directory access citserver[14575]: Opening databases citserver[14575]: bdb(): open_databases() starting citserver[14575]: Compiled db: Berkeley DB 4.8.30: (March 31, 2016) citserver[14575]: Linked db: Berkeley DB 4.8.30: (October 21, 2013) citserver[14575]: Calculated dbversion: 4008030 citserver[14575]: Previous dbversion: 4008030 citserver[14575]: Linked zlib: 1.2.8 citserver[14575]: bdb(): Setting up DB environment citserver[14575]: dbenv->open(dbenv, /var/lib/citadel/data/, 10899, 0) citserver[14575]: DB: Finding last valid log LSN: file: 6494 offset 9355549 citserver[14575]: DB: Recovery starting from [6494][9355421] citserver[14575]: DB: Recovery complete at Sun Feb 4 22:10:24 2018 citserver[14575]: DB: Maximum transaction ID 80000024 Recovery checkpoint [6494][9355549] citserver[14575]: Starting up DB citserver[14575]: Checking floor reference counts citserver[14575]: bdb(): cursor still in progress on cdb 04: can't begin transaction during r/o cursor citserver[14575]: citserver is stopping in order to prevent data loss. uid=0 gid=0 euid=0 egid=0
Hi Ignatius,any help on this? In the meantime I fired up the old server, did a sendcommand "CULL" and retransfered all the data files ... still the same problem!As, unfortunately citadel 9.01-13 seems to be regarded as positively ancient, too, I gave EasyInstall a try, still having in mind I will have to reconfigure all the startup scripting, let's encrypt SSL Cert updating, fetchmail with TLS/SSL etc..But EasyInstall chokes up on libsieve:2nd run:Installation will now begin.
Command output will not be sent to the terminal.
To view progress, see the /tmp/citadel-install-log.txt file.
* libical does not need updating.
* libsieve does not need updating.
* Berkeley DB does not need updating.
* expat does not need updating.
* libcurl does not need updating.
* libcitadel does not need updating.
* Downloading Citadel...
* Installing Citadel...
Citadel Easy Install is aborting.
A log file has been written to /tmp/citadel-install-log.txt
Reading this file may tell you what went wrong. If you
need to ask for help on the support forum, please post the
last screenful of text from this log.
Operating system: Linux 4.4.104-39-default( 4.4.104-39-default x86_64)last lines of the install log:checking for libical/ical.h... yes
checking for icaltimezone_set_tzid_prefix in -lical... yes
checking sieve2.h usability... yes
checking sieve2.h presence... yes
checking for sieve2.h... yes
checking for sieve2_license in -lsieve... no
configure: error: libsieve was not found and is required. More info: http://www.citadel.org/doku.php/installation:start
Operating system: Linux 4.4.104-39-default( 4.4.104-39-default x86_64)
having trouble getting past login after following instructions here https://pimylifeup.com/raspberry-pi-email-server/ i have to click login multiple times then gets stuck with please wait many thanks for any help i can get
Subject: Re: citadel refuses to start after OpenSuSE upgrade - now with Easyins
checking for libical/ical.h... yes
checking for icaltimezone_set_tzid_prefix in -lical... yes
checking sieve2.h usability... yes
checking sieve2.h presence... yes
checking for sieve2.h... yes
checking for sieve2_license in -lsieve... no
configure: error: libsieve was not found and is required. More info: http://www.citadel.org/doku.php/installation:start
Operating system: Linux 4.4.104-39-default( 4.4.104-39-default x86_64)
According to that log, it couldn't link to libsieve, even though libsieve had clearly been installed. That is quite weird.
Can you attach the full log please? We need to see what happened during the libsieve build.
Subject: Re: Unable to connect pidgin to citadel server
Sat Feb 24 2018 11:43:32 EST from bobdoe @ Uncensored Subject: Unable to connect pidgin to citadel serverI'd like to attempt reformulating the question in a more neutral way, if I got chance. Already read the proper questions faq.
I'm trying to connect Pidgin chat client to Citadel server.
Setup:
Citadel 917 installed through easy-install on Centos 7.4. Firewalld disabled.
Pidgin 2.12 running on Windows 10.So I followed the corresponding documentation: http://www.citadel.org/doku.php/faq:everydayuse:jabber#configuring.a.jabber.client.to.access.citadel
But after that I get the following error: "The certificate for <server> could not be validated. The certificate chain presented is invalid".Now, I noticed in latest pidgin build that there's seemingly no way to turn off SSL/TLS encryption anymore; at most there's the option "use old style SSL".
What I have tried and what I got:
--Use old style SSL:
no certificate error, but Pidgin gets stuck in "Connecting..." forever.
--Export Citadel server's certificate with Firefox, name it after server's hostname (ip address), and manually adding it to Pidgin:
still get the same previous "certificate chain is invalid" error
--Run "openssl s_client -connect <server>:<port> -starttls xmpp" in Centos server, and copying generated cert to Pidgin on Windows:
still get the same previous "certificate chain is invalid" error
--Change Citadel XMPP port to 5223 as well as in Pidgin, and use old style SSL:
Pidgin complains about not finding the server.Finally I tried other XMPP clients such as Jitsi, Gajim and Spark. Long story short (unless I'm required to provide further details), they also expect to connect through SSL/TLS with no option to disable it.
Could anyone assist, please?
Or should I try finding a XMPP client with option to not use SSL/TLS at all?Thanks.
Again, not a Citadel expert, but when I see the error "The certificate for <server> could not be validated. The certificate chain presented is invalid". this indicates an issue with the certificate chain.
If this is a self signed certificate, then Pidgin doesn't support those anymore. If this isn't a self signed certificate, please check the intermediate certificates are in place. Usually when you buy a certificate you get a bundle, which includes your certificate, plus their certificate chain, just in case, so the cert can be verified by the issuing body.
Link to an article about how SSL works: https://www.entrustdatacard.com/pages/ssl
Subject: Re: Unable to connect pidgin to citadel server
Mon Feb 26 2018 09:11:30 AM EST from Haven @ Uncensored Subject: Re: Unable to connect pidgin to citadel server
Sat Feb 24 2018 11:43:32 EST from bobdoe @ Uncensored Subject: Unable to connect pidgin to citadel serverI'd like to attempt reformulating the question in a more neutral way, if I got chance. Already read the proper questions faq.
I'm trying to connect Pidgin chat client to Citadel server.
Setup:
Citadel 917 installed through easy-install on Centos 7.4. Firewalld disabled.
Pidgin 2.12 running on Windows 10.So I followed the corresponding documentation: http://www.citadel.org/doku.php/faq:everydayuse:jabber#configuring.a.jabber.client.to.access.citadel
But after that I get the following error: "The certificate for <server> could not be validated. The certificate chain presented is invalid".Now, I noticed in latest pidgin build that there's seemingly no way to turn off SSL/TLS encryption anymore; at most there's the option "use old style SSL".
What I have tried and what I got:
--Use old style SSL:
no certificate error, but Pidgin gets stuck in "Connecting..." forever.
--Export Citadel server's certificate with Firefox, name it after server's hostname (ip address), and manually adding it to Pidgin:
still get the same previous "certificate chain is invalid" error
--Run "openssl s_client -connect <server>:<port> -starttls xmpp" in Centos server, and copying generated cert to Pidgin on Windows:
still get the same previous "certificate chain is invalid" error
--Change Citadel XMPP port to 5223 as well as in Pidgin, and use old style SSL:
Pidgin complains about not finding the server.Finally I tried other XMPP clients such as Jitsi, Gajim and Spark. Long story short (unless I'm required to provide further details), they also expect to connect through SSL/TLS with no option to disable it.
Could anyone assist, please?
Or should I try finding a XMPP client with option to not use SSL/TLS at all?Thanks.
Again, not a Citadel expert, but when I see the error "The certificate for <server> could not be validated. The certificate chain presented is invalid". this indicates an issue with the certificate chain.
If this is a self signed certificate, then Pidgin doesn't support those anymore. If this isn't a self signed certificate, please check the intermediate certificates are in place. Usually when you buy a certificate you get a bundle, which includes your certificate, plus their certificate chain, just in case, so the cert can be verified by the issuing body.
Link to an article about how SSL works: https://www.entrustdatacard.com/pages/ssl
Thanks.
Meanwhile I have already read several articles about general SSL and TLS. I also searched again in all citadel.org documents.
And yes, I already realized Citadel installs self-signed certificates by default (evident when accessing webcit through https).
I also tried with other XMPP clients such as Jitsi and Miranda. Their options regarding SSL are certainly different of Pidgin's, in the sense one can seemingly enable/disable SSL option. Yet, by following similar steps to those described in citadel's pidgin documentation, I still cannot connect to server. Jitsi complains about not finding the server, and Miranda gets stuck at attempting to conenct and not showing any contacts or groups.
Ignatius:
I'd be willing to offer apologies. But also, if you had chance, could you give some advise please? Is it that Citadel still needs further TLS compatibility?
I'm still trying stuff by myself, and searching for more TLS documents, but I'm fearing I'd reach my limit soon, and this feature would be very useful for the place here.
Thanks.
Subject: Re: Unable to connect pidgin to citadel server
Citadel Server and WebCit both follow the same procedure for auto-generating a certificate at startup if you haven't supplied one:
1. If there is no private key, one is generated.
2. A certificate signing request (CSR) is generated using that key.
3. If there is no public certificate, a self-signed certificate is generated using the key and CSR.
If you are applying to a certificate authority for a "real" certificate, the generated key will be fine to use, but the CSR will probably have incorrect information in it. Here's a quick rundown of what you need to do, for Citadel or any other software which needs an SSL certificate.
1. Generate a key with a command like:
openssl genrsa -out citadel.key 2048
2. Generate a certificate signing request:
openssl req -new -key citadel.key -out citadel.csr
Answer all prompts carefully!
3. Submit your CSR to the certificate authority of your choice. When they supply your signed certificate, they will likely indicate to you that there are one or more intermediate certificates that must be included. Create a file called "citadel.cer" containing your server's certificate, followed by the intermediate certificate(s).
4. Restart citserver. Connect to it and see if it works.
WebCit is the same way, except the filenames are webcit.[key|csr|cer] instead of citadel.[key|csr|cer]. It's probably easier to test with WebCit first, since you can easily verify it with your web browser, and then copy the files over to Citadel after testing.
You can and should use the same key/cert for both programs.
In the future we will be looking into implementing the Let's Encrypt framework to automatically obtain and install free SSL certificates, but that is some way off at this point. In the mean time I'm pleased to see that the number of options for trial and short term SSL certificates at no cost has increrased.
I'm trying to use the replication feature to migrate from one server to another, but I can't find ANY documentation on the feature. How do I use it? Thanks!
Hi there!
I'm trying to migrate a citadel server from one server to another. I was trying to use the replication utility, but couldn't find any real documentation on it.
I can re-configure the useres and such if I need to, I just need to move all the emails over.
Thanks in advance for your help!
Subject: Re: Unable to connect pidgin to citadel server
Mon Feb 26 2018 12:28:50 PM EST from IGnatius T Foobar @ Uncensored Subject: Re: Unable to connect pidgin to citadel serverCitadel XMPP honors the 'starttls' command to upgrade a non-encrypted connection to an encrypted connection. I'm surprised to hear that there are clients which cannot be configured to ignore certificate trust errors, but if that is the case, there are a number of places offering free SSL certificates now, so you can try-before-you-buy.
Citadel Server and WebCit both follow the same procedure for auto-generating a certificate at startup if you haven't supplied one:
1. If there is no private key, one is generated.
2. A certificate signing request (CSR) is generated using that key.
3. If there is no public certificate, a self-signed certificate is generated using the key and CSR.
If you are applying to a certificate authority for a "real" certificate, the generated key will be fine to use, but the CSR will probably have incorrect information in it. Here's a quick rundown of what you need to do, for Citadel or any other software which needs an SSL certificate.
1. Generate a key with a command like:
openssl genrsa -out citadel.key 2048
2. Generate a certificate signing request:
openssl req -new -key citadel.key -out citadel.csr
Answer all prompts carefully!
3. Submit your CSR to the certificate authority of your choice. When they supply your signed certificate, they will likely indicate to you that there are one or more intermediate certificates that must be included. Create a file called "citadel.cer" containing your server's certificate, followed by the intermediate certificate(s).
4. Restart citserver. Connect to it and see if it works.
WebCit is the same way, except the filenames are webcit.[key|csr|cer] instead of citadel.[key|csr|cer]. It's probably easier to test with WebCit first, since you can easily verify it with your web browser, and then copy the files over to Citadel after testing.
You can and should use the same key/cert for both programs.
In the future we will be looking into implementing the Let's Encrypt framework to automatically obtain and install free SSL certificates, but that is some way off at this point. In the mean time I'm pleased to see that the number of options for trial and short term SSL certificates at no cost has increrased.
Thanks very much for answering.
As I previously mentioned, I have already reviewed -more than once- the documents at citadel.org site, so I was already well aware of what you just explained. Sorry if I didn't mention it earlier.
Just wanted to mention this before keeping trying a few more possible stuff. Somewhere in Pidgin site I had read it can actually handle self-signed or untrusted certificates just well; it just didn't say how to. I was about to search again there but the site is currently down...
From the docs and what you just explained, I'd guess Citadel currently lacks self-signed certificate support at least for XMPP...
Note: i've seen the page that says not to use the replication function for this. The other suggested methods don't seem to have worked.
Subject: Re: Unable to connect pidgin to citadel server
From the docs and what you just explained, I'd guess Citadel currently lacks self-signed certificate support at least for XMPP...
Well ... not quite. It's not really an issue specific to XMPP, or even to Citadel.
Any server that supports SSL/TLS, on any protocol which uses it, is just going to supply whatever certificate you've installed on it. The server does not care whether the client chooses to trust it. It's the client's decision whether to trust the server certificate or not. The server cannot choose to "support" any specific type of certificate. Only the client can do that.
Note: i've seen the page that says not to use the replication function for this. The other suggested methods don't seem to have worked.
If you're going from like-to-like architecture (for example, 64-bit Intel on both sides) it's best to just copy the data files over.
Subject: Re: citadel refuses to start after OpenSuSE upgrade - now with Easyins
Sun Feb 25 2018 21:46:41 EST from IGnatius T Foobar @ Uncensored Subject: Re: citadel refuses to start after OpenSuSE upgrade - now with Easyins
checking for libical/ical.h... yes
checking for icaltimezone_set_tzid_prefix in -lical... yes
checking sieve2.h usability... yes
checking sieve2.h presence... yes
checking for sieve2.h... yes
checking for sieve2_license in -lsieve... no
configure: error: libsieve was not found and is required. More info: http://www.citadel.org/doku.php/installation:start
Operating system: Linux 4.4.104-39-default( 4.4.104-39-default x86_64)According to that log, it couldn't link to libsieve, even though libsieve had clearly been installed. That is quite weird.
Can you attach the full log please? We need to see what happened during the libsieve build.
unfortunately the 2nd try has overwritten the original log. I also did some updates overnight... but attached you find the current EasyInstall Log
Auflösen des Hostnamen »easyinstall.citadel.org (easyinstall.citadel.org)«... 216.150.130.115
Verbindungsaufbau zu easyinstall.citadel.org (easyinstall.citadel.org)|216.150.130.115|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 32553 (32K) [text/plain]
In »»gpl.txt«« speichern.
0K .......... .......... .......... . 100% 97,1K=0,3s
2018-02-26 22:30:27 (97,1 KB/s) - »»gpl.txt«« gespeichert [32553/32553]
--2018-02-26 22:30:31-- http://easyinstall.citadel.org/libical-easyinstall.sum
Auflösen des Hostnamen »easyinstall.citadel.org (easyinstall.citadel.org)«... 216.150.130.115
Verbindungsaufbau zu easyinstall.citadel.org (easyinstall.citadel.org)|216.150.130.115|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 33 [text/plain]
In »»libical-easyinstall.sum«« speichern.
0K 100% 1,61M=0s
2018-02-26 22:30:31 (1,61 MB/s) - »»libical-easyinstall.sum«« gespeichert [33/33]
--2018-02-26 22:30:31-- http://easyinstall.citadel.org/libsieve-easyinstall.sum
Auflösen des Hostnamen »easyinstall.citadel.org (easyinstall.citadel.org)«... 216.150.130.115
Verbindungsaufbau zu easyinstall.citadel.org (easyinstall.citadel.org)|216.150.130.115|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 9 [text/plain]
In »»libsieve-easyinstall.sum«« speichern.
0K 100% 413K=0s
2018-02-26 22:30:31 (413 KB/s) - »»libsieve-easyinstall.sum«« gespeichert [9/9]
--2018-02-26 22:30:32-- http://easyinstall.citadel.org/db-easyinstall.sum
Auflösen des Hostnamen »easyinstall.citadel.org (easyinstall.citadel.org)«... 216.150.130.115
Verbindungsaufbau zu easyinstall.citadel.org (easyinstall.citadel.org)|216.150.130.115|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 33 [text/plain]
In »»db-easyinstall.sum«« speichern.
0K 100% 1,55M=0s
2018-02-26 22:30:32 (1,55 MB/s) - »»db-easyinstall.sum«« gespeichert [33/33]
--2018-02-26 22:30:32-- http://easyinstall.citadel.org/expat-easyinstall.sum
Auflösen des Hostnamen »easyinstall.citadel.org (easyinstall.citadel.org)«... 216.150.130.115
Verbindungsaufbau zu easyinstall.citadel.org (easyinstall.citadel.org)|216.150.130.115|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 33 [text/plain]
In »»expat-easyinstall.sum«« speichern.
0K 100% 1,06M=0s
2018-02-26 22:30:32 (1,06 MB/s) - »»expat-easyinstall.sum«« gespeichert [33/33]
--2018-02-26 22:30:32-- http://easyinstall.citadel.org/libcurl-easyinstall.sum
Auflösen des Hostnamen »easyinstall.citadel.org (easyinstall.citadel.org)«... 216.150.130.115
Verbindungsaufbau zu easyinstall.citadel.org (easyinstall.citadel.org)|216.150.130.115|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 33 [text/plain]
In »»libcurl-easyinstall.sum«« speichern.
0K 100% 1,48M=0s
2018-02-26 22:30:32 (1,48 MB/s) - »»libcurl-easyinstall.sum«« gespeichert [33/33]
--2018-02-26 22:30:32-- http://easyinstall.citadel.org/libcitadel-easyinstall.sum
Auflösen des Hostnamen »easyinstall.citadel.org (easyinstall.citadel.org)«... 216.150.130.115
Verbindungsaufbau zu easyinstall.citadel.org (easyinstall.citadel.org)|216.150.130.115|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 41 [text/plain]
In »»libcitadel-easyinstall.sum«« speichern.
0K 100% 1,87M=0s
2018-02-26 22:30:33 (1,87 MB/s) - »»libcitadel-easyinstall.sum«« gespeichert [41/41]
--2018-02-26 22:30:33-- http://easyinstall.citadel.org/citadel-easyinstall.sum
Auflösen des Hostnamen »easyinstall.citadel.org (easyinstall.citadel.org)«... 216.150.130.115
Verbindungsaufbau zu easyinstall.citadel.org (easyinstall.citadel.org)|216.150.130.115|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 41 [text/plain]
In »»citadel-easyinstall.sum«« speichern.
0K 100% 1,42M=0s
2018-02-26 22:30:33 (1,42 MB/s) - »»citadel-easyinstall.sum«« gespeichert [41/41]
--2018-02-26 22:30:33-- http://easyinstall.citadel.org/citadel-easyinstall.tar.gz
Auflösen des Hostnamen »easyinstall.citadel.org (easyinstall.citadel.org)«... 216.150.130.115
Verbindungsaufbau zu easyinstall.citadel.org (easyinstall.citadel.org)|216.150.130.115|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 727044 (710K) [application/x-gzip]
In »»citadel-easyinstall.tar.gz«« speichern.
0K .......... .......... .......... .......... .......... 7% 99,5K 7s
50K .......... .......... .......... .......... .......... 14% 249K 4s
100K .......... .......... .......... .......... .......... 21% 497K 3s
150K .......... .......... .......... .......... .......... 28% 499K 2s
200K .......... .......... .......... .......... .......... 35% 6,60M 2s
250K .......... .......... .......... .......... .......... 42% 488K 1s
300K .......... .......... .......... .......... .......... 49% 6,31M 1s
350K .......... .......... .......... .......... .......... 56% 513K 1s
400K .......... .......... .......... .......... .......... 63% 7,55M 1s
450K .......... .......... .......... .......... .......... 70% 581K 1s
500K .......... .......... .......... .......... .......... 77% 2,43M 0s
550K .......... .......... .......... .......... .......... 84% 19,2M 0s
600K .......... .......... .......... .......... .......... 91% 3,75M 0s
650K .......... .......... .......... .......... .......... 98% 587K 0s
700K .......... 100% 17,8M=1,3s
2018-02-26 22:30:35 (532 KB/s) - »»citadel-easyinstall.tar.gz«« gespeichert [727044/727044]
configure: WARNING: unrecognized options: --with-libical, --disable-threaded-client
configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for zlibVersion in -lz... yes
checking Checking to see if your system supports iconv... yes
Citadel will be built with character set conversion.
checking for libintl_bindtextdomain in -lintl... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to compile with POSIX threads... Linux
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking how to create dependancy checks... checking for a BSD-compatible install... /usr/bin/install -c
checking for bison... bison -y
checking for diff... /usr/bin/diff
checking for patch... /usr/bin/patch
/tmp/citadel-build.8703/citadel/missing: Unknown `--is-lightweight' option
Try `/tmp/citadel-build.8703/citadel/missing --help' for more information
configure: WARNING: 'missing' script is too old or missing
checking size of char... 1
checking size of short... 2
checking size of int... 4
checking size of long... 8
checking size of size_t... 8
checking size of loff_t... 8
checking for crypt... no
checking for gethostbyname... yes
checking for connect... yes
checking for getpwnam_r... yes
checking for getpwuid_r... yes
checking for getloadavg... yes
checking for strftime_l... yes
checking for uselocale... yes
checking for gettext... yes
checking for xgettext... yes
checking for msgmerge... yes
checking for msgfmt... yes
citadel will be built with national language support.
checking for sched_yield in -lrt... yes
checking for pam_start in -lpam... yes
checking for pam_start... yes
checking for vw_printw... no
checking for wcolor_set... no
checking for resizeterm... no
checking for wresize... no
checking for pthread_create in -lpthread... yes
checking for pthread_create in -lpthreads... no
checking libical/ical.h usability... yes
checking libical/ical.h presence... yes
checking for libical/ical.h... yes
checking for icaltimezone_set_tzid_prefix in -lical... yes
checking sieve2.h usability... yes
checking sieve2.h presence... yes
checking for sieve2.h... yes
checking for sieve2_license in -lsieve... no
configure: error: libsieve was not found and is required. More info: http://www.citadel.org/doku.php/installation:start
Operating system: Linux 4.4.114-42-default( 4.4.114-42-default x86_64)
Subject: Re: Unable to connect pidgin to citadel server
Mon Feb 26 2018 04:09:59 PM EST from IGnatius T Foobar @ Uncensored Subject: Re: Unable to connect pidgin to citadel serverFrom the docs and what you just explained, I'd guess Citadel currently lacks self-signed certificate support at least for XMPP...
Well ... not quite. It's not really an issue specific to XMPP, or even to Citadel.
Any server that supports SSL/TLS, on any protocol which uses it, is just going to supply whatever certificate you've installed on it. The server does not care whether the client chooses to trust it. It's the client's decision whether to trust the server certificate or not. The server cannot choose to "support" any specific type of certificate. Only the client can do that.
Yes, already just realized.
So I did some more tests, with 2 versions of Pidgin: current 2.12.0 one; and 2.7.3, which was the last one having the same options as screenshots illustrated here
http://www.citadel.org/doku.php/faq:everydayuse:jabber#configuring.a.jabber.client.to.access.citadel
I tried this old build as well to see if having the option to disable SSL could make a difference.
Setup, just for review:
Citadel 917 installed from easy-install on Centos 7.4, both firewalld and selinux disabled
Server's ip: 10.0.1.5
Testing user: user123
Pidgin clients running on Windows 10
So, summarizing again what I tried and what I got:
--Use old style SSL, either with port 5222 and 5223 (both Pidgin versions):
no certificate error, but Pidgin gets stuck in "Connecting..." forever according to its debug window.
--Export Citadel server's certificate with Firefox, name it after server's hostname (ip address), and manually adding it to Pidgin
--Run "openssl s_client -connect 10.0.1.5:5222 -starttls xmpp" in Centos server, and copying generated cert to Pidgin on Windows (filename is ip address):
I need to correct myself in these 2. It seems last time I had messed up server. It fixed and I could try for real this time.
This time Pidgin accepted the certificate. But now a new problem arouse. I posted Pidgin's 2.12.0 debug window output here https://pastebin.com/Kr2dAr81 .
In Pidgin 2.12.0 line 67 "connection: purple_connection_error_reason called with NULL description" was the killer one marked in red.
Log for Pidgin 2.7.3 was virtually the same, except that lines 66 and 67 were not there; killer error was the "Don't know howto do 'set'!".
But the interesting thing is, this "set" error is present in both logs.
Just in case I posted in Pidgin forums. To my surprise, they pointed at the "set" error:
"The software you're using is lacking some basic core XMPP stuff in its implementation, namely something like this https://tools.ietf.org/html/rfc6120#page-95 "
Think this could be a bug?
Thanks again.
Subject: Re: Unable to connect pidgin to citadel server
What we really need is a Lua module to authenticate Prosody thru the Citadel API. Prosody supports lots of XEP specs, and has a fairly active community. It's lightweight, and can run just fine along Citadel on small VPS. I've used it for years. We just need to hook them up.
Even if you were to get your SSL sorted out, you'll immediately want some XMPP feature that Citadel doesn't support, and may not ever.. so, it's easier to write the authentication than waste more time testing old versions of pidgin. If a few of us got together, we could have it done in a few days, if not hours. All XMPP clients are junk btw.
I spent some time with auth_imap a while ago, but don't recall what happened. It may work. Take a look at the other auth modules. They are only ~75-100 loc.
https://modules.prosody.im/type_auth.html
Mon Feb 26 2018 04:09:59 PM EST from IGnatius T Foobar @ Uncensored Subject: Re: Unable to connect pidgin to citadel serverFrom the docs and what you just explained, I'd guess Citadel currently lacks self-signed certificate support at least for XMPP...
Well ... not quite. It's not really an issue specific to XMPP, or even to Citadel.
Any server that supports SSL/TLS, on any protocol which uses it, is just going to supply whatever certificate you've installed on it. The server does not care whether the client chooses to trust it. It's the client's decision whether to trust the server certificate or not. The server cannot choose to "support" any specific type of certificate. Only the client can do that.
Yes, already just realized.
So I did some more tests, with 2 versions of Pidgin: current 2.12.0 one; and 2.7.3, which was the last one having the same options as screenshots illustrated here
http://www.citadel.org/doku.php/faq:everydayuse:jabber#configuring.a.jabber.client.to.access.citadel
I tried this old build as well to see if having the option to disable SSL could make a difference.Setup, just for review:
Citadel 917 installed from easy-install on Centos 7.4, both firewalld and selinux disabled
Server's ip: 10.0.1.5
Testing user: user123
Pidgin clients running on Windows 10
So, summarizing again what I tried and what I got:
--Use old style SSL, either with port 5222 and 5223 (both Pidgin versions):
no certificate error, but Pidgin gets stuck in "Connecting..." forever according to its debug window.
--Export Citadel server's certificate with Firefox, name it after server's hostname (ip address), and manually adding it to Pidgin
--Run "openssl s_client -connect 10.0.1.5:5222 -starttls xmpp" in Centos server, and copying generated cert to Pidgin on Windows (filename is ip address):
I need to correct myself in these 2. It seems last time I had messed up server. It fixed and I could try for real this time.
This time Pidgin accepted the certificate. But now a new problem arouse. I posted Pidgin's 2.12.0 debug window output here https://pastebin.com/Kr2dAr81 .In Pidgin 2.12.0 line 67 "connection: purple_connection_error_reason called with NULL description" was the killer one marked in red.
Log for Pidgin 2.7.3 was virtually the same, except that lines 66 and 67 were not there; killer error was the "Don't know howto do 'set'!".
But the interesting thing is, this "set" error is present in both logs.Just in case I posted in Pidgin forums. To my surprise, they pointed at the "set" error:
"The software you're using is lacking some basic core XMPP stuff in its implementation, namely something like this https://tools.ietf.org/html/rfc6120#page-95 "Think this could be a bug?
Thanks again.
Subject: Re: Unable to connect pidgin to citadel server
I dared to take a look at Citadel source code out of curiosity.
By all means I'm no dev and I may have dared too much for myself, but... could it be there might be something missing in this part?
http://code.citadel.org/?p=citadel.git;a=blob;f=citadel/modules/xmpp/serv_xmpp.c;h=3248a11cb39bbbf98b1281ec78082c10d3da3774;hb=HEAD#l177
In general, can this be fixed?
Subject: Fix crashes when some external APIs fail
Hi,
I'm a PhD student. I analyzed the Citadel source code and found some potential API bugs that may cause crashes. These crashes are mainly caused by insufficient error handling of API functions like chown or fopen.
I think it's unsafe to assume the library function would be correct. It would be better if we could handle the error properly. Attached please find the patch against the current development version. Hopefully, it can solve these potential bugs.
Best,
Zhouyang
Hi,
I am Md.Moniruzzaman,I want to try install and configure Citadel mail server. But I can't understand the system of citadel.How I can install and configure citadel server in Open-suse.If any one give sequential instruction than i will got the system.
Thank you.
Hi,
I want to try install and configure Citadel mail server. But I can't understand the system of citadel.How I can install and configure citadel server in Open-suse.If any one give sequential instruction than i will got the system.
Thank you.
Subject: Re: Unable to connect pidgin to citadel server
Prosody is an XMPP server, not a client.
Tue Feb 27 2018 10:58:00 AM EST from bobdoe @ Uncensored Subject: Re: Unable to connect pidgin to citadel server
Mon Feb 26 2018 11:58:15 PM EST from warbaby @ Uncensored Subject: Re: Unable to connect pidgin to citadel serverWhat we really need is a Lua module to authenticate Prosody thru the Citadel API. Prosody supports lots of XEP specs, and has a fairly active community. It's lightweight, and can run just fine along Citadel on small VPS. I've used it for years. We just need to hook them up.
Even if you were to get your SSL sorted out, you'll immediately want some XMPP feature that Citadel doesn't support, and may not ever.. so, it's easier to write the authentication than waste more time testing old versions of pidgin. If a few of us got together, we could have it done in a few days, if not hours. All XMPP clients are junk btw.
I spent some time with auth_imap a while ago, but don't recall what happened. It may work. Take a look at the other auth modules. They are only ~75-100 loc.
https://modules.prosody.im/type_auth.html
Mon Feb 26 2018 04:09:59 PM EST from IGnatius T Foobar @ Uncensored Subject: Re: Unable to connect pidgin to citadel serverFrom the docs and what you just explained, I'd guess Citadel currently lacks self-signed certificate support at least for XMPP...
Well ... not quite. It's not really an issue specific to XMPP, or even to Citadel.
Any server that supports SSL/TLS, on any protocol which uses it, is just going to supply whatever certificate you've installed on it. The server does not care whether the client chooses to trust it. It's the client's decision whether to trust the server certificate or not. The server cannot choose to "support" any specific type of certificate. Only the client can do that.
Yes, already just realized.
So I did some more tests, with 2 versions of Pidgin: current 2.12.0 one; and 2.7.3, which was the last one having the same options as screenshots illustrated here
http://www.citadel.org/doku.php/faq:everydayuse:jabber#configuring.a.jabber.client.to.access.citadel
I tried this old build as well to see if having the option to disable SSL could make a difference.Setup, just for review:
Citadel 917 installed from easy-install on Centos 7.4, both firewalld and selinux disabled
Server's ip: 10.0.1.5
Testing user: user123
Pidgin clients running on Windows 10
So, summarizing again what I tried and what I got:
--Use old style SSL, either with port 5222 and 5223 (both Pidgin versions):
no certificate error, but Pidgin gets stuck in "Connecting..." forever according to its debug window.
--Export Citadel server's certificate with Firefox, name it after server's hostname (ip address), and manually adding it to Pidgin
--Run "openssl s_client -connect 10.0.1.5:5222 -starttls xmpp" in Centos server, and copying generated cert to Pidgin on Windows (filename is ip address):
I need to correct myself in these 2. It seems last time I had messed up server. It fixed and I could try for real this time.
This time Pidgin accepted the certificate. But now a new problem arouse. I posted Pidgin's 2.12.0 debug window output here https://pastebin.com/Kr2dAr81 .In Pidgin 2.12.0 line 67 "connection: purple_connection_error_reason called with NULL description" was the killer one marked in red.
Log for Pidgin 2.7.3 was virtually the same, except that lines 66 and 67 were not there; killer error was the "Don't know howto do 'set'!".
But the interesting thing is, this "set" error is present in both logs.Just in case I posted in Pidgin forums. To my surprise, they pointed at the "set" error:
"The software you're using is lacking some basic core XMPP stuff in its implementation, namely something like this https://tools.ietf.org/html/rfc6120#page-95 "Think this could be a bug?
Thanks again.
To clarify:
I only tested the old 2.7.3 version of Pidgin in order to temporarily put the SSL variable out of here (i.e., unchecking the option) and see if it made a difference. For some reason it still asked for the SSL certificate, *but* gave the option to accept the "unknown" certificate, which latest version 2.12.0 no longer allows by default.
As I also mentioned, I however managed to sort the SSL thing in latest Pidgin 2.12.0 release.
So in the end, SSL seems to no longer be the issue here, both leading to a different common error:
"Don't know howto do 'set'!"I was also about to try Prosody client, but then I read they discontinued Windows builds, and unfortunately Windows clients are needed here in the place.
By the way, I forgot to mention, I *did do* searches around internet about this "set" error, and found little to no good hits. Then I posted in the Pidgin boards and got that response.