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.
Related
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 have fifteen virtual hosts (servers) with separate log location for it. I am a bit confused about which would be the best option to write nginx config file for each. All server blocks in one file or a separate file for each server?
Which would be a more efficient way?
Nginx reads config once on start (or reload), so do whatever is more appropriate for you.
I would write related server blocks together in one file, and have one bunch of related servers per file.
Or have one file per server.
Or write them all in one file.
Efficiency is not effected by how you define the blocks in nginx. Thus, it would be same in the given case.
If there's some commonality between your virtual hosts configs, such as general SSL settings or denying certain types of requests, you may want to use includes.
I like to keep separate vhosts config files, it's easier to take one domain offline for maintenance for instance.
I have a plugin on a Wordpress site called WP Security, most of the stuff it does is easy to use and understandable, the changes it suggests like not have default 'WP_' prefix for databases etc.
One of the things it highlights is: The index.php file was not found in the uploads directory! You should create one in order to prevent directory listings.
So can anyone tell why preventing directory listings is good and do I need to put anything in the index file, and if so what code do I need to put in? Finally what is the importance of the index file in website I don't really get this part of web design? I have read it has to be there to make site visible to browsers but why is this, why can't browsers just use the URL with no index page?
Thanks for suggestions
Andrew
Yes, blocking directory index is a good idea in web apps. The index.* file is interpreted by web server instead of providing standard directory listing. Creating an empty index.* file is ony one (although the easiest and compatible with all(?) http servers) way of blocking users from viewing the contents of the directory. Another way is to configure webserver to not serve the directory index. In Apache this can be done in the .conf file with
Options -Indexes
in the <Directory> clause. Or you might tell apache to:
AllowOverride All
And create a .htaccess in the directory containing:
Options -Indexes
line.
Yes creating index.* file is really necessary to protect your asset as absence of index files shows whole directory structure and listed assets.
Easiest way to create an index.php file with simple coding.
I usually cannot see .htaccess file because it is hidden, when I login to remote servers with ftp access.
Since I don't have shell access, I usually perform the following steps to edit the file:
I change the settings on my mac (from terminal) to see invisible files
I open .htaccess file on a standard drupal installation and I edit it
I upload it to the remote server and I overwrite the existent one
I disable hidden files on my mac
I was wondering if there is a faster solution
thanks
I often have a separate file in my Drupal root called production.htaccess or something along those lines. Not only does this expose the file in Finder without revealing every single .DS_Store on my system, it also allows me to set separate .htaccess directives for different environments. Then, I just rename production.htaccess to .htaccess after I upload it to the server.
More often than not, the two .htaccess files are identical, but even in that case, I still use this method for the sake of convenience.
The FTP application should have the option to show you hidden files; normally, that is an option available on FTP client applications for Mac OS X.
First off, how do I know if my html file is running on localhost in Xampp?
Is there a tutorial on how to manage files/directories and get that all working under htdocs?
Is there a good tutorial on how to setup includes?
I want to use "includes" in Xampp with my html.
Can I use both html includes AND php includes?
Do I have to put shtml?
Can I use shtml, html, htm, and php includes?
Do they have to be in an includes directory that is a subdirectory right under htdocs?
Can I reference includes in some other subdirectory?
My site will have over 100 pages, and I am trying to do "experiments" with different versions until I am happy. So, I have subdirectories for the various drop down menus. Unfortunately, I don't seem to be able to get this working in xampp.
Having trouble getting my javascript menus from Vista Buttons to show up, now that I moved my main directory for my site to the htdocs directory.
Since XAMPP uses Apache you need to configure it to permit SSI.
To permit SSI on your server, you must have the following directive either in your httpd.conf file, or in a .htaccess file:
Options +Includes
This tells Apache that you want to permit files to be parsed for SSI directives. Note that most configurations contain multiple Options directives that can override each other. You will probably need to apply the Options to the specific directory where you want SSI enabled in order to assure that it gets evaluated last.
Not just any file is parsed for SSI directives. You have to tell Apache which files should be parsed. There are two ways to do this. You can tell Apache to parse any file with a particular file extension, such as .shtml, with the following directives:
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
One disadvantage to this approach is that if you wanted to add SSI directives to an existing page, you would have to change the name of that page, and all links to that page, in order to give it a .shtml extension, so that those directives would be executed.
The other method is to use the XBitHack directive:
XBitHack on
XBitHack tells Apache to parse files for SSI directives if they have the execute bit set. So, to add SSI directives to an existing page, rather than having to change the file name, you would just need to make the file executable using chmod.
chmod +x pagename.html
According to Apache Tutorial: Introduction to Server Side Includes
I have faced the same issue but I was not able to figure out where exactly I have to modify and which files. So to fix it follow the below steps in XAMPP Localhost server.
Go to your:
c:/xampp/apache/conf/httpd.conf
Search for:
AddType text/html .shtml
Add the below two lines:
AddType text/html .html
AddOutputFilter INCLUDES .html
Go to Xampp Control Panel and stop the session and restart again.
Refresh the page in browser and see, the virtual includes will start working.
To answer your first question, can you access http://localhost/? If so, then xampp is running correctly and there is nothing more that you need to do.
EDIT: If you want to ensure that things are working correctly, place foo.html under /xampp/htdocs and then access it in a browser at http://localhost/foo.html. If you can't get this page then xampp still isn't running correctly.
In answer to your second question, all Includes whether in the HTML or within PHP are server side. If you have xampp installed correctly, then you can begin working in PHP immediately and can use the include functions within PHP (please note that even if a page only contains HTML, if you're using PHP it must still have a .php extension).
If you would rather use SSI in your .html pages, then this link might provide some help on how to set up and debug SSI in xampp.
Additionally, if you are not already doing so I would recommend that you work in Firefox with Firebug installed. Firebug will handle most of your JavaScript debugging needs.
As a final note, if you've moved directories and the like, the first thing I would check would be the src attributes on your script tags.
I found out that for includes to work in XAMPP your page with the include function needs to have the extension '.shtml' while the included file has '.html'. Most modern browsers don't require the shtml extension but XAMPP seems to.
.js seems to be the same.
You might want to look at AMPstart instead of xampp-control. It has some nice ability to allow you to place site-folders outside of htdocs w/o messing around with apache conf stuff