Language:
switch to room list switch to menu My folders
Go to page: First ... 28 29 30 31 [32] 33 34 35
[#] 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]
[#] Thu Nov 02 2017 20:47:49 EDT from techacq1Aa @ Uncensored

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

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

This all has an acrid stench reminiscent of some kind of POLKIT chicanery.

I am away from the machines I have testing this on
but when I get back to them I will be looking at this possibility.

 

 

Thu Nov 02 2017 14:04:54 EDT from kinetix @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

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



 



[#] Fri Nov 03 2017 02:13:41 EDT from techacq1Aa @ Uncensored

Subject: Re: easyinstall creating a crashing citadel on debian stretch

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

 

This does not happen with an xubuntu image I tried last night (easy install worked well, mostly...),
so this problem definitely belong Debian

looks like the first run by citserver dives into an infinity loop,
(so it never arrives at creating the socket ?):

 

 

Nov  2 18:59:08 debian9.1xfceVirgin citserver[26324]: db: Compiled libdb: Berkeley DB 6.2.32: (April  5, 2017)
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26324]: db:   Linked libdb: Berkeley DB 6.2.32: (April  5, 2017)
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26324]: db:    Linked zlib: 1.2.8
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26324]: db: Setting up DB environment
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26324]: db: dbenv->open(dbenv, /usr/local/citadel/data/, 75043, 0)
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26324]: db: mounting databases
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26324]: Initializing configuration system
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]:
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]:
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: *** Citadel server engine ***
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: Version 911 (build 3f857d7) ***
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: Copyright (C) 1987-2017 by the Citadel development team.
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: This program is distributed under the terms of the GNU General Public License.
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]:
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: libcitadel(unnumbered)
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: main: creating lockfile
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: extensions: registered server command STLS (Start SSL/TLS session)
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: extensions: registered server command GTLS (Get SSL/TLS session status)
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: extensions: registered a new session function (type 0 Priority 30010)
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: master_startup() started
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: Checking directory access
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: Opening databases
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: db: open_databases() starting
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: db: Compiled libdb: Berkeley DB 6.2.32: (April  5, 2017)
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: db:   Linked libdb: Berkeley DB 6.2.32: (April  5, 2017)
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: db:    Linked zlib: 1.2.8
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: db: Setting up DB environment
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: db: dbenv->open(dbenv, /usr/local/citadel/data/, 75043, 0)
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: db: mounting databases
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26325]: Initializing configuration system
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26326]:
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26326]:
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26326]: *** Citadel server engine ***
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26326]: Version 911 (build 3f857d7) ***
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26326]: Copyright (C) 1987-2017 by the Citadel development team.
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26326]: This program is distributed under the terms of the GNU General Public License.
Nov  2 18:59:08 debian9.1xfceVirgin citserver[26326]:

 

Thu Nov 02 2017 14:23:46 EDT from kinetix @ Uncensored Subject: easyinstall creating a crashing citadel on debian stretch

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.



(, 0 bytes) [View| Download]

 



strace-out.txt (text/plain, 419432 bytes) [View| Download]
[#] Fri Nov 03 2017 05:14:43 EDT from techacq1Aa @ Uncensored

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

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

The temporary solution to the initial problem:

getting Login-Names to not be publicized in the Username/DisplayName/emailaddress space

 

Private and not handed around like a business card

Login-Name         "Fetish King of Transylvania"

Password             "543210"

Public and visible to anyone who reads the headers

User-Name          "Bob"

Email address      "bob@sumcitserver.org"

Display-Name      "Sir Robert I. Payswell, Phd"

 

 

is to set in

ADMINISTRATION ->

-> EDIT SITE-WIDE SETTINGS ->

-> "Correct forged From: lines during authenticated SMTP"->

* No, allow any address in the From: header

 

This is spooky, but it does seem to work for the lastest Easy-Instal in my older version of SolydX

Guessing here,
but apparently when you set to "allow any"
then the culprit code rewriting the Display Name ceases overwriting anything.

Just a quick hack for the moment,
in memorial to Brian who was a minimalist until the very end..

 

 

Cheers ->  I will keep digging to see if I can come up with a less permissive solution.

 

 

 

Thu Nov 02 2017 20:47:49 EDT from techacq1Aa @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

This all has an acrid stench reminiscent of some kind of POLKIT chicanery.

I am away from the machines I have testing this on
but when I get back to them I will be looking at this possibility.

 

 

Thu Nov 02 2017 14:04:54 EDT from kinetix @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

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



 



 



[#] Fri Nov 03 2017 17:19:17 EDT from kinetix @ Uncensored

Subject: Re: easyinstall creating a crashing citadel on debian stretch

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

I wanted to note a couple of things I saw today with further testing:

- When using the debian -dev packages for libdb, libical, libsieve2, libexpat1, libcurl4 and libssl and compiling by hand from citadel-easyinstall.tar.gz, I initially had compile errors until I noticed that libical in debian stretch is at version 2.  After removing and replacing that with the libical from easyinstall, citadel compiled fine again.

- Citadel built around the system dev packages and the easyinstall libical, citadel starts fine and doesn't exhibit the crash issue.

I am going to rebuild citadel from the easyinstall script and see which libraries it's linked to.



strace-out.txt (text/plain, 419432 bytes) [View| Download]