From sogo@opengroupware.org  Wed Nov  2 16:38:01 2005
From: sogo@opengroupware.org (sogo@opengroupware.org)
Date: Wed, 2 Nov 2005 17:38:01 +0100 (CET)
Subject: [SOGo] Re: SOGo LDAP Cache Desactivation
In-Reply-To: <4CE89026-16D2-4836-B1DF-4F4041A12469@skyrix.com>
References: <45306.192.168.1.254.1130929113.squirrel@tomate.linagora.lan>
 <4CE89026-16D2-4836-B1DF-4F4041A12469@skyrix.com>
Message-ID: <55410.192.168.1.254.1130949481.squirrel@tomate.linagora.lan>

> Hi,
>
> I would prefer if we use the SOGo mailing list so that generic
> questions are answered there for later reference.
OK (corrected by present post)

I have set the cache flush rate to 1 sec as you said and all my ldap
update have corrected.
Thanks a lot.

>> We're facing a problem with the integration of Agenor with the LDAP
>> machinery of ministery.
>> There is an external app (accessible via the last Tab
>> 'Administration')
>> which allow to change some LDAP fields. The problem is when user
>> goes back
>> to Agenor, SOGo use LDAP cache which is not up to date.
>>
>> The direct and easy way to correct this would to desactivate SOGo
>> LDAP cache.
>> The solution was proposed by ministery, so LDAP performance
>> consequences
>> of it is not on our side (The fact is they're relying on a very
>> agressive
>> LDAP load balancing scheme : Many LDAP servers with round-robin DNS).
>>
>> The question is : Is possible to desable SOGo LDAP cache easily.
>
> You cannot disable it, but you can increase the cache flush rate with
> the AgenorCacheCheckInterval default, eg to "10" for flushing the
> cache every 10 seconds.
>
> I suppose its better to reduce the cache flush to 1s than to disable
> it completely so that at least for one HTTP transaction the cache is
> used.
>
>> I'm loocking for some Defaults setting to do it but i'm not sure it
>> exists.
>> If not (then no dessert) is there some (less easy) code
>> modification to
>> achieve this ?
>
> I think it should be sufficient to comment out the creation of the
> cache dictionaries in the -init method of the AgenorUserManager class
> (SoObjects/SOGo).
>
> Greets,
>    Helge
>
>
>



From sogo@opengroupware.org  Fri Nov  4 15:32:28 2005
From: sogo@opengroupware.org (sogo@opengroupware.org)
Date: Fri, 4 Nov 2005 16:32:28 +0100 (CET)
Subject: [SOGo] Make SOGo fully IE compliant
Message-ID: <37917.192.168.1.254.1131118348.squirrel@tomate.linagora.lan>

Hello,

Next week we'll investigate to patch SOGo to make it IE compliant.
This is mostly a webmail (javascripts) problem and i'd like to know if you
could give us some advices/rules on how to do it cleverly so our work
could be reused by you instead of you rewrite it the way you like.

More generaly, Do you continue to work on the main branch ?
If so, are there some instesting stuff for us you add ?


PS : Do you know this emacs stuff. Make it easy to edit remote files
without the need of X server on your Mac : www.gnu.org/software/tramp/
I'm currently using with GNUstep-emacs and i'm very happy of it.


From sogo@opengroupware.org  Mon Nov  7 12:41:11 2005
From: sogo@opengroupware.org (Helge Hess)
Date: Mon, 7 Nov 2005 13:41:11 +0100
Subject: [SOGo] Re: Make SOGo fully IE compliant
In-Reply-To: <37917.192.168.1.254.1131118348.squirrel@tomate.linagora.lan>
References: <37917.192.168.1.254.1131118348.squirrel@tomate.linagora.lan>
Message-ID: <c0f8264e720badf1c80202cc8fa1f690@skyrix.com>

On Nov 4, 2005, at 16:32, mwacker@linagora.com wrote:
> Next week we'll investigate to patch SOGo to make it IE compliant.
> This is mostly a webmail (javascripts) problem and i'd like to know if 
> you could give us some advices/rules on how to do it cleverly so our 
> work could be reused by you instead of you rewrite it the way you 
> like.

I don't know yet what issues IE JS gives, but I suppose I would use 
different .js files (one for Moz, one for IE) and the 
WEClientCapabilities object to detect IE.

eg:
   <var:if
    condition="context.required.clientCapabilities.isInternetExplorer">
    <script filename="generic-ie.js"> </script>
   </var:if>
   <var:if
    condition="context.required.clientCapabilities.isInternetExplorer"
    const:negate="1">
    <script filename="generic-moz.js"> </script>
   </var:if>

I think there are also per-component .js files where this could be done 
automagically in the component frame (eg UIxAppointmentEditor.js).


Besides JS there are IE CSS support issues. One of the first things I 
wanted to do is to rewrite the toolbar to use tables and images instead 
of CSS and anker background-images. While the latter is a beautiful 
solution for Mozilla, it doesn't work very well with IE and older 
browsers.

> More generaly, Do you continue to work on the main branch ?

Yes, of course. Though this is most likely to evolve a bit different 
from the Agenor branch (both in UI and backend). But we should be able 
to merge features between the two branches back and forth.

I plan to do a lot of work on trunk in Q1/2006.

> If so, are there some instesting stuff for us you add ?

Not yet ;-) Check the ChangeLogs.

> PS : Do you know this emacs stuff. Make it easy to edit remote files
> without the need of X server on your Mac : www.gnu.org/software/tramp/
> I'm currently using with GNUstep-emacs and i'm very happy of it.

I have no issues with X11 and this used to be the least troublesome way 
for me. With all those remote filesystem stuff I tend to have timestamp 
issues ...
In the past I have also worked with Ange-FTP which is quite nice (don't 
know what is better with tramp).

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org


From sogo@opengroupware.org  Mon Nov 14 16:25:30 2005
From: sogo@opengroupware.org (sogo@opengroupware.org)
Date: Mon, 14 Nov 2005 17:25:30 +0100 (CET)
Subject: [SOGo] Re: Make SOGo fully IE compliant + HTTP Adaptor SIGPIPE
In-Reply-To: <c0f8264e720badf1c80202cc8fa1f690@skyrix.com>
References: <37917.192.168.1.254.1131118348.squirrel@tomate.linagora.lan>
 <c0f8264e720badf1c80202cc8fa1f690@skyrix.com>
Message-ID: <41190.192.168.1.254.1131985530.squirrel@tomate.linagora.lan>

> On Nov 4, 2005, at 16:32, mwacker@linagora.com wrote:
>> Next week we'll investigate to patch SOGo to make it IE compliant.
>> This is mostly a webmail (javascripts) problem and i'd like to know if
>> you could give us some advices/rules on how to do it cleverly so our
>> work could be reused by you instead of you rewrite it the way you
>> like.
>
> I don't know yet what issues IE JS gives, but I suppose I would use
> different .js files (one for Moz, one for IE) and the
> WEClientCapabilities object to detect IE.
>
> eg:
>    <var:if
>     condition="context.required.clientCapabilities.isInternetExplorer">
>     <script filename="generic-ie.js"> </script>
>    </var:if>
>    <var:if
>     condition="context.required.clientCapabilities.isInternetExplorer"
>     const:negate="1">
>     <script filename="generic-moz.js"> </script>
>    </var:if>

I can't make work :
I tried to put
<p>
	Anybody there ?
	     <var:string value="context.clientCapabilities.isInternetExplorer" />
	     <var:string value="context.clientCapabilities.userAgent" />
	And there ?
	     <var:string
value="context.required.clientCapabilities.isInternetExplorer" />
	     <var:string value="context.required.clientCapabilities.userAgent" />

</p>
in UIxMailToSelection.wox
None of the var:string is displayed (and as a consequence the var:if don't
work neither).
Am i missing something ?
The fact is i corrected most JS problem but now i need user agent
detection to have the full final correcition for IE _and_ Firefox (it was
mainly DOM childNodes indexing problem).



From sogo@opengroupware.org  Mon Nov 14 17:33:05 2005
From: sogo@opengroupware.org (Helge Hess)
Date: Mon, 14 Nov 2005 18:33:05 +0100
Subject: [SOGo] Re: Make SOGo fully IE compliant + HTTP Adaptor SIGPIPE
In-Reply-To: <41190.192.168.1.254.1131985530.squirrel@tomate.linagora.lan>
References: <37917.192.168.1.254.1131118348.squirrel@tomate.linagora.lan> <c0f8264e720badf1c80202cc8fa1f690@skyrix.com> <41190.192.168.1.254.1131985530.squirrel@tomate.linagora.lan>
Message-ID: <7CBD4288-B3D0-497E-A78D-BD564C428FFD@skyrix.com>

On 14. Nov 2005, at 17:25 Uhr, mwacker@linagora.com wrote:
> 	And there ?
> 	     <var:string
> value="context.required.clientCapabilities.isInternetExplorer" />
> 	     <var:string  
> value="context.required.clientCapabilities.userAgent" />

Its context.request.clientCapabilities.

You find the available bindings in the WEClientCapabilities object  
(part of NGObjWeb).

Greets,
   Helge


From sogo@opengroupware.org  Wed Nov 16 16:52:22 2005
From: sogo@opengroupware.org (sogo@opengroupware.org)
Date: Wed, 16 Nov 2005 17:52:22 +0100 (CET)
Subject: [SOGo] Badly displayed adresses in MailViewer corrected, but
Message-ID: <53028.192.168.1.254.1132159942.squirrel@tomate.linagora.lan>

Hi,

I discovered that those badly displayed adresses in MailViewer were
correctly displayed in MailListView. So i compared their .wox and put the
same working formatter in MailViewer as in MailListViewer :

<var:string value="currentAddress"
formatter="context.mailEnvelopeAddressFormatter" />
Instead of
 <var:string value="currentAddress"
formatter="context.mailEnvelopeFullAddressFormatter" />

The problem left out is the mailto href enclosing it not right neither :

The UIxMailView.wox parts

<a var:href="currentAddressLink">
      <var:string value="currentAddress"
formatter="context.mailEnvelopeAddressFormatter" />
</a>

gives

<a
href="mailto:=?iso-8859-15?q?A=20Ali=E9nor=20=2D=20Tests=20montee=20en=20charge=20Ogo=2FFemmes=20=3CAlienor=2EA=40equipement=2Egouv=2Efr=3E?=@sogotest-01.csac.melanie2.i2">
    "A_Aliénor_-_Tests_montee_en_charge_Ogo/Femmes_&lt;
     Alienor.A@equipement.gouv.fr&gt;@sogotest-01.
     csac.melanie2.i2_(par_Intranet,_dépôt_
     alienor.a@equipement.gouv.fr)"
</a>

Where to go from there ?
Put another formatter on currentAddressLink or rearrange
currentAddressLink directly to correct those bad codes ?


From sogo@opengroupware.org  Wed Nov 16 18:03:36 2005
From: sogo@opengroupware.org (Helge Hess)
Date: Wed, 16 Nov 2005 19:03:36 +0100
Subject: [SOGo] Badly displayed adresses in MailViewer corrected, but
In-Reply-To: <53028.192.168.1.254.1132159942.squirrel@tomate.linagora.lan>
References: <53028.192.168.1.254.1132159942.squirrel@tomate.linagora.lan>
Message-ID: <0CA222EE-AF69-49FE-8805-46362EBF2F3B@skyrix.com>

On 16. Nov 2005, at 17:52 Uhr, mwacker@linagora.com wrote:
> I discovered that those badly displayed adresses in MailViewer were
> correctly displayed in MailListView. So i compared their .wox and =20
> put the
> same working formatter in MailViewer as in MailListViewer :
>
> <var:string value=3D"currentAddress"
> formatter=3D"context.mailEnvelopeAddressFormatter" />
> Instead of
>  <var:string value=3D"currentAddress"
> formatter=3D"context.mailEnvelopeFullAddressFormatter" />

Actually this is the same formatter class, =20
UIxEnvelopeAddressFormatter, but with different options:
---snip---
- (NSFormatter *)mailEnvelopeAddressFormatter {
   return [[[UIxEnvelopeAddressFormatter alloc] init] autorelease];
}
- (NSFormatter *)mailEnvelopeFullAddressFormatter {
   return [[[UIxEnvelopeAddressFormatter alloc]
	    initWithMaxLength:256 generateFullEMail:YES] autorelease];
}
---snap---

The first method (just -init) does:
---snip---
- (id)init {
   return [self initWithMaxLength:128 generateFullEMail:NO];
}
---snap---

I suppose the difference is this section:
---snip---
- (NSString *)stringForEnvelopeAddress:(NGImap4EnvelopeAddress *)=20
_address {
   NSString *s;

   if ([self generateFullEMail])
     return [_address email];

   s =3D [_address personalName];
   if ([s isNotNull]) return s;

   s =3D [_address baseEMail];
   if ([s isNotNull]) return s;

   [self warnWithFormat:@"unexpected envelope address: %@", _address];
   return [_address stringValue];
}
---snap---

In other words the "full" formatter includes the email address and =20
everything. The regular one just prints out the name of the name of =20
the sender when available.

Did you create a bugreport?
Can you reproduce the issue on agenor.opengroupware.org?

> The problem left out is the mailto href enclosing it not right =20
> neither :
>
> The UIxMailView.wox parts
>
> <a var:href=3D"currentAddressLink">
>       <var:string value=3D"currentAddress"
> formatter=3D"context.mailEnvelopeAddressFormatter" />
> </a>
>
> gives
>
> <a
> href=3D"mailto:=3D?iso-8859-15?q?=20
> A=3D20Ali=3DE9nor=3D20=3D2D=3D20Tests=3D20montee=3D20en=3D20charge=3D20O=
go=3D2FFemmes=3D20=3D3=20
> CAlienor=3D2EA=3D40equipement=3D2Egouv=3D2Efr=3D3E?=20
> =3D@sogotest-01.csac.melanie2.i2">
>     "A_Ali=E9nor_-_Tests_montee_en_charge_Ogo/Femmes_&lt;
>      Alienor.A@equipement.gouv.fr&gt;@sogotest-01.
>      csac.melanie2.i2_(par_Intranet,_d=E9p=F4t_
>      alienor.a@equipement.gouv.fr)"
> </a>
>
> Where to go from there ?

Well, we must be able to reproduce the issue, then we can check it. =20
Maybe there is some Cyrus charset decoding issue or maybe this is an =20
address decoding issue in NGImap4.

> Put another formatter on currentAddressLink or rearrange
> currentAddressLink directly to correct those bad codes ?

Well, I suppose we first need to find out why the escaping is wrong. =20
Then we can make decisions on how to approach it.

Mit freundlichen Gr=FC=DFen,
   Helge He=DF
--=20
SKYRIX Software AG      Tel:    +49-391-6623-200
Universit=E4tsplatz 12    Fax:    +49-391-6623-599
39104 Magdeburg
Germany


From sogo@opengroupware.org  Thu Nov 17 09:20:58 2005
From: sogo@opengroupware.org (sogo@opengroupware.org)
Date: Thu, 17 Nov 2005 10:20:58 +0100 (CET)
Subject: [SOGo] Badly displayed adresses in MailViewer corrected, but
In-Reply-To: <0CA222EE-AF69-49FE-8805-46362EBF2F3B@skyrix.com>
References: <53028.192.168.1.254.1132159942.squirrel@tomate.linagora.lan>
 <0CA222EE-AF69-49FE-8805-46362EBF2F3B@skyrix.com>
Message-ID: <34415.192.168.1.254.1132219258.squirrel@tomate.linagora.lan>

> On 16. Nov 2005, at 17:52 Uhr, mwacker@linagora.com wrote:
>> I discovered that those badly displayed adresses in MailViewer were
>> correctly displayed in MailListView. So i compared their .wox and
>> put the
>> same working formatter in MailViewer as in MailListViewer :
>>
>> <var:string value="currentAddress"
>> formatter="context.mailEnvelopeAddressFormatter" />
>> Instead of
>>  <var:string value="currentAddress"
>> formatter="context.mailEnvelopeFullAddressFormatter" />
>
> Actually this is the same formatter class,
> UIxEnvelopeAddressFormatter, but with different options:
> ---snip---
> - (NSFormatter *)mailEnvelopeAddressFormatter {
>    return [[[UIxEnvelopeAddressFormatter alloc] init] autorelease];
> }
> - (NSFormatter *)mailEnvelopeFullAddressFormatter {
>    return [[[UIxEnvelopeAddressFormatter alloc]
> 	    initWithMaxLength:256 generateFullEMail:YES] autorelease];
> }
> ---snap---
>
> The first method (just -init) does:
> ---snip---
> - (id)init {
>    return [self initWithMaxLength:128 generateFullEMail:NO];
> }
> ---snap---
>
> I suppose the difference is this section:
> ---snip---
> - (NSString *)stringForEnvelopeAddress:(NGImap4EnvelopeAddress *)
> _address {
>    NSString *s;
>
>    if ([self generateFullEMail])
>      return [_address email];
>
>    s = [_address personalName];
>    if ([s isNotNull]) return s;
>
>    s = [_address baseEMail];
>    if ([s isNotNull]) return s;
>
>    [self warnWithFormat:@"unexpected envelope address: %@", _address];
>    return [_address stringValue];
> }
> ---snap---
>
> In other words the "full" formatter includes the email address and
> everything. The regular one just prints out the name of the name of
> the sender when available.
I went to this point by my own. But as you say farther. The problem is
from elsewhere.


> Did you create a bugreport?
No. I apologize. I'll do just it after having reproduced it ...
> Can you reproduce the issue on agenor.opengroupware.org?
I just did a spotlight search to retrieve my July access to it. Can't find it
What i remember is  http://agenor.opengroupware.org/sogoMaX/so but it's
not working.
Maybe the corresponding sogod is not running at all. Maybe my remebering
is bad.

>
>> The problem left out is the mailto href enclosing it not right
>> neither :
>>
>> The UIxMailView.wox parts
>>
>> <a var:href="currentAddressLink">
>>       <var:string value="currentAddress"
>> formatter="context.mailEnvelopeAddressFormatter" />
>> </a>
>>
>> gives
>>
>> <a
>> href="mailto:=?iso-8859-15?q?
>> A=20Ali=E9nor=20=2D=20Tests=20montee=20en=20charge=20Ogo=2FFemmes=20=3
>> CAlienor=2EA=40equipement=2Egouv=2Efr=3E?
>> =@sogotest-01.csac.melanie2.i2">
>>     "A_Aliénor_-_Tests_montee_en_charge_Ogo/Femmes_&lt;
>>      Alienor.A@equipement.gouv.fr&gt;@sogotest-01.
>>      csac.melanie2.i2_(par_Intranet,_dépôt_
>>      alienor.a@equipement.gouv.fr)"
>> </a>
>>
>> Where to go from there ?
>
> Well, we must be able to reproduce the issue, then we can check it.
> Maybe there is some Cyrus charset decoding issue or maybe this is an
> address decoding issue in NGImap4.
>
>> Put another formatter on currentAddressLink or rearrange
>> currentAddressLink directly to correct those bad codes ?
>
> Well, I suppose we first need to find out why the escaping is wrong.
> Then we can make decisions on how to approach it.
Yes i need to show you. Is it possible to have znek (or someone else)
checking my url.
Or let me do a ssh to agenor.opengroupware so i can set up my sogod by my
self.

>
> Mit freundlichen Grüßen,
>    Helge Heß
A l'amitié franco-allemande


From sogo@opengroupware.org  Thu Nov 17 10:37:02 2005
From: sogo@opengroupware.org (sogo@opengroupware.org)
Date: Thu, 17 Nov 2005 11:37:02 +0100 (CET)
Subject: [SOGo] Badly displayed adresses in MailViewer corrected, but
In-Reply-To: <34415.192.168.1.254.1132219258.squirrel@tomate.linagora.lan>
References: <53028.192.168.1.254.1132159942.squirrel@tomate.linagora.lan>
 <0CA222EE-AF69-49FE-8805-46362EBF2F3B@skyrix.com>
 <34415.192.168.1.254.1132219258.squirrel@tomate.linagora.lan>
Message-ID: <36614.192.168.1.254.1132223822.squirrel@tomate.linagora.lan>

>> Did you create a bugreport?
> No. I apologize. I'll do just it after having reproduced it ...
>> Can you reproduce the issue on agenor.opengroupware.org?
> I just did a spotlight search to retrieve my July access to it. Can't find
> it
> What i remember is  http://agenor.opengroupware.org/sogoMaX/so but it's
> not working.
> Maybe the corresponding sogod is not running at all. Maybe my remebering
> is bad.

I finally retrieve my URL. it was http://agenor.opengroupware.org/SOGoMX/so.
But it's not UP (No sogod behind it i presume). So an ssh access for user
max would be sufficient for me to make it UP. The fact is i'm not sure to
remember my password and i can't do ssh from where i'm now (i'll try
tonight). Could you ask someone (admin) to reset my password please.

Thx



From sogo@opengroupware.org  Thu Nov 17 17:41:18 2005
From: sogo@opengroupware.org (Helge Hess)
Date: Thu, 17 Nov 2005 18:41:18 +0100
Subject: [SOGo] Feature List
In-Reply-To: <36614.192.168.1.254.1132223822.squirrel@tomate.linagora.lan>
References: <53028.192.168.1.254.1132159942.squirrel@tomate.linagora.lan>    <0CA222EE-AF69-49FE-8805-46362EBF2F3B@skyrix.com> <34415.192.168.1.254.1132219258.squirrel@tomate.linagora.lan> <36614.192.168.1.254.1132223822.squirrel@tomate.linagora.lan>
Message-ID: <941BE736-C8C4-45B7-AE43-7905D92B4F70@opengroupware.org>

Hi Maxime,

people now and then ask for a "feature list" of SOGo. I wonder  
whether you could find some time to turn one of your requirement  
documents into a small feature list for the current Agenor branch SOGo.

What is currently implemented in which module? A short outline of all  
the small integration "features" like shared mailbox permissions etc.

I think something like this would be quite valuable for all of us.

Thanks a lot,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org


From sogo@opengroupware.org  Mon Nov 21 15:03:11 2005
From: sogo@opengroupware.org (sogo@opengroupware.org)
Date: Mon, 21 Nov 2005 16:03:11 +0100 (CET)
Subject: [SOGo] HttpAdaptor SIGPIPE
Message-ID: <52389.192.168.1.254.1132585391.squirrel@tomate.linagora.lan>

Hi,

Sometimes, i could not describe in which circumstances exactly, the sogod
logs tells :

Nov 10 15:31:58 sogod-0.9 [5959]: [WARN] <0x0836CADC[WOHttpAdaptor]>
caught SIGPIPE !

After that content isn't served correctly (page are still available but
without storage content : no apt showed, no mailboxes)
The only thing i know about that is that it appends frequently after a
certain amount time (3-4 days) during which sogod is not requested at all.

i scanned the web to see if other SOPE app get the same problem with no luck.


From sogo@opengroupware.org  Mon Nov 21 15:16:20 2005
From: sogo@opengroupware.org (Helge Hess)
Date: Mon, 21 Nov 2005 16:16:20 +0100
Subject: [SOGo] HttpAdaptor SIGPIPE
In-Reply-To: <52389.192.168.1.254.1132585391.squirrel@tomate.linagora.lan>
References: <52389.192.168.1.254.1132585391.squirrel@tomate.linagora.lan>
Message-ID: <b1ba82456f643df6d1caeab4d774d4d8@opengroupware.org>

On Nov 21, 2005, at 16:03, mwacker@linagora.com wrote:
> Nov 10 15:31:58 sogod-0.9 [5959]: [WARN] <0x0836CADC[WOHttpAdaptor]>
> caught SIGPIPE !

SIGPIPE happens if some socket goes down. This can be one of those:
a) Apache=>SOGo socket
b) LDAP connection
c) IMAP4 connection
d) PostgreSQL connection

Its a bit hard to debug if we can't reproduce it though :-/

> After that content isn't served correctly (page are still available but
> without storage content : no apt showed, no mailboxes)

Weird. Please file a bugreport.

Its not unusual that signal handler bugs corrupt memory, so maybe there 
is some bug in there. But of course the real question is why the 
SIGPIPE occurs in the first place.

One thing to do for you: if you have a sogod instance running for some 
two days, list the file descriptors which are opened by the process 
(using lsof as root).
Attach that to the bug. Maybe we can see what connections are still 
open and might go down.

> The only thing i know about that is that it appends frequently after a
> certain amount time (3-4 days) during which sogod is not requested at 
> all.

It would be best if SOGo instances would recycle themselves once a day 
automagically.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org


From sogo@opengroupware.org  Mon Nov 21 16:18:09 2005
From: sogo@opengroupware.org (sogo@opengroupware.org)
Date: Mon, 21 Nov 2005 17:18:09 +0100 (CET)
Subject: [SOGo] HttpAdaptor SIGPIPE
In-Reply-To: <b1ba82456f643df6d1caeab4d774d4d8@opengroupware.org>
References: <52389.192.168.1.254.1132585391.squirrel@tomate.linagora.lan>
 <b1ba82456f643df6d1caeab4d774d4d8@opengroupware.org>
Message-ID: <54177.192.168.1.254.1132589889.squirrel@tomate.linagora.lan>

> On Nov 21, 2005, at 16:03, mwacker@linagora.com wrote:
>> Nov 10 15:31:58 sogod-0.9 [5959]: [WARN] <0x0836CADC[WOHttpAdaptor]>
>> caught SIGPIPE !
>
> SIGPIPE happens if some socket goes down. This can be one of those:
> a) Apache=>SOGo socket
> b) LDAP connection
> c) IMAP4 connection
> d) PostgreSQL connection
>
> Its a bit hard to debug if we can't reproduce it though :-/
>
>> After that content isn't served correctly (page are still available but
>> without storage content : no apt showed, no mailboxes)
>
> Weird. Please file a bugreport.
>
> Its not unusual that signal handler bugs corrupt memory, so maybe there
> is some bug in there. But of course the real question is why the
> SIGPIPE occurs in the first place.
>
> One thing to do for you: if you have a sogod instance running for some
> two days, list the file descriptors which are opened by the process
> (using lsof as root).
> Attach that to the bug. Maybe we can see what connections are still
> open and might go down.
>
>> The only thing i know about that is that it appends frequently after a
>> certain amount time (3-4 days) during which sogod is not requested at
>> all.
>
> It would be best if SOGo instances would recycle themselves once a day
> automagically.

I'll put some cron job to do it. Just after i'll be able get a sogod
sigpiped, to get lsof on it, and fill the detailed bug report.




From sogo@opengroupware.org  Mon Nov 21 16:39:56 2005
From: sogo@opengroupware.org (Helge Hess)
Date: Mon, 21 Nov 2005 17:39:56 +0100
Subject: [SOGo] HttpAdaptor SIGPIPE
In-Reply-To: <54177.192.168.1.254.1132589889.squirrel@tomate.linagora.lan>
References: <52389.192.168.1.254.1132585391.squirrel@tomate.linagora.lan> <b1ba82456f643df6d1caeab4d774d4d8@opengroupware.org> <54177.192.168.1.254.1132589889.squirrel@tomate.linagora.lan>
Message-ID: <1599a9921bf84a662ff5a78edf264e14@opengroupware.org>

On Nov 21, 2005, at 17:18, mwacker@linagora.com wrote:
> I'll put some cron job to do it.

This is a temporary workaround, but it can loose requests. If the 
appserver itself does the restart, it can do so in a "safe" way.
Please file a bugreport for this.

SOGo already does a clean recycle after reaching a certain memory limit.

> Just after i'll be able get a sogod sigpiped, to get lsof on it

No, please do this _before_ it sigpipes but after a long, idle run [2 
days or so] (so do not use the cronjob during this test).

I assume that maybe some connections are leaked or so (honestly 
libldap2 sounds like a prime suspect ;-)

Thanks,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org


From sogo@opengroupware.org  Mon Nov 21 16:53:46 2005
From: sogo@opengroupware.org (sogo@opengroupware.org)
Date: Mon, 21 Nov 2005 17:53:46 +0100 (CET)
Subject: [SOGo] HttpAdaptor SIGPIPE
In-Reply-To: <1599a9921bf84a662ff5a78edf264e14@opengroupware.org>
References: <52389.192.168.1.254.1132585391.squirrel@tomate.linagora.lan>
 <b1ba82456f643df6d1caeab4d774d4d8@opengroupware.org>
 <54177.192.168.1.254.1132589889.squirrel@tomate.linagora.lan>
 <1599a9921bf84a662ff5a78edf264e14@opengroupware.org>
Message-ID: <55634.192.168.1.254.1132592026.squirrel@tomate.linagora.lan>

> On Nov 21, 2005, at 17:18, mwacker@linagora.com wrote:
>> I'll put some cron job to do it.
>
> This is a temporary workaround, but it can loose requests. If the
> appserver itself does the restart, it can do so in a "safe" way.
> Please file a bugreport for this.
>
> SOGo already does a clean recycle after reaching a certain memory limit.
>
>> Just after i'll be able get a sogod sigpiped, to get lsof on it
>
> No, please do this _before_ it sigpipes but after a long, idle run [2
> days or so] (so do not use the cronjob during this test).

I would have mean :
I'll put some cron job just after having sent the bug report with lsof
output in it.

So were misunderstanding, but saying the same thing.

Just after, i'll learn deutch speaking (and you, french OK ? ;-)
Or maybe i'll just try to write better english. (sorry)




From sogo@opengroupware.org  Tue Nov 22 15:08:01 2005
From: sogo@opengroupware.org (sogo@opengroupware.org)
Date: Tue, 22 Nov 2005 16:08:01 +0100 (CET)
Subject: [SOGo] SOGo behind a Reverse Proxy
Message-ID: <45978.192.168.1.254.1132672081.squirrel@tomate.linagora.lan>

Hi Helge,

I've got some complex problem to expose. I hope to be clear enough.
Well as a reminder i explain how SOGo is accessed in our net architecture.

web client send request to a reverse-proxy (RP) with say
http://address-proxy/sogo. The RP do some HTTP marking on
x-mineqprovenance HTTP header field, telling if request comes from
internet or intranet.
The request is then forwarded to pound (http://address-pound) and then
forwarded to apache from pound.
In apache, there's a module which checks the presence of the
x-mineqprovenance header and forbids access if such a header field is not
present.
If the x-mineqprovenance field is found in the header and the user
authenticated, the request enters sogod.
In the HTML pages returned  there are some absolute 'href' and 'src' field
build by sogo containing absolute URLs. The host written in those URLs is
'adresss-pound' (retrieved from the HTTP header Host field, and not from
the apache servername as you said in a previous mail).

When the HTML is interpreted in the web client, the
'http://address-pound/...' URLs initiate new HTTP requests which don't
pass through the proxy. So the request are not marked (x-mineqprovenance)
and so are refused by apache. These links are broken in those HTML pages.

The problem would not appear if URLs where relative, in the HTML produced
from wox. But i noticed that every 'rsrc:src' and 'var:href' wox
constructs produce some absolute path with hostname coming from the Host
HTTP header field.
Is there a way to change this behavior ?
Or any other clever way correct the whole problem ?



From sogo@opengroupware.org  Tue Nov 22 15:49:46 2005
From: sogo@opengroupware.org (Helge Hess)
Date: Tue, 22 Nov 2005 16:49:46 +0100
Subject: [SOGo] SOGo behind a Reverse Proxy
In-Reply-To: <45978.192.168.1.254.1132672081.squirrel@tomate.linagora.lan>
References: <45978.192.168.1.254.1132672081.squirrel@tomate.linagora.lan>
Message-ID: <02cae64acd3b3ec2429193315450b355@skyrix.com>

On Nov 22, 2005, at 16:08, mwacker@linagora.com wrote:
> web client send request to a reverse-proxy (RP) with say
> http://address-proxy/sogo. The RP do some HTTP marking on
> x-mineqprovenance HTTP header field, telling if request comes from
> internet or intranet.
> The request is then forwarded to pound (http://address-pound) and then
> forwarded to apache from pound.
...
> The host written in those URLs is
> 'adresss-pound' (retrieved from the HTTP header Host field, and not 
> from
> the apache servername as you said in a previous mail).

Well, that would be a bug in Pound?! Why would it rewrite the 'host' 
header to its own host? A proxy must pass the header as-is.
This should be fixed.

Nevertheless I'm all in for removing absolute URLs. If 
WOUseRelativeURLs is on (which it is per default), it should only 
generate relative URLs. But of course there can be bugs :-) So we 
should also fix that.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org


From sogo@opengroupware.org  Tue Nov 22 16:08:39 2005
From: sogo@opengroupware.org (sogo@opengroupware.org)
Date: Tue, 22 Nov 2005 17:08:39 +0100 (CET)
Subject: [SOGo] SOGo behind a Reverse Proxy
In-Reply-To: <02cae64acd3b3ec2429193315450b355@skyrix.com>
References: <45978.192.168.1.254.1132672081.squirrel@tomate.linagora.lan>
 <02cae64acd3b3ec2429193315450b355@skyrix.com>
Message-ID: <47271.192.168.1.254.1132675719.squirrel@tomate.linagora.lan>

> On Nov 22, 2005, at 16:08, mwacker@linagora.com wrote:
>> web client send request to a reverse-proxy (RP) with say
>> http://address-proxy/sogo. The RP do some HTTP marking on
>> x-mineqprovenance HTTP header field, telling if request comes from
>> internet or intranet.
>> The request is then forwarded to pound (http://address-pound) and then
>> forwarded to apache from pound.
> ...
>> The host written in those URLs is
>> 'adresss-pound' (retrieved from the HTTP header Host field, and not
>> from
>> the apache servername as you said in a previous mail).
>
> Well, that would be a bug in Pound?!
It's not Pound. It's the HTTP-Marker (x-mineqprovenance) reverse-proxy, in
the previous stage.

> Why would it rewrite the 'host'
> header to its own host? A proxy must pass the header as-is.
In fact, i read HTTP RFC about this because i wanted to accuse ministery
infrastructure first (the easiest way to resolve Agenor bug;-). But RFC
only says :
"
An HTTP/1.1 proxy MUST ensure that any request message it forwards does
contain an appropriate Host header field that identifies the service being
requested by the proxy.
"
> This should be fixed.
What i understand is that the proxy is seen as a normal client by servers.
So it seems normal  to me that the proxy put the name of the requested
server in the HOST field.

>
> Nevertheless I'm all in for removing absolute URLs. If
> WOUseRelativeURLs is on (which it is per default), it should only
> generate relative URLs.
> But of course there can be bugs :-) So we
> should also fix that.
This doesn't change anything for us : URLs are still absolutes, with
WOUseRelativeURLs=YES (or without it at all, ie default).  So yes, there
are bugs

If the ministery respects HTTP Host policy (need to have expert sentence
about it) we'll have to debug WOUseRelativeURLs. I'll try ...


From sogo@opengroupware.org  Tue Nov 22 18:07:28 2005
From: sogo@opengroupware.org (Helge Hess)
Date: Tue, 22 Nov 2005 19:07:28 +0100
Subject: [SOGo] SOGo behind a Reverse Proxy
In-Reply-To: <47271.192.168.1.254.1132675719.squirrel@tomate.linagora.lan>
References: <45978.192.168.1.254.1132672081.squirrel@tomate.linagora.lan> <02cae64acd3b3ec2429193315450b355@skyrix.com> <47271.192.168.1.254.1132675719.squirrel@tomate.linagora.lan>
Message-ID: <569A5229-DF1C-4D7B-A269-30D484BD9CDE@opengroupware.org>

On 22. Nov 2005, at 17:08 Uhr, mwacker@linagora.com wrote:
> It's not Pound. It's the HTTP-Marker (x-mineqprovenance) reverse- 
> proxy, in
> the previous stage.

What kind of software is this proxy? Why does it rewrite the host  
header?

>> Why would it rewrite the 'host'
>> header to its own host? A proxy must pass the header as-is.
> In fact, i read HTTP RFC about this because i wanted to accuse  
> ministery
> infrastructure first (the easiest way to resolve Agenor bug;-). But  
> RFC
> only says :
> "
> An HTTP/1.1 proxy MUST ensure that any request message it forwards  
> does
> contain an appropriate Host header field that identifies the  
> service being
> requested by the proxy.
> "

Hm, yes, thats not very clear and can be read multiple ways as it  
doesn't define "appropriate". In my opinion the "appropriate" host is  
the host of the initial request.

>> This should be fixed.
> What i understand is that the proxy is seen as a normal client by  
> servers.
> So it seems normal  to me that the proxy put the name of the requested
> server in the HOST field.

A proxy in the HTTP sense is definitely not a "normal client". The  
spec explicitly distinguishes proxies and origin servers and also  
adds proxy specific headers (eg Via).

Anyway, I suppose there is no point discussing that. Personally I can  
see situations where both variants make sense.

> This doesn't change anything for us : URLs are still absolutes, with
> WOUseRelativeURLs=YES (or without it at all, ie default).  So yes,  
> there
> are bugs

Yes, needs to be checked (bug report?). URL processing is not exactly  
trivial to get right.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org


From sogo@opengroupware.org  Wed Nov 23 18:00:40 2005
From: sogo@opengroupware.org (sogo@opengroupware.org)
Date: Wed, 23 Nov 2005 19:00:40 +0100 (CET)
Subject: [SOGo] Help URLs
Message-ID: <42718.192.168.1.254.1132768840.squirrel@tomate.linagora.lan>

Hello,

I'm filling the online help of Agenor (really exciting ;) and on some
page, the help URL targets "OpenGroupware.org.html".
These page are Contacts, Calendar/proposal, Calendar/edit (and perhaps
some others).

I think that it's the page name which is not correctly initialized, but I
did not find where is the problem. Have you any idea on that ?

Moreover, for the webmail, the "helpURL" function is missing in
UIxMailMainFrame.m.
I try to copy/past the method from UIxPageFrame.m, but it seems to be bad
idea...

Have you an idea about something I can try to build these help URLs ?

Good Evening !


From sogo@opengroupware.org  Thu Nov 24 13:30:51 2005
From: sogo@opengroupware.org (Helge Hess)
Date: Thu, 24 Nov 2005 14:30:51 +0100
Subject: [SOGo] Help URLs
In-Reply-To: <42718.192.168.1.254.1132768840.squirrel@tomate.linagora.lan>
References: <42718.192.168.1.254.1132768840.squirrel@tomate.linagora.lan>
Message-ID: <1367176f48c48e2cdcdb67c442144fa8@opengroupware.org>

Hi,

to quote what we are talking about:
---snip---
- (NSString *)helpURL {
   return [NSString stringWithFormat:@"help/%@.html", self->title];
}
- (NSString *)helpWindowTarget {
   return [NSString stringWithFormat:@"Help_%@", self->title];
}
---snap---

Actually I don't understand this code, the title of a page is a 
localized label, how can it be used as a resource specifier?

I guess what is actually required is:
- (NSString *)helpURL {
   return [NSString stringWithFormat:@"help/%@.html",
             [[[self context] page] name]];
}

Resulting in links like "html/UIxContactEditor.html".


Further I do not know how the help system works. Apparently it 
generates a relative URL (help/). Where is this 'help' container 
specified?
Shouldn't that be a regular WebServerResource?

I guess it should be done like that:
- (NSString *)helpURL {
   return [[self resourceManager]
                 urlForResourceNamed:
                   [[self name] stringByAppendingString:@".html"]
                 languages:nil];
}

The SOPE localization system would select the proper help pages which 
would need to be available in WebServerResources (English.lproj, 
French.lproj etc).


I suppose we only get answers for that when ZNeK is back from NZ.


On Nov 23, 2005, at 19:00, farmand@linagora.com wrote:
> I'm filling the online help of Agenor (really exciting ;) and on some
> page, the help URL targets "OpenGroupware.org.html".
> These page are Contacts, Calendar/proposal, Calendar/edit (and perhaps
> some others).

Since eg UIxContactEditor.wox specifies a 'title' binding for the 
frame, I don't know why/when this would happen. Maybe if there is no 
translation for the title.

> I think that it's the page name which is not correctly initialized, 
> but I
> did not find where is the problem. Have you any idea on that ?

Well, use the debugger and -logWithFormat: and search for the issue.

> Moreover, for the webmail, the "helpURL" function is missing in
> UIxMailMainFrame.m.
> I try to copy/past the method from UIxPageFrame.m, but it seems to be 
> bad
> idea...

No, I think a copy is OK in this case because those are really separate 
"UIs". In a shrinkwrapped SOGo all pages would use the same frame (and 
UI).

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org


From sogo@opengroupware.org  Thu Nov 24 13:43:19 2005
From: sogo@opengroupware.org (sogo@opengroupware.org)
Date: Thu, 24 Nov 2005 14:43:19 +0100 (CET)
Subject: [SOGo] Help URLs
In-Reply-To: <1367176f48c48e2cdcdb67c442144fa8@opengroupware.org>
References: <42718.192.168.1.254.1132768840.squirrel@tomate.linagora.lan>
 <1367176f48c48e2cdcdb67c442144fa8@opengroupware.org>
Message-ID: <58480.192.168.1.254.1132839799.squirrel@tomate.linagora.lan>

> Hi,

Hello !

> to quote what we are talking about:
> ---snip---
> - (NSString *)helpURL {
>    return [NSString stringWithFormat:@"help/%@.html", self->title];
> }
> - (NSString *)helpWindowTarget {
>    return [NSString stringWithFormat:@"Help_%@", self->title];
> }
> ---snap---
>
> Actually I don't understand this code, the title of a page is a
> localized label, how can it be used as a resource specifier?

Ah ! I thought it was me who did not understand this code.

> snip
> Resulting in links like "html/UIxContactEditor.html".

Yes, it is what the code is supposed to do.

> Further I do not know how the help system works. Apparently it
> generates a relative URL (help/). Where is this 'help' container
> specified?
> Shouldn't that be a regular WebServerResource?

Yes, I think it would be better.

> snip
> The SOPE localization system would select the proper help pages which
> would need to be available in WebServerResources (English.lproj,
> French.lproj etc).

It would be perfect ;)

> I suppose we only get answers for that when ZNeK is back from NZ.

Yes, It was Marcus Code. I'm going to modify the code as you explain here.

Thank's a lot for your precise answer.

Francois