RE: lighttpd & sessions

I'm stumped.
I tried running it under Apache 2.2.
I changed qmailadmin to read/write to /tmp/$time.qw, and then  
/tmp/1test.qw, to ensure it's not a NFS issue or a POST value issue,  
or anything to do with the time variable.
I even re-configured with --disable-ipauth for giggles.

Nothing works.  I can log in as any user, but any further action  
causes qmailadmin to return to the login screen.  After login, the  
content of the
the .qw file is always:
ip_addr=172.16.100.199&returntext=&returnhttp=

Is that correct?   I'm not sure how to do an strace, but I could throw  
additional logging into the code... I'm just not quite sure where the  
best place to start would be.  I assume auth.c

This is the latest qmailadmin on FreeBSD 7.2 built from ports,  
vpopmail 5.4.17 w/ MySQL backend, mailboxes on OpenSolaris NFS share.

Rick

Quoting "Tren Blackburn" <[email protected]>:

> I guess the next thing would be to strace the process to see what's
> going on behind the scenes. Hopefully an inter7 developer will voice in
> saying either "it doesn't work...but it will" or "try magic flag X" ;)
>
> Sorry I can't be of any more help.
>
> t.
>
> -----Original Message-----
> From: Rick Romero [mailto:[email protected]]
> Sent: October-29-09 10:51 AM
> To: [email protected]
> Subject: RE: [qmailadmin] lighttpd & sessions
>
>
> Hey Tren,
>
> It was working with Apache, so I'm fairly confident that it's lighttpd
> - but I just started looking at the configs to make sure I don't break
> anything bringing up Apache again :)
>
> I'm using IPVS (ldirectord/heartbeat) on a pair of Debian Intel Atom
> machines, so 'internally' these web servers are standalone.
>
> One nice thing about lighttpd is virtual domains can be created just
> by creating a directory of the fqdn (www.havokmon.com/ for example),
> or a link to a directory. (192.168.1.1 -> www.havokmon.com/)
>
> The cgi stuff has been a bit of a headache though..
>
> Rick
>
> Quoting "Tren Blackburn" <[email protected]>:
>
>> Hrm. Well, I'm out of ideas ;) I also don't use lightthpd :) That
> might
>> be part of it. Is it possible to try your setup with Apapche? Just to
>> confirm if the issue is specific to lightthpd?
>>
>> Are you using IPVS for your load balancer? Or a proprietary product?
> If
>> IPVS what are you using for transmitting the packets to the RIP?
>>
>> -----Original Message-----
>> From: Rick Romero [mailto:[email protected]]
>> Sent: October-29-09 10:24 AM
>> To: [email protected]
>> Subject: RE: [qmailadmin] lighttpd & sessions
>>
>>
>> I wish it were that easy - I have virtual hosts on each box's internal
>> IP, and when I access via the internal IP from a system on the same
>> subnet (no balancing, no firewalls), I still have the same problem..
> :(
>>
>> Rick
>>
>> Quoting "Tren Blackburn" <[email protected]>:
>>
>>> Try compiling qmailadmin with --disable-ipauth
>>>
>>> I have a similar setup to yours where I run qmailadmin behind a load
>>> balancer. However I run qmailadmin via https and have my load
> balancer
>>> set to provide 10 minutes of persistence for https sessions.
>>>
>>> HTH,
>>>
>>> t.
>>>
>>> -----Original Message-----
>>> From: Rick Romero [mailto:[email protected]]
>>> Sent: October-29-09 10:16 AM
>>> To: [email protected]
>>> Subject: [qmailadmin] lighttpd & sessions
>>>
>>> Hi all,
>>>
>>> I have installed qmailadmin 1.2.13 on a pair of load balanced web
>>> servers running lighttpd.
>>>
>>> The problem is I can seem to keep a session. I can log in, but any
>>> further action (such as password change) takes right me back to the
>>> login page.
>>>
>>> I've verified the locatime.qw file gets written to my Maildir folder.
>>> I've verified this file contains some data (not sure exactly what it
>>> should look like) - that might help?
>>> I've verified the .qw files can be deleted
>>> I've verified the HTML post contains a matching time.  The web page
>>> contains the correct number, and the browser sends it as the URL
>>> (which is displayed on the login page, and is a timestamp that
> matches
>>> the file name).
>>>
>>>
>>> There's not a whole lot going on there, so I'm stuck as to why the
>>> session verification is failing.
>>>
>>> Any thoughts?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
> 
>
>



!DSPAM:4aecab3232715435241766!