Hello,
we've been using perdition as a pop3/pop3s/imap/imaps proxy for about
four years now, first with Debian Sarge package and now under Etch.
And throughout this time I've seen pop3s (and from the looks of it
the same happens with imaps) processes stuck in connect, like this:
---
16836 ? S 5:31 0 120 32179 2204 0.0 perdition.pop3s
28070 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect
7782 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect
24468 ? S 0:00 0 120 32311 1568 0.0 \_ perdition.pop3s: connect
14180 ? S 0:00 0 120 32311 1568 0.0 \_ perdition.pop3s: connect
13503 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect
---
They never die off, keep the connection open, there is no traffic and the
other end might be long gone. Last trace in the logs is always like this:
---
Feb 5 22:05:16 pp11 perdition[7782]: Connect: hi.mi.ts.u->203.216.5.113
---
It must be something related to the SSL'ness of these service, since I'm
not seeing this happening ever for imap/pop3. Alas a lot of people do use
TLS with those, so it's not a generic SSL issue. Maybe the master process
could kick a child handling connections in the head after "timeout"
seconds in connect state?
If more information is needed I can try to provide it, but note that with a
rate of roughly 35 pops per second I'm a bit weary to turn on
debugging. ^_-
This may or may not be related to another SSL related issue, which will
be for the sake of making searches in the archive more likely to find good
keywords in a separate mail.
Regards,
Christian
--
Christian Balzer Network/Systems Engineer NOC
chibi(a)gol.com Global OnLine Japan/Fusion Network Services
http://www.gol.com/
Hello simon,
sorry for not stumbling over this earlier but my test setup has just
one server configured and I just ran into this trying a run on a
(thankfully) standby machine in the production environment.
Perdition is 1.18-2 (Debian Sid/Lenny backports).
If the LDAP URL has more than one LDAP server in it, queries fail with
this:
---
dbserver_get2: ldap_initialize: Bad parameter to an ldap routine
---
Which had me rather stumped for a while until in one iteration I reduced
things to one server. And no, version 2 or 3 make no difference. ^^
Working config line:
---
m 3:ldap://localhost/ou=mail,dc=gol,dc=com?mailLocaladdress,mailServer?one?(uid=%s)
---
Not working:
---
m 3:ldap://localhost ldap.dentaku.gol.com/ou=mail,dc=gol,dc=com?mailLocaladdress,mailServer?one?…
---
And while I know you are not really involved with the LDAP bits, do you
(or anybody else here) know how a hostname resolving to multiple IPs is
treated? I.e, pick the first IP the resolver returns and if that is dead,
this "host" is dead. Or try all IPs returned until one succeeds and if
not, next server (if configured).
Regards,
Chibi
--
Christian Balzer Network/Systems Engineer
chibi(a)gol.com Global OnLine Japan/Fusion Communications
http://www.gol.com/
Since I'm on the subject of logging...
I notice that even if I am coming in on port 993, the port field that is
logged is the port of the outgoing connection:
Apr 4 11:19:24 auk perdition[19421]: Auth: 0.0.0.0->0.0.0.0 ---- server="0.0.0.0" port="143" status="ok"
In this case, my incoming imap connection was an imaps (993) connection
to perdition, it then looked up my user and found the server to connect
to, and then made the connection to that server over port 143. I
expected it to connect to the remote server over 143, but I was
expecting to get a log entry from perdition that the port it received
the connection on is port 993.
Is there a way to get a log entry that indicates the incoming port
number, as well as the outgoing one?
Thanks!
micah
--
"It is no measure of health to be well adjusted to a profoundly sick society." - J Krishnamurti
Hello All,
I'm attempting to setup an SSL IMAP proxy with perdition and I'm getting
fatal errors when establishing the SSL connection. My configuration is
pretty trivial and is basically a firewall proxy, all users will be
relayed to the same server. When I set the output_server to
imap.server.com:143 connections are successful. Given this I have to
assume perdition is not establishing an IMAPS connection to the
output_server, though I could certainly be wrong as this is the first
time I've played with perdition.
I'm running perdition 1.18 on OpenSuSE 11.2 from the "horms" repository.
perdition.conf:
connection_logging
debug
outgoing_server imap.server.com
ssl_mode ssl_listen
ssl_ca_chain_file /etc/ssl/certs/cacert.pem
ssl_ca_accept_self_signed
ssl_cert_file /etc/ssl/certs/cert.pem
ssl_key_file /etc/ssl/certs/key.pem
The imap server is cyrus-imapd-2.2.13.
Thanks!
--
Darin Perusich
Unix Systems Administrator
Cognigen Corporation
395 Youngs Rd.
Williamsville, NY 14221
Phone: 716-633-3463
Email: darinper(a)cognigencorp.com
Hi!
We are using perdition 1.17.1 on Centos 5.3 x64.
I tried to use the CentOS repo for updating to 1.18 but that version
dies immediately after a imap4 connect with "Exit 11" -
as we are using ldap as database I thing that is related to that patch
http://hg.vergenet.net/perdition/perdition/rev/28264fe9e31b
so I tried to compile perdition 1.18 manually.
That fails with:
-DHAVE_CONFIG_H -I. -I.. -DPERDITION_LIBDIR=\"/opt/perdition180/lib\"
-DPERDITION_SYSCONFDIR=\"/opt/perdition180/etc/perdition\"
-DPERDITION_LOCALSTATEDIR=\"/opt/perdition180/var\" -I/usr/include
-g -O2 -MT perdition.o -MD -MP -MF .deps/perdition.Tpo -c -o perdition.o
perdition.c
perdition.c: In function »main«:
perdition.c:547: Warning: Zuweisung erzeugt Zeiger von Ganzzahl ohne
Typkonvertierung
perdition.c:712: Fehler: expected expression before »else«
perdition.c:950: Fehler: expected expression before »else«
perdition.c:998: Fehler: expected expression before »else«
make[3]: *** [perdition.o] Fehler 1
make[3]: Leaving directory `/root/perdition-1.18/perdition'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/root/perdition-1.18/perdition'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/root/perdition-1.18'
make: *** [all] Fehler 2
Can somebody give me a hint please?
regards martin
Hello everybody.
We’re using gmail for our domain down there but we sent to Google MD5 hashed
password for users, not clear text passwords. So we’re in the need to mangle
on the fly the password.
I searched the mailing list and fount hints involving pam and mysql … I think
this is not the best way for our needs.
So I started to play with source and now I do have what is, for me, a working
solution, read below.
Meanwhile I guess my approach is quite not the best one. Will be far better if
we could have something like a hook, a void function to fill-in whit local
code, to cheat with source only in that file. I’m not aware of others having
the same need around, to mangle password I mean, but I guess could be some
around so I hope the developer will consider to help us :)
Anyway here what I did. Ty for any hint.
Paolo.
In perditon.c
/* we don’t want to malloc & free more than once*/
char *gmail_passwd;
gmail_passwd = malloc(256 * sizeof (char));
/* mangle the password
pw2.pw_passwd=pw.pw_passwd;
*/
passwd_mangle(pw.pw_passwd,gmail_passwd);
pw2.pw_passwd=gmail_passwd;
In username.h
/**********************************************************************
* passwd_mangle
* MD5 encode password
**********************************************************************/
void passwd_mangle(char *old_password, char *gmail_password);
In username.c
#include <crypt.h>
#include <openssl/md5.h>
#include <openssl/bio.h>
#include <openssl/evp.h>
#include <openssl/buffer.h>
void passwd_mangle(char *old_password, char *gmail_password){
unsigned char hash[64], pwd64[64];
unsigned long bytes;
BIO *bmem, *b64;
BUF_MEM *bptr;
char *buff;
/* critto MD5 la password in chiaro, usando una funzione di libreria SSL */
bytes=strlen(old_password);
MD5(old_password, bytes, hash);
/*
Per codificare Base64 uso ancora le librerie ssl
I tipi BIO sono in pratica filtri concatenabili fra loro; quello che
scrivo da un lato esce modificato dall'altro.
In questo caso concateno un filtro che fa l'encode base64 con un
filtro che rende disponibile il risultato in una zona di memoria
*/
b64 = BIO_new(BIO_f_base64());
bmem = BIO_new(BIO_s_mem());
/* concateno */
b64 = BIO_push(b64, bmem);
/*
scrivo la password crittata MD5
OKKIO che vanno scritti sempre e comunque 16 caratteri
perche' la codifica MD5 e' un bin e potrebbe contenere qualsiasi mondezza
*/
BIO_write(b64, hash, 16);
BIO_flush(b64);
/* leggo il risultato, la faccenda e' complicata dal fatto che bisogna
fare malloc per la stringa in uscita
*/
BIO_get_mem_ptr(b64, &bptr);
buff = (char *)malloc(bptr->length);
memcpy(buff, bptr->data, bptr->length-1);
buff[bptr->length-1] = 0;
BIO_free_all(b64);
strcpy(gmail_password, "{MD5}");
strcat(gmail_password, buff);
free(buff);
}
