why would varnish care what skin is used?

[Dmacleo]

ip 3.3.4 been messing around trying to see why people getting logged out when varnish (using unixy varnish for directadmin) running.
when using stock ip skin everything is fine, when using Evanescence Steel Glass skin its fine, when using anything else it fails.
user logs in and whenever they goto any part restricted by permissions they are logged out.

have not yet tried making ONLY one of the skins that fails the one and only skin on board, but it just seems odd skin choice could do this.
is it maybe both were pulling some data from /master and conflicting?
would making sure there are ZERO common elements between master and custom skins even make a difference?

[Elly]

Can you paste your VCL file?

[Dmacleo]

got it uninstalled right now, will install it and grab that in few hours.
just cannot seem to pinpoint why it works fine on stock skin but fails on other skins.
would think if was cookie issue (or vanish handling of it) would show up on all skins wouldn't it?

when testing I also had no cdn or apc cache running just to be sure.

I'll post vcl in a bit.

[Dmacleo]

here it is, this is plugin for directadmin server

###################################################

# Copyright © UNIXY - http://www.unixy.net #

# The leading truly fully managed server provider #

###################################################


include "/etc/varnish/backends.vcl";


sub vcl_recv {


# Use the default backend for all other requests

set req.backend = default;


# Setup the different backends logic

include "/etc/varnish/acllogic.vcl";


# Allow a grace period for offering "stale" data in case backend lags

set req.grace = 5m;


remove req.http.X-Forwarded-For;

set req.http.X-Forwarded-For = client.ip;


# Properly handle different encoding types

if (req.http.Accept-Encoding) {

if (req.url ~ ".(jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|ico)$") {

# No point in compressing these

remove req.http.Accept-Encoding;

} elsif (req.http.Accept-Encoding ~ "gzip") {

set req.http.Accept-Encoding = "gzip";

} elsif (req.http.Accept-Encoding ~ "deflate") {

set req.http.Accept-Encoding = "deflate";

} else {

# unkown algorithm

remove req.http.Accept-Encoding;

}

}


# Set up exceptions

include "/etc/varnish/vhost.exclude.vcl";


# Restart rule for bfile recv

include "/etc/varnish/bigfile.recv.vcl";



## Default request checks

if (req.request != "GET" &&

req.request != "HEAD" &&

req.request != "PUT" &&

req.request != "POST" &&

req.request != "TRACE" &&

req.request != "OPTIONS" &&

req.request != "DELETE") {

return (pipe);

}

if (req.request != "GET" && req.request != "HEAD") {

return (pass);

}


## Modified from default to allow caching if cookies are set, but not http auth

if (req.http.Authorization) {

return (pass);

}


include "/etc/varnish/versioning.static.vcl";


## Remove has_js and Google Analytics cookies.

set req.http.Cookie = regsuball(req.http.Cookie, "(^|;s*)(__[a-z]+|has_js)=[^;]*", "");


set req.http.Cookie = regsub(req.http.Cookie, "^;s*", "");


if (req.http.Cookie ~ "^s*$") {

unset req.http.Cookie;

}


# Exclude upgrade, install, server-status, etc

include "/etc/varnish/known.exclude.vcl";


# Set up exceptions

include "/etc/varnish/url.exclude.vcl";



# Cache things with these extensions

if (req.url ~ ".(js|css|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|pdf)$" && ! (req.url ~ ".(php)") ) {

unset req.http.Cookie;

return (lookup);

}


return (lookup);

}


sub vcl_fetch {


set beresp.ttl = 40s;

set beresp.http.Server = " - Web acceleration by http://www.unixy.net/varnish ";


# Grace to allow varnish to serve content if backend is lagged

set beresp.grace = 5m;


# Restart rule bfile for fetch

include "/etc/varnish/bigfile.fetch.vcl";


# These status codes should always pass through and never cache.

if (beresp.status == 503 || beresp.status == 500) {

set beresp.http.X-Cacheable = "NO: beresp.status";

set beresp.http.X-Cacheable-status = beresp.status;

return (pass);

}


if (beresp.status == 404) {

set beresp.http.magicmarker = "1";

set beresp.http.X-Cacheable = "YES";

set beresp.cacheable = true;

set beresp.ttl = 20s;

return (deliver);

}


/* Remove Expires from backend, it's not long enough */

unset beresp.http.expires;


if (req.url ~ ".(js|css|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|pdf|ico)$" && ! (req.url ~ ".(php)") ) {

unset beresp.http.set-cookie;

set beresp.cacheable = true;

include "/etc/varnish/static.ttl.vcl";

}

else {

include "/etc/varnish/dynamic.ttl.vcl";

}


/* marker for vcl_deliver to reset Age: */

set beresp.http.magicmarker = "1";


# All tests passed, therefore item is cacheable

set beresp.http.X-Cacheable = "YES";


return (deliver);

}


sub vcl_deliver {


# From http://varnish-cache.org/wiki/VCLExampleLongerCaching

if (resp.http.magicmarker) {

/* Remove the magic marker */

unset resp.http.magicmarker;


/* By definition we have a fresh object */

set resp.http.age = "0";

}


#add cache hit data

if (obj.hits > 0) {

#if hit add hit count

set resp.http.X-Cache = "HIT";

set resp.http.X-Cache-Hits = obj.hits;

}

else {

set resp.http.X-Cache = "MISS";

}


}


sub vcl_error {


if (obj.status == 503 && req.restarts < 5) {

set obj.http.X-Restarts = req.restarts;

restart;

}


}


# Added to let users force refresh

sub vcl_hit {


if (!obj.cacheable) {

return (pass);

}


if (req.http.Cache-Control ~ "no-cache") {

# Ignore requests via proxy caches, IE users and badly behaved crawlers

# like msnbot that send no-cache with every request.

if (! (req.http.Via || req.http.User-Agent ~ "bot|MSIE|HostTracker")) {

set obj.ttl = 0s;

return (restart);

}

}


return (deliver);


}


sub vcl_hash {


set req.hash += req.http.cookie;

}

backends vcl just lists the ips on the server

[Dmacleo]

well setting Print HTTP headers to NO seems to make a huge difference.
probably going to jinx myself and regret typing this but been going on 30 min with no errors and multiple skin changes.

[Dmacleo]

yeah I jinxed it. worked about 30 hours.
damn this is irritating me.
the unixy plugin specifically built to allow cache for logged in users, I may need to dump that "benefit" and have it handle only for guests.
waiting to hear back from unixy on this issue, if solvable it would be helpful IMO.

[Dmacleo]

the unixy da plugin is missing this in default vcl

sub vcl_fetch {


## Remove the X-Forwarded-For header if it exists.

remove req.http.X-Forwarded-For;


## insert the client IP address as X-Forwarded-For. This is the normal IP address of the user.

set req.http.X-Forwarded-For = req.http.rlnclientipaddr;

added that section in the fetch and so far so good. 20 or so logged in and 250+ guests last night with no issues.
many many many skin swaps done by logged in people to test LOL
so time will tell.

[Dmacleo]

and that lasted about 30 hours or so.
think I found a chown issue though that may have been playing havoc, will try again tomorrow

[Dmacleo]

this is confusing the heck out of me.
ip stock skin works fine.
if I allow other skins to be chosen then issues (members getting logged out) start, seems to NOT be browser related, happens to all of them

[Dmacleo]

if anyone happens across this issue try NOT using furls.

[Luis Manson]

did you try with other skins? not just your main one?

also did you try with the vcl from the varnish thread?

[Dmacleo]

yup tried everything. been working this issue for weeks.
the rewrite rules listed in furls section were the issue.
furls turned off with no rewrites happening works fine.
later today going to setup rewites in vcl.
think this would only happen in specific setup like mine where everything is run under public_html and IP.Content is set as home page using constants.php file. thinking the rewrite rules for the index.php/index.html (content page) are the issue.

[Luis Manson]

are you with apache or nginx?

[Dmacleo]

apache with cpanel.
w/o varnish the rules worked fine.
unixy support questioned cookie settings, we ruled them out.
one thing thta always bugged me was the ACP ALWAYS worked, and when trying to find out why I saw ACP never uses FURLS.
mad it took me so long to make the connection.
later today when I do some vcl rewrite tests I'll post what works for me if I can.

I think the initial issue here, the working on some skins only, was just a coincedence really and most likely led me down wrong troubleshooting direction.

[Luis Manson]

its weird, i had extrange problems when i first tried varnish, which i had again with nginx cache...mostly session mixed, so user A from time to time saw himself loged in as B and so on....

misteriously varnish started to work a few days ago :S

[Dmacleo]

have not seen that one, have had zero issues since I deleted the htaccess files and turned off furls.
I also have not had a chance to work on the furl setup, and I really hate how urls look w/o them.

[Luis Manson]

furls are a very nice thing, but why dont u try nginx?

[Dmacleo]

cause for my stuff varnish is better option.
for what I need cached along with the resiliance varnish is better for me.
for many nginx, which I have used before and liked, is the better choice.
where I am cpanel user (host some dns stuff for friends, cpanel makes it easier) I am bound to apache.

now with that being said I am looking at testing apachebooster which is a cpanel nginx/varnish hybrid combo.

[Dmacleo]

this is caused by using ip.content as the default app, defining it as such in initdata or constant.php or running it outside of forum root (using the supplied index file) drives this issue with varnish. I expect its tied to how index.php? is utilized depending on what default app is.
leave forums as default app and it seems to work fine.
running normal and test board on the same server and the second I make ccs default app in test board I have to stop using furls.

so I am a bit ccloser at least.

[Luis Manson]

weird, dint tought of that, maybe you will have to do a bug report!

[Dmacleo]

not sure its a bug though, only happens with varnish and its most likely, and this is pure opinion, due to how everything is driven off the index.php file. going to mess with it more tomorrow and maybe able to find a work around that works for me.

[Luis Manson]

keep me updated please...
maybe its not an IPB bug but some kind of side-effet, but i feel this should be addresed, many ppl use varnish to reduce load

[Dmacleo]

I'll do my best. little out of my element here LOL

[.Nuno.]

Hi Dmacleo

Just a quick note .. your board isn't caching anything beside static content. Have you disabled caching in Varnish?

Edit: the board in your signature.

[Dmacleo]

yeah its been on and off while testing and when on I usually had dynamic ttl set to 5 seconds or lower as I was changing stuff so often on 2 sites comparing findings.
running about 60% hoit 40 miss rate when running.
apc disabled too forgot to swap that back on.