Images outside of public/images

TLDR: I’d like to have images in /dir/images not /public/images and symlinks do not solve the problem.

It’s a long story but part of my site is actually stored on github as a project. I have it setup to auto-deploy when this site branch is pushed to github. The branch is only part of the site and I’d like to have it all self-contained, which for templates works fine. However I have to include images referenced in the site branch in the main root public/ directory in some place like public/images. This doesn’t fit the way I deploy, which is tied to the github push.

I’d like to have a single github project with /posts and /posts/images and when I push it would auto-deploy to /posts and /posts/images and update all templates and images at the same time. In a template I’d like /images/posts/image.png (or any URL for that matter) to actually reference the file in posts/images/image.png.

I tried creating a simlink from public/images/posts -> posts/images/ and put image.png there but get:

error: Symlink cycle detected at public/images/posts

The reference on the server is not cyclic so I suspect this has something to do with client/server split. I also tried to figure out how to do this with the router but couldn’t see how.

Any ideas would be greatly appreciated.

Any clues that I can research? I have a “pro” helping build the site that I will take over but he’s not aware of a way to do this. He suggested symlinks but they are sensed by Meteor and cause the entire app to refuse to startup.

You could use nginx (apache will probably work as well, though I haven’t tried it there) and serve up your static files directly through nginx, passing everything else off to Meteor via nginx acting as a proxy.

Bonus: You can easily activate SSL that way, too.

Config for /etc/nginx/sites-available/site-name

upstream my_meteor_app {
        server 127.0.0.1:3000;
}

server {
        listen [::]:80;
        listen 80;

        server_name site-name.com www.site-namecom;
        return 301 https://site-name.com$request_uri;
}

server {
        listen [::]:443 ssl spdy;
        listen 443 ssl spdy;
        server_name www.site-name.com;
        include /var/www/nginx_ssl.conf;
        return 301 https://site-name.com$request_uri;
}

server {
        listen [::]:443 ssl spdy;
        listen 443 ssl spdy;
        server_name site-name.com;
        include /var/www/nginx_ssl.conf;
        access_log /var/log/nginx/site-name.ssl.access_log;
        error_log /var/log/nginx/site-name.ssl.error_log;

        location /static {
                alias /var/www/static;
        }
        location / {
                proxy_pass http://my_meteor_app/;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}

And /var/www/nginx_ssl.conf looks like this:

# Protect against the BEAST and POODLE attacks by not using SSLv3 at all. If you need to support older browsers (IE6) you may need to add
# SSLv3 to the list of protocols below.
ssl_protocols              TLSv1 TLSv1.1 TLSv1.2;

# Ciphers set to best allow protection from Beast, while providing forwarding secrecy, as defined by Mozilla (Intermediate Set) - https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx
ssl_ciphers                ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA;
ssl_prefer_server_ciphers  on;

ssl_session_cache    shared:SSL:10m; # a 1mb cache can hold about 4000 sessions, so we can hold 40000 sessions
ssl_session_timeout  24h;

keepalive_timeout 300s; # up from 75 secs default

ssl_certificate      /etc/ssl/nginx/certificate.crt;
ssl_certificate_key  /etc/ssl/nginx/certificate.key;

So, what this does is the following:

Redirect everything going http to use https, also redirect anything from www.site.com to just site.com.

It will also serve up anything under /var/www/static directly under site.com/static (you are free to chose other directories and URIs of course).

1 Like

Oh, yes, great idea, thanks. I use Apache but I get what you’re saying. Will try some experimentation.

If anyone has gotten this to work with Apache, would appreciate the config you used.