Difference between pages "Package:Nginx" and "Subarches"

(Difference between pages)
m (add up some php caching.)
 
 
Line 1: Line 1:
{{Ebuild
+
{{:Install/Header}}
|Summary=Robust, small and high performance HTTP and reverse proxy server
+
= Funtoo Linux Sub-Architectures =
|CatPkg=www-servers/nginx
+
__NOTITLE__
|Maintainer=Drobbins
+
This page provides an overview of Funtoo Linux sub-architectures (also called ''subarches'',) designed for quick and easy reference. While this information is available in other places, such as Wikipedia, it often takes some time to study and cross-reference the various articles to get a good understanding of each type of sub-architecture, and this information generally isn't all collected neatly in one place. That is the purpose of this page. When possible, links to more detailed Wikipedia pages are provided. You are encouraged to help maintain this page as well as the Wikipedia articles referenced here.
|Repository=Funtoo Overlay
+
|Overlay=Funtoo
+
}}
+
[[Image:nginx.gif|frame]]
+
  
nginx (pronounced "engin-x") is a Web and reverse proxy server for HTTP, SMTP, POP3 and IMAP protocols. It focuses on high concurrency, performance and low memory usage. Nginx quickly delivers static content with efficient use of system resources, also dynamic content is delivered on a network using FastCGI, SCGI handlers for scripts, uWSGI application servers or Phusion Passenger module (atm broken in [http://funtoo.org funtoo]), further more it can serve a very capable software load balancer. It uses an asynchronos event-driven approach to handle requests which provides more predictable performance under load, in contrast to the Apache HTTP server model, that uses a threaded or process-oriented approach to handling request. Nginx is licensed under a BSD-like license and it runs on Unix, Linux, BSD variants, Mac OS X, Solaris, AIX and Microsoft Windows.
+
== AMD Processors ==
  
=== USE Expanded flags ===
+
=== amd64-k10 ===
  
Furthermore, you can set the nginx modules you like to use in ''/etc/make.conf'' in the NGINX_MODULES_HTTP variable as NGINX_MODULES_HTTP="variables".
+
The '''amd64-k10''' subarch provides support for the [[Wikipedia:AMD10h|AMD Family 10h processors]], which were released in late 2007 as a successor to the AMD K8 series processors.
  
nginx USE flags go into ''/etc/portage/package.use'' or ''/etc/portage/package.use/nginx'', while the HTTP and MAIL modules go as NGINX_MODULES_HTTP or NGINX_MODULES_MAIL are stored in /etc/make.conf. And as you wouldn't server only static html files, but most commonly also php files/scripts you should also install php with fpm enabled and xcache for caching the content, what makes your nginx setup way faster. For xcache you need to set PHP_TARGETS="php5-3" in '/etc/make.conf'.
+
Desktop amd64-k10 CPUs include [[Wikipedia:AMD Phenom|AMD Phenom]], [[Wikipedia:AMD_10h#Phenom_II_Models|AMD Phenom II]] and [[Wikipedia:AMD_10h#Athlon_II_Models|AMD Athlon II]]. Server CPUs include Budapest, Barcelona, Suzuka, Shanghai, Istanbul, Lisbon, and Magny-Cours (more information [[Wikipedia:List_of_AMD_Opteron_microprocessors#K10_based_Opterons|can be found here]].)
  
Example:
+
=== amd64-bulldozer ===
<console>
+
###i## echo "www-servers/nginx USE-FLAG-List" >> /etc/portage/package.use/nginx
+
</console>
+
  
=== Emerging nginx ===
+
The '''amd64-bulldozer''' subarch supports the [[Wikipedia:Bulldozer (microarchitecture)|AMD bulldozer microarchitecture]] CPUs, which were released from late 2011 through the first quarter of 2012 as a replacement for the [[Wikipedia:AMD10h|K10 microarchitecture]] CPUs.
 +
Bulldozer CPUs use the [[Wikipedia:Socket_AM3+|AM3+ socket]] and [[Wikipedia:Socket_G34|G34 socket]] for server CPUs.
  
Now you are ready to install nginx with php and xcache support:
+
Desktop bulldozer CPUs include the '''[[Wikipedia:List_of_AMD_FX_microprocessors#.22Zambezi.22_.2832_nm_SOI.29|Zambezi FX-series CPUs]]'''. Server bulldozer CPUs include '''Zurich''' (Opteron 3200-series), '''Valencia''' (Opteron 4200-series) and '''Interlagos''' (Opteron 6200 series). [[Wikipedia:http://en.wikipedia.org/wiki/Opteron#Opteron_.2832_nm_SOI.29-_First_Generation_Bulldozer_Microarchitecture|More information here.]].
<console>
+
###i## emerge -avt nginx php xcache
+
</console>
+
so now just check your useflags and press enter to start emerge.
+
  
== Configuring ==
+
=== amd64-piledriver ===
  
All configuration is done in ''/etc/nginx'' with ''nginx.conf'' as the main configuration file and all virtual hosts in ''/etc/nginx/sites/available'' while you have to symlink ''/etc/nginx/sites-available/{VHOST}'' to ''/etc/nginx/sites-enabled/{VHOST}'' to activate them. An example config for such a {VHOST} looks like that:
+
The '''amd64-piledriver''' subarch supports the [[Wikipedia:Piledriver (microarchitecture)|AMD Piledriver microarchitecture]] produced by AMD from mid-2012 through 2015, which is the successor to the [[Wikipedia:Bulldozer (microarchitecture)|AMD bulldozer microarchitecture]].  
 +
Piledriver CPUs and APUs are available that use the [[Wikipedia:FM2 Socket|FM2 socket]]. Desktop Piledriver CPUs use the [[Wikipedia:Socket_AM3+|AM3+ socket]]. Server Piledriver CPUs use a variety of sockets, including [[Wikipedia:Socket_AM3+|AM3+]], [[Wikipedia:Socket_C32|C32]] and [[Wikipedia:Socket_G34|G34]].
  
<pre>
+
Desktop piledriver CPU and APUs include '''Vishera''' (FX-8350, FX-8370),  '''[[Wikipedia:List_of_AMD_accelerated_processing_unit_microprocessors#Virgo:_.22Trinity.22_.282012.2C_32_nm.29|Trinity A-series APUs]]''' (A6-5400K, A10-5800K) and '''[[Wikipedia:http://en.wikipedia.org/wiki/List_of_AMD_accelerated_processing_unit_microprocessors#.22Richland.22_.282013.2C_32_nm.29_2|Richland A-series APUs]]'''.  
server {
+
    listen          80;
+
    server_name    www.example.com;
+
  
    access_log      /var/log/nginx/www.example.com.access_log main;
+
Server piledriver CPUs include '''Delhi''' (Opteron 3300-series, [[Wikipedia:Socket_AM3+|AM3+]]), '''Seoul''' (Opteron 4300-series, [[Wikipedia:Socket_C32|C32]])  and '''Abu Dhabi''' (Opteron 6300-series, [[Wikipedia:Socket_G34|G34]]). [[Wikipedia:Opteron#Opteron_.2832_nm_SOI.29_-_Piledriver_Microarchitecture|More information here]].
    error_log      /var/log/nginx/www.example.com.error_log info;
+
  
    root /var/www/www.example.com/htdocs;
+
Piledriver adds several new instructions over bulldozer, so AMD bulldozer systems cannot run amd64-piledriver-optimized stages. However, this subarch is  instruction-compatible with its successor, the, so amd64-piledriver stages can run on amd64-steamroller systems, and vice versa.
}
+
</pre>
+
  
The ''nginx.conf'' and ''sites-available/localhost'' file is well commented. Customize it to your needs. Make sure you set the listen option correctly. By default, the listen option is set to listen on the loopback interface. If you leave this unchanged other computers on the network will not be able to connect to the server.
+
=== amd64-steamroller ===
  
=== php-fpm ===
+
The '''amd64-steamroller''' subarch supports the  [[Wikipedia:Steamroller (microarchitecture)|AMD steamroller microarchitecture]], produced from early 2014. It is the successor to the [[Wikipedia:Piledriver (microarchitecture)|AMD Piledriver microarchitecture]].
 +
Steamroller APUs are available that use the [[Wikipedia:FM2+ Socket|FM2+ socket]] and  [[Wikipedia:Socket_FP3|FP3 socket]] (mobile.)
  
nginx does not natively support php, so we delegate that responsibility to [[Package:Php#Fpm | php-fpm]]
+
Desktop steamroller APUs include the '''[[Wikipedia:AMD_Accelerated_Processing_Unit#Steamroller_architecture_.282014.29:_Kaveri|Kaveri A-Series APUs]]''', such as the quad-core AMD A10-7850K APU. Steamroller APUs are also available in mobile versions. Server steamroller APUs include the '''Berlin APUs''', which are not yet released.
  
{{file|name=/etc/nginx/sites-available/localhost|desc=fpm configuration|body=
+
Amd64-steamroller subarches are instruction-compatible with amd64-piledriver, but add new instructions over amd64-bulldozer.
server {
+
        ...
+
index index.php index.cgi index.htm index.html;
+
location ~ .php$ {
+
        fastcgi_pass 127.0.0.1:9000;
+
include fastcgi.conf;
+
        }
+
        ...
+
}
+
}}
+
  
==== php caching ====
+
=== amd64-jaguar ===
{{file|name=/etc/nginx/sites-available/localhost|desc=fpm cache configuration|body=
+
fastcgi_cache_path /etc/nginx/cache levels=1:2 keys_zone=MYAPP:100m inactive=60m;
+
fastcgi_cache_key "$scheme$request_method$host$request_uri";
+
server {
+
...
+
        location ~ \.php$ {
+
...
+
fastcgi_cache MYAPP;
+
fastcgi_cache_valid 200 60m;
+
...
+
}}
+
[https://www.digitalocean.com/community/tutorials/how-to-setup-fastcgi-caching-with-nginx-on-your-vps for more information on php caching]
+
  
=== proxy_pass===
+
The '''amd64-jaguar''' (also called AMD Family 16h) subarch supports the [[Wikipedia:Jaguar (microarchitecture)|AMD jaguar microarchitecture]], which is targeted at low-power devices, including notebooks, tablets and small form-factor desktops and servers. It is perhaps most well-known for being the microarchitecture used for the [[Wikipedia:Playstation 4|Playstation 4]] and [[Wikipedia:Xbox One|Xbox One]], which each use custom 8-core Jaguar APUs.
This configuration proxies to other webservers. In this example we have webrick running on port 3000 behind nginx producing the live link http://localhost/rails
+
Socketed Jaguar APUs use the [[Wikipedia:AM1 Socket|AM1 socket]] and  [[Wikipedia:Socket_FT3|FT3 socket]] for mobile devices. G-series [[Wikipedia:System_on_a_chip|"system on a chip" (SoC)]] APUs are available for non-socketed devices such as tablets and embedded system boards.
  
{{file|name=/etc/nginx/sites-available/localhost|desc=rails or python configurations|body=
+
Desktop Jaguar APUs include the '''[[Wikipedia:List_of_AMD_accelerated_processing_unit_microprocessors#.22Kabini.22.2C_.22Temash.22_.282013.2C_28_nm.29|Kabini A-series APUs and Temash E-series APUs]]''', Athlon 5150 and 5350 APUs, and Sempron 2650 and 3850.
server {
+
        ...
+
location /rails/ {
+
    proxy_set_header Host $host;
+
    proxy_set_header X-Real-IP $remote_addr;
+
    proxy_pass http://127.0.0.1:3000/; #for ruby on rails webrick
+
            #proxy_pass http://127.0.0.1:8000/; #for python -m http.server
+
            #proxy_pass http://127.0.0.1:8080/; #for other web servers like apache, lighttpd, tengine, cherokee, etc...
+
}
+
        ...
+
}
+
}}
+
  
== Location Processing Order ==
+
Amd64-jaguar subarches use the MOVBE instruction which is not available on amd64-bulldozer, amd64-piledriver or amd64-steamroller. They are thus not instruction-compatible with any of these subarches.
One often confusing aspect of nginx configuration is the order in which it processes location directives. This section is intended to clarify the confusion and help you to write secure nginx location directives.
+
{{:Install/Footer}}
 
+
=== Two basic types of Location directives ===
+
There are two basic types of location directives. The first is called a "conventional string", and looks something like this:
+
location /foo { deny all; }
+
The second basic type of location directive is a regex, or regular expression block. In its most basic form, it looks like this, with a "~" and then a regular expression that is matched against the request path. "^" can be used to match the beginning of the request path, and "$" can be used to match the end of the request path. If you need to match a ".", you must escape it as "\." as per regular expression matching rules:
+
location ~ \.php$ { blah; }
+
 
+
=== The basic algorithm ===
+
Nginx uses a special algorithm to find the proper location string to match the incoming request. The basic concept to remember is that conventional string directives are placed in one "bucket", and then regular expression strings are placed in another "bucket". Nginx will use the first regular expression match that it finds, when scanning the file from top to bottom. If no matching regular expression is found, nginx will look in its "conventional string" bucket, and try to find a match. In the case of the conventional string matches, the most ''specific'' match will be used, in other words, the one will be used that matches the greatest number of characters in the request path.
+
 
+
This is the foundation for nginx location processing, so always use these rules as a starting point for understanding location matching order. Nginx then provides various sub-types of location directives which modify this default behavior in a number of ways. This will be covered in the next section.
+
 
+
== Advanced Location Processing ==
+
Always use the location processing logic described in the previous section as the foundation for understanding how nginx finds a matching location directive, and then once you are comfortable with how this works, read about these more advanced directives and understand how they fit into nginx's overall logic.
+
 
+
=== = (equals) Location ===
+
One advanced location directive is the "=" location, which can be considered a variant of a "conventional string" directive. "=" directives are searched before all other directives, and if a match found, then the corresponding location block is used. A "=" location must the requested path ''exactly'' and ''completely''. For example, the following location block will match only the request /foo/bar, but not /foo/bar/oni.html:
+
location = /foo/bar { deny all; }
+
 
+
=== ~* (case-insensitive regex) Location ===
+
A "~*" regex match is just like a regular "~" regex match, except matches will be performed in a case-insensitive manner. "~*" location directives, being regex directives, fall into the regex "bucket" and are processed along other regex directives. This means that they are processed in the order they appear in your configuration file and the first match will be used -- assuming no "=" directives match.
+
 
+
=== ^~ (short-circuit conventional string) Location ===
+
You may think that a "^~" location is a regex location, but it is not. It is a variant of a conventional string location. If you recall, nginx will search for conventional string matches by finding the ''most specific'' match. However, when you use a "^~" location, nginx behavior is modified. Imagine the way a conventional string match works. Nginx scans your configuration file, looking at each conventional string match from line 1 to the end of file, but it scans ''all'' conventional string matches to find the ''best'' match. Well, the "~^" location match short-circuits this process. If, in the process of scanning each conventional string match in the config file, nginx encounters a "^~" match that matches the current request path, then nginx will apply this match, and stop looking for the ''best'' match.
+
 
+
== Ebuild Update Protocol ==
+
 
+
To work on a new version of the ebuild, perform the following steps.
+
 
+
First, temporarily set the following settings in <tt>/etc/make.conf</tt>:
+
 
+
<syntaxhighlight lang="bash">
+
NGINX_MODULES_HTTP="*"
+
NGINX_MODULES_MAIL="*"
+
</syntaxhighlight>
+
 
+
This will enable all available modules for nginx.
+
 
+
Now, create a new version of the ebuild in your overlay, and look at all the modules listed at the top of the ebuild. Visit the URLs in the comments above each one and ensure that the latest versions of each are included. Now run <tt>ebuild nginx-x.y.ebuild clean install</tt> to ensure that all modules patch/build properly. Basic build testing is now complete.
+
{{EbuildFooter}}
+

Revision as of 05:08, November 16, 2014

Funtoo Linux Sub-Architectures

This page provides an overview of Funtoo Linux sub-architectures (also called subarches,) designed for quick and easy reference. While this information is available in other places, such as Wikipedia, it often takes some time to study and cross-reference the various articles to get a good understanding of each type of sub-architecture, and this information generally isn't all collected neatly in one place. That is the purpose of this page. When possible, links to more detailed Wikipedia pages are provided. You are encouraged to help maintain this page as well as the Wikipedia articles referenced here.

AMD Processors

amd64-k10

The amd64-k10 subarch provides support for the AMD Family 10h processors, which were released in late 2007 as a successor to the AMD K8 series processors.

Desktop amd64-k10 CPUs include AMD Phenom, AMD Phenom II and AMD Athlon II. Server CPUs include Budapest, Barcelona, Suzuka, Shanghai, Istanbul, Lisbon, and Magny-Cours (more information can be found here.)

amd64-bulldozer

The amd64-bulldozer subarch supports the AMD bulldozer microarchitecture CPUs, which were released from late 2011 through the first quarter of 2012 as a replacement for the K10 microarchitecture CPUs. Bulldozer CPUs use the AM3+ socket and G34 socket for server CPUs.

Desktop bulldozer CPUs include the Zambezi FX-series CPUs. Server bulldozer CPUs include Zurich (Opteron 3200-series), Valencia (Opteron 4200-series) and Interlagos (Opteron 6200 series). More information here..

amd64-piledriver

The amd64-piledriver subarch supports the AMD Piledriver microarchitecture produced by AMD from mid-2012 through 2015, which is the successor to the AMD bulldozer microarchitecture. Piledriver CPUs and APUs are available that use the FM2 socket. Desktop Piledriver CPUs use the AM3+ socket. Server Piledriver CPUs use a variety of sockets, including AM3+, C32 and G34.

Desktop piledriver CPU and APUs include Vishera (FX-8350, FX-8370), Trinity A-series APUs (A6-5400K, A10-5800K) and Richland A-series APUs.

Server piledriver CPUs include Delhi (Opteron 3300-series, AM3+), Seoul (Opteron 4300-series, C32) and Abu Dhabi (Opteron 6300-series, G34). More information here.

Piledriver adds several new instructions over bulldozer, so AMD bulldozer systems cannot run amd64-piledriver-optimized stages. However, this subarch is instruction-compatible with its successor, the, so amd64-piledriver stages can run on amd64-steamroller systems, and vice versa.

amd64-steamroller

The amd64-steamroller subarch supports the AMD steamroller microarchitecture, produced from early 2014. It is the successor to the AMD Piledriver microarchitecture. Steamroller APUs are available that use the FM2+ socket and FP3 socket (mobile.)

Desktop steamroller APUs include the Kaveri A-Series APUs, such as the quad-core AMD A10-7850K APU. Steamroller APUs are also available in mobile versions. Server steamroller APUs include the Berlin APUs, which are not yet released.

Amd64-steamroller subarches are instruction-compatible with amd64-piledriver, but add new instructions over amd64-bulldozer.

amd64-jaguar

The amd64-jaguar (also called AMD Family 16h) subarch supports the AMD jaguar microarchitecture, which is targeted at low-power devices, including notebooks, tablets and small form-factor desktops and servers. It is perhaps most well-known for being the microarchitecture used for the Playstation 4 and Xbox One, which each use custom 8-core Jaguar APUs. Socketed Jaguar APUs use the AM1 socket and FT3 socket for mobile devices. G-series "system on a chip" (SoC) APUs are available for non-socketed devices such as tablets and embedded system boards.

Desktop Jaguar APUs include the Kabini A-series APUs and Temash E-series APUs, Athlon 5150 and 5350 APUs, and Sempron 2650 and 3850.

Amd64-jaguar subarches use the MOVBE instruction which is not available on amd64-bulldozer, amd64-piledriver or amd64-steamroller. They are thus not instruction-compatible with any of these subarches.