Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#381 re-open / update multiple usermin user via httpd reverse pro

open
nobody
None
5
2009-08-14
2009-08-14
harry wwc
No

ref. previous entry "multiple usermin user via httpd reverse proxy - ID: 2831383" that I closed,
too soon I am afraid.
last night - hours after I logged on to close that call, several class users mentioned that the problem was "still happening". That is, they would log on as themselves - several "nearly simultaneously", and would receive their usermin display with a the username in the top lh corner of one of the other student/users.
When they refreshed, they would retrieve their correct details, and as long as there wasn't "too much" activity, most of the session threads seemed to stay "untangled".
Any suggestions on how I might assist you in tracking this down?
regards, (crestfallen)
Harry

Discussion

  • Jamie Cameron
    Jamie Cameron
    2009-08-14

    Just to confirm, did you add nokeepalive=1 to /etc/usermin/miniserv.conf and then run /etc/usermin/restart ?

    I suspect that your proxy may be re-using the same connection for different users, which confuses Usermin..

     
  • harry wwc
    harry wwc
    2009-08-14

    Hi Jamie,

    ummm... in /etc/usermin/miniserv.conf ?? I thought it was in /etc/usermin/config ?

    Ok, have made that change to miniserv.conf, and we'll see how we go next week :')

    sorry for the slow turnaround - but it needs a 'load' to show the issue.

    thanks for the support,

    friday arvo, looks like beer-o-clock :')

    kind reg's,

    .h

     
  • Jamie Cameron
    Jamie Cameron
    2009-08-14

    Yes, it needs to be in miniserv.conf , and then Usermin restarted.

     
  • harry wwc
    harry wwc
    2009-08-14

    done and done
    now it really is "beer-o-clock"
    have a good weekend
    .h

     
  • harry wwc
    harry wwc
    2009-08-18

    Hullo Jamie,

    still no joy.

    It appears that once we get over 4 or 5 concurrent users, the 'threads' start to get tangled until some of the sessions time out :'(

    e.g. I logged in as user "teacher01", a student (assigned the account 'magenta10') then connected and was presented with the name on the top lhs of "teacher01" - but of course, when he attempted to access the files (not noticing the login name) he received a pop-up telling him he didn't have permissions to view 'teacher01' - fair enough, too :')

    After a couple of re-freshes of his browser his directory tree showed up, and it seemed to work ok. And then another student had a similar problem with one of the other student's accounts.

    Which files would you like to see to help track this down? I'm guessing the usermin/config and usermin/miniserv config files? any others? I'll zip them together and upload them.

    kind regards,

    Harry

     
  • Jamie Cameron
    Jamie Cameron
    2009-08-18

    Hmm, I am confused now as to how this could be happening..

    Are the students connecting to the Apache proxy directly, or via a proxy of some kind (like Squid) ?

     
  • harry wwc
    harry wwc
    2009-08-18

    they have proxy.pac / wpad.dat pointed to in their browser which returns "direct" for the internal (172.19.24.0/23) network - other (external) accesses are via a filtering proxy.
    I will d/l a copy of that and examine it - but I would expect it to be 'correct'.
    I will have a closer look at the broswers of the machines exhibiting the "errors" - although they /should/ be all set to the SOE - they are 'students' afterall, and will often look for ways to 'get around' things ;')
    thanks for the pointer - will keep you posted.
    .h

     
  • Jamie Cameron
    Jamie Cameron
    2009-08-18

    You can also check /var/usermin/miniserv.log to see the IPs that client connections are coming from ..

     
  • {grumble} - lost all this {grumble} - maybe 'cause I dissed the network guys :')

    I checked miniserv.log - all addy's from 127.0.0.1 - using the local httpd reverse-proxy. which twigged me to /var/httpd/access.log - and bugger me, all the "problematic" accounts were from the *external* address of the proxy server.

    I will have to investigate more, examine the proxy pac file (and maybe debug it for them ;') no wonder accesses are so slow too, they're taking the scenic route - twice via the firewall - outbound, and back again.

    thanks for the pointers on where to look :')

    just a thought - those who are _really_ traversing the proxy / firewall from "outside" - are they likely to get the same issue? I would have thought not, in that the 'source port' would be different for each inbound connection to the httpd server, and it would keep track of these - but then, in theory... it should have coped with the current situation. blech! sometimes I hate networking! :')

    thanks, I will dig deeper and see - first thing to do is look at the proxy pac, then look at the alternatives

    kind reg's,

    Harry

     
  • Jamie Cameron
    Jamie Cameron
    2009-08-18

    See if you can turn off caching on the proxy, at least for the webmail URL - it may be incorrectly caching some pages causing the kind of session overlap you are seeing.

    Also, you can have Usermin force off caching by adding pragma_no_cache=1 to /etc/usermin/config , although this won't apply to pages already in the proxy cache.