date:20171017

Re: Possible bug in task_wakeup() impacts Lua tasks

2017-10-17 Thread Emeric Brun

Hi Adis,

On 10/17/2017 05:48 PM, Emeric Brun wrote:
> Hi Adis,
> 
> On 10/17/2017 05:41 PM, Adis Nezirovic wrote:
>> Hello guys,
>>
>> After this commit:
>>
>>   commit 0194897e540cec67d7d1e9281648b70efe403f08
>>   Author: Emeric Brun 
>>   Date:   Thu Mar 30 15:37:25 2017 +0200
>>
>>   MAJOR: task: task scheduler rework.
>>
>> basic Lua tasks don't work anymore.
>> e.g. this only gets called once:
>>
>>   function cron()
>>   while true do
>>   core.Debug("Hello from Cron")
>>   core.sleep(1)
>>   end
>>   end
>>   core.register_task(cron)
>>
>> 
>>
>> The current code in task_wakeup() checks for TASK_RUNNING and decides
>> that it won't call __task_wakeup(), but when Lua task wakes up, it has
>> both, TASK_WOKEN_TIMER and TASK_RUNNING set.
>>
>> My quick fix/workaround was to add an additional check:
>>
>>   if (unlikely(!(t->state & TASK_WOKEN_TIMER) &&
>>(t->state & TASK_RUNNING)))
>>
>> But I might be missing something more fundamental (i.e. this is really
>> necessary for multithreaded stuff), maybe we need additional flags when
>> running task_wakeup from task handlers or threads.
>>
>>
>> Best regards,
>> Adis
>>
> 
> I'm adding the haproxy's LUA engine maintainer in CC, Thierry.
> 
> He should be helpful.
> 
> R,
> Emeric
> 

This patch should fix the issue more consistently.

Could you confirm?

R,
Emeric
>From 03e97e72ce2736db7ec04ee76583e480fc85be75 Mon Sep 17 00:00:00 2001
From: Emeric Brun 
Date: Tue, 17 Oct 2017 18:58:40 +0200
Subject: [PATCH] BUG/MAJOR: lua: scheduled task is freezing.

Since commit 'MAJOR: task: task scheduler rework'
0194897e540cec67d7d1e9281648b70efe403f08. LUA's
scheduling tasks are freezing.

A running task should not handle the scheduling itself
but let the task scheduler to handle it based on the
'expire' field.
---
 src/hlua.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/src/hlua.c b/src/hlua.c
index c68495b..7eddda8 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -5360,12 +5360,6 @@ static struct task *hlua_process_task(struct task *task)
 	struct hlua *hlua = task->context;
 	enum hlua_exec status;
 
-	/* We need to remove the task from the wait queue before executing
-	 * the Lua code because we don't know if it needs to wait for
-	 * another timer or not in the case of E_AGAIN.
-	 */
-	task_delete(task);
-
 	/* If it is the first call to the task, we must initialize the
 	 * execution timeouts.
 	 */
@@ -5385,7 +5379,7 @@ static struct task *hlua_process_task(struct task *task)
 
 	case HLUA_E_AGAIN: /* co process or timeout wake me later. */
 		if (hlua->wake_time != TICK_ETERNITY)
-			task_schedule(task, hlua->wake_time);
+			task->expire = hlua->wake_time;
 		break;
 
 	/* finished with error. */
@@ -5394,6 +5388,7 @@ static struct task *hlua_process_task(struct task *task)
 		hlua_ctx_destroy(hlua);
 		task_delete(task);
 		task_free(task);
+		task = NULL;
 		break;
 
 	case HLUA_E_ERR:
@@ -5402,9 +5397,10 @@ static struct task *hlua_process_task(struct task *task)
 		hlua_ctx_destroy(hlua);
 		task_delete(task);
 		task_free(task);
+		task = NULL;
 		break;
 	}
-	return NULL;
+	return task;
 }
 
 /* This function is an LUA binding that register LUA function to be
-- 
2.7.4

Apache Spark Using Companies

2017-10-17 Thread cherl . brown

Hello,



We have the new, redesigned *Apache Spark users list*, including email
addresses and complete contact data for your business leads.



If you are seeking out specific titles, please let me know and I will
provide you with additional data.



*We also have client records for other applications, such as:*



*MongoDB*

*Amazon EMR*

*Hortonworks*

*TIBCO Spotfire*

*SAS Visual Analytics*

*Microsoft SQL Server* *and more!*



We offer information from all over the world, including *North America,
EMEA, Asia Pacific, and LATAM*.



If *Apache Spark users* are not applicable to you, please respond with your
specific criteria and the enterprises you'd prefer to focus on in your
advertising effort. We have all kinds of marketing information available.



Thank you. I look forward to hearing from you.



Much obliged,



*Cheryl Brown*

Information Specialist



To quit, please respond with Remove.

Re: [PATCH] checks: Add a keyword to specify the SNI in health checks

2017-10-17 Thread Willy Tarreau

On Tue, Oct 17, 2017 at 05:36:19PM +0200, Olivier Houchard wrote:
> Hi,
> 
> The attached patch adds a new keyword to servers, "check-sni", that lets you
> specify which SNI to use when doing health checks over SSL.

And applied as well (I thought we already had this). Thanks!

Willy

Re: [PATCH] Properly handle weight increase with consistent weight

2017-10-17 Thread Willy Tarreau

On Tue, Oct 17, 2017 at 04:02:00PM +0200, Olivier Houchard wrote:
> Hi,
> 
> When consistent hash is used, when the weight of the server is increased
> beyond the original one, it currently has no effect (well really it will
> reset the weight to the original one, if it was decreased), to fix this,
> the attached patch allocates more nodes, and add them to the ebtree as needed.

Applied, thanks Olivier!

I think we could backport it as it fixes an unexpected behaviour that's
not clearly documented.

Willy

Re: Possible bug in task_wakeup() impacts Lua tasks

2017-10-17 Thread Emeric Brun

Hi Adis,

On 10/17/2017 05:41 PM, Adis Nezirovic wrote:
> Hello guys,
> 
> After this commit:
> 
>   commit 0194897e540cec67d7d1e9281648b70efe403f08
>   Author: Emeric Brun 
>   Date:   Thu Mar 30 15:37:25 2017 +0200
> 
>   MAJOR: task: task scheduler rework.
> 
> basic Lua tasks don't work anymore.
> e.g. this only gets called once:
> 
>   function cron()
>   while true do
>   core.Debug("Hello from Cron")
>   core.sleep(1)
>   end
>   end
>   core.register_task(cron)
> 
> 
> 
> The current code in task_wakeup() checks for TASK_RUNNING and decides
> that it won't call __task_wakeup(), but when Lua task wakes up, it has
> both, TASK_WOKEN_TIMER and TASK_RUNNING set.
> 
> My quick fix/workaround was to add an additional check:
> 
>   if (unlikely(!(t->state & TASK_WOKEN_TIMER) &&
>(t->state & TASK_RUNNING)))
> 
> But I might be missing something more fundamental (i.e. this is really
> necessary for multithreaded stuff), maybe we need additional flags when
> running task_wakeup from task handlers or threads.
> 
> 
> Best regards,
> Adis
> 

I'm adding the haproxy's LUA engine maintainer in CC, Thierry.

He should be helpful.

R,
Emeric

Possible bug in task_wakeup() impacts Lua tasks

2017-10-17 Thread Adis Nezirovic

Hello guys,

After this commit:

  commit 0194897e540cec67d7d1e9281648b70efe403f08
  Author: Emeric Brun 
  Date:   Thu Mar 30 15:37:25 2017 +0200

  MAJOR: task: task scheduler rework.

basic Lua tasks don't work anymore.
e.g. this only gets called once:

  function cron()
  while true do
  core.Debug("Hello from Cron")
  core.sleep(1)
  end
  end
  core.register_task(cron)



The current code in task_wakeup() checks for TASK_RUNNING and decides
that it won't call __task_wakeup(), but when Lua task wakes up, it has
both, TASK_WOKEN_TIMER and TASK_RUNNING set.

My quick fix/workaround was to add an additional check:

  if (unlikely(!(t->state & TASK_WOKEN_TIMER) &&
   (t->state & TASK_RUNNING)))

But I might be missing something more fundamental (i.e. this is really
necessary for multithreaded stuff), maybe we need additional flags when
running task_wakeup from task handlers or threads.


Best regards,
Adis

[PATCH] checks: Add a keyword to specify the SNI in health checks

2017-10-17 Thread Olivier Houchard

Hi,

The attached patch adds a new keyword to servers, "check-sni", that lets you
specify which SNI to use when doing health checks over SSL.

Regards,

Olivier
>From 24779f0985041f4e680855d453a4bc5d096756f9 Mon Sep 17 00:00:00 2001
From: Olivier Houchard 
Date: Tue, 17 Oct 2017 17:33:43 +0200
Subject: [PATCH] MINOR: checks: Add a new keyword to specify a SNI when doing
 SSL checks.

Add a new keyword, "check-sni", to be able to specify the SNI to be used when
doing health checks over SSL.
---
 doc/configuration.txt  |  4 
 include/types/checks.h |  1 +
 src/checks.c   |  8 
 src/ssl_sock.c | 19 +++
 4 files changed, 32 insertions(+)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 934f87759..1421808b8 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -10970,6 +10970,10 @@ check-send-proxy
   "check-send-proxy" option needs to be used to force the use of the
   protocol. See also the "send-proxy" option for more information.
 
+check-sni
+  This option allows you to specify the SNI to be used when doing health checks
+  over SSL.
+
 check-ssl
   This option forces encryption of all health checks over SSL, regardless of
   whether the server uses SSL or not for the normal traffic. This is generally
diff --git a/include/types/checks.h b/include/types/checks.h
index 283ff3dbe..3559f2d52 100644
--- a/include/types/checks.h
+++ b/include/types/checks.h
@@ -184,6 +184,7 @@ struct check {
char **envp;/* the environment to use if 
running a process-based check */
struct pid_list *curpid;/* entry in pid_list used for 
current process-based test, or -1 if not in test */
struct sockaddr_storage addr;   /* the address to check */
+   char *sni;  /* Server name */
 };
 
 struct check_status {
diff --git a/src/checks.c b/src/checks.c
index c02935cf0..413365b24 100644
--- a/src/checks.c
+++ b/src/checks.c
@@ -60,6 +60,10 @@
 #include 
 #include 
 
+#ifdef USE_OPENSSL
+#include 
+#endif /* USE_OPENSSL */
+
 static int httpchk_expect(struct server *s, int done);
 static int tcpcheck_get_step_id(struct check *);
 static char * tcpcheck_get_step_comment(struct check *, int);
@@ -1597,6 +1601,10 @@ static int connect_conn_chk(struct task *t)
ret = SF_ERR_INTERNAL;
if (proto && proto->connect)
ret = proto->connect(conn, check->type, quickack ? 2 : 0);
+#ifdef USE_OPENSSL
+   if (s->check.sni)
+   ssl_sock_set_servername(conn, s->check.sni);
+#endif
if (s->check.send_proxy && !(check->state & CHK_ST_AGENT)) {
conn->send_proxy_ofs = 1;
conn->flags |= CO_FL_SEND_PROXY;
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 774a5a683..1d00b42e4 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -7075,6 +7075,24 @@ static int srv_parse_ca_file(char **args, int *cur_arg, 
struct proxy *px, struct
return 0;
 }
 
+/* parse the "check-sni" server keyword */
+static int srv_parse_check_sni(char **args, int *cur_arg, struct proxy *px, 
struct server *newsrv, char **err)
+{
+   if (!*args[*cur_arg + 1]) {
+   if (err)
+   memprintf(err, "'%s' : missing SNI", args[*cur_arg]);
+   return ERR_ALERT | ERR_FATAL;
+   }
+
+   newsrv->check.sni = strdup(args[*cur_arg + 1]);
+   if (!newsrv->check.sni) {
+   memprintf(err, "'%s' : failed to allocate memory", 
args[*cur_arg]);
+   return ERR_ALERT | ERR_FATAL;
+   }
+   return 0;
+
+}
+
 /* parse the "check-ssl" server keyword */
 static int srv_parse_check_ssl(char **args, int *cur_arg, struct proxy *px, 
struct server *newsrv, char **err)
 {
@@ -8031,6 +8049,7 @@ static struct bind_kw_list bind_kws = { "SSL", { }, {
  */
 static struct srv_kw_list srv_kws = { "SSL", { }, {
{ "ca-file", srv_parse_ca_file,1, 1 }, /* 
set CAfile to process verify server cert */
+   { "check-sni",   srv_parse_check_sni,  1, 1 }, /* 
set SNI */
{ "check-ssl",   srv_parse_check_ssl,  0, 1 }, /* 
enable SSL for health checks */
{ "ciphers", srv_parse_ciphers,1, 1 }, /* 
select the cipher suite */
{ "crl-file",srv_parse_crl_file,   1, 1 }, /* 
set certificate revocation list file use on server cert verify */
-- 
2.13.5

Re: Haproxy config for sticky route

2017-10-17 Thread Moemen MHEDHBI

Hi Ruben,

You are defining only one server, in your backend so even if your
resolvers return 3 addresses, HAProxy will pick only one (probably the
first).

You need to define three servers, you can do it manually (three server
lines) or use the "server-template" keyword.



On 13/10/2017 14:59, Ruben wrote:
> Well =fun should be a variable name. But the name, whatever it is,
> should always be routed to the same ip based on some consistency
> algorhithm.
>
> I've build some DNS server to correct for the randomizing of the
> server list from the dns. So the following:
>
> dig @ordered-dns-proxy chat
>
> always gives me the list:
>
> 10.0.0.11
> 10.0.0.12
> 10.0.0.13
>
> in this order.
>
> My config now looks like:
> -
> defaults
>     mode http
>     timeout client 5s
>     timeout connect 5s
>     timeout server 5s
>
> resolvers dns
>     nameserver srv_dns ordered-dns-proxy:53
>
> frontend all
>     bind :80
>     mode http
>     timeout client 120s
>     option forwardfor
>
>     default_backend chat
>
> backend chat
>     balance url_param chatName
>     timeout server 120s
>
>     server srv_chat chat:80 resolvers dns
> ---
>
> But still not working. It is always routed to a different server.
>
> What I want to accomplish is something like.
>
> dig @ordered-dns-proxy chat
>
> always gives me the list:
>
> 10.0.0.11
> 10.0.0.12
> 10.0.0.13
>
> I want to have the connection:
>
> ?chatName=
>
> crc32() % 3 is for example 2
>
> always route to the second server in the dns list.
>
> With my current config this won't happen. The balancer is always going
> to the first.
>
>
>
> 2017-10-11 1:27 GMT+02:00 Igor Cicimov  >:
> >
> >
> >
> > On Tue, Oct 10, 2017 at 11:25 PM, Ruben  > wrote:
> >>
> >> I have some stateful chat servers (SockJS) running in docker swarm
> mode. When doing dig chat I get an unordered randomized list of
> servers for example:
> >>
> >> (every time the order is different)
> >> 10.0.0.12
> >> 10.0.0.10
> >> 10.0.0.11
> >>
> >> The chat is accessed by a chatName url parameter. Now I want to be
> able to run a chat-load-balancer service in docker with multiple
> replicas using the haproxy image.
> >>
> >> The problem is that docker always resolves to a randomized list
> when doing dig chat.
> >>
> >> I want to map the chatName param from the url to a fixed server
> which always have the same ip from the list of ips of dig chat. So the
> mapping of the url_param should not be based on the position of the
> server in the list, but solely on the ip of the server.
> >>
> >> So for example ?chatName=fun should always route to ip 10.0.0.12,
> no matter what.
> >>
> >> My current haproxy.cfg is:
> >>
> >> defaults
> >>   mode http
> >>   timeout client 5s
> >>   timeout connect 5s
> >>   timeout server 5s
> >>
> >> frontend frontend_chat
> >>   bind :80
> >>   mode http
> >>   timeout client 120s
> >>   option forwardfor
> >>   option http-server-close
> >>   option http-pretend-keepalive
> >>   default_backend backend_chat
> >>
> >> backend backend_chat
> >>   balance url_param chatName
> >>   timeout server 120s
> >>   server chat chat:80
> >>
> >> At the moment it seems that only the Commercial Subscribtion of
> Nginx can handle this kind of cases using the sticky route $variable
> ...; directive in the upstream module.
> >
> >
> > Maybe try:
> >
> > http-request set-header Host 10.0.0.12 if { query -m beg -i
> chatName=fun }
> >

-- 
Moemen MHEDHBI

[PATCH] Properly handle weight increase with consistent weight

2017-10-17 Thread Olivier Houchard

Hi,

When consistent hash is used, when the weight of the server is increased
beyond the original one, it currently has no effect (well really it will
reset the weight to the original one, if it was decreased), to fix this,
the attached patch allocates more nodes, and add them to the ebtree as needed.

Regards,

Olivier
>From a8d290e08d4820fe5058ba00fd4ef762e562cb69 Mon Sep 17 00:00:00 2001
From: Olivier Houchard 
Date: Tue, 17 Oct 2017 15:52:59 +0200
Subject: [PATCH] MINOR: server: Handle weight increase in consistent hash.

When the server weight is rised using the CLI, extra nodes have to be
allocated, or the weight will be effectively the same as the original one.
---
 src/lb_chash.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/src/lb_chash.c b/src/lb_chash.c
index 82124bc27..f368b684e 100644
--- a/src/lb_chash.c
+++ b/src/lb_chash.c
@@ -78,6 +78,25 @@ static inline void chash_queue_dequeue_srv(struct server *s)
eb32_delete(>lb_nodes[s->lb_nodes_now].node);
}
 
+   /* Attempt to increase the total number of nodes, if the user
+* increased the weight beyond the original weight
+*/
+   if (s->lb_nodes_tot < s->next_eweight) {
+   struct tree_occ *new_nodes = realloc(s->lb_nodes, 
s->next_eweight);
+
+   if (new_nodes) {
+   unsigned int j;
+
+   s->lb_nodes = new_nodes;
+   memset(>lb_nodes[s->lb_nodes_tot], 0,
+   (s->next_eweight - s->lb_nodes_tot) * 
sizeof(*s->lb_nodes));
+   for (j = s->lb_nodes_tot; j < s->next_eweight; j++) {
+   s->lb_nodes[j].server = s;
+   s->lb_nodes[j].node.key = full_hash(s->puid * 
SRV_EWGHT_RANGE + j);
+   }
+   s->lb_nodes_tot = s->next_eweight;
+   }
+   }
while (s->lb_nodes_now < s->next_eweight) {
if (s->lb_nodes_now >= s->lb_nodes_tot) // should always be 
false anyway
break;
-- 
2.13.5

Re: Question related to gpc0_rate values in stick-table

2017-10-17 Thread Daniel Schneller

> Can you please provide the details of the known issue which might be related 
> to this situation? I have gone through the list of all unknown issues but 
> couldn't find the relevant one.

If you are referring to the list of bugs in the old version compared to more 
current ones, I doubt you (or anyone else, with a reasonable amount of effort) 
will find an exact match describing your issue.
It could be something that was fixed (or not) along with other changes since 
that very old release.
So you should upgrade and see if the issue remains. If so, it will be a much 
more reasonable starting point to figure out where the issue comes from.

Regards,
Daniel



-- 
Daniel Schneller
Principal Cloud Engineer
 
CenterDevice GmbH  | Hochstraße 11
   | 42697 Solingen
tel: +49 1754155711| Deutschland
daniel.schnel...@centerdevice.de   | www.centerdevice.de

Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina,
Michael Rosbach, Handelsregister-Nr.: HRB 18655,
HR-Gericht: Bonn, USt-IdNr.: DE-815299431


> On 17. Oct. 2017, at 10:41, Saurabh Patwardhan 
>  wrote:
> 
> Gentle Reminder.
> Can you please share your thought on the below queries?
> 
> Regards,
> Saurabh
> 
> -Original Message-
> From: Saurabh Patwardhan
> Sent: Thursday, October 05, 2017 3:15 PM
> To: 'Lukas Tribus'; haproxy@formilux.org
> Cc: Manoj Mahadik; Tatiana Parshina
> Subject: RE: Question related to gpc0_rate values in stick-table
> 
> Thanks Lukas.
> Can you please provide the details of the known issue which might be related 
> to this situation? I have gone through the list of all unknown issues but 
> couldn't find the relevant one.
> 
> Regards,
> Saurabh
> 
> -Original Message-
> From: Lukas Tribus [mailto:lu...@gmx.net]
> Sent: Monday, September 25, 2017 11:05 PM
> To: Saurabh Patwardhan; haproxy@formilux.org
> Cc: Manoj Mahadik; Tatiana Parshina
> Subject: Re: Question related to gpc0_rate values in stick-table
> 
> [External Email]
> 
> 
> 
> 
> Hello,
> 
> 
> Am 25.09.2017 um 10:34 schrieb Saurabh Patwardhan:
>> 
>> Hi HAProxy Team,
>> 
>> 
>> 
>> We are using haproxy 1.5.2 as a load balancer for our solution.
>> 
> 
> Before going any further here, notice that 1.5.2 is 3 years old and has a 
> huge amount of bugs:
> http://www.haproxy.org/bugs/bugs-1.5.2.html
> 
> I strongly suggest you upgrade the code before diving into a full blown 
> investigation, as very likely you hit at least one of the 199 known bugs in 
> haproxy 1.5.2.
> 
> 
> Regards,
> Lukas
> 
> 
> 
> 
> 
> The information transmitted herein is intended only for the person or entity 
> to which it is addressed and may contain confidential, proprietary and/or 
> privileged material. Any review, retransmission, dissemination or other use 
> of, or taking of any action in reliance upon, this information by persons or 
> entities other than the intended recipient is prohibited. If you received 
> this in error, please contact the sender and delete the material from any 
> computer.
>

RE: Question related to gpc0_rate values in stick-table

2017-10-17 Thread Saurabh Patwardhan

Gentle Reminder.
Can you please share your thought on the below queries?

Regards,
Saurabh

-Original Message-
From: Saurabh Patwardhan
Sent: Thursday, October 05, 2017 3:15 PM
To: 'Lukas Tribus'; haproxy@formilux.org
Cc: Manoj Mahadik; Tatiana Parshina
Subject: RE: Question related to gpc0_rate values in stick-table

Thanks Lukas.
Can you please provide the details of the known issue which might be related to 
this situation? I have gone through the list of all unknown issues but couldn't 
find the relevant one.

Regards,
Saurabh

-Original Message-
From: Lukas Tribus [mailto:lu...@gmx.net]
Sent: Monday, September 25, 2017 11:05 PM
To: Saurabh Patwardhan; haproxy@formilux.org
Cc: Manoj Mahadik; Tatiana Parshina
Subject: Re: Question related to gpc0_rate values in stick-table

[External Email]

Hello,

Am 25.09.2017 um 10:34 schrieb Saurabh Patwardhan:
>
> Hi HAProxy Team,
>
>
>
> We are using haproxy 1.5.2 as a load balancer for our solution.
>

Before going any further here, notice that 1.5.2 is 3 years old and has a huge 
amount of bugs:
http://www.haproxy.org/bugs/bugs-1.5.2.html

I strongly suggest you upgrade the code before diving into a full blown 
investigation, as very likely you hit at least one of the 199 known bugs in 
haproxy 1.5.2.

Regards,
Lukas

The information transmitted herein is intended only for the person or entity to 
which it is addressed and may contain confidential, proprietary and/or 
privileged material. Any review, retransmission, dissemination or other use of, 
or taking of any action in reliance upon, this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and delete the material from any computer.

2017-10-17 Thread adrian.p.smith

Re: Possible bug in task_wakeup() impacts Lua tasks

Apache Spark Using Companies

Re: [PATCH] checks: Add a keyword to specify the SNI in health checks

Re: [PATCH] Properly handle weight increase with consistent weight

Re: Possible bug in task_wakeup() impacts Lua tasks

Possible bug in task_wakeup() impacts Lua tasks

[PATCH] checks: Add a keyword to specify the SNI in health checks

Re: Haproxy config for sticky route

[PATCH] Properly handle weight increase with consistent weight

Re: Question related to gpc0_rate values in stick-table

RE: Question related to gpc0_rate values in stick-table

subscribe

12 matches

Site Navigation

Mail list logo

Footer information