Language:
switch to room list switch to menu My folders
Go to page: First ... 27 28 29 30 [31] 32 33 34 35 36
[#] Thu Oct 26 2017 10:13:17 EDT from IGnatius T Foobar @ Uncensored

Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

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


The code downloadable from the web site, and via Easy Install, has been patched.
It should work with OpenSSL 1.1 now.

Big thanks to Chris West who sent in the required patches. Turns out we already had this fixed in the development tree thanks to his efforts; we just had to backport those patches to production.

[#] Mon Oct 30 2017 06:34:35 EDT from HDuepmann @ Uncensored

Subject: Install ssl-certifikate from CA (Commodo)

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

I have a certificate generated for apache2 (key, crt, ca-bundle) on my Citadel-Server with the proper FQDN. Can I use this files just by renaming them to citadel.key, citadel.cer and citadel.ca-bundle and put them in place instead of the existing files. What is about the csr-file.



[#] Mon Oct 30 2017 13:42:00 EDT from Dedonde @ Uncensored

Subject: Re: Install ssl-certifikate from CA (Commodo)

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

 

Mon Oct 30 2017 06:34:35 EDT from HDuepmann @ Uncensored Subject: Install ssl-certifikate from CA (Commodo)

I have a certificate generated for apache2 (key, crt, ca-bundle) on my Citadel-Server with the proper FQDN. Can I use this files just by renaming them to citadel.key, citadel.cer and citadel.ca-bundle and put them in place instead of the existing files. What is about the csr-file.



Was getting the certificate from Commodo free? I have used startSSL in the past and I am hoping I can use it again and get it working.

How have you dealt withe securing your mail server?



[#] Tue Oct 31 2017 01:50:17 EDT from kinetix @ Uncensored

Subject: Re: Install ssl-certifikate from CA (Commodo)

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

I think there's two sane ways to go about this - use the .key, .csr and .crt files as directed in http://citadel.org/doku.php/faq:systemadmin:how_to_install_a_certificate_signed_by_a_recognized_certificate_authority or use apache to do the SSL and offload that work to apache using proxypass http://citadel.org/doku.php/faq:installation:apacheproxy

With Apache you can do SNI, so you can use multiple SSL setups on a single IP, which may have some benefit to you.



[#] Tue Oct 31 2017 01:56:03 EDT from kinetix @ Uncensored

Subject: Re: Install ssl-certifikate from CA (Commodo)

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

Was getting the certificate from Commodo free? I have used startSSL in the past and I am hoping I can use it again and get it working.

As a public service, I would strongly recommend against using startSSL ever again, browsers aren't trusting them any longer, and for good reason: https://en.wikipedia.org/wiki/StartCom
From what I've seen lately, it's worth your while to setup certbot and use https://letsencrypt.org/ if you want free certificates.  Seems to work very nicely.


[#] Tue Oct 31 2017 04:15:54 EDT from bennabiy @ Uncensored

Subject: Re: Install ssl-certifikate from CA (Commodo)

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

citadel.key and citadel.cer and then dont forget to link webcit to them as well....

Mon Oct 30 2017 06:34:35 AM EDT from HDuepmann @ Uncensored Subject: Install ssl-certifikate from CA (Commodo)

I have a certificate generated for apache2 (key, crt, ca-bundle) on my Citadel-Server with the proper FQDN. Can I use this files just by renaming them to citadel.key, citadel.cer and citadel.ca-bundle and put them in place instead of the existing files. What is about the csr-file.



 



[#] Tue Oct 31 2017 06:50:08 EDT from techacq1 @ Uncensored

Subject: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

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

Accepting that aliases are for the moment stuck,

we still get hung up by the 'preferred display name' not being used when connecting from outside SMTP.

It appears that only WebCit understands how to retrieve the "Preferred Display Name for Email Messages".

 

from serv_smtp.c:

 341 /*
 342  * The configuration item for the user's preferred display name for outgoing email is, unfortunately,
 343  * stored in the account's WebCit configuration.  We have to fetch it now.
 344  */

when sending from Webcit we have a username,

when sending from something like Claws, Outlook, etc  we get the login name (=room name)

the aliases issue seems to have more to it than first appeared.

(Editing the Global Address Book has no effect, just in case someone suggests)

Debian 9.1  here, latest Easy install upgrade (today)

Still looking but not sure where in the logs to go for this vcard ? issue

probably something simple, as usual.



[#] Tue Oct 31 2017 23:39:25 EDT from techacq1Aa @ Uncensored

Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

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

Notes along the way:

Webcit runs as root but citserver runs as a user (citadel or whatever set) but this is apparently not the problem.

I was thinking this may be some systemd issue (having run into systemd permissions issues elsewhere)
but running without using systemD fails the display name as well, so this may not be the issue. Still investigating...

usernames with spaces (yep, this is not windows but I find that a single space is acceptable in login name
and also (as usual) in display names. for an email address this obviously fails,

 but maybe using spaces in the login name could be a problem, checking now.

The plan to "raise the security bar" by using an obfuscation login name with a different email  username is thwarted
by the failure to have a username assigned to emails, which is why this is a definite "want".

And I will continue to dig,
someone else may end up here looking for this problem someday.

cheers for now

 

Tue Oct 31 2017 06:50:08 EDT from techacq1 @ Uncensored Subject: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

Accepting that aliases are for the moment stuck,

we still get hung up by the 'preferred display name' not being used when connecting from outside SMTP.

It appears that only WebCit understands how to retrieve the "Preferred Display Name for Email Messages".

 

from serv_smtp.c:

 341 /*
 342  * The configuration item for the user's preferred display name for outgoing email is, unfortunately,
 343  * stored in the account's WebCit configuration.  We have to fetch it now.
 344  */

when sending from Webcit we have a username,

when sending from something like Claws, Outlook, etc  we get the login name (=room name)

the aliases issue seems to have more to it than first appeared.

(Editing the Global Address Book has no effect, just in case someone suggests)

Debian 9.1  here, latest Easy install upgrade (today)

Still looking but not sure where in the logs to go for this vcard ? issue

probably something simple, as usual.



 



[#] Wed Nov 01 2017 00:11:45 EDT from techacq1Aa @ Uncensored

Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

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

well, what can I say ?

one space is okay for login name but SENDCOMMAND RENU reaalllyy does not like that,
even wrapped in quotes, escaped in backlsahes or whatever

using two adjacent spaces is even more exciting
- I can login with a username of "one two  three" and have no problems inside WEBCIT,

but deleting the user "one two  three" seems to be mission utterly impossible.

we are having fun now ;^)}

 

Tue Oct 31 2017 23:39:25 EDT from techacq1Aa @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

Notes along the way:

Webcit runs as root but citserver runs as a user (citadel or whatever set) but this is apparently not the problem.

I was thinking this may be some systemd issue (having run into systemd permissions issues elsewhere)
but running without using systemD fails the display name as well, so this may not be the issue. Still investigating...

usernames with spaces (yep, this is not windows but I find that a single space is acceptable in login name
and also (as usual) in display names. for an email address this obviously fails,

 but maybe using spaces in the login name could be a problem, checking now.

The plan to "raise the security bar" by using an obfuscation login name with a different email  username is thwarted
by the failure to have a username assigned to emails, which is why this is a definite "want".

And I will continue to dig,
someone else may end up here looking for this problem someday.

cheers for now

 

Tue Oct 31 2017 06:50:08 EDT from techacq1 @ Uncensored Subject: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

Accepting that aliases are for the moment stuck,

we still get hung up by the 'preferred display name' not being used when connecting from outside SMTP.

It appears that only WebCit understands how to retrieve the "Preferred Display Name for Email Messages".

 

from serv_smtp.c:

 341 /*
 342  * The configuration item for the user's preferred display name for outgoing email is, unfortunately,
 343  * stored in the account's WebCit configuration.  We have to fetch it now.
 344  */

when sending from Webcit we have a username,

when sending from something like Claws, Outlook, etc  we get the login name (=room name)

the aliases issue seems to have more to it than first appeared.

(Editing the Global Address Book has no effect, just in case someone suggests)

Debian 9.1  here, latest Easy install upgrade (today)

Still looking but not sure where in the logs to go for this vcard ? issue

probably something simple, as usual.



 



 



[#] Wed Nov 01 2017 02:21:46 EDT from techacq1Aa @ Uncensored

Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

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

learned something new today:

sudo /usr/local/citadel/sendcommand "ASUP someUserNamewhatever|0|0|0|0|0|"

will erase even a username with two consecutive spaces in it, as demonstrated below with a username of "one two  three":

sudo /usr/local/citadel/sendcommand "ASUP one two  three|0|0|0|0|0|"

The key is wrapping the entire ASUP command in quotes so SENDCOMMAND sentds it as a single sentence.

Using webcit aide status does not work at this time for usernames with two consecutive spaces

(adjacents become a single space, which fail the test for deletion - on my particular OS,

so probably not always true )

now back to SEENDCOMMAND IGAB and fixing the Display Name issue....

Wed Nov 01 2017 00:11:45 EDT from techacq1Aa @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

well, what can I say ?

one space is okay for login name but SENDCOMMAND RENU reaalllyy does not like that,
even wrapped in quotes, escaped in backlsahes or whatever

using two adjacent spaces is even more exciting
- I can login with a username of "one two  three" and have no problems inside WEBCIT,

but deleting the user "one two  three" seems to be mission utterly impossible.

we are having fun now ;^)}

 

Tue Oct 31 2017 23:39:25 EDT from techacq1Aa @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

Notes along the way:

Webcit runs as root but citserver runs as a user (citadel or whatever set) but this is apparently not the problem.

I was thinking this may be some systemd issue (having run into systemd permissions issues elsewhere)
but running without using systemD fails the display name as well, so this may not be the issue. Still investigating...

usernames with spaces (yep, this is not windows but I find that a single space is acceptable in login name
and also (as usual) in display names. for an email address this obviously fails,

 but maybe using spaces in the login name could be a problem, checking now.

The plan to "raise the security bar" by using an obfuscation login name with a different email  username is thwarted
by the failure to have a username assigned to emails, which is why this is a definite "want".

And I will continue to dig,
someone else may end up here looking for this problem someday.

cheers for now

 

Tue Oct 31 2017 06:50:08 EDT from techacq1 @ Uncensored Subject: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

Accepting that aliases are for the moment stuck,



 



 



 



[#] Wed Nov 01 2017 11:41:45 EDT from kinetix @ Uncensored

Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

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

Hey there,

Can you describe in a little further detail what exactly is occurring, and where?  What are you trying to do and/or what are the expected results, and what are you experiencing instead?

From what I understand from your report, you're not able to set the From: email header the way that you'd like - is that the issue?  I just ran a test through a citadel installation of mine, using Thunderbird (though it shouldn't make a difference), and delivering through the MSA port, the From shows the name I configured in Thunderbird.

Perhaps that's not quite what you're having issues with, though?

 

Tue Oct 31 2017 06:50:08 EDT from techacq1 @ Uncensored Subject: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

when sending from Webcit we have a username,

when sending from something like Claws, Outlook, etc  we get the login name (=room name)

the aliases issue seems to have more to it than first appeared.

(Editing the Global Address Book has no effect, just in case someone suggests)

Debian 9.1  here, latest Easy install upgrade (today)

Still looking but not sure where in the logs to go for this vcard ? issue

probably something simple, as usual.



 



[#] Wed Nov 01 2017 12:57:58 EDT from techacq1Aa @ Uncensored

Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

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

Hi Kinetix,

Thanks for the interest -

yes what you describe is exactly what I am working against.

I expect I have probably mangled something in the install or later, but not quite sure where it went off the rails.

The OS is the atest Solydx which is a very close Debian descendan, but there are variations to be sure.

 

There are a number of issues and I suspect they all arise from common mismatches.

The MTA and MSA ports both work well, using SSL everything is tight and works mostly,
except for the Preferred Display Name.

(Looking at your use of Thunderbird, I will give that a try tomorrow,

but our staff are allergic to anything that does not involve MicroSoft, sadly.)

 

The result is that the desired username is replaced with the login name.

This is a disappointment in that I am trying to provide login names very different from email addresses and preferred names.

For example:

 

1.
for Bob@somecitamail.com

2.
he might want his emails show the  attribution  "Mr. Robert Payswell"

3.
and I give him a login username of  "FaBd51bB"  alongside an encouragement to use a real passphrase

 

but this all is pointless  if everyone receives emails from:    "FaBd51bB" <Bob@somecitamail.com>

instead of "Mr. Robert Payswell" <Bob@somecitamail.com>

 

Using something beside "Bob" as the login username is a big reason for all this,

 I seem to be swimming in an ocean of people who insist on email names like "Mary@" "Bob@" "Tom@" and "Joe@"

with passwords like 123456 or 77777777 and unable to fathom logins longer than 6 letters long.

But we must try....

 

 

cheers

 

 

Wed Nov 01 2017 11:41:45 EDT from kinetix @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

Hey there,

Can you describe in a little further detail what exactly is occurring, and where?  What are you trying to do and/or what are the expected results, and what are you experiencing instead?

From what I understand from your report, you're not able to set the From: email header the way that you'd like - is that the issue?  I just ran a test through a citadel installation of mine, using Thunderbird (though it shouldn't make a difference), and delivering through the MSA port, the From shows the name I configured in Thunderbird.

Perhaps that's not quite what you're having issues with, though?

 

Tue Oct 31 2017 06:50:08 EDT from techacq1 @ Uncensored Subject: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

when sending from Webcit we have a username,

when sending from something like Claws, Outlook, etc  we get the login name (=room name)

the aliases issue seems to have more to it than first appeared.

(Editing the Global Address Book has no effect, just in case someone suggests)

Debian 9.1  here, latest Easy install upgrade (today)

Still looking but not sure where in the logs to go for this vcard ? issue

probably something simple, as usual.



 



 



[#] Wed Nov 01 2017 14:26:29 EDT from movian @ Uncensored

Subject: Citadel e-mail - Catch All

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

Hey, Is there a setting or option to set a user account to be a catch all address?

 

if you had a user named user   and domain  example.org

 

and they had their e-mail setup (user@example.org)  but if someone sends mail to   test@example.org   I want it to be placed in user's inbox.... is there an option for that ?



[#] Wed Nov 01 2017 14:42:53 EDT from movian @ Uncensored

Subject: Re: Citadel e-mail - Catch All

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

Never mind found out citadel doesn't support it 
http://www.citadel.org/doku.php/faq:everydayuse:catchall



[#] Wed Nov 01 2017 15:50:13 EDT from judgeraid @ Uncensored

Subject: Can't do the first admin login to citadel

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

Hello,

I can't log into citadel with admin user on a raspberry pi3b.

I've got :

S'il vous plaît, patientez pendant...

-> It means Please waiting during loading ... but nothing was loaded :-(

Here's the /var/log/mail.log :


Nov  1 20:24:58 pi3 citserver[27752]: Session (citadel-TCP) started from 192.168.0.9 (192.168.0.9).
Nov  1 20:24:58 pi3 citserver[27752]: W Context: <admincitadel> logged in
Nov  1 20:24:58 pi3 citserver[27757]:
Nov  1 20:24:58 pi3 citserver[27757]:
Nov  1 20:24:58 pi3 citserver[27757]: *** Citadel server engine ***
Nov  1 20:24:58 pi3 citserver[27757]: Version 902 (build 1a4ec92) ***
Nov  1 20:24:58 pi3 citserver[27757]: Copyright (C) 1987-2016 by the Citadel development team.
Nov  1 20:24:58 pi3 citserver[27757]: This program is distributed under the terms of the GNU General Public License.
Nov  1 20:24:58 pi3 citserver[27757]:
Nov  1 20:24:58 pi3 citserver[27757]: Called as: /usr/sbin/citserver
Nov  1 20:24:58 pi3 citserver[27757]: libcitadel(unnumbered)
Nov  1 20:24:58 pi3 citserver[27757]: master_startup() started
Nov  1 20:24:58 pi3 citserver[27757]: Checking directory access
Nov  1 20:24:58 pi3 citserver[27757]: Opening databases
Nov  1 20:24:58 pi3 citserver[27757]: bdb(): open_databases() starting
Nov  1 20:24:58 pi3 citserver[27757]: Compiled db: Berkeley DB 5.3.28: (September  9, 2013)
Nov  1 20:24:58 pi3 citserver[27757]:   Linked db: Berkeley DB 5.3.28: (September  9, 2013)
Nov  1 20:24:58 pi3 citserver[27757]: Linked zlib: 1.2.8
Nov  1 20:24:58 pi3 citserver[27757]: bdb(): Setting up DB environment
Nov  1 20:24:58 pi3 citserver[27757]: dbenv->open(dbenv, /var/lib/citadel/data/, 75043, 0)
Nov  1 20:24:58 pi3 citserver[27757]: DB: BDB2526 Finding last valid log LSN: file: 9 offset 5333699
Nov  1 20:24:58 pi3 citserver[27757]: DB: BDB1514 Recovery starting from [9][5327211]
Nov  1 20:24:58 pi3 citserver[27757]: DB: BDB1518 Recovery complete at Wed Nov  1 20:24:58 2017
Nov  1 20:24:58 pi3 citserver[27757]: DB: BDB1519 Maximum transaction ID 8000002d recovery checkpoint [9][5334861]
Nov  1 20:24:58 pi3 citserver[27757]: Starting up DB
Nov  1 20:24:58 pi3 citserver[27757]: Initializing configuration system
Nov  1 20:24:58 pi3 citserver[27757]: Checking floor reference counts
Nov  1 20:24:59 pi3 citserver[27757]: Floor 0: 18 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 1: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 2: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 3: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 4: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 5: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 6: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 7: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 8: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 9: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 10: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 11: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 12: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 13: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 14: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Floor 15: 0 rooms
Nov  1 20:24:59 pi3 citserver[27757]: Creating base rooms (if necessary)
Nov  1 20:24:59 pi3 citserver[27757]: Seeding the pseudo-random number generator...
Nov  1 20:24:59 pi3 citserver[27757]: master_startup() finished
Nov  1 20:24:59 pi3 citserver[27757]: Sanity checking the recorded highest message, user, and room numbers
Nov  1 20:24:59 pi3 citserver[27757]: Upgrading modules.
Nov  1 20:24:59 pi3 citserver[27757]: (null) Modules: Upgrade modules.
Nov  1 20:24:59 pi3 citserver[27757]: Existing database version on disk is 902
Nov  1 20:24:59 pi3 citserver[27757]: (null) Modules: upgrade
Nov  1 20:24:59 pi3 citserver[27757]: (null) Modules: Unix domain socket '/var/run/citadel/citadel.socket': registered.
Nov  1 20:24:59 pi3 citserver[27757]: (null) Modules: Unix domain socket '/var/run/citadel/citadel-admin.socket': registered.
Nov  1 20:24:59 pi3 citserver[27757]: (null) Modules: TCP port 192.168.0.9:50504: (citadel-TCP) registered.
Nov  1 20:24:59 pi3 citserver[27757]: Initializing server extensions
Nov  1 20:24:59 pi3 citserver[27757]: (null) Modules: Initializing. CtdlThreads not yet enabled.
Nov  1 20:24:59 pi3 citserver[27757]: Importing old style bio files into the message base
Nov  1 20:24:59 pi3 citserver[27757]: Importing old style userpic files into the message base
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: TCP port 192.168.0.9:143: (IMAP) registered.
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: TCP port 192.168.0.9:993: (IMAPS) registered.
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: TCP port 192.168.0.9:2020: (ManageSieve) registered.
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: TCP port 192.168.0.9:119: (NNTP) registered.
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: TCP port 192.168.0.9:563: (NNTPS) registered.
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: TCP port 192.168.0.9:110: (POP3) registered.
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: TCP port 192.168.0.9:995: (POP3S) registered.
Nov  1 20:24:59 pi3 citserver[27757]: libcurl/7.52.1 OpenSSL/1.0.2l zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Nov  1 20:24:59 pi3 citserver[27757]: Sieve: libSieve is written and maintained by Aaron Stone with ...
Nov  1 20:24:59 pi3 citserver[27757]: Sieve: Extensions: regex imap4flags relational fileinto reject envelope vacation
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: TCP port 192.168.0.9:25: (SMTP-MTA) registered.
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: TCP port 192.168.0.9:465: (SMTPs-MTA) registered.
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: TCP port 192.168.0.9:587: (SMTP-MSA) registered.
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: Unix domain socket '/var/run/citadel/lmtp.socket': registered.
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: Unix domain socket '/var/run/citadel/lmtp-unfiltered.socket': registered.
Nov  1 20:24:59 pi3 citserver[27757]: Cannot create /etc/citadel/netconfigs/7: No such file or directory
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: Service DICT_TCP has been manually disabled, skipping
Nov  1 20:24:59 pi3 citserver[27757]: WX Modules: TCP port 192.168.0.9:5222: (XMPP) registered.
Nov  1 20:24:59 pi3 citserver[27757]: Posting crash message
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//refcount_adjustments.dat, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//refcount_adjustments.dat, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.0b, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.0b, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.05, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.05, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.0c, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.0c, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.04, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.04, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.0a, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.0a, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.00, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.00, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.0d, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.0d, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.03, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.03, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.09, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.09, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//log.0000000009, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//log.0000000009, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.02, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.02, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.06, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.06, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.01, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.01, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.08, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.08, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chmod(/var/lib/citadel/data//cdb.07, 0600) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: chown(/var/lib/citadel/data//cdb.07, CTDLUID, -1) returned 0
Nov  1 20:24:59 pi3 citserver[27757]: open_databases() finished
Nov  1 20:24:59 pi3 citserver[27757]: Changing uid to 116
Nov  1 20:24:59 pi3 citserver[27757]: libcurl/7.52.1 OpenSSL/1.0.2l zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Nov  1 20:25:09 pi3 citserver[27757]: New client socket 40
Nov  1 20:25:09 pi3 citserver[27757]: Session (citadel-TCP) started from 192.168.0.9 (192.168.0.9).
Nov  1 20:40:11 pi3 citserver[27757]: W CC[1]: Citadel client disconnected: ending session.
Nov  1 20:40:11 pi3 citserver[27757]: W Context: [  1]SRV[citadel-TCP] Session ended.

 

I tried to create /etc/citadel/netconfigs but when i restarted the citadel service, the directory was automatically deteled.

Have you any suggestion to solve the issue ?

Thanks in advance,

Judgeraid

 

 



[#] Wed Nov 01 2017 16:52:24 EDT from kinetix @ Uncensored

Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

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

This seems interesting as it sounds like there may be a couple of ways to deal with things overall - and I don't use LDAP anywhere so I think there could be further solutions available if it were used, but I'll go with the plain-Jane stuff I'm used to:

First, in a useful email client, the person's real name, email address, and IMAP/SMTP user/pass credentials should all be separate entities.  If you're setting up users with awful usernames such as a1b2c3blah, which by default turn in to an ugly email address, and are then assigning email aliases to each user, then there shouldn't be anything in the way of setting the wanted display name in Webcit and in the email client.  ie: No reason why user a1b2c3blah can't have their email client configured with Real Name "Bob Smith" and an email address presented in the from: line (to go with the real name) of bob.smith@citaserver.com, all while the client uses username "a1b2c3blah" and their password to login to IMAP/SMTP to receive/deliver email.

The other thing you might consider, which we do in the company I work for, is set usernames to "first.last", and I don't think we've had a conflict there yet.  If you do that, then a new account for Bob Smith would have the bob.smith username, and by default their email address would be bob.smith@citaserver.com, which could go a long way to reducing the number of confusions for the users, and cut down on the number of different pieces of information one needs to maintain per user.

My example of Thunderbird is just one of the email clients I use myself that handles credential separation from From line generation appropriately - same things apply to KMail and K-9 Mail on Android, and I don't recall the last time I saw an email client that couldn't separate server credentials from an email address.

 

 

Wed Nov 01 2017 12:57:58 EDTfrom techacq1Aa @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

Hi Kinetix,

Thanks for the interest -

yes what you describe is exactly what I am working against.

I expect I have probably mangled something in the install or later, but not quite sure where it went off the rails.

The OS is the atest Solydx which is a very close Debian descendan, but there are variations to be sure.

There are a number of issues and I suspect they all arise from common mismatches.

The MTA and MSA ports both work well, using SSL everything is tight and works mostly,
except for the Preferred Display Name.

(Looking at your use of Thunderbird, I will give that a try tomorrow,

but our staff are allergic to anything that does not involve MicroSoft, sadly.)

The result is that the desired username is replaced with the login name.

This is a disappointment in that I am trying to provide login names very different from email addresses and preferred names.

For example:

1.
for Bob@somecitamail.com

2.
he might want his emails show the  attribution  "Mr. Robert Payswell"

3.
and I give him a login username of  "FaBd51bB"  alongside an encouragement to use a real passphrase

but this all is pointless  if everyone receives emails from:    "FaBd51bB" <Bob@somecitamail.com>

instead of "Mr. Robert Payswell" <Bob@somecitamail.com>

Using something beside "Bob" as the login username is a big reason for all this,

 I seem to be swimming in an ocean of people who insist on email names like "Mary@" "Bob@" "Tom@" and "Joe@"

with passwords like 123456 or 77777777 and unable to fathom logins longer than 6 letters long.

But we must try....

cheers





 



[#] Thu Nov 02 2017 00:37:24 EDT from techacq1Aa @ Uncensored

Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

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

Hi, I will keep on at this until I find out what the issue is.

Noting your mention LDAP,
but I will stick with the defaults for various reasons, mostly for whoever picks up after I depart.

 

The issue with using an awful login-name is to not be giving away the login credentials with every email:

An email from "Sue" <sue@ritchWidowPleaseHackMeRightnow.com>
using her very publicized login-name of "Sue" and a "123456" password is stuff of legend.

Watching "Jason" use his VPNvanishIP from the Ukraine/Romania/Turkey/HK/wherever
having a go at my servers with his dictionary attack is amusing,
but a long vacation is all he needs to finally guess a password "Sue" has enlightened the server with.
(He has been trying for almost a year now, even long after "Sue" has been erased from the system.)

She can rest a bit easier with an 'awful' login-name
as long as citadel never publicizes the login-name and always
inserts either her citadel Preferred Display Name in or uses her email client preferences.

Fail2ban, TLS and all the other security measures need all the help they can get, and a login name that is not publicized helps a lot.


What seems to be happening is that my easy-install of citadel ignores everything and only uses the login username as the "signatory user".

It simply ignores everything and just uses the login-name and even wants to default that as the Primary email address.

Only AIDE can fix that, which I am guessing is a security feature for Citadels open to public use.

For small private clubs this may not be necessarily desirable.

 

There seem to be permission issues everywhere I look, so I am in the process now of creating a new machine using

the original clean true Debian 9.1 straight from Debian instead of the derivative versions I have been using - maybe I had some bad configs loose.

I will definitely post if I get progress, otherwise I will shift to yet another OS
(Ubuntu ? I have a Sabayon image cooking but it is not yet ready for citadel)
and see if I can find some diffs to examine.

 

cheers for now, more news later

 

 

Wed Nov 01 2017 16:52:24 EDT from kinetix @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

This seems interesting as it sounds like there may be a couple of ways to deal with things overall - and I don't use LDAP anywhere so I think there could be further solutions available if it were used, but I'll go with the plain-Jane stuff I'm used to:

First, in a useful email client, the person's real name, email address, and IMAP/SMTP user/pass credentials should all be separate entities.  If you're setting up users with awful usernames such as a1b2c3blah, which by default turn in to an ugly email address, and are then assigning email aliases to each user, then there shouldn't be anything in the way of setting the wanted display name in Webcit and in the email client.  ie: No reason why user a1b2c3blah can't have their email client configured with Real Name "Bob Smith" and an email address presented in the from: line (to go with the real name) of bob.smith@citaserver.com, all while the client uses username "a1b2c3blah" and their password to login to IMAP/SMTP to receive/deliver email.

The other thing you might consider, which we do in the company I work for, is set usernames to "first.last", and I don't think we've had a conflict there yet.  If you do that, then a new account for Bob Smith would have the bob.smith username, and by default their email address would be bob.smith@citaserver.com, which could go a long way to reducing the number of confusions for the users, and cut down on the number of different pieces of information one needs to maintain per user.

My example of Thunderbird is just one of the email clients I use myself that handles credential separation from From line generation appropriately - same things apply to KMail and K-9 Mail on Android, and I don't recall the last time I saw an email client that couldn't separate server credentials from an email address.

 

 


 


 



 



[#] Thu Nov 02 2017 04:33:09 EDT from techacq1Aa @ Uncensored

Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

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

With a squeaky clean slate fresh install of Debian Debian 9.1 xfce

 rebooted with no apparent errors

the first inkling their may be unseen menace is the absence of a 'panel',

easily restored with the settings ->panel
but a curt message explains editing it is a no-no, we are in kiosk mode ( WTF - over ?!?)

it edits just fine, so this unpleasant bit is shelved for future reference.

the first thing we encounter after successfully updating to all correct prerequisites

apt-get update
apt-get install build-essential curl g++ gettext shared-mime-info libssl-dev zlib1g-dev

 

is running the easy-install with zero complaints or indications

until

Setup could not connect to a running server.: No such file

or directory /usr/local/citadel/citadel-admin.socket

ordinarily I would just steamroller some silly thing like this,

but this suggests other less obvious problems yet to come.

<deleted expletives>

There is a single running instance of citserver, but no socket (as the message says) in /usr/local/citadel

This is all done as root

I am convinced something in Debian has quietly died

 

 

 

 

 

Thu Nov 02 2017 00:37:24 EDT from techacq1Aa @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

Hi, I will keep on at this until I find out what the issue is.

Noting your mention LDAP,
but I will stick with the defaults for various reasons, mostly for whoever picks up after I depart.

 

The issue with using an awful login-name is to not be giving away the login credentials with every email:

An email from "Sue" <sue@ritchWidowPleaseHackMeRightnow.com>
using her very publicized login-name of "Sue" and a "123456" password is stuff of legend.

Watching "Jason" use his VPNvanishIP from the Ukraine/Romania/Turkey/HK/wherever
having a go at my servers with his dictionary attack is amusing,
but a long vacation is all he needs to finally guess a password "Sue" has enlightened the server with.
(He has been trying for almost a year now, even long after "Sue" has been erased from the system.)

She can rest a bit easier with an 'awful' login-name
as long as citadel never publicizes the login-name and always
inserts either her citadel Preferred Display Name in or uses her email client preferences.

Fail2ban, TLS and all the other security measures need all the help they can get, and a login name that is not publicized helps a lot.


What seems to be happening is that my easy-install of citadel ignores everything and only uses the login username as the "signatory user".

It simply ignores everything and just uses the login-name and even wants to default that as the Primary email address.

Only AIDE can fix that, which I am guessing is a security feature for Citadels open to public use.

For small private clubs this may not be necessarily desirable.

 

There seem to be permission issues everywhere I look, so I am in the process now of creating a new machine using

the original clean true Debian 9.1 straight from Debian instead of the derivative versions I have been using - maybe I had some bad configs loose.

I will definitely post if I get progress, otherwise I will shift to yet another OS
(Ubuntu ? I have a Sabayon image cooking but it is not yet ready for citadel)
and see if I can find some diffs to examine.

 

cheers for now, more news later

 

 

Wed Nov 01 2017 16:52:24 EDT from kinetix @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

This seems interesting as it sounds like there may be a couple of ways to deal with things overall - and I don't use LDAP anywhere so I think there could be further solutions available if it were used, but I'll go with the plain-Jane stuff I'm used to:

First, in a useful email client, the person's real name, email address, and IMAP/SMTP user/pass credentials should all be separate entities.  If you're setting up users with awful usernames such as a1b2c3blah, which by default turn in to an ugly email address, and are then assigning email aliases to each user, then there shouldn't be anything in the way of setting the wanted display name in Webcit and in the email client.  ie: No reason why user a1b2c3blah can't have their email client configured with Real Name "Bob Smith" and an email address presented in the from: line (to go with the real name) of bob.smith@citaserver.com, all while the client uses username "a1b2c3blah" and their password to login to IMAP/SMTP to receive/deliver email.

The other thing you might consider, which we do in the company I work for, is set usernames to "first.last", and I don't think we've had a conflict there yet.  If you do that, then a new account for Bob Smith would have the bob.smith username, and by default their email address would be bob.smith@citaserver.com, which could go a long way to reducing the number of confusions for the users, and cut down on the number of different pieces of information one needs to maintain per user.

My example of Thunderbird is just one of the email clients I use myself that handles credential separation from From line generation appropriately - same things apply to KMail and K-9 Mail on Android, and I don't recall the last time I saw an email client that couldn't separate server credentials from an email address.

 

 


 


 



 



 



[#] Thu Nov 02 2017 14:04:54 EDT from kinetix @ Uncensored

Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

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

I have just run a test of easyinstall on a fresh debian stretch install and am seeing exactly what you're seeing.  Will post another message here with my findings for the citadel team.

 

Thu Nov 02 2017 04:33:09 EDTfrom techacq1Aa @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

 

is running the easy-install with zero complaints or indications

until

Setup could not connect to a running server.: No such file

or directory /usr/local/citadel/citadel-admin.socket

ordinarily I would just steamroller some silly thing like this,

but this suggests other less obvious problems yet to come.

<deleted expletives>

There is a single running instance of citserver, but no socket (as the message says) in /usr/local/citadel

This is all done as root

I am convinced something in Debian has quietly died



[#] Thu Nov 02 2017 14:23:46 EDT from kinetix @ Uncensored

Subject: easyinstall creating a crashing citadel on debian stretch

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

Hi all,

I've just done a test easyinstall of citadel on a fresh debian stretch VM.  The pre-reqs were installed and easyinstall seemed to have no issue going through it's paces getting everything in place.  It does complain at the end of the citadel.socket not being in place, and it looks like citserver goes in to a boot loop, recycling itself over and over and getting nowhere.

The logs look like this:

Nov  2 09:54:12 testdebian citserver[487]: 

Nov  2 09:54:12 testdebian citserver[487]: 

Nov  2 09:54:12 testdebian citserver[487]: *** Citadel server engine ***

Nov  2 09:54:12 testdebian citserver[487]: Version 911 (build 3f857d7) ***

Nov  2 09:54:12 testdebian citserver[487]: Copyright (C) 1987-2017 by the Citadel development team.

Nov  2 09:54:12 testdebian citserver[487]: This program is distributed under the terms of the GNU General Public License.

Nov  2 09:54:12 testdebian citserver[487]: 

Nov  2 09:54:12 testdebian citserver[487]: libcitadel(unnumbered)

Nov  2 09:54:12 testdebian citserver[487]: main: creating lockfile

Nov  2 09:54:12 testdebian citserver[487]: Generating RSA key pair.

Nov  2 09:54:12 testdebian citserver[487]: Generating a generic certificate signing request.

Nov  2 09:54:12 testdebian citserver[487]: Generating a generic self-signed certificate.

Nov  2 09:54:12 testdebian citserver[487]: extensions: registered server command STLS (Start SSL/TLS session)

Nov  2 09:54:12 testdebian citserver[487]: extensions: registered server command GTLS (Get SSL/TLS session status)

Nov  2 09:54:12 testdebian citserver[487]: extensions: registered a new session function (type 0 Priority 30010)

Nov  2 09:54:12 testdebian citserver[487]: master_startup() started

Nov  2 09:54:12 testdebian citserver[487]: Checking directory access

Nov  2 09:54:12 testdebian citserver[487]: Opening databases

Nov  2 09:54:12 testdebian citserver[487]: db: open_databases() starting

Nov  2 09:54:12 testdebian citserver[487]: db: Compiled libdb: Berkeley DB 6.2.32: (April  5, 2017)

Nov  2 09:54:12 testdebian citserver[487]: db:   Linked libdb: Berkeley DB 6.2.32: (April  5, 2017)

Nov  2 09:54:12 testdebian citserver[487]: db:    Linked zlib: 1.2.8

Nov  2 09:54:12 testdebian citserver[487]: db: Setting up DB environment

Nov  2 09:54:12 testdebian citserver[487]: db: dbenv->open(dbenv, /usr/local/citadel/data/, 75043, 0)

Nov  2 09:54:12 testdebian citserver[487]: db: mounting databases

Nov  2 09:54:12 testdebian citserver[487]: Initializing configuration system

Nov  2 09:54:12 testdebian citserver[488]: 

Nov  2 09:54:12 testdebian citserver[488]: 

Nov  2 09:54:12 testdebian citserver[488]: *** Citadel server engine ***

Nov  2 09:54:12 testdebian citserver[488]: Version 911 (build 3f857d7) ***

Running an strace on it concludes with:
 
stat("/usr/local/citadel/data/cdb.0d", {st_mode=S_IFREG|0600, st_size=8192, ...}) = 0
open("/usr/local/citadel/data/cdb.0d", O_RDWR|O_CREAT, 000) = 18
fcntl(18, F_GETFD)                      = 0
fcntl(18, F_SETFD, FD_CLOEXEC)          = 0
fstat(18, {st_mode=S_IFREG|0600, st_size=8192, ...}) = 0
getpid()                                = 20256
writev(2, [{iov_base="citserver[20256]: Initializing c"..., iov_len=51}, {iov_base="\n", iov_len=1}], 2citserver[20256]: I
nitializing configuration system
) = 52
sendto(3, "<30>Nov  2 11:15:04 citserver[20"..., 71, MSG_NOSIGNAL, NULL, 0) = 71
chdir("/usr/local/citadel/")            = 0
open("/usr/local/citadel/citadel.config", O_RDONLY) = -1 ENOENT (No such file or directory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x100000154} ---
+++ killed by SIGSEGV +++

I've attached the full strace if it helps.



strace-out.txt (text/plain, 419432 bytes) [View| Download]
Go to page: First ... 27 28 29 30 [31] 32 33 34 35 36