Language:
switch to room list switch to menu My folders
Go to page: First ... 42 43 44 45 [46]
[#] Fri Jul 17 2015 09:45:48 EDT from CarlGambolputty @ Uncensored

Subject: Re: Remote Retrieval of POP3 from pop.gmail.com:995

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

Update: Maybe I'm missing something Bart, but there isn't any /etc/defaults directory. There is an /etc/default directory (as expected) w/o any name citadel directory or file.

 

sudo find / -iname citadel returns:

/var/lib/citadel

/var/spool/citadel

/usr/bin/citadel

/run/citadel

/etc/ssl/citadel

/etc/init.d/citadel     <- as said, I already modified this file to run verbose logging for pop3client

/etc/citadel

 

These are all the files I have in var/log:

 

alternatives.log    apport.log.3.gz  auth.log.3.gz  dist-upgrade  fsck           kern.log.3.gz  mail.err.1     mail.log.1     samba        syslog.3.gz  unattended-upgrades

alternatives.log.1  apt              auth.log.4.gz  dmesg         installer      kern.log.4.gz  mail.err.2.gz  mail.log.2.gz  stunnel4     syslog.4.gz  webcit

apport.log          auth.log         bootstrap.log  dpkg.log      kern.log       landscape      mail.err.3.gz  mail.log.3.gz  syslog       syslog.5.gz  wtmp

apport.log.1        auth.log.1       btmp           dpkg.log.1    kern.log.1     lastlog        mail.err.4.gz  mail.log.4.gz  syslog.1     syslog.6.gz  wtmp.1

apport.log.2.gz     auth.log.2.gz    btmp.1         faillog       kern.log.2.gz  mail.err       mail.log       ntpstats       syslog.2.gz  syslog.7.gz

 
All information in mail.log, mail.err is mirrored in syslog, as expected.
 
Webcit dir has no logs in it. Stunnel dir has one file, stunnel.log, which is empty, as expected. None of the other log files pertain to citadel, webcit or stunnel4.
 
Checking syslog shows that citadel has been dutifully checking email overnight on its usual internal. Still hasn't pulled anything, despite both email accounts getting several additional emails overnight. 
 
Please let me know what I might be missing.
 
 
 
 


[#] Fri Jul 17 2015 10:51:58 EDT from dothebart @ Uncensored

Subject: Re: Remote Retrieval of POP3 from pop.gmail.com:995

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

You should be fine with the environment variable. you should be able to verify the checkmarks in webcit whether it worked out after a restart.

the imap is abouth the imap server - that would be your imap client talking to citadel.



[#] Fri Jul 17 2015 12:38:28 EDT from CarlGambolputty @ Uncensored

Subject: Re: Remote Retrieval of POP3 from pop.gmail.com:995

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

 

Fri Jul 17 2015 10:51:58 EDT from dothebart @ Uncensored Subject: Re: Remote Retrieval of POP3 from pop.gmail.com:995

You should be fine with the environment variable. you should be able to verify the checkmarks in webcit whether it worked out after a restart.

 

Interesting. I checked out the webcit page as an aide, went into Administration-Enable/Disable Logging of Server Components and looked down the list, and found that nothing is checkmarked. This is after re-confirming the init.d/citadel logging changes, and restarting both citadel and webcit. 

This is the gobal environment variable section of my /etc/init.d/citadel file; the only thing I changed was the CITADEL_LOGDEBUG line:

RUNDIR=/var/run/citadel

PATH=/sbin:/usr/sbin:/bin:/usr/bin

DESC="Citadel Groupware "

NAME=citserver

DAEMON=/usr/sbin/$NAME

PIDFILE=$RUNDIR/citadel.pid

DAEMON_ARGS=" -d -x3 -lmail -t/dev/null"

SCRIPTNAME=/etc/init.d/citadel

SENDCOMMAND=/usr/sbin/sendcommand

CITADEL_LOGDEBUG=pop3client,imapsrv

Curious to see if I could just go it manually in webcit, I set debugging under the same menu for pop3client and logged myself out/in and verified that it stuck. (because paranoid by this point). I then went back in to syslog to look at the output. Despite having CITADEL_LOGDEBUG set, via setting logging in webcit there is indeed quite alot more stuff; it looks like Citadel logs in this mode every telnet command it makes.
 
I went through the commands and found that Citadel was successfully logging into each email account I was giving it, issuing the right user/pass, and retrieving a list of mail via telnet. It then went through each mail to get its unique UIDL. Then it ends the session without pulling any of the messages. At no point can I see any error issued from either Citadel, stunnel or the email client through telnet. At the end of teach telnet session, I see the two folloiwng lines:
 
IO[10][11]POP3: POP3: POP3_C_ReAttachToFetchMessages
IO[12]CC[13][9]POP3: IO[12]CC[13][9]POP3: > QUIT#015#0123)
 
I'm *guessing* that the first line is a reference to Citadel saving all recorded UDIL's to a table for later use in weeding out non-new mail. (If you want the whole log snippet, let me know and I can send it to you; it's obviously too big to post here).
 
At this point, I started wondering if Citadel isn't having issues writing these log results, since when I was first installing Citadel, I ran into issues saving the initial config due to the 'citadel' user not having the auth to create the netconfig directory. Later, I ran into a similar issue when I tried entering the remote retrieval addresses, where the citadel user had issues saving those. The first I solved by creating the directory; the second, I chown'd citadel to the netconfigs folder. Anticipating that citadel would be writing these results to a citadel or webcit directory or file, I took the results from find for both webcit and citadel and chown -R citadel'd them all. The results of find for webcit and citadel I've posted below (just to make sure there isn't a directory for either that the citadel user just failed to make during the install.)
 
tech@PICARD:~$ sudo find / -iname citadel
/var/lib/citadel
/var/spool/citadel
/usr/bin/citadel
/run/citadel
/etc/ssl/citadel
/etc/init.d/citadel
/etc/citadel
 
tech@PICARD:~$ sudo find / -iname webcit
/var/log/webcit
/usr/sbin/webcit
/run/webcit
/etc/ssl/webcit
/etc/init.d/webcit
/etc/default/webcit
 
After this, I restarted the server and confirmed that ownership for all the above stuck. I also added the citadel user to the adm group as a secondary group, because paranoid. Same thing happened.
 
Where does Citadel store the saved UDIL values for emails? maybe if I manually clear it out Citadel will start pulling messages.


[#] Fri Jul 17 2015 14:02:49 EDT from CarlGambolputty @ Uncensored

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

Sorry, I meant to say 'writing UDIL values to an internal database' instead of 'log values.'



[#] Wed Jul 22 2015 11:42:06 EDT from CarlGambolputty @ Uncensored

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

Any ideas? I can't find any reference to how Citadel handles its UDIL / mail ID records in the documentation... going to opt for a total purge and reset as a last resort otherwise (uuuuuuuuuuuugh).



[#] Fri Jul 24 2015 10:48:15 EDT from IGnatius T Foobar @ Uncensored

Subject: UIDL values

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

CarlGambolputty: are you looking for information on UID/UIDL values for messages it is serving up, or messages it is fetching from remote servers?

For local messages being served, UID/UIDL is quite simply the fixed value of the message number in the database (which is a global ascending sequence).

For messages fetched from remote servers, the UID/UIDL of the last-fetched message is stored in the "netconfigs" record for the room into which it is being fetched.



[#] Fri Jul 24 2015 11:20:02 EDT from CarlGambolputty @ Uncensored

Subject: Re: UIDL values

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

I'm looking for where it puts UIDL (derp) values when fetched from remote servers to a room. If that is put into the netconfigs folder, I'm not sure where to go from there, except maybe delete the netconfigs folder, recreate it, rerun setup, make sure citadel has ownership and trying to get the rooms to pull remotely again.

As said, even on new rooms I add new remote POP3 server information on, it'll telnet LIST the pop3 server after connecting and authorizing, then ask the pop3 server for UIDL values for each, but even if it's a completely new room it'll then close the connection without pulling a single one, and list '0 of X new messages' (paraphrasing) where X equals the total number of emails LIST'd. 



[#] Fri Jul 24 2015 12:59:00 EDT from CarlGambolputty @ Uncensored

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

Here's a log of the server output when it checks for messages, just in case I'm blind to something. This is from right after I started POP3 debugging after removing and recreating the netconfigs folder:

 

Jul 24 12:36:30 PICARD stunnel: LOG7[1144]: Service [GmailPop3sRelay] accepted (FD=3) from <Server Info>

Jul 24 12:36:30 PICARD citserver[17247]: CC[0]MSGCtdlFetchMessage(237, 1)

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: Service [GmailPop3sRelay] started

Jul 24 12:36:30 PICARD stunnel: LOG5[17406]: Service [GmailPop3sRelay] accepted connection from <Server Info>

Jul 24 12:36:30 PICARD citserver[17247]: SMTPCQ: queue run completed; 1 messages processed 0 activated

Jul 24 12:36:30 PICARD stunnel: LOG6[17406]: s_connect: connecting 74.125.202.109:995

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: s_connect: s_poll_wait 74.125.202.109:995: waiting 10 seconds

Jul 24 12:36:30 PICARD citserver[17247]: network: no neighbor nodes are configured - not polling.

Jul 24 12:36:30 PICARD citserver[17247]: No external notifiers configured on system/user

Jul 24 12:36:30 PICARD citserver[17247]: -- db checkpoint --

Jul 24 12:36:30 PICARD stunnel: LOG5[17406]: s_connect: connected 74.125.202.109:995

Jul 24 12:36:30 PICARD stunnel: LOG5[17406]: Service [GmailPop3sRelay] connected remote server from <Server Info>

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: Remote socket (FD=11) initialized

Jul 24 12:36:30 PICARD stunnel: LOG6[17406]: SNI: sending servername: pop.gmail.com

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: SSL state (connect): before/connect initialization

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: SSL state (connect): SSLv3 write client hello A

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: SSL state (connect): SSLv3 read server hello A

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: SSL state (connect): SSLv3 read finished A

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: SSL state (connect): SSLv3 write change cipher spec A

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: SSL state (connect): SSLv3 write finished A

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: SSL state (connect): SSLv3 flush data

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]:    0 items in the session cache

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: 4132 client connects (SSL_connect())

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: 4132 client connects that finished

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]:    0 client renegotiations requested

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]:    0 server connects (SSL_accept())

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]:    0 server connects that finished

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]:    0 server renegotiations requested

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: 4119 session cache hits

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]:    0 server renegotiations requested

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]: 4119 session cache hits

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]:    0 external session cache hits

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]:    0 session cache misses

Jul 24 12:36:30 PICARD stunnel: LOG7[17406]:    0 session cache timeouts

Jul 24 12:36:30 PICARD stunnel: LOG6[17406]: SSL connected: previous session reused

Jul 24 12:36:30 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: < +OK Gpop ready for requests from <Server Info>

Jul 24 12:36:30 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:30 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: > USER <user info>

Jul 24 12:36:30 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:30 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: < +OK send PASS

Jul 24 12:36:30 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:30 PICARD citserver[17247]: IO[4]CC[11][3]POP3: <PASS <password>

Jul 24 12:36:30 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:30 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: < +OK Welcome.

Jul 24 12:36:30 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:30 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: > LIST

Jul 24 12:36:30 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:31 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: < +OK 57 messages (3636174 bytes)

Jul 24 12:36:31 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:31 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: < 1 643

Jul 24 12:36:31 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

<SNIP>

Jul 24 12:36:31 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: < 57 491374

Jul 24 12:36:31 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:31 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: < .

Jul 24 12:36:31 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:31 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: > UIDL 53

Jul 24 12:36:31 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:31 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: < +OK 53 GmailId14eb72043928da2d

Jul 24 12:36:31 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

<SNIP>

Jul 24 12:36:39 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: > UIDL 24

Jul 24 12:36:39 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:39 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: < +OK 24 GmailId14eb0881d3219226

Jul 24 12:36:39 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:39 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:39 PICARD citserver[17247]: IO[4][3]POP3: POP3: POP3_C_ReAttachToFetchMessages

Jul 24 12:36:39 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: > QUIT#015#0123)

Jul 24 12:36:39 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:39 PICARD stunnel: LOG6[17406]: SSL socket closed (SSL_read)

Jul 24 12:36:39 PICARD stunnel: LOG7[17406]: Sent socket write shutdown

Jul 24 12:36:39 PICARD stunnel: LOG5[17406]: Connection closed: 558 byte(s) sent to SSL, 2524 byte(s) sent to socket

Jul 24 12:36:39 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:39 PICARD citserver[17247]: IO[4]CC[11][3]POP3: IO[4]CC[11][3]POP3: < +OK Farewell.

Jul 24 12:36:39 PICARD citserver[17247]: IO[4]CC[11][3]POP3: POP3: POP3SetTimeout

Jul 24 12:36:39 PICARD stunnel: LOG7[17406]: Remote socket (FD=11) closed

Jul 24 12:36:39 PICARD citserver[17247]: IO[4][3]POP3: POP3: POP3_C_Terminate

Jul 24 12:36:39 PICARD stunnel: LOG7[17406]: Local socket (FD=3) closed

Jul 24 12:36:39 PICARD citserver[17247]: IO[4]CC[11][3]POP3: <user>@<domain>: fetched 0 new of 57 messages in 9.473770s. bye.

 

A variation of this happens no matter what I try. I did notice that Citadel did not ask for EVERY UIDL value in sequence on first request, even though I removed/replaced netconfigs and everything in it. Where else are UIDL values stored for later checking?



[#] Sat Jul 25 2015 06:00:45 EDT from dothebart @ Uncensored

Subject: Re: UIDL values

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

I already added some handling for this a while ago (whilst debugging its use in the RSS-aggregator) but forgot to document it. here it is:

http://www.citadel.org/doku.php/documentation:appproto:system_config#rsenretrieveseenstatus



[#] Mon Jul 27 2015 13:11:23 EDT from CarlGambolputty @ Uncensored

Subject: Re: UIDL values

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

Excellent. I'll try those and see what I come up with in a little while; currently tied up in other stuff. Do you remember if the debug strings include the location of the database?



[#] Mon Jul 27 2015 16:30:25 EDT from dothebart @ Uncensored

Subject: Re: UIDL values

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

the log output is sufficient to query entries from that table.



[#] Mon Jul 27 2015 17:32:02 EDT from CarlGambolputty @ Uncensored

Subject: Re: UIDL values

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

RSEN via telnet console returns 530 Unrecognized or unsupported command. I've confirmed I can execute LOGP, so it knows I'm an aide. I also don't see under LOGP any database debug log settings; are you talking about something separate to Berkley DB?

I should have the latest versions of the citadel packages.



Go to page: First ... 42 43 44 45 [46]