Images outside of public/images


#1

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.


#2

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.


#3

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).


#4

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.