headers
Vincent Fox | 2 Aug 2006 02:21
Picon

SSL certs on proxy pool?


Wondering how folks handle SSL certs?

Assuming you have 2 or more Perdition units in a load-balancer.  Do you get
wildcard certs?

The only other way that immediately occurs is to use a load-balancer that
can handle SSL processing. I can see how that should work okay with
sessions that are 995/pops or 993/imaps. But what about sessions that are
TLS? They start out plaintext on 110 or 143 and switch using STARTTLS.
Doesn't the loadbalancer need to acts as a sort of app proxy to handle that
shift? Maybe I'm overthinking it but it seems like this would be more
complicated.

--

-- 
Perdition - http://www.vergenet.net/linux/perdition/
To UNSUBSCRIBE, email to lisa <at> vergenet.net, with a body:
unsubscribe perdition-users your-email-address <at> some.domain
where "your-email-address <at> some.domain" is YOUR email address.
Permalink | Reply | 1 comment |
headers
Matt Cuttler | 2 Aug 2006 02:54
Favicon

Re: SSL certs on proxy pool?

Vincent Fox wrote:
> Wondering how folks handle SSL certs?
>
> Assuming you have 2 or more Perdition units in a load-balancer.  Do you get
> wildcard certs?
>   

Wildcard certs? No, not needed. Use the same certificate on each of your
load-balanced servers.

> The only other way that immediately occurs is to use a load-balancer that
> can handle SSL processing. I can see how that should work okay with
> sessions that are 995/pops or 993/imaps. But what about sessions that are
> TLS? They start out plaintext on 110 or 143 and switch using STARTTLS.
>   

Heckofalot easier to offer IMAP/POP3 SSL services on the 'alternate
ports'. If your mail clients are configured to use SSL on the alternate
ports, and you don't allow standard 110/143, you don't have to worry
about whether or not a given client attempts a STARTTLS or not.

> Doesn't the loadbalancer need to acts as a sort of app proxy to handle that
> shift? Maybe I'm overthinking it but it seems like this would be more
> complicated.
>   

The load-balancer should not fit into the equation much, it's just a NAT
box :-)  Of course, there are many bells and whistles offered with
"content switching" products (hardware SSL offload, sticky sessions
etc.), but you just need Layer 3 load balancing. Round-robin or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vincent Fox | 3 Aug 2006 22:20
Picon

Kerberos authentication?


I know that Perdition supports PLAIN and nothing else.

Has anyone looked at the feasibility of Kerberizing it?

We have a bunch of UWash IMAP servers that users have been hitting directly
and we run Kerberos.  Now we want to put Perdition in front of them to hide
the growing complexity and make it easier to move users, etc.

For ordinary POP clients out in the field no change.  However, this will
inconvenience some existing users with Pine and similar Kerberized clients
who will suddenly hit a login prompt that they did not before.  When you
have 40,000+ users this can be a real issue that generates lots of phone calls.

We're looking at funding some in-house development work to add this, but if
there is someone out there who thinks it's an easy and quick bolt-on job
we'd consider paying a consultant for it.

--

-- 
Perdition - http://www.vergenet.net/linux/perdition/
To UNSUBSCRIBE, email to lisa <at> vergenet.net, with a body:
unsubscribe perdition-users your-email-address <at> some.domain
where "your-email-address <at> some.domain" is YOUR email address.
Permalink | Reply | 0 comments |
headers
Vincent Fox | 4 Aug 2006 21:58
Picon

64-bit any benefit?


Does compiling in 64-bit offer any benefit for Perdition?

I ask because I have RPM's already from a Pentium-3 system.

I am fiddling with the build process on an Opteron system which is 64-bit
to get it to compile. Vanessa_socket for instance needed -L/usr/lib64 added
in a Makefile before libpopt.  Wondering if I am wasting my time and I
should just copy over the 32-bit RPM's?

--

-- 
Perdition - http://www.vergenet.net/linux/perdition/
To UNSUBSCRIBE, email to lisa <at> vergenet.net, with a body:
unsubscribe perdition-users your-email-address <at> some.domain
where "your-email-address <at> some.domain" is YOUR email address.
Permalink | Reply | 1 comment |
headers
Alexander Dalloz | 5 Aug 2006 00:10

Re: 64-bit any benefit?

Vincent Fox schrieb:

>Does compiling in 64-bit offer any benefit for Perdition?
>
>I ask because I have RPM's already from a Pentium-3 system.
>
>I am fiddling with the build process on an Opteron system which is 64-bit
>to get it to compile. Vanessa_socket for instance needed -L/usr/lib64 added
>in a Makefile before libpopt.  Wondering if I am wasting my time and I
>should just copy over the 32-bit RPM's?
>
You would need a multi-arch setup then, means other 32bit libraries 
would be required as well while having the 64bit ones there too. From 
running "ldd" on my box against the perdition binary that would mean 
quite a lot of 32bit packages needed. I prefer to not mix arches.

A simple approach: get the src.rpms from Simon Matter's server (I used 
them too for my x86_64 CentOS4 system)

http://www.invoca.ch/pub/packages/perdition/
http://www.invoca.ch/pub/packages/vanessa_adt/
http://www.invoca.ch/pub/packages/vanessa_logger/
http://www.invoca.ch/pub/packages/vanessa_socket/

They build nicely on a 64bit Red Hat platform. His perdition package 
also has patches required on RHEL4.

Alexander

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rudy Gevaert | 18 Aug 2006 11:51
Picon
Favicon

kill -HUP doesn't work

Hi,

I'm using perdition from debian stable.

Is it normal that sending the -HUP signal just stops perdition?

(/etc/init.d/perdition reload kills it too).

Thanks in advance,
-- 
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Rudy Gevaert          Rudy.Gevaert <at> UGent.be          tel:+32 9 264 4734
Directie ICT, afd. Infrastructuur  Direction ICT, Infrastructure dept.
Groep Systemen                     Systems group
Universiteit Gent                  Ghent University
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie               www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

--

-- 
Perdition - http://www.vergenet.net/linux/perdition/
To UNSUBSCRIBE, email to lisa <at> vergenet.net, with a body:
unsubscribe perdition-users your-email-address <at> some.domain
where "your-email-address <at> some.domain" is YOUR email address.
Permalink | Reply | 0 comments |
headers
Vincent Fox | 21 Aug 2006 20:05
Picon

proxy kernel tuning for handling large number of connects?


Any guidelines on kernel tuning for Perdition assuming you might have a
large number of clients? i.e. 50,000+ possible users spread across 2-3
proxies. RHEL4 on modern dual CPU units with 4G RAM.

First thing that occurred to me was adding to /etc/sysctl.conf
kernel.pid_max=65536

Anything else?

--

-- 
Perdition - http://www.vergenet.net/linux/perdition/
To UNSUBSCRIBE, email to lisa <at> vergenet.net, with a body:
unsubscribe perdition-users your-email-address <at> some.domain
where "your-email-address <at> some.domain" is YOUR email address.
Permalink | Reply | 2 comments |
headers
Matt Cuttler | 21 Aug 2006 20:59
Favicon

Re: proxy kernel tuning for handling large number of connects?

Vincent Fox wrote:
> Any guidelines on kernel tuning for Perdition assuming you might have a
> large number of clients? i.e. 50,000+ possible users spread across 2-3
> proxies. RHEL4 on modern dual CPU units with 4G RAM.
> 
> First thing that occurred to me was adding to /etc/sysctl.conf
> kernel.pid_max=65536
> 
> Anything else?
> 
> 

Probably more in the way of TCP stack tuning (rather than
Perdition-specific tweaks) to handle that many concurrent connections.
Off the top of my head:

net.ipv4.ip_local_port_range = 8192 65535
(this will enable more outbound connections to the real mail servers)

If you have two NICs, ensure that each NIC is using a separate interrupt.

If you have a multi-core machine, ensure that your perdition processes
are bound to a core which is not the one used by the IRQ handler.

There's a lot of texts out there w/r/t Linux 2.6 TCP stack tuning. Just
be careful, though - some of the information you'll find is dated (older
2.4 -specific information), and consider what you're tuning for (you're
not tuning for large individual streams; you're tuning for many
concurrent connections).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Fagan | 21 Aug 2006 22:22

Re: proxy kernel tuning for handling large number of connects?

Vincent Fox wrote:
> Any guidelines on kernel tuning for Perdition assuming you might have a
> large number of clients? i.e. 50,000+ possible users spread across 2-3
> proxies. RHEL4 on modern dual CPU units with 4G RAM.
>
> First thing that occurred to me was adding to /etc/sysctl.conf
> kernel.pid_max=65536
>
> Anything else?
>
>
>   
I ran Perdition (pop3 proxying only) for 125k cable broadband users load 
balanced across 5 PIII-800s on RH7.3.  There wasn't any significant load 
or impact on the systems; the only tweak I made was enabling fast 
recycling of TIME-WAIT sockets (net.ipv4.tcp_tw_recycle=1).  It's 
possible that's already enabled in your distro tho; I really don't 
know.  I guess you could cat /proc/sys/net/ipv4/tcp_tw_recycle to find 
out.  There usually wasn't more than 5-10 connections/sec on each box so 
I would only see a handful of open processes spawned at any given time.

--eric
**


--

-- 
Perdition - http://www.vergenet.net/linux/perdition/
To UNSUBSCRIBE, email to lisa <at> vergenet.net, with a body:
unsubscribe perdition-users your-email-address <at> some.domain
where "your-email-address <at> some.domain" is YOUR email address.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cami | 31 Aug 2006 15:06
Picon
Favicon

Perdition 1.17: Duplicate syslog process and other logging funnies

Hi Horms,

Perdition 1.15 we've been running for a veery long time
and its been really stable. Today we're trying to upgrade
to Perdition 1.17 for some of its new functionality.

Everything is working except for the syslog records:

Aug 31 14:51:47 popwall01.mweb.co.za perdition[27036]: perdition[27036]: Connect: 127.0.0.1->127.0.0.1
Aug 31 14:51:49 popwall01.mweb.co.za perdition[27036]: perdition[27036]: Closing NULL session:
127.0.0.1->127.0.0.1 username=(null)
Aug 31 14:52:52 popwall01.mweb.co.za perdition[27039]: perdition[27039]: Connect: 127.0.0.1->127.0.0.1
Aug 31 14:52:54 popwall01.mweb.co.za perdition[27039]: perdition[27039]: Closing NULL session:
127.0.0.1->127.0.0.1 username=(null)
Aug 31 14:53:08 popwall01.mweb.co.za perdition[27041]: perdition[27041]: Connect: 196.2.61.23->196.2.50.80
                                      ^^^^^^^^^         ^^^^^^^^^^
Aug 31 14:53:08 popwall01.mweb.co.za perdition[27041]: perdition[27041]: Closing NULL session:
196.2.61.23->196.2.50.80 username=(null)
Aug 31 14:53:08 popwall01.mweb.co.za perdition[27043]: Aug 31 14:53:08: Connect: 196.2.61.23->196.2.50.80
Aug 31 14:53:08 popwall01.mweb.co.za perdition[27043]: Aug 31 14:53:08: Closing NULL session:
196.2.61.23->196.2.50.80 username=(null)
^^^^^^^^^^^^^^^                                        ^^^^^^^^^^^^^^^^
Aug 31 14:55:24 popwall01.mweb.co.za perdition[26935]: perdition[26935]: Exiting on signal 15
Aug 31 14:55:24 popwall01.mweb.co.za perdition[26941]: Aug 31 14:55:24: Exiting on signal 15

At first, i thought it was a syslog-ng issue, so i rolled
back to the original syslog that is released with Fedora
Core 3. It was not the case at all.

An strace shows the following being send directly to syslog-ng:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane