nginx as caching proxy for freebsd-update

SirDice

Administrator
Staff member
Administrator
Moderator
I'm going to start pulling out what little hair I have left on this thing. I just cannot get it working correctly and I have no idea what I'm doing wrong.

Quick nginx.conf:
Code:
http {
 server {
   listen 80;
   server_name fbsd-update.example.com;
   
   location / {
     proxy_pass http://update.freebsd.org;
     proxy_store on;
   }
 }
}
If I set /etc/freebsd-update.conf and point ServerName to fbsd-update.example.com it appears to be working. But it never seems to cache anything. Searching Google I found hundreds of examples working like this:
Code:
http {
 server {
   listen 80;
   server_name fbsd-update.example.com;

   proxy_cache_path /var/cache/nginx level=1:2 keys_zone=MYCACHE:500m max_size=1000m inactive=1d;

   location / {
     proxy_pass http://update.freebsd.org;
     proxy_cache MYCACHE;
   }
 }
}
But this doesn't work at all. Nothing is ever proxied.

What am I doing wrong?
 
Your setup seems ok to me. Nothing suspicious in /var/log/nginx/nginx-error.log? /var/cache/nginx is in another disk or partition?
 
igorino said:
Nothing suspicious in /var/log/nginx/nginx-error.log?
Nothing out of the ordinary.

/var/cache/nginx is in another disk or partition?
No, there's only one filesystem (standard 9.x install).
 
Maybe a shot in the dark, but what about experimenting with these options: proxy_buffers, proxy_buffering and proxy_buffer_size in nginx.conf http section?
 
I'm going to try those next Monday. I can't access the servers from home ;)
 
Ok, I finally got something that actually caches something:
Code:
  server {
    listen 80;
    server_name fbsd-update.example.org;

    location / {
      root /var/cache/freebsd-update/;
      try_files $uri @cache;
    }

    location @cache {
      internal;
      proxy_store on;
      proxy_http_version 1.1;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass http://update.freebsd.org;
      root /var/cache/freebsd-update/;
    }
  }

And you have to make sure /var/cache/ is world-readable. Don't ask me why but it doesn't work with the default 750 permissions.
 
  • Thanks
Reactions: vmb
SirDice said:
And you have to make sure /var/cache/ is world-readable. Don't ask me why but it doesn't work with the default 750 permissions.
If I recall correctly then nginx drops its privileges after booting, by default it uses userid nobody (at least that's what I assume after looking at the default nginx.conf).

However, since /var/cache is owned by root and wheel the process can't access it by default.
 
Yeah, I had thought of that. But I have nginx running on the www user. Funny thing is that even though I had set /var/cache/freebsd-update to 777 it would still complain about permissions. For some reason it just wants to be able to read the directory above. No big deal, there isn't much else in there so a chmod 755 /var/cache/ fixed it for me.

It seems to work like a charm. I tried a few hosts, modified /etc/freebsd-update.conf and pointed it to my server. All hosts had no problems fetching updates. If it wasn't available nginx would fetch it from the internet and store it. After a while you get a nice mirror copy of the freebsd-update server. Updating servers should be relatively easy now. And I can block access to the internet for those servers, only the nginx server will be able to access the internet.
 
SirDice said:
Funny thing is that even though I had set /var/cache/freebsd-update to 777 it would still complain about permissions. For some reason it just wants to be able to read the directory above.
Hi,

It is not related to Nginx itself. To be able to perform a request Nginx needs read and execute permission on every parent directory in the hierachy. I.e. if your /var/cache is owned by root:wheel and has permission of 750, and you have a file called 1.png with permission 777 in the /var/cache, when you try to access this file in your browser you will not able to do it, until you place read and execute rights on the directory or chown it to the user or group of Nginx. If you place /var with permission of 750 and /var/cache with permission 777 and 1.png with permission 777, (we assume everything is root:wheel chowned again) again you will not able to open the file in the browser, until the same procedure as above.

I don't have caching Nginx to check now (and I don't know does it ported with the defaults regarding the next option), but also check your proxy_store_access directive, because by defaults it assigns:
Code:
Default: 	user:rw
for created files and directories. For example you can use the example from the documentation:
Code:
This directive assigns the permissions for the created files and directories, for example:

proxy_store_access  user:rw  group:rw  all:r;
depending on your needs.
 
Yes, I had played with that. The defaults seem to work fine though.
 
Back
Top