In nginx we have root option to serve files from a specific directory, eg: root /var/www/data/ in nginx conf, if my url is https://mydom.com/$file_name, nginx will look for files present in /var/www/data/$file_name and return the file if present otherwise return 404.
Now, I want something similar option in Varnish. Is there a way where I can serve files from a specific directory? How can I tell varnish to look for files in a specific directory and return that file?
Varnish is a cache, not a webserver. Varnish doesn't serve pages from a document root on the disk, but it caches responses that came from a pre-defined backend server.
Although Varnish and Nginx have some similarities, and cover some of the same use cases, they are entirely different products.
However, if you use Nginx as a reverse proxy, instead of a webserver, it won't use the root option either.
There is one way you can make Varnish act like a webserver, and that is by leveraging the file module in Varnish Enterprise. This allows Varnish to serve files from disk, but this is not available in the open source version of Varnish, only in the commercial version.
Related
I noticed my install of nginx has three folders called
etc/nginx/sites-available
etc/nginx/sites-enabled
etc/nginx/conf.d
Do I really need these if I just want to work directly in the etc/nginx/nginx.conf file and remove the include lines that include these items in nginx.conf? Are these directories used for anything else that would mess things up if I delete them?
No, they are not needed if you define your server blocks properly in nginx.conf, but it's highly suggested. As you noticed, they are only used because of the include /etc/nginx/sites-enabled/*; in nginx.conf.
For curiosity, is there a reason why you do not want to use them? They are very useful; easier to add new sites, disabling sites, etc. Rather than having one large config file. This is a kind of a best practice of nginx folder layout.
Important information:
You should edit files only in sites-available directory.
Never edit files inside the sites-enabled directory, otherwise you can have problems if your editor runs out of memory or, for any reason, it receives a SIGHUP or SIGTERM.
For example: if you are using nano to edit the file sites-enabled/default and it runs out of memory or, for any reason, it receives a SIGHUP or SIGTERM, then nano will create an emergency file called default.save, inside the sites-enabled directory. So, there will be an extra file inside the sites-enabled directory. That will prevent Apache or NGINX to start. If your site was working, it will not be anymore. You will have a hard time until you find out, in the logs, something related to the default.save file and, then, remove it.
In the example above, if you were editing the file inside the sites-available directory, nothing bad would have happened. The file sites-available/default.save would have been created, but it wouldn't do any harm inside the sites-available directory.
I saw below comment in The Complete NGINX Cookbook in NGINX official site !.
The /etc/nginx/conf.d/ directory contains the default HTTP
server configuration file. Files in this directory ending in .conf
are included in the top-level http block from within the /etc/
nginx/nginx.conf file. It’s best practice to utilize include state‐
ments and organize your configuration in this way to keep your
configuration files concise. In some package repositories, this
folder is named sites-enabled, and configuration files are linked
from a folder named site-available; this convention is deprecated.
It is not a must, but a best practise if you host more than one sites on your box.
It will be easier to manage by keep http context and common directives (such as ssl_dhparam, ssl_ciphers, or even gzip settings, etc.) on the nginx.conf so that it applied across all sites.
Keep site-specific server context (such as ssl-certificate, location directives, etc.) at etc/nginx/sites-available/ and name the configuration file as your-domain.conf. The file in etc/nginx/sites-enabled can be just a link to the file to the etc/nginx/sites-available.
In apache, the rewrite rule can be written in the configuration file or in .htaccess file. How about in nginx? Can I use url rewriting without access to the configuration file?
Unfortunately, you can't. This is one of the reasons shared hostings typically use apache or litespeed, not nginx or lighttpd.
A (very ugly) workaround would be to handle all requests with a script which would contain the rewrite rules and would serve the file/script according to the request URI (and which could be modified by a user without having root privileges). However you'd have a bad performance serving static files and you'd need to handle all the request headers by this script, which is not very practical.
This question is related to this SO question, but the recommended solution in the comments to use Meteor.absoluteUrl() doesn't seem to be working as expected. I want to be able to deploy multiple meteor applications to the same server and use nginx as a reverse proxy to each application.
Because each application is segregated none of the applications are going to be accessible from the ROOT_URL, but Meteor is only using the ROOT_URL to reference back for the assets it needs to load a meteor app.
I tried appending to the address using Meteor.absoluteUrl() in the server's startup, the client's startup function, and outside of the client's startup function. It had no affect in any of these places.
For example. I have nginx listening at /site1 for server_name: example.com and a reverse proxy to port 3001 to my meteor application.
When going to the site it initially loads fine but the browser dev tool shows Meteor is trying to find the javascript and css files at https://example.com when it should be looking from a base url of https://example.com/site1
Meteor.absoluteUrl("site1",{ssl:true}) was set in Meteor.startup() to try and force that as the correct path. As you can see, I am only appending to ROOT_URL with no leading / as described in the Meteor documentation.
I'm using meteor up to deploy and here's how the mup.json environment settings look:
"env": {
"ROOT_URL": "https://example.com",
"PORT": 3001,
"MONGO_URL": "mongodb://user:password#localhost:27017/db"
}
Any clarification about this this should work is greatly appreciated.
Using sub-domains suggested by apendua seems to be the easiest way to accommodate multiple Meteor applications on the same server behind nginx (if you that option available to you).
Register a sub-domain for each application (i.e. app1.domain.com, app2.domain.com, etc.)
Add an nginx server configuration for each sub-domain, setting the server_name property to your sub-domain address.
Add a default location for that server and set your proxy_pass to http://127.0.0.1:port where port is the port number you set in your environment configuration when you deployed your Meteor application (in my case I set this in my mup.json).
The root url for public assets under a meteor app is actually at /public. Each of your apps has a different base directory for the app. Assuming that you have an overall structure that looks like:
app1/ - nginx maps to https://example1.com/
client/
lib/
public/
server/
app2/ - nginx maps to https://example2.com/
client/
lib/
public/
server/
etc...
Then each app's public assets will just be under Meteor.absoluteUrl() which will serve files from app/public. Meteor.absoluteUrl()+"app1" has no meaning.
When I open a website's url such as www.stackoverflow.com via curl, which file is actually being visited in the server? I know usually it is index.html. But I cannot find such a convention in the RFC2616 document. How can I know it?
BR
The document dilivered by calling a website without a path in the URL is configured by the webserver. So you have no standard there. Is a users joice.
Curl will download the file the webserver is delivering him, or follow the redirect (if -L option is given) when webserver responses a redirect.
There is no way for the client to know how the data for the HTTP response was generated. It might not even be related to a specific file.
The last time I wrote a significant bit of server side code, everything outside of /static/ was routed (via mod_rewrite) though a FastCGI program that got its data from a few different controller libraries, a dozen database schema libraries, a database and a dozen template files.
The WWW is built on links between URLs, not files. Don't worry about files if you are writing client code.
It's not necessarily index.html, and you can't actually know that it could be anything depending on the Server Configuration, for instance in Apache you can change the directory index to the one that suits you
DirectoryIndex home.php
in this case the default file accessed is home.php
in IIS you can take a look about default index and how to change it
but the defaults are
in Apache
index.php (usually: depending on the server configuration)
index.html (is the default that comes with a fresh install)
in IIS
Default.htm
Default.asp
Index.htm
Index.html
Iisstart.htm
I need to put a file at this address: http://localhost:51547/file.txt
What folder would I put it in on C:/?
Tony
If I understand your question correctly and you're trying to expose a file via the ASP.NET development server at that location (http://localhost:51547/file.txt) I'm afraid the answer is not quite to your liking.
Basically I don't think you can serve files from the root of the ASP.NET development server (i.e right after the localhost:port/ part - the port is automatically selected by ASP but you can also manually configure it). ASP.NET automatically creates a virtual application path right after localhost:por> and so you're most likely going to be limited to serving files from the virtual application folder. So, assuming you web application name is: "testApp", if you put a file called file.txt in the directory where you're storing the source code for "testApp" it will also become available when you're testing at: http://localhost:port/testApp/file.txt (note the testApp in between the host-name & port, and the file-name)
UPDATE
In light of you comment, here's something you could do. You could try to get a simple HTTP server installed on your development computer and have it serve files on a different port (say port 8000). In that case you would serve file.txt using this secondary HTTP server and it would be accessible at: http://localhost:8000/file.txt.
You could try to install Apache or use IIS which comes with Windows. For Apache, the quickest way to get it going would be to install a WAMP environment. You may also try Lighttpd, and also note that MySQL or PHP are not required at all if you're only serving static files.
Any folder you want. The port designator is specified in IIS itself.
http://support.microsoft.com/kb/149605
I suggest you that if you want to do a site(HTTP) is better to use the port 80 or to do a redirection for another port, remember too that localhoost is a loop back and also take a look at PortForward to check some ports that are used by specific applications and types of servers, and please improve your question.
Regards.