text:
LPI Linux Certification/Implementing A Web Server

= 208.1 Implementing a Web server =

Detailed Objectives (208.1)
(LPIC-1 Version 4.5)

Weight: 4

Description: Candidates should be able to install and configure a web server. This objective includes monitoring the servers load and performance, restricting client user access, configuring support for scripting languages as modules and setting up client user authentication. Also included is configuring server options to restrict usage of resources. Candidates should be able to configure a web server to use virtual hosts and customize file access.

Key Knowledge Areas:
 * Apache 2.4 configuration files, terms and utilities.
 * Apache log files configuration and content.
 * Access restriction methods and files.
 * and PHP configuration.
 * Client user authentication files and utilities.
 * Configuration of maximum requests, minimum and maximum servers and clients.
 * Apache 2.4 virtual host implementation (with and without dedicated IP addresses).
 * Using redirect statements in Apache’s configuration files to customize file access.

Terms and Utilities:
 * access logs and error logs

Overview
Apache is the most used web server on the Internet, and the "poster child" for successful open source development. While a web server itself don't need to be particularly fancy (many programming languages have tutorials how to write a HTTP server) Apaches "secret of success" is its flexibility and robustness. Apache can be easily extended by various modules,  and   will be featured in this section.

Installation and Configuration
The Apache HTTP server in its most recent version (2.2 as of writing this) can be downloaded in source code from the Apache HTTP Server Website, or pre compiled as binary package from the repository of your favorite Linux distribution.

For the rest of this section we will refer to the Apache documentation for file names. This documentation is usually installed with the Apache binary inside the. If we cannot reach the local documentation, there still is the official documentation from the Apache Website. We will use a virtual network with Slackware 13.0 inside VirtualBox, which is free (as in cost) and available Free (as in Freedom) with small restrictions. Distribution specific summaries for Debian Lenny and a clone of Redhat Enterprise, Centos 5.4 will follow below.

If we want to compile Apache from source, we use the usual,  ,   steps. For further details please refer to the documentation page.

The web server binary  itself is usually located in. We can use the binary directly to start and stop the web server through command line options, but a better idea is to use the control script  to interface with the. can control the web server process (start and stop) in a convenient way and sets up the environment and checks the configuration file in the background. Back in the days of the transition from Apache 1.3 to the Apache 2.x series the control script was called  to tell it apart from the Apache 1.3 script (then).

It is unfortunate that the LPI still refers to  while the Apache source code produces.

[root@lpislack ~]# apachectl Usage: /usr/sbin/httpd [-D name] [-d directory] [-f file] [-C "directive"] [-c "directive"] [-k start|restart|graceful|graceful-stop|stop] [-v] [-V] [-h] [-l] [-L] [-t] [-S] Options: -D name           : define a name for use in  directives -d directory      : specify an alternate initial ServerRoot -f file           : specify an alternate ServerConfigFile -C "directive"    : process directive before reading config files -c "directive"    : process directive after reading config files -e level          : show startup errors of level (see LogLevel) -E file           : log startup errors to file -v                : show version number -V                : show compile settings -h                : list available command line options (this page) -l                : list compiled in modules -L                : list available configuration directives -t -D DUMP_VHOSTS : show parsed settings (currently only vhost settings) -S                : a synonym for -t -D DUMP_VHOSTS -t -D DUMP_MODULES : show all loaded modules -M                : a synonym for -t -D DUMP_MODULES -t                : run syntax check for config files

Hmmm. This does not look right, because if  encounters parameters it does not understand, it passes them directly to. And no parameter is such a parameter, so  invokes   without any parameter.

can,   and   the web server, but even more useful is   and   which restarts/stops the web server while not stopping currently open connections. does the same as  in testing the apache configuration file. The options  and   need the   module to display many useful status informations about our http server.

The logs for your Apache instance go to. The two most important log files are, which logs every access to the web server and   which only records errors. Tools like Awstats and Webalizer use the  to generate their reports.

A snippet of  shows (taken from the Debian Lenny machine  ) the IP   accessing   on the website, which is the “welcome” page of the web server (more on this later), then trying to   and then   which both result in a “ ”, which means “ ”. 192.168.10.21 - - [02/Jun/2009:17:06:01 -0400] "GET / HTTP/1.1" 200 56 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10" 192.168.10.21 - - [02/Jun/2009:17:17:12 -0400] "GET /favicon.ico HTTP/1.1" 404 300 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10" 192.168.10.21 - - [05/Jun/2009:16:41:39 -0400] "GET / HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux 2.6.27.7-smp) KHTML/3.5.10 (like Gecko)" 192.168.10.21 - - [05/Jun/2009:16:41:39 -0400] "GET /favicon.ico HTTP/1.1" 404 300 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux 2.6.27.7-smp) KHTML/3.5.10 (like Gecko)" 192.168.10.21 - - [05/Jun/2009:16:41:50 -0400] "GET /login.html HTTP/1.1" 404 299 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux 2.6.27.7-smp) KHTML/3.5.10 (like Gecko)" This snippet from  shows the same errors but in greater detail: [Fri Jun 05 13:41:10 2009] [notice] mod_python: using mutex_directory /tmp [Fri Jun 05 13:41:11 2009] [notice] Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny3 with Suhosin-Patch mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations [Fri Jun 05 16:41:39 2009] [error] [client 192.168.10.21] File does not exist: /var/www/favicon.ico [Fri Jun 05 16:41:50 2009] [error] [client 192.168.10.21] File does not exist: /var/www/login.html

The configuration of Apache takes place in. This lengthy, but well documented, configuration file is in part structured similar to a HTML page. To strip out any comments you can easily use. root@lpislack:~# grep -v ^# /etc/httpd/httpd.conf | grep -v ^$ | grep -v "^   #" ServerRoot "/usr" Listen 80 LoadModule auth_basic_module lib/httpd/modules/mod_auth_basic.so LoadModule auth_digest_module lib/httpd/modules/mod_auth_digest.so ... LoadModule log_config_module lib/httpd/modules/mod_log_config.so LoadModule userdir_module lib/httpd/modules/mod_userdir.so LoadModule alias_module lib/httpd/modules/mod_alias.so LoadModule rewrite_module lib/httpd/modules/mod_rewrite.so User apache Group apache ServerAdmin webadmin@your.site DocumentRoot "/srv/httpd/htdocs"  Options FollowSymLinks AllowOverride None Order deny,allow Deny from all   Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all  DirectoryIndex index.html ErrorLog "/var/log/httpd/error_log" LogLevel warn LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined CustomLog "/var/log/httpd/access_log" common ScriptAlias /cgi-bin/ "/srv/httpd/cgi-bin/"  AllowOverride None Options None Order allow,deny Allow from all  DefaultType text/plain TypesConfig /etc/httpd/mime.types root@lpislack:~# This slightly striped down  is taken from a Slackware 13.0 system ( . There are two terms to know when talking about  : "directives" and "containers". "Directives" are the configuration options (and their values) themselves, while "containers" are directories or collections of files. Any directive inside a container will only be valid inside this container, directives outside the container are of global effect for the whole site. On the other side, there are directives that are only valid inside a container.
 * This is a tricky on. All relative paths start from here, the absolute ones are, as implied by the name, absolute.
 * This is a tricky on. All relative paths start from here, the absolute ones are, as implied by the name, absolute.

 * : The TCP port the  listens for incoming connection requests. If our machine has more than one network address, we can bind the   to one (ore more) IP adresses/port combinations here as well.
 * Loads the module  located in   relative to the , so the whole path to this module is
 * Loads the module  located in   relative to the , so the whole path to this module is

 * : The user account  runs as. This better be an restricted account. One (the first)   process has to run as root, if it wants to claim port 80.
 * : The group of the user  runs as.
 * : the e-mail address of the administrator responsible for running the . This shows up when errors occur.
 * : This is the directory where the actual HTML documents live on your hard drive!
 * This is a container object. All directives inside are only valid for this directory " " and all of its subdirectories.
 * This is a container object. All directives inside are only valid for this directory " " and all of its subdirectories.

 * Potential security risk! Does what its name suggest.
 * Potential security risk! Does what its name suggest.

 * You can override most directives with a  file. This is a security risk and the use of   is denied by this directive.
 * You can override most directives with a  file. This is a security risk and the use of   is denied by this directive.

 * Controls the access to files and directories. First look who is not allowed, then look who is allowed. The default is the last control that matches, if non matches or both match, use the default (=last)!
 * Controls the access to files and directories. First look who is not allowed, then look who is allowed. The default is the last control that matches, if non matches or both match, use the default (=last)!

 * Denies all hosts the access to all file in this container.
 * Denies all hosts the access to all file in this container.

 * Container for the  directory. Note the   and the   directives. Here we want access from all hosts.
 * Container for the  directory. Note the   and the   directives. Here we want access from all hosts.

If no  exist in this directory the contents of the directory itself is shown. allows this, while  generates an error message instead of listing the directories contents.
 * The file with this name is presented to the client when a web browser accesses a directory and not a specific HTML page.
 * The file with this name is presented to the client when a web browser accesses a directory and not a specific HTML page.

 * Sets the logfile for error messages.
 * Sets the logfile for error messages.

 * Sets the verbosity of the error messages.
 * Sets the verbosity of the error messages.

 * Sets the format of the entries in the custom log file (usually )
 * Sets the format of the entries in the custom log file (usually )

 * Sets name and location of the custom log file.
 * Sets name and location of the custom log file.

 * Directory for CGI scripts.
 * Directory for CGI scripts.

 * Apache uses this MIME type for the HTML pages it provides to the web browser, if the HTML page itself contains no other information.
 * Apache uses this MIME type for the HTML pages it provides to the web browser, if the HTML page itself contains no other information.

 * List of MIME types to use for different types of file names.
 * List of MIME types to use for different types of file names.

Access restrictions methods and files
Access to files and directories on the web server can be restricted based on the machines IP or network (hostname, domain, IP address, or network) or based on user name and password. While the access can be restricted by this methods all content transmitted in both directions is still not encrypted! To secure the communication and ensure the identity of the web server the SSL/TLS protocol will be used in the next chapter of this book.

Container
The behaviour of the Apache web server can be finely tuned in the Apache configuration (or the  file) on a per directory (  container), per file (  container), or per URL (  container) basis. The directives inside a  (or  ) container are valid for the directory itself and all its subdirectories. Most of this directives can be overwritten by external configuration files, usually. This is highly discouraged for security and sanity reasons. Some possible directives for  are:
 * : no use of external configuration changes allowed (safest)
 * : all directives can be changed (most insecure)
 * : some changes are allowed (not secure at all)
 * : mainly authentication related directives can be changed
 * : mainly  directives can be overwritten

Machine Restrictions
sets the sequence of access restrictions, where the last matching rule wins. The last rule is also the default rule if neither rule matches or both match. The possible /  restrictions are hostname (host.domain.example), domain (domain2.example), ip (192.168.10.3) and network (192.168.10 192.168.10.0/24).  Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all Deny from example.com  All access from everywhere is allowed, but the domain  is denied.

User Based Restrictions
User based access restrictions are insecure on different levels:
 * passwords are not encrypted (danger: snooping)
 * every content up- and download is clear text (danger: snooping)
 * there is no guarantee about the identity of the server (danger: fraud/phishing)

One big part of Apaches flexibility is its capability to talk to different back ends for user authentication, the most simple being plain text files, which is OK for smaller numbers of users, but do not scale to more than (about) 150 people.

Usernames, passwords and groups are stored in text files usually called  and. These names are defined in  or   by the directives   and. Both directives are part of the  module. We create/change a username and password with the  utility. The  option creates a new password file, if such a file already exists it will be destroyed without warning! requires two parameters: password and username. root@lpislack# htpasswd -c /etc/httpd/htpasswd newuser ... One other important thing to keep in mind is that the only safe place for password file and group file is outside the , where these files can't accidentally or maliciously be downloaded by unauthorized visitors.

Going back to reality, overwriting the  directives with a   file and placing the   and   inside the document directories is often done, if the web site administrator does not have full access to the Apache configuration, e. g. in shared hosting environments. To protect these files one can restrict the access to them in a  container spelled out in the :  Order allow,deny Deny from all Satisfy All

Example 1
This example shows the preferred, but sadly not always possible configuration. The restricted directory is, that can be reached at   by my web browser.

AuthType Basic AuthName "Private1! Restricted Access!" require valid-user AuthUserFile /etc/httpd/htpasswd  After fiddling with the configuration file we probably should restart the  server process. root@lpislack:/etc/httpd# /etc/rc.d/rc.httpd restart

Create password file : root@lpislack:/etc/httpd# htpasswd -c /etc/httpd/htpasswd firstuser New password: Re-type new password: Adding password for user firstuser root@lpislack:/etc/httpd# cat htpasswd firstuser:2km7TAXpj3scw root@lpislack:/etc/httpd# This file is only accessible by authorized ( !) users. (And by the way, the password is .)

The password protected page  source code: root@lpislack:/srv/www/htdocs/private1# cat index.html This is private!

Example 2
This example shows a commonly used configuration. It is not the best, but sometimes the only possible setup. We can do much better (much safer) if we can locate the password file outside the . The restricted directory here is, that can be reached at   by the web browser.

The only change to  is to allow. In fact, if we can change, we could do the right thing in the first place (see Example 1).  AllowOverride AuthConfig

Set up the external configuration file  in  : AuthType Basic AuthName "Private2! Restricted Access!" require valid-user AuthUserFile /srv/httpd/htdocs/private2/.htpasswd

Restart : root@lpislack:/etc/httpd# /etc/rc.d/rc.httpd restart

Create password file with the user  with the password  : root@lpislack:/etc/httpd# htpasswd -c /srv/www/htdocs/private2/.htpasswd seconduser New password: Re-type new password: Adding password for user seconduser root@lpislack:/etc/httpd# cat /srv/www/htdocs/private2/.htpasswd seconduser:2l.jKENGUwyQ6

Modules and CGI
Flexibility and easy extendability are two important reasons for Apaches success. They are achieved in part by the CGI (=common gateway interconnect) concept and the ability to extend an already compiled Apache instance with modules. CGI programs (often called "CGI scripts") are executable programs that can be written in any language, be it bash, pearl, php, basic, assembler or ada. They run on the server, which uses up hardware resources of the server (RAM and CPU time) but do not impact the client. He receives what looks like any static HTML page, although the HTML page was dynamically created by the CGI program. The  takes the output of the CGI program and gives it unchanged and unchecked to the client web browser. (e.g., the HTTP headers have to be crafted by the CGI program). CGI programms can also take user input (via PUT or GET requests).

Example
This  script outputs "don't try this at home" in ugly blinking letters and prints the content of   to show how dangerous CGI programming can be! echo "Content-type: text/html" echo "" echo " " echo " " echo " DON'T TRY THIS AT HOME! " cat /etc/passwd echo " " echo " "
 * 1) !/bin/sh

Modules
Modules on the other hand can extend the abilites of the  with features that are not part of the main Apache source code. (Some modules can be compiled into the  directly.) Modules can be switched on and off (e. g. for security reasons) with a simple change in the. Most modules need addional configuration directives in, usually by importing configuration files.

For security reasons we will only enable modules actually needed by our web site.

mod_php
One very useful example is. If PHP code is executed as a simple CGI script, every script starts the PHP parsing engine, the HTML text is generated, and then the PHP parsing engine is shut down.

starts the PHP engine as a module for the Apache process and the PHP engine will be persisted over multiple requests. This drastically reduces the overhead of using PHP for dynamic web site creation. As an added bonus we can use PHP code directly in our HTTP sourcecode. This code also runs at the server side and is then replaced by its output before the complete HTML page is sent to the client. If we use a database, this connection can also be persisted if we use.

The PHP language itself is configured by, located at  , but this file usually don't need to be changed.

To enable  on Slackware 13.0 we only need to uncomment the line Include /etc/httpd/mod_php.conf in. This will include this already set up configuration directly into our.

We now change  to AddType application/x-httpd-php .php .html .htm to use PHP code inside HTML documents. This can be convenient, but increases the workload on high traffic websites considerably, because ever requested HTML page is shoved through the PHP interpreter. Another thing we can do to make our lives a bit easier, is adding  to the   directive.

Now we restart the

Example
To check if it works we create  somewhere below the Status for PHP  Now remove this file (or at least deny read access), because this will blast our entire web server configuration to the whole internet, where every creep of the planet is just milliseconds away from us. (Try searching for  in Google...)

mod_perl
While Slackware 13.0 comes with  as an installable package, the minimal test CGI script   in   needs a small help. First we need to mark it as an executable by root@lpislack:/srv/www/htdocs# chmod a+x ../cgi-bin/printenv and then change the first line " " to " ". Now we can navigate our web browser to http://lpislack.vbox.privat/cgi-bin/printenv and see if it works: DOCUMENT_ROOT="/srv/httpd/htdocs" GATEWAY_INTERFACE="CGI/1.1" HTTP_ACCEPT="text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1" HTTP_ACCEPT_CHARSET="iso-8859-1, utf-8, utf-16, *;q=0.1" HTTP_ACCEPT_ENCODING="deflate, gzip, x-gzip, identity, *;q=0" HTTP_ACCEPT_LANGUAGE="de-DE,de;q=0.9,en;q=0.8" HTTP_CACHE_CONTROL="no-cache" HTTP_CONNECTION="Keep-Alive, TE" HTTP_HOST="lpislack.vbox.privat" HTTP_TE="deflate, gzip, chunked, identity, trailers" HTTP_USER_AGENT="Opera/9.80 (X11; Linux i686; U; de) Presto/2.2.15 Version/10.10" PATH="/bin:/usr/bin:/sbin:/usr/sbin" QUERY_STRING="" REMOTE_ADDR="192.168.10.21" REMOTE_PORT="40206" REQUEST_METHOD="GET" REQUEST_URI="/cgi-bin/printenv" SCRIPT_FILENAME="/srv/httpd/cgi-bin/printenv" SCRIPT_NAME="/cgi-bin/printenv" SERVER_ADDR="172.25.28.4" SERVER_ADMIN="you@example.com" SERVER_NAME="lpislack.vbox.privat" SERVER_PORT="80" SERVER_PROTOCOL="HTTP/1.1" SERVER_SIGNATURE="" SERVER_SOFTWARE="Apache/2.2.14 (Unix) DAV/2 PHP/5.2.12" UNIQUE_ID="S3ibiawZHAQAAAq2Hf0AAAAD" We do not use  at this time but run CGI scripts written in Perl as we would run any other executable.

So  (from http://perl.apache.org) does for the Perl language the same as   does for PHP : it adds native language support directly into the Apache web server and so reduces load and speeds up response time.

Sadly there is no pre built  package for Slackware 13.0, but http://slackbuilds.org has at http://slackbuilds.org/repository/13.0/network/mod_perl/ a tried and true buildscript for everyone who can read the instructions. (As as sidenote, SlackBuilds are the preferred method to build Slackware packages from source.)

 * This situation demonstrates the use of modules: Functionality that is not included in Apache can be added by external modules without recompiling Apache. If there was a bugfix for Apache and we had to upgrade,  will still work fine as a modul. If   was compiled into Apache we had to get the source code, fit it to our setup, compile and install it. With every update we would need to go through the same process, just to keep using Perl.

After building and installing the package we simply need to include  to   and restart the Apache server.

# mod_perl mode SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI </Files> Perl files can live everywhere in the  and their name has to end in " ". Let's go back to the  example. If we call it again, it will still be executed as CGI, but if we copy it to the  and rename it   it will be run by , as we can clearly see by the   and   lines in the output below: DOCUMENT_ROOT="/srv/httpd/htdocs" GATEWAY_INTERFACE="CGI/1.1" HTTP_ACCEPT="text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1" HTTP_ACCEPT_CHARSET="iso-8859-1, utf-8, utf-16, *;q=0.1" HTTP_ACCEPT_ENCODING="deflate, gzip, x-gzip, identity, *;q=0" HTTP_ACCEPT_LANGUAGE="de-DE,de;q=0.9,en;q=0.8" HTTP_CONNECTION="Keep-Alive, TE" HTTP_HOST="lpislack.vbox.privat" HTTP_TE="deflate, gzip, chunked, identity, trailers" HTTP_USER_AGENT="Opera/9.80 (X11; Linux i686; U; de) Presto/2.2.15 Version/10.10" MOD_PERL="mod_perl/2.0.4" MOD_PERL_API_VERSION="2" PATH="/bin:/usr/bin:/sbin:/usr/sbin" QUERY_STRING="" REMOTE_ADDR="192.168.10.21" REMOTE_PORT="45519" REQUEST_METHOD="GET" REQUEST_URI="/printenv.pl" SCRIPT_FILENAME="/srv/httpd/htdocs/printenv.pl" SCRIPT_NAME="/printenv.pl" SERVER_ADDR="172.25.28.4" SERVER_ADMIN="webadmin@lpislack.vbox.privat" SERVER_NAME="lpislack.vbox.privat" SERVER_PORT="80" SERVER_PROTOCOL="HTTP/1.1" SERVER_SIGNATURE="" SERVER_SOFTWARE="Apache/2.2.14 (Unix) DAV/2 PHP/5.2.12 mod_perl/2.0.4 Perl/v5.10.0" UNIQUE_ID="S3i3VqwZHAQAAAxfFDUAAAAA"

Restrict Resource Usage
Apache is capable of serving up pretty busy web sites. One mechanism to provide quick responsetimes under heavy load is to have waiting processes ready to jump into action at any given time. So unlike most other programs Apache spawns multiple processes when it is started. The number of processes is adjusted depending on the numbers of connections by creating and destroying child processes as needed.

One control process listens for new requests, usually on TCP port 80, while every client is connected to its very own child process that serves requests for the whole lifetime of this connection. determines the number of processes to begin with when Apache is started. But this is of little meaning, because  sets the minimum number of idle Apache processes waiting to server new connections. If there are less spare servers left, they are created at a rate of one per second. If that is not enough, the rate of process creation is doubled every second up to 32 new processes per second. If this is not sufficient, we sure as hell have other problems. On the other hand, if there are more idle servers than  the unneeded processes are shut down one by one.

limits the absolute number of simultaneously running server processes, and with that the maximum number of simultaneous client connections. The maximum number of 256 is a hard limit set at compile time. If there are more connection requests than apache processes to serve them, the requests are first moved to a backlog, and only if this backlog is filled up too, the requests are rejected.

The lifetime of an apache (child) process can be limited by the absolute number of connections he will serve as defined by. This can mitigate problems when memory leaks on less stable platforms occur or problems caused by buggy modules or badly written CGIs. If set to  child processes can live indefinitely, if they are not terminated because of too many spare servers.

Redhat/CentOS
Installation The web server binary is called. The control script is called. The access and error log files are located in  and called   and.
 * 1) yum install httpd

Debian
Intallation The web server binary is called. The control script is called, which is not the same as   by another name. The access and error log files are located in  and called   and. (Note the dot “.” instead of the underscore “_”.)
 * 1) aptitude install apache2


text:
LPI Linux Certification/Maintaining A Web Server

= 208.2 Maintaining A Web Server =

Detailed Objectives (208.2)
(LPIC-2 Version 4.5)

Weight: 3

Description: Candidates should be able to configure a web server to provide HTTPS.

Key knowledge areas
 * SSL configuration files, tools and utilities.
 * Generate a server private key and CSR for a commercial CA.
 * Generate a self-signed Certificate.
 * Install the key and certificate, including intermediate CAs.
 * Configure Virtual Hosting using SNI.
 * Awareness of the issues with Virtual Hosting and use of SSL.
 * Security issues in SSL use, disable insecure protocols and ciphers.

Terms and Utilities:
 * Apache2 configuration files
 * SSLEngine, SSLCertificateKeyFile, SSLCertificateFile
 * SSLCACertificateFile, SSLCACertificatePath
 * SSLProtocol, SSLCipherSuite, ServerTokens, ServerSignature, TraceEnable
 * SSLCACertificateFile, SSLCACertificatePath
 * SSLProtocol, SSLCipherSuite, ServerTokens, ServerSignature, TraceEnable

Overview
Apache is an impressive and powerful application. It is not only able to serve simple (static) HTTP pages, which is (essentially) a trivial task. Apache can host multiple web sites (http://www.example.com and http://www.beispiel.de) on one physical machine at one IP address using one Apache process by using "virtual hosts". Apache can also use multiple IP addresses to store different web sites on the same physical machine, which does not (necessarily) need different networking card. This is also realized by "virtual hosts".

Also, Apache can use very sophisticated methods to redirect queries.

Most importantly, at least to me, is the use SSL (as OpenSSL). SSL can do many things for many people: it can secure (encrypt) the content going back and forth between the web client and the web server. It can also ensure the identity of both parties communicating, the server and the client.

Virtual Hosts
VirtualHost sections contain directives that apply only to a specific hostname or IP address. See and

OpenSSL
OpenSSL(link) is a collection of tools that implement and handle certificates(link) that conform to the Transport Layer Security (TLS) ??? protocol(link).

What are certificates?
Secure Socket Layer (SSL)(link), or Transport Layer Security (TLS)(link) as SSL versions beyond 3 are called now, uses Public Key Cryptography(link) to protect transactions over the insecure and not secureable internet. Like all public key cryptographic schemes (I know of) TLS uses a secret private key and an openly shared public key, called a certificate. The special twist with TLS certificates is the certification authority (CA)(link). For a TLS certificate to be recognized as valid, it has to be (cryptographically) signed by a "Certification Authority".

Flashback Public Key Crypto
In a nutshell, public key crypto works like this: there are two keys, one public key for everyone to have, and one private key, for my eyes only. The private key is also (usually) protected by a very strong password.

Both keys can be used to encrypt data that only the other key can decrypt. There is in principle no difference between the public and private key!

On the other hand side it seems to make no sense to encrypt data with your private key, because everyone on the internet has already or can get your public key and decrypt the data. But if you encrypt data with your private key, you can prove you are in possession of the private key. This way you can (cryptographically) sign the data. To sign a piece of data we usually don't encrypt the whole but a (cryptographic) hash(link) of it and so can prove the authenticity of the data, provided we guard our private key very carefully. The password simply is a second security measure, in case the private key leaked into the public or gets lost.

What does a CA do exactly?
A Certification Authority signs our public keys with its private key. Then they are called certificates. Thats it! Almost. We send in a "certificate signing request" (more on this later), a claim of your identity and a varying sum of money and the CA tries (depending on the amount of money we spent) to check our identity and if succeeded will sign our request and finally send back the signed certificate. But keep in mind that there is only so much The Hong Kong Post Office(TM) (or any other CA) can do to verify e. g. a Brazilian identity. But now the problem is to get the certificate of the CA... and here the trick is: we already have it! Most pieces of software that can use TLS certificates come with a list of trusted (this is the magic word) CAs. Any new certificate (e. g. shop.example.com) signed by this trusted CAs (e. g. by StartSSL) with their certificates installed on our machines is also regarded as trusted. Unsigned certificates or ones signed by unknown CA are regarded as "not trusted" an we are presented with a dire warning.

How do certificates work exactly?
We can use TLS certificates with almost any insecure service on the internet, if we only try hard enough.
 * Web browsing (HTTPS instead of HTTP)
 * Sending Mail (SMTPS instead of SMTP)
 * Receiving Mail (IMAPS instead of IMAP/POP3S instead of POP3)
 * Chat (IRC over TLS)
 * VPN (OpenVPN)

How does it work (for web surfing)? A bit simplified:
 * 1) the client connects to the server
 * 2) the server sends over the certificate
 * 3) the client checks certain properties of the certificate
 * 4) the certificate is bound to the Full Qualified Host Name (FQHN) of the server we connect to. The web browser checks if the FQHN of the server and the certificate match, if not it generates an error.
 * 5) the certificate needs to be signed by a trusted CA, if not the web browser generates an error.
 * 6) certificates have a limited lifetime, depending on the amount of money we paid. The web browser checks if the certificate is still "fresh" and if not, it generates an error.
 * 7) there is a list of invalid certificates on our computer. These certificates are revoked for different reasons: they were compromised, had errors, were stolen, ... If the server certificate is on that list, the client software generates an error.
 * 8) if the certificate is deemed valid (or if an invalid certificate is accepted, despite being not valid) the client encrypts a random value with the certificate and sends it to the server.
 * 9) only the client (because he generated it) and the server (because only he can decrypt it) know the random value, generated by the client
 * 10) from the random value a symmetric key is generated on both ends and any further communication both ways is encrypted with this generated key. (A symmetric key is used, because encryption and decryption are much easier to handle by the CPU.)

How to find and use certificates
CA root certificates are stored on our computers in lots of different places. Often every piece of software that uses TLS brings their own list of trusted CAs.
 * openssl:
 * firefox:
 * thunderbird:
 * claws-mail:

On the other hand side  can act as an TLS client for classical "clear text" protocols like, well like all the internet protocols, e. g. POP3

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
LPI Linux Certification/Implementing A Proxy Server

Detailed Objectives (208.3)
(LPIC-2 Version 4.5)

Weight: 2

Description: Candidates should be able to install and configure a proxy server, including access policies, authentication and resource usage.

Key Knowledge Areas:
 * Squid 3.x configuration files, terms and utilities
 * Access restriction methods
 * Client user authentication methods
 * Layout and content of ACL in the Squid configuration files

Terms and Utilities:

Exercises

 * Implementing a proxy server

We will be using the squid web proxy server version 2.4 and Linux kernel version 2.4.

Proxying can be done in two ways : normal proxying and transparent proxying
 * In normal proxying, the client specifies the hostname and port number of a proxy in his web browsing software. The browser then makes requests to the proxy, and the proxy forwards them to the origin servers.
 * In transparent proxying, ...

Use transparent proxying if : You want to force clients on your network to use the proxy, whether they want to or not. You want clients to use a proxy, but don't want them to know they're being proxied. You want clients to be proxied, but don't want to go to all the work of updating the settings in hundreds or thousands of web browsers.

There are two types of transparent proxying :

 * Squid on the gateway
 * Squid on a separate box than the gateway

Squid on the gateway box
Setting up squid for ordinary proxying is quite simple : after installing squid, edit the default configuration file squid.conf Find the following directives, uncomment them, and change them to the appropriate values: Next, look at the cache_effective_user and cache_effective_group directives, and set them up with a dedicated user and group (i.e squid/squid)
 * httpd_accel_host virtual
 * httpd_accel_port 80
 * httpd_accel_with_proxy on
 * httpd_accel_uses_host_header on

Finally, look at the http_access directive. The default is usually ``http_access deny all''. This will prevent anyone from accessing squid. For now, you can change this to ``http_access allow all'', but once it is working, you will probably want to read the directions on ACLs (Access Control Lists), and setup the cache such that only people on your local network (or whatever) can access the cache.

ACLs in squid will enable you to restrict access to the proxy. The general format for an ACL rule is : acl aclname acltype string1 ... ACL rules can then be used in the http_access directive

ACL types are : acl aclname src 172.16.1.0/24 acl aclname dst 172.16.1.0/24 acl ACLTIME time M 9:00-17:00 acl acceleratedport port 80 acl aclname proto HTTP FTP acl aclname method GET POST acl twoconn maxconn 5
 * Src : acl aclname src ip-address/netmask
 * Dst : acl aclname dst ip-address/netmask
 * Time : acl aclname time [day-abbreviations: M,T,W,H,F,A,S] [h1:m1-h2:m2]
 * Port : acl aclname port port-no
 * Proto : acl aclname proto protocol
 * Method : acl aclname method method-type
 * Maxconn : acl aclname maxconn integer

Next, initialize the cache directories with squid -z (if this is a not a new installation of squid, you should skip this step). Next, launch squid via the /etc/init.d/squid script, and you should be able to set your web browser's proxy settings to the IP of the box and port 3128 (unless you changed the default port number) and access squid as a normal proxy. Implementing a proxy server Transparent proxying can be set up in two different ways : on the router or on another (remote) host Transparent proxying on the router will involve setting up squid in the « normal », and configuring the packet filtering subsystem to redirect clients' connections to squid The kernel's networking options required are :
 * Under 'General Setup'
 * Networking support
 * Sysctl support

 * Under 'Networking Options'
 * Network packet filtering
 * TCP/IP networking

 * Under 'Networking Options' -> IP: Netfilter Configuration
 * Connection tracking
 * IP tables support
 * Full NAT
 * REDIRECT target support

 * Under 'File Systems'
 * /proc filesystem support

You must say NO to Fast switching under Networking Options !

Once you have your new kernel up and running, make sure you have IP forwarding enabled. Next, to configure iptables to enable transparent proxying, all you have to do is :

Transparent proxying to a remote box
Let's assume we have two boxes called squid-box and iptables-box, and that they are on the network local-network. First, on the machine that squid will be running on, squid-box, you do not need iptables or any special kernel options on this machine, just squid. You *will*, however, need the 'http_accel' options as described above. Now, on the machine that iptables will be running on, iptables-box, you will need to configure the kernel as described above, except that you don't need the REDIRECT target support. You will need 2 iptables rules : '''iptables -t nat -A PREROUTING -i eth0 -s ! squid-box -p tcp --dport 80 -j DNAT --to squid-box:3128''' iptables -t nat -A POSTROUTING -o eth0 -s local-network -d squid-box -j SNAT --to iptables-box The first one sends the packets to squid-box from iptables-box. The second makes sure that the reply gets sent back through iptables-box, instead of directly to the client. This is very important, because otherwise squid will never receive the answer from the target web server (and thus, no caching can take place!)

Key terms, files and utilities :
 * squid.conf
 * Acl
 * http_access
 * Exercises


text:
LPI Linux Certification/DHCP Configuration

Detailed Objectives (210.1)
(LPIC-2 Version 4.5)

Weight: 2

Description: Candidates should be able to configure a DHCP server. This objective includes setting default and per client options, adding static hosts and BOOTP hosts. Also included is configuring a DHCP relay agent and maintaining the DHCP server.

Key Knowledge Areas:
 * DHCP configuration files, terms and utilities.
 * Subnet and dynamically-allocated range setup.
 * Awareness of DHCPv6 and IPv6 Router Advertisements

Terms and Utilities:
 * DHCP Log messages in syslog or systemd journal
 * DHCP Log messages in syslog or systemd journal
 * DHCP Log messages in syslog or systemd journal

= DHCP configuration ==

Overview
Description: ''The candidate should be able to configure a DHCP server and set default options, create a subnet, and create a dynamically-allocated range. This objective includes adding a static host, setting options for a single host, and adding bootp hosts. Also included is to configure a DHCP relay agent, and reload the DHCP server after making changes.''

Key files, terms, and utilities include:

dhcpd.conf dhcpd.leases

DHCP?
Most people reading this will already know the DHCP protocol. Just as a quick reminder. DHCP stands for Dynamic Host Configuration Protocol and is commonly used to distribute specific network settings in networks. Settings such as the default gateway, nameservers, IP addresses and much more.

As for a small illustration of the protocol itself.

Configuring dhcpd
After the installation of dhcpd the main configuration file can be found at /etc/dhcpd.conf. For Debian installations, one should edit /etc/default/dhcp as soon as the installation is finished and change the following line according to your setup.

INTERFACES="eth1" # or "eth1 eth2", whatever interfaces you wish to serve ip's.

The dhcpd.conf file is divided in global parameters and subnet specific parameters. Each subnet can override the global parameters. The most commonly used parameters are the following.

option domain-name "example.com"; option domain-name-servers "192.168.0.1, 193.190.63.172" option subnet-mask 255.255.255.0; # global Subnet mask default-lease-time 600; # Seconds each DHCP lease is granted and after which a request for the same ip is launched. max-lease-time 7200; # If DHCP server does not respond, keep IP till 7200 seconds are passed. subnet 192.168.0.0 netmask 255.255.255.240 { # Subnet for first 13 devices, 10 of which are servers, 3 printers range 192.168.0.10 192.168.0.13; # Range of IP's for our printers option subnet-mask 255.255.255.240; option broadcast-address 192.168.0.15; # This is the subnets broadcast address option routers 192.168.0.14; # The gateway of this subnet option time-servers 192.168.0.14; # Gateway is running a timeserver option ntp-servers 192.168.0.14; # Gateway running a timeserver } subnet 192.168.0.16 netmask 255.255.255.224 { # Subnet for 29 computers range 192.168.0.17 192.168.0.45; option subnet-mask 255.255.255.224; option broadcast-address 192.168.0.47; option routers 192.168.0.46; } group { host server1 { # the first fixed server for subnet 192.168.0.0/28 server-name server1; hardware ethernet 0f:45:d3:23:11:90; fixed-address 192.168.0.1; } host server2 { server-name server2; hardware ethernet 0f:45:d3:23:11:91; fixed-address 192.168.0.2; } }

This example is just providing a hint about possible options and overrides.

More info can be found on dhcpd.conf and dhcp-options in man pages. Look in those pages too for information about using the DHCP server to serve BOOTP as well, useful for diskless clients.


text:
LPI Linux Certification/NIS Configuration

Detailed Objective
Weight: 1

Description: Candidates should be able to configure an NIS server. This objective includes configuring a system as an NIS client.

 * Key knowledge area(s):
 * NIS configuration files, terms and utilities
 * Create NIS maps for major configuration files
 * Manipulate nsswitch.conf to configure the ability to search local files, DNS, NIS, etc.

 * The following is a partial list of the used files, terms and utilities:
 * ypbind
 * ypcat
 * ypmatch
 * ypserv
 * yppasswd
 * yppoll
 * yppush
 * ypwhich
 * rpcinfo
 * nsswitch.conf
 * ypserv.conf
 * contents of /var/yp/*
 * netgroup
 * nicknames
 * securenets
 * Makefile

Overview
Description: ''The candidate should be able to configure an NIS server and create NIS maps for major configuration files. This objective includes configuring a system as a NIS client, setting up an NIS slave server, and configuring ability to search local files, DNS, NIS, etc. in nsswitch.conf.''

Key files, terms, and utilities include:

nisupdate, ypbind, ypcat, ypmatch, ypserv, ypswitch, yppasswd, yppoll, yppush, ypwhich, rpcinfo nis.conf, nsswitch.conf, ypserv.conf /etc/nis/netgroup /etc/nis/nicknames /etc/nis/securenets

NIS
NIS stands for Network Information Service. Its purpose is to provide information, that has to be known throughout the network, to all machines on the network. Information likely to be distributed by NIS is login names/passwords/home directories (/etc/passwd) and group information (/etc/group)

If, for example, your password entry is recorded in the NIS passwd database, you will be able to login on all machines on the network which have the NIS client programs running.

Within a network there must be at least one machine acting as a NIS server. You can have multiple NIS servers, each serving different NIS "domains" - or you can have cooperating NIS servers, where one is the master NIS server, and all the other are so-called slave NIS servers (for a certain NIS "domain", that is!) - or you can have a mix of them...

Slave servers only have copies of the NIS databases and receive these copies from the master NIS server whenever changes are made to the master's databases. Depending on the number of machines in your network and the reliability of your network, you might decide to install one or more slave servers. Whenever a NIS server goes down or is too slow in responding to requests, a NIS client connected to that server will try to find one that is up or faster.

NIS databases are in so-called DBM format, derived from ASCII databases. For example, the files /etc/passwd and /etc/group can be directly converted to DBM format using ASCII-to-DBM translation software ("makedbm", included with the server software). The master NIS server should have both, the ASCII databases and the DBM databases.

Slave servers will be notified of any change to the NIS maps, (via the "yppush" program), and automatically retrieve the necessary changes in order to synchronize their databases. NIS clients do not need to do this since they always talk to the NIS server to read the information stored in it's DBM databases.

To run any of the software mentioned below you will need to run the program /usr/sbin/portmap. The RPC portmapper (portmap(8)) is a server that converts RPC program numbers into TCP/IP (or UDP/IP) protocol port numbers. It must be running in order to make RPC calls (which is what the NIS/NIS+ client software does) to RPC servers (like a NIS or NIS+ server) on that machine. When an RPC server is started, it will tell portmap what port number it is listening to, and what RPC program numbers it is prepared to serve. When a client wishes to make an RPC call to a given program number, it will first contact portmap on the server machine to determine the port number where RPC packets should be sent.

Since RPC servers could be started by inetd(8), portmap should be running before inetd is started. For secure RPC, the portmapper needs the Time service. Make sure, that the Time service is enabled in /etc/inetd.conf on all hosts:

# time   stream  tcp     nowait  root    internal time   dgram   udp     wait    root    internal
 * 1) Time service is used for clock synchronization.

IMPORTANT: Don't forget to restart inetd after changes on its configuration file !

What do you need to set up NIS?

Determine whether you are a Server, Slave or Client : Your machine is going to be part of a network with existing NIS servers You do not have any NIS servers in the network yet

In the first case, you only need the client programs (ypbind, ypwhich, ypcat, yppoll, ypmatch). The most important program is ypbind. This program must be running at all times, which means, it should always appear in the list of processes. It is a daemon process and needs to be started from the system's startup file (eg. /etc/init.d/nis, /sbin/init.d/ypclient, /etc/rc.d/init.d/ypbind, /etc/rc.local). As soon as ypbind is running your system has become a NIS client.

In the second case, if you don't have NIS servers, then you will also need a NIS server program (usually called ypserv). Section 9 describes how to set up a NIS server on your Linux machine using the "ypserv" daemon.

Setting Up the NIS Client
The ypbind daemon

Newer ypbind versions have a configuration file called /etc/yp.conf. You can hardcode a NIS server there - for more info see the manual page for ypbind(8). You also need this file for NYS. An example:

ypserver 10.10.0.1 ypserver 10.0.100.8 ypserver 10.3.1.1

If the system can resolve the hostnames without NIS, you may use the name, otherwise you have to use the IP address. ypbind 3.3 has a bug and will only use the last entry (ypserver 10.3.1.1 in the example). All other entries are ignored. ypbind-mt handle this correct and uses that one, which answered at first.

It might be a good idea to test ypbind before incorporating it in the startup files. To test ypbind do the following:

Make sure you have your YP-domain name set. If it is not set then issue the command: /bin/domainname nis.domain

where nis.domain should be some string _NOT_ normally associated with the DNS-domain name of your machine! The reason for this is that it makes it a little harder for external crackers to retrieve the password database from your NIS servers. If you don't know what the NIS domain name is on your network, ask your system/network administrator.

Start up "/usr/sbin/portmap" if it is not already running. Create the directory "/var/yp" if it does not exist. Start up "/usr/sbin/ypbind"

Use the command "rpcinfo -p localhost" to check if ypbind was able to register its service with the portmapper. The output should look like:

program vers proto  port 100000   2   tcp    111  portmapper 100000   2   udp    111  portmapper 100007   2   udp    637  ypbind 100007   2   tcp    639  ypbind

Or like this (depending on the version of ypbind you are using) :

program vers proto  port 100000   2   tcp    111  portmapper 100000   2   udp    111  portmapper 100007   2   udp    758  ypbind 100007   1   udp    758  ypbind 100007   2   tcp    761  ypbind 100007   1   tcp    761  ypbind

You may also run "rpcinfo -u localhost ypbind". This command should produce something like:

program 100007 version 1 ready and waiting program 100007 version 2 ready and waiting

The output depends on the ypbind version you have installed. Important is only the "version 2" message. At this point you should be able to use NIS client programs like ypcat, etc... For example, "ypcat passwd.byname" will give you the entire NIS password database.

IMPORTANT: If you skipped the test procedure then make sure you have set the domain name, and created the directory /var/yp. This directory MUST exist for ypbind to start up successfully. To check if the domainname is set correct, use the /bin/ypdomainname from yp-tools 2.2. It uses the yp_get_default_domain function which is more restrict. It doesn't allow for example the "(none)" domainname, which is the default under Linux and makes a lot of problems.

If the test worked you may now want to change your startupd files so that ypbind will be started at boot time and your system will act as a NIS client. Make sure that the domainname will be set before you start ypbind. Well, that's it. Reboot the machine and watch the boot messages to see if ypbind is actually started. For host lookups you must set (or add) "nis" to the lookup order line in your /etc/host.conf file. Please read the manpage "resolv+.8" for more details. Add the following line to /etc/passwd on your NIS clients:

+::::::

You can also use the + and - characters to include/exclude or change users. If you want to exclude the user guest just add -guest to your /etc/passwd file. You want to use a different shell (e.g. ksh) for the user "linux"? No problem, just add "+linux::::::/bin/ksh" (without the quotes) to your /etc/passwd. Fields that you don't want to change have to be left empty. You could also use Netgroups for user control.

For example, to allow login-access only to miquels, dth and ed, and all members of the sysadmin netgroup, but to have the account data of all other users available use:

+miquels::::::: +ed::::::: +dth::::::: +@sysadmins::::::: -ftp +:*::::::/etc/NoShell

Note that in Linux you can also override the password field, as we did in this example. We also remove the login "ftp", so it isn't known any longer, and anonymous ftp will not work. The netgroup would look like :

sysadmins (-,software,) (-,kukuk,)

The nsswitch.conf File
The Network Services switch file /etc/nsswitch.conf determines the order of lookups performed when a certain piece of information is requested, just like the /etc/host.conf file which determines the way host lookups are performed. For example, the line :

hosts: files nis dns

specifies that host lookup functions should first look in the local /etc/hosts file, followed by a NIS lookup and finally through the domain name service (/etc/resolv.conf and named), at which point if no match is found an error is returned. This file must be readable for every user! You can find more information in the man-page nsswitch.5 or nsswitch.conf.5.

A good /etc/nsswitch.conf file for NIS is:

passwd:    compat group:     compat
 * 1) /etc/nsswitch.conf

shadow:    compat passwd_compat: nis group_compat: nis shadow_compat: nis hosts:     nis files dns services:  nis [NOTFOUND=return] files networks:  nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc:       nis [NOTFOUND=return] files ethers:    nis [NOTFOUND=return] files netmasks:  nis [NOTFOUND=return] files netgroup:  nis bootparams: nis [NOTFOUND=return] files publickey: nis [NOTFOUND=return] files automount: files aliases:   nis [NOTFOUND=return] files
 * 1) For libc5, you must use shadow: files nis

Setting up a NIS Server
The Server Program ypserv

If you run your server as master, determine what files you require to be available via NIS and then add or remove the appropriate entries to the "all" rule in /var/yp/Makefile. You always should look at the Makefile and edit the Options at the beginning of the file.

There was one big change between ypserv 1.1 and ypserv 1.2. Since version 1.2, the file handles are cached. This means you have to call makedbm always with the -c option if you create new maps. Make sure, you are using the new /var/yp/Makefile from ypserv 1.2 or later, or add the -c flag to makedbm in the Makefile. If you don't do that, ypserv will continue to use the old maps, and not the updated one.

Now edit /var/yp/securenets and /etc/ypserv.conf. For more information, read the ypserv(8) and ypserv.conf(5) manual pages.

Make sure the portmapper (portmap(8)) is running, and start the server ypserv. The command « rpcinfo -u localhost ypserv » should output something like :

program 100004 version 1 ready and waiting program 100004 version 2 ready and waiting

The "version 1" line could be missing, depending on the ypserv version and configuration you are using. It is only necessary if you have old SunOS 4.x clients.

Now generate the NIS (YP) database. On the master, run :

% /usr/lib/yp/ypinit -m

On a slave make sure that ypwhich -m works. This means, that your slave must be configured as NIS client before you could run « /usr/lib/yp/ypinit -s masterhost » to install the host as NIS slave. That's it, your server is up and running.

If you have bigger problems, you could start ypserv and ypbind in debug mode on different xterms. The debug output should show you what goes wrong.

If you need to update a map, run make in the /var/yp directory on the NIS master. This will update a map if the source file is newer, and push the files to the slave servers. Please don't use ypinit for updating a map. You might want to edit root's crontab *on the slave* server and add the following lines:

20 *   * * *    /usr/lib/yp/ypxfr_1perhour 40 6   * * *    /usr/lib/yp/ypxfr_1perday 55 6,18 * * *   /usr/lib/yp/ypxfr_2perday

This will ensure that most NIS maps are kept up-to-date, even if an update is missed because the slave was down at the time the update was done on the master.

You can add a slave at every time later. At first, make sure that the new slave server has permissions to contact the NIS master. Then run :

% /usr/lib/yp/ypinit -s masterhost

on the new slave. On the master server, add the new slave server name to /var/yp/ypservers and run make in /var/yp to update the map.

The Program rpc.ypxfrd
rpc.ypxfrd is used for speed up the transfer of very large NIS maps from a NIS master to NIS slave servers. If a NIS slave server receives a message that there is a new map, it will start ypxfr for transfering the new map. ypxfr will read the contents of a map from the master server using the yp_all function. This process can take several minutes when there are very large maps which have to store by the database library.

The rpc.ypxfrd server speeds up the transfer process by allowing NIS slave servers to simply copy the master server's map files rather than building their own from scratch. rpc.ypxfrd uses an RPC-based file transfer protocol, so that there is no need for building a new map.

rpc.ypxfrd can be started by inetd. But since it starts very slow, it should be started with ypserv. You need to start rpc.ypxfrd only on the NIS master server.

The Program rpc.yppasswdd
Whenever users change their passwords, the NIS password database and probably other NIS databases, which depend on the NIS password database, should be updated. The program "rpc.yppasswdd" is a server that handles password changes and makes sure that the NIS information will be updated accordingly. rpc.yppasswdd is now integrated in ypserv. You don't need the older, separate yppasswd-0.9.tar.gz or yppasswd-0.10.tar.gz, and you shouldn't use them any longer. The rpc.yppasswdd in ypserv 1.3.2 has full shadow support. yppasswd is now part of yp-tools-2.2.tar.gz.

You need to start rpc.yppasswdd only on the NIS master server. By default, users are not allowed to change their full name or the login shell. You can allow this with the -e chfn or -e chsh option. If your passwd and shadow files are not in another directory then /etc, you need to add the -D option. For example, if you have put all source files in /etc/yp and wish to allow the user to change his shell, you need to start rpc.yppasswdd with the following parameters:

rpc.yppasswdd -D /etc/yp -e chsh or rpc.yppasswdd -s /etc/yp/shadow -p /etc/yp/passwd -e chsh

There is nothing more to do. You just need to make sure, that rpc.yppasswdd uses the same files as /var/yp/Makefile. Errors will be logged using syslog.

If everything is fine (as it should be), you should be able to verify your installation with a few simple commands. Assuming, for example, your passwd file is being supplied by NIS, the command :

% ypcat passwd

should give you the contents of your NIS passwd file. The command :

% ypmatch userid passwd

(where userid is the login name of an arbitrary user) should give you the user's entry in the NIS passwd file. The "ypcat" and "ypmatch" programs should be included with your distribution of traditional NIS or NYS. Once you have NIS correctly configured on the server and client, you do need to be sure that the configuration will survive a reboot. On RedHat, create or modify the variable NISDOMAIN in the file /etc/sysconfig/network.


text:
LPI Linux Certification/LDAP Configuration

Detailed Objectives (210.4)
(LPIC-2 Version 4.5)

Weight: 4

Description: Candidates should be able to configure a basic OpenLDAP server including knowledge of LDIF format and essential access controls.

Key Knowledge Areas:
 * OpenLDAP
 * Directory based configuration
 * Access Control
 * Distinguished Names
 * Changetype Operations
 * Schemas and Whitepages
 * Directories
 * Object IDs, Attributes and Classes

Terms and Utilities:
 * LDIF
 * loglevel
 * LDIF
 * loglevel
 * loglevel
 * loglevel
 * loglevel
 * loglevel


text:
LPI Linux Certification/PAM Authentication

Detailed Objectives (210.2)
(LPIC-2 Version 4.5)

Weight: 3

Description: The candidate should be able to configure PAM to support authentication using various available methods. This includes basic SSSD functionality.

Key Knowledge Areas:
 * PAM configuration files, terms and utilities.
 * passwd and shadow passwords.
 * Use sssd for LDAP authentication.

Terms and Utilities:

PAM authentication
test

PAM (Pluggable Authentication Modules) is a flexible mechanism for authenticating users.

Since the beginnings of UNIX, authenticating a user has been accomplished via the user entering a password and the system checking if the entered password corresponds to the encrypted official password that is stored in /etc/passwd. The idea being that the user *is* really that user if and only if they can correctly enter their secret password. That was in the beginning. Since then, a number of new ways of authenticating users have become popular. Including more complicated replacements for the /etc/passwd file, and hardware devices Smart cards etc.. The problem is that each time a new authentication scheme is developed, it requires all the necessary programs (login, ftpd etc...) to be rewritten to support it.

PAM provides a way to develop programs that are independent of authentication scheme. These programs need "authentication modules" to be attatched to them at run-time in order to work. Which authentication module is to be attatched is dependent upon the local system setup and is at the discretion of the local system administrator.

PAM authentication

Linux-PAM (Pluggable Authentication Modules for Linux) is a suite of shared libraries that enable the local system administrator to choose how applications authenticate users.

In other words, without (rewriting and) recompiling a PAM-aware application, it is possible to switch between the authentication mechanism(s) it uses. Indeed, one may entirely upgrade the local authentication system without touching the applications themselves.

Historically an application that has required a given user to be authenticated, has had to be compiled to use a specific authentication mechanism. For example, in the case of traditional UN*X systems, the identity of the user is verified by the user entering a correct password. This password, after being prefixed by a two character salt, is encrypted (with crypt(3)). The user is then authenticated if this encrypted password is identical to the second field of the user's entry in the system password database (the /etc/passwd file). On such systems, most if not all forms of privileges are granted based on this single authentication scheme. Privilege comes in the form of a personal user-identifier (uid) and membership of various groups. Services and applications are available based on the personal and group identity of the user. Traditionally, group membership has been assigned based on entries in the /etc/group file.

PAM authentication

Unfortunately, increases in the speed of computers and the widespread introduction of network based computing, have made once secure authentication mechanisms, such as this, vulnerable to attack. In the light of such realities, new methods of authentication are continuously being developed. It is the purpose of the Linux-PAM project to separate the development of privilege granting software from the development of secure and appropriate authentication schemes. This is accomplished by providing a library of functions that an application may use to request that a user be authenticated. This PAM library is configured locally with a system file, /etc/pam.conf (or a series of configuration files located in /etc/pam.d/) to authenticate a user request via the locally available authentication modules. The modules themselves will usually be located in the directory /lib/security and take the form of dynamically loadable object files (see dlopen(3)).

PAM authentication

Overview

For the uninitiated, we begin by considering an example. We take an application that grants some service to users; login is one such program. Login does two things, it first establishes that the requesting user is whom they claim to be and second provides them with the requested service: in the case of login the service is a command shell (bash, tcsh, zsh, etc.) running with the identity of the user.

Traditionally, the former step is achieved by the login application prompting the user for a password and then verifying that it agrees with that located on the system; hence verifying that as far as the system is concerned the user is who they claim to be. This is the task that is delegated to Linux-PAM. From the perspective of the application programmer (in this case the person that wrote the login application), Linux-PAM takes care of this authentication task -- verifying the identity of the user.

PAM authentication

The flexibility of Linux-PAM is that you, the system administrator, have the freedom to stipulate which authentication scheme is to be used. You have the freedom to set the scheme for any/all PAM-aware applications on your Linux system. That is, you can authenticate from anything as naive as simple trust (pam_permit) to something as paranoid as a combination of a retinal scan, a voice print and a one-time password!

To illustrate the flexibility you face, consider the following situation: a system administrator (parent) wishes to improve the mathematical ability of her users (children). She can configure their favorite Shoot 'em up game (PAM-aware of course) to authenticate them with a request for the product of a couple of random numbers less than 12. It is clear that if the game is any good they will soon learn their multiplication tables. As they mature, the authentication can be upgraded to include (long) division!

PAM authentication

Linux-PAM deals with four separate types of (management) task. These are: authentication management; account management; session management; and password management. The association of the preferred management scheme with the behavior of an application is made with entries in the relevant Linux-PAM configuration file. The management functions are performed by modules specified in the configuration file.

The Linux-PAM library consults the contents of the PAM configuration file and loads the modules that are appropriate for an application. These modules fall into one of four management groups and are stacked in the order they appear in the configuration file. These modules, when called by Linux-PAM, perform the various authentication tasks for the application. Textual information, required from/or offered to the user, can be exchanged through the use of the application-supplied conversation function.

PAM authentication

Linux-PAM is designed to provide the system administrator with a great deal of flexibility in configuring the privilege granting applications of their system. The local configuration of those aspects of system security controlled by Linux-PAM is contained in one of two places: either the single system file, /etc/pam.conf; or the /etc/pam.d/ directory.

Linux-PAM specific tokens in this file are case insensitive. The module paths, however, are case sensitive since they indicate a file's name and reflect the case dependence of typical Linux file-systems. The case-sensitivity of the arguments to any given module is defined for each module in turn. In addition to the lines described below, there are two special characters provided for the convenience of the system administrator: comments are preceded by a `#' and extend to the next end-of-line; also, module specification lines may be extended with a `\' escaped newline.

A general configuration line of the /etc/pam.conf file has the following form: : service-name module-type  control-flag  module-path  args

PAM authentication

Below, we explain the meaning of each of these tokens. The second (and more recently adopted) way of configuring Linux-PAM is via the contents of the /etc/pam.d/ directory. Once we have explained the meaning of the above tokens, we will describe this method.

Service-name

The name of the service associated with this entry. Frequently the service name is the conventional name of the given application. For example, `ftpd', `rlogind' and `su', etc.. There is a special service-name, reserved for defining a default authentication mechanism. It has the name `OTHER' and may be specified in either lower or upper case characters. Note, when there is a module specified for a named service, the `OTHER' entries are ignored.

PAM authentication Module-type One of (currently) four types of module. The four types are as follows:

auth; this module type provides two aspects of authenticating the user. Firstly, it establishes that the user is who they claim to be, by instructing the application to prompt the user for a password or other means of identification. Secondly, the module can grant group membership (independently of the /etc/groups file discussed above) or other privileges through its credential granting properties.

account; this module performs non-authentication based account management. It is typically used to restrict/permit access to a service based on the time of day, currently available system resources (maximum number of users) or perhaps the location of the applicant user---`root' login only on the console.

session; primarily, this module is associated with doing things that need to be done for the user before/after they can be given service. Such things include the logging of information concerning the opening/closing of some data exchange with a user, mounting directories, etc..

password; this last module type is required for updating the authentication token associated with the user. Typically, there is one module for each `challenge/response' based authentication (auth) module-type. PAM authentication

Control-flag

The control-flag is used to indicate how the PAM library will react to the success or failure of the module it is associated with. Since modules can be stacked (modules of the same type execute in series, one after another), the control-flags determine the relative importance of each module. The application is not made aware of the individual success or failure of modules listed in the `/etc/pam.conf' file. Instead, it receives a summary success or fail response from the Linux-PAM library. The order of execution of these modules is that of the entries in the /etc/pam.conf file; earlier entries are executed before later ones. As of Linux-PAM v0.60, this control-flag can be defined with one of two syntaxes.

The simpler (and historical) syntax for the control-flag is a single keyword defined to indicate the severity of concern associated with the success or failure of a specific module. There are four such keywords: required, requisite, sufficient and optional.

PAM authentication

Control-flag

The Linux-PAM library interprets these keywords in the following manner: required; this indicates that the success of the module is required for the module-type facility to succeed. Failure of this module will not be apparent to the user until all of the remaining modules (of the same module-type) have been executed.

requisite; like required, however, in the case that such a module returns a failure, control is directly returned to the application. The return value is that associated with the first required or requisite module to fail. Note, this flag can be used to protect against the possibility of a user getting the opportunity to enter a password over an unsafe medium. It is conceivable that such behavior might inform an attacker of valid accounts on a system. This possibility should be weighed against the not insignificant concerns of exposing a sensitive password in a hostile environment.

sufficient; the success of this module is deemed `sufficient' to satisfy the Linux-PAM library that this module-type has succeeded in its purpose. In the event that no previous required module has failed, no more `stacked' modules of this type are invoked. (Note, in this case subsequent required modules are not invoked.). A failure of this module is not deemed as fatal to satisfying the application that this module-type has succeeded.

Optional; as its name suggests, this control-flag marks the module as not being critical to the success or failure of the user's application for service. In general, Linux-PAM ignores such a module when determining if the module stack will succeed or fail. However, in the absence of any definite successes or failures of previous or subsequent stacked modules this module will determine the nature of the response to the application. One example of this latter case, is when the other modules return something like PAM_IGNORE. PAM authentication

Control-flag :

The more elaborate (newer) syntax is much more specific and gives the administrator a great deal of control over how the user is authenticated. This form of the control flag is delimited with square brackets and consists of a series of value=action tokens: [value1=action1 value2=action2 ...] Here, valueI is one of the following return values: success; open_err; symbol_err; service_err; system_err; buf_err; perm_denied; auth_err; cred_insufficient; authinfo_unavail; user_unknown; maxtries; new_authtok_reqd; acct_expired; session_err; cred_unavail; cred_expired; cred_err; no_module_data; conv_err; authtok_err; authtok_recover_err; authtok_lock_busy; authtok_disable_aging; try_again; ignore; abort; authtok_expired; module_unknown; bad_item; and default. The last of these (default) can be used to set the action for those return values that are not explicitly defined.

The actionI can be a positive integer or one of the following tokens: ignore; ok; done; bad; die; and reset. A positive integer, J, when specified as the action, can be used to indicate that the next J modules of the current module-type will be skipped. In this way, the administrator can develop a moderately sophisticated stack of modules with a number of different paths of execution. Which path is taken can be determined by the reactions of individual modules.

PAM authentication

ignore - when used with a stack of modules, the module's return status will not contribute to the return code the application obtains.

bad - this action indicates that the return code should be thought of as indicative of the module failing. If this module is the first in the stack to fail, its status value will be used for that of the whole stack.

die - equivalent to bad with the side effect of terminating the module stack and PAM immediately returning to the application.

ok - this tells PAM that the administrator thinks this return code should contribute directly to the return code of the full stack of modules. In other words, if the former state of the stack would lead to a return of PAM_SUCCESS, the module's return code will override this value. Note, if the former state of the stack holds some value that is indicative of a modules failure, this 'ok' value will not be used to override that value.

done - equivalent to ok with the side effect of terminating the module stack and PAM immediately returning to the application.

reset - clear all memory of the state of the module stack and start again with the next stacked module. PAM authentication Each of the four keywords: required; requisite; sufficient; and optional, have an equivalent expression in terms of the [...] syntax. They are as follows:

required is equivalent to [success=ok new_authtok_reqd=ok ignore=ignore default=bad]

requisite is equivalent to [success=ok new_authtok_reqd=ok ignore=ignore default=die]

sufficient is equivalent to [success=done new_authtok_reqd=done default=ignore]

optional is equivalent to [success=ok new_authtok_reqd=ok default=ignore]

Just to get a feel for the power of this new syntax, here is a taste of what you can do with it. With Linux-PAM-0.63, the notion of client plug-in agents was introduced. This is something that makes it possible for PAM to support machine-machine authentication using the transport protocol inherent to the client/server application. With the [ ... value=action ... ] control syntax, it is possible for an application to be configured to support binary prompts with compliant clients, but to gracefully fall over into an alternative authentication mode for older, legacy, applications.

PAM authentication

Module-path

The path-name of the dynamically loadable object file; the pluggable module itself. If the first character of the module path is `/', it is assumed to be a complete path. If this is not the case, the given module path is appended to the default module path: /lib/security

Args

The args are a list of tokens that are passed to the module when it is invoked. Much like arguments to a typical Linux shell command. Generally, valid arguments are optional and are specific to any given module. Invalid arguments are ignored by a module, however, when encountering an invalid argument, the module is required to write an error to syslog(3). For a list of generic options see the next section.

Any line in (one of) the configuration file(s), that is not formatted correctly, will generally tend (erring on the side of caution) to make the authentication process fail. A corresponding error is written to the system log files with a call to syslog(3).

PAM authentication

Directory based configuration

More flexible than the single configuration file, as of version 0.56, it is possible to configure libpam via the contents of the /etc/pam.d/ directory. In this case the directory is filled with files each of which has a filename equal to a service-name (in lower-case): it is the personal configuration file for the named service.

Linux-PAM can be compiled in one of two modes. The preferred mode uses either /etc/pam.d/ or /etc/pam.conf configuration but not both. That is to say, if there is a /etc/pam.d/ directory then libpam only uses the files contained in this directory. However, in the absence of the /etc/pam.d/ directory the /etc/pam.conf file is used (this is likely to be the mode your preferred distribution uses). The other mode is to use both /etc/pam.d/ and /etc/pam.conf in sequence. In this mode, entries in /etc/pam.d/ override those of /etc/pam.conf. The syntax of each file in /etc/pam.d/ is similar to that of the /etc/pam.conf file and is made up of lines of the following form:

module-type control-flag  module-path  arguments The only difference being that the service-name is not present. The service-name is of course the name of the given configuration file. For example, /etc/pam.d/login contains the configuration for the login service.

PAM authentication

This method of configuration has a number of advantages over the single file approach. We list them here to assist the reader in deciding which scheme to adopt:

A lower chance of misconfiguring an application. There is one less field to mis-type when editing the configuration files by hand.

Easier to maintain. One application may be reconfigured without risk of interfering with other applications on the system.

It is possible to symbolically link different services configuration files to a single file. This makes it easier to keep the system policy for access consistent across different applications. (It should be noted, to conserve space, it is equally possible to hard link a number of configuration files. However, care should be taken when administering this arrangement as editing a hard linked file is likely to break the link.)

A potential for quicker configuration file parsing. Only the relevant entries are parsed when a service gets bound to its modules. It is possible to limit read access to individual Linux-PAM configuration files using the file protections of the filesystem.

Package management becomes simpler. Every time a new application is installed, it can be accompanied by an /etc/pam.d/xxxxxx file.

PAM authentication

The following are optional arguments which are likely to be understood by any module. Arguments (including these) are in general optional.

Debug : Use the syslog(3) call to log debugging information to the system log files. no_warn : Instruct module to not give warning messages to the application. use_first_pass : The module should not prompt the user for a password. Instead, it should obtain the previously typed password (from the preceding auth module), and use that. If that doesn't work, then the user will not be authenticated. (This option is intended for auth and password modules only). try_first_pass : The module should attempt authentication with the previously typed password (from the preceding auth module). If that doesn't work, then the user is prompted for a password. (This option is intended for auth modules only). use_mapped_pass : This argument is not currently supported by any of the modules in the Linux-PAM distribution because of possible consequences associated with U.S. encryption exporting restrictions. Within the U.S., module developers are, of course, free to implement it (as are developers in other countries). expose_account : In general the leakage of some information about user accounts is not a secure policy for modules to adopt. Sometimes information such as users names or home directories, or preferred shell, can be used to attack a user's account. In some circumstances, however, this sort of information is not deemed a threat: displaying a user's full name when asking them for a password in a secured environment could also be called being 'friendly'. The expose_account argument is a standard module argument to encourage a module to be less discrete about account information as it is deemed appropriate by the local administrator.

PAM authentication

Example configuration file entries

Default policy : If a system is to be considered secure, it had better have a reasonably secure `OTHER' entry. The following is a paranoid setting (which is not a bad place to start!): OTHER auth   required    pam_deny.so OTHER  account required    pam_deny.so OTHER  password required    pam_deny.so OTHER  session required    pam_deny.so
 * 1) default; deny access
 * 1) default; deny access

Whilst fundamentally a secure default, this is not very sympathetic to a misconfigured system. For example, such a system is vulnerable to locking everyone out should the rest of the file become badly written. The module pam_deny is not very sophisticated. For example, it logs no information when it is invoked so unless the users of a system contact the administrator when failing to execute a service application, the administrator may go for a long while in ignorance of the fact that his system is misconfigured.

PAM authentication

The addition of the following line before those in the above example would provide a suitable warning to the administrator. OTHER auth   required    pam_warn.so OTHER  password required    pam_warn.so
 * 1) default; wake up! This application is not configured
 * 1) default; wake up! This application is not configured

Having two OTHER auth lines is an example of stacking. On a system that uses the /etc/pam.d/ configuration, the corresponding default setup would be achieved with the following file: auth  required    pam_warn.so auth   required    pam_deny.so account required    pam_deny.so password required    pam_warn.so password required    pam_deny.so session required    pam_deny.so
 * 1) default configuration: /etc/pam.d/other
 * 1) default configuration: /etc/pam.d/other

PAM authentication

On a less sensitive computer, one on which the system administrator wishes to remain ignorant of much of the power of Linux-PAM, the following selection of lines (in /etc/pam.conf) is likely to mimic the historically familiar Linux setup.

OTHER auth   required    pam_unix.so OTHER  account required    pam_unix.so OTHER  password required    pam_unix.so OTHER  session required    pam_unix.so
 * 1) default; standard UN*X access
 * 1) default; standard UN*X access

PAM authentication Key terms, files and utilities : /etc/pam.d /etc/pam.conf /lib/libpam.so.*


text:
Java Persistence/Transactions

=Transactions=

A transaction is a set of operations that either fail or succeed as a unit. Transactions are a fundamental part of persistence. A database transaction consists of a set of SQL DML (Data Manipulation Language) operations that are committed or rolled back as a single unit. An object level transaction is one in which a set of changes made to a set of objects are committed to the database as a single unit.

JPA provides two mechanisms for transactions. When used in Java EE JPA provides integration with JTA (Java Transaction API). JPA also provides its own  implementation to Java SE and for use in a non-managed mode in Java EE. Transactions in JPA are always at the object level, this means that all changes made to all persistent objects in the persistence context are part of the transaction.

Resource Local Transactions
Resource local transactions are used in JSE, or in application managed (non-managed) mode in Java EE. To use resource local transactions the  attribute in the   is set to. If resource local transactions are used with a, the   element should be used to reference a server   that has been configured to not be JTA managed.

Local JPA transactions are defined through the class. It contains basic transaction API including,   and.

Technically in JPA the  is in a transaction from the point it is created. So  is somewhat redundant. Until  is called, certain operations such as ,  ,   cannot be called. Queries can still be performed, and objects that were queried can be changed, although this is somewhat unspecified what will happen to these changes in the JPA spec, normally they will be committed, however it is best to call  before making any changes to your objects. Normally it is best to create a new  for each transaction to avoid have stale objects remaining in the persistence context, and to allow previously managed objects to garbage collect.

After a successful  the   can continue to be used, and all of the managed objects remain managed. However it is normally best to  or   the   to allow garbage collection and avoid stale data. If the commit fails, then the managed objects are considered detached, and the  is cleared. This means that commit failures cannot be caught and retried, if a failure occurs, the entire transaction must be performed again. The previously managed object may also be left in an inconsistent state, meaning some of the objects locking version may have been incremented. Commit will also fail if the transaction has been marked for rollback. This can occur either explicitly by calling  or is required to be set if any query or find operation fails. This can be an issue, as some queries may fail, but may not be desired to cause the entire transaction to be rolled back.

The  operation will rollback the database transaction only. The managed objects in the persistence context will become detached and the  is cleared. This means any object previously read, should no longer be used, and is no longer part of the persistence context. The changes made to the objects will be left as is, the object changes will not be reverted.

JTA Transactions
JTA transactions are used in Java EE, in managed mode (EJB). To use JTA transactions the  attribute in the   is set to. If JTA transactions are used with a, the   element should be used to reference a server   that has been configure to be JTA managed.

JTA transactions are defined through the JTA class, or more likely implicitly defined through   usage/methods. In a  each   method defaults to a     and hence its invocation starts a JTA transaction, if no JTA transaction is in progress. If a method is the first called that requires a transaction, it will commit the changes upon completion.

JTA transaction can be shared among  methods, hence if a method is called through it's business interface from another method that already started a transaction, the second method will work inside the existing transaction. Moreover the second method can only change the state of the  by persisting objects or doing other operations, and when it returns control to the calling method it delegates to it the execution of the actual. To perform DB operations in a transaction isolated from any transaction in progress a  method can be annotated as. The s that can be associate to   methods are:

can be obtained through a JNDI lookup in most application servers, or from the  in EJB 2.0 style  s.

JTA transactions can be used in two modes in Java EE. In Java EE managed mode, such as an  injected into a , the   reference, represents a new persistence context for each transaction. This means objects read in one transaction become detached after the end of the transaction, and should no longer be used, or need to be merged into the next transaction. In managed mode, you never create or close an.

The second mode allows the  to be application managed, (normally obtained from an injected , or directly from JPA  ). This allows the persistence context to survive transaction boundaries, and follow the normal  life-cycle similar to resource local. If the  is created in the context of an active JTA transaction, it will automatically be part of the JTA transaction and commit/rollback with the JTA transaction. Otherwise it must join a JTA transaction to commit/rollback using

Example JTA transaction
=Advanced=

Join Transaction
The API allows an application managed   to join the active JTA transaction context. This allows an  to be created outside the JTA transaction scope and commit its changes as part of the current transaction. This is normally used with a, or with a JSP or Servlet where an   is used in a stateful architecture. A stateful architecture is one where the server stores information on a client connection until the client's session is over, it differs from a stateless architecture where nothing is stored on the server in between client requests (each request is processed on its own).

There are pros and cons with both stateful and stateless architectures. One of the advantages with using a stateful architecture and an, is that you do not have to worry about merging objects. You can read your objects in one request, let the client modify them, and then commit them as part of a new transaction. This is where  would be used. One issue with this is that you normally want to create the  when there is no active JTA transaction, otherwise it will commit as part of that transaction. However, even if it does commit, you can still continue to use it and join a future transaction. You do have to avoid using transactional API such as  or   until you are ready to commit the transaction.

is only used with JTA managed s (JTA transaction-type in persistence.xml). For   s you can just commit the JPA transaction whenever you desire.

Retrying Transactions, Handling Commit Failures
Sometimes it is desirable to handle persistence errors, and recover and retry transactions. This normally requires a lot of application knowledge to know what failed, what state the system is in, and how to fix it.

Unfortunately JPA does not provide a direct way of handling commit failures or error handling. When a transaction commit fails, the transaction is automatically rolled back, and the persistence context cleared, and all managed objects detached. Not only is there no way to handle a commit failure, but if any error occurs in an query before the commit, the transaction will be marked for rollback, so there is no real way to handle any error. This is because any query could potentially change the state of the database, so JPA does not know if the database is in an invalid or inconsistent state so must rollback the transaction. As well if the commit fails, the state of the objects registered in the persistence context may also be inconsistent (such as partially committed objects having their optimistic lock versions incremented), so the persistence context is cleared to avoid further errors.

Some JPA providers may provide extended API to allow handling commit failures, or handling errors on queries.

There are some methods to generically handle commit failures and other errors. Error handling in general is normally easier when using  transactions, and not when using JTA transactions.

One method of error handling is to call  for each managed object after the commit fails into a new , then try to commit the new. One issue may be that any ids that were assigned, or optimistic lock versions that were assigned or incremented may need to be reset. Also, if the original  was , any objects that were in use would still become detached, and need to be reset.

Another more involved method to error handling is to always work with a non-transactional. When it's time to commit, a new  is created, the non-transactional objects are merged into it, and the new   is committed. If the commit fails, only the state of the new  may be inconsistent, the original   will be unaffected. This can allow the problem to be corrected, and the  re-merged into another new. If the commit is successful any commit changes can be merged back into the original, which can then continue to be used as normal. This solution requires a fair bit of overhead, so should only be used if error handling is really required, and the JPA provider provides no alternatives.

Nested Transactions
JPA and JTA do not support nested transactions.

A nested transaction is used to provide a transactional guarantee for a subset of operations performed within the scope of a larger transaction. Doing this allows you to commit and abort the subset of operations independently of the larger transaction.

The rules to the usage of a nested transaction are as follows:

While the nested (child) transaction is active, the parent transaction may not perform any operations other than to commit or abort, or to create more child transactions.

Committing a nested transaction has no effect on the state of the parent transaction. The parent transaction is still uncommitted. However, the parent transaction can now see any modifications made by the child transaction. Those modifications, of course, are still hidden to all other transactions until the parent also commits.

Likewise, aborting the nested transaction has no effect on the state of the parent transaction. The only result of the abort is that neither the parent nor any other transactions will see any of the database modifications performed under the protection of the nested transaction.

If the parent transaction commits or aborts while it has active children, the child transactions are resolved in the same way as the parent. That is, if the parent aborts, then the child transactions abort as well. If the parent commits, then whatever modifications have been performed by the child transactions are also committed.

The locks held by a nested transaction are not released when that transaction commits. Rather, they are now held by the parent transaction until such a time as that parent commits.

Any database modifications performed by the nested transaction are not visible outside of the larger encompassing transaction until such a time as that parent transaction is committed.

The depth of the nesting that you can achieve with nested transaction is limited only by memory.

Transaction Isolation
/Runtime

title: Java Persistence/Transactions


text:
Talk:Non-Programmer's Tutorial for Python 2.6/Induction

Redundant chapter?
I think all the points mentioned in this chapter are more thoroughly introduced later in the book. There may be one exception: Structuring code by indentation rather than bracketing (which I think is not "weird" but a matter of taste). I think this chapter is redundant and not necessary at this point and would leave it out completely. Siebengang 14:44, 25 September 2007 (UTC)

 * I agree. I have no objection to removing the introduction section.  Jrincayc 12:05, 26 September 2007 (UTC)


text:
LPI Linux Certification/Configuring A Router

Detailed Objectives (212.1)
(LPIC-2 Version 4.5)

Weight: 3

Description: Candidates should be able to configure a system to forward IP packet and perform network address translation (NAT, IP masquerading) and state its significance in protecting a network. This objective includes configuring port redirection, managing filter rules and averting attacks.

Key Knowledge Areas:
 * iptables and ip6tables configuration files, tools and utilities.
 * Tools, commands and utilities to manage routing tables.
 * Private address ranges (IPv4) and Unique Local Addresses as well as Link Local Addresses (IPv6)
 * Port redirection and IP forwarding.
 * List and write filtering and rules that accept or block IP packets based on source or destination protocol, port and address.
 * Save and reload filtering configurations.

Terms and Utilities:

Overview
Description: ''The candidate should be able to configure ipchains and iptables to perform IP masquerading, and state the significance of Network Address Translation and Private Network Addresses in protecting a network. This objective includes configuring port redirection, listing filtering rules, and writing rules that accept or block datagrams based upon source or destination protocol, port and address. Also included is saving and reloading filtering configurations, using settings in /proc/sys/net/ipv4 to respond to DOS attacks, using /proc/sys/net/ipv4/ip_forward to turn IP forwarding on and off, and usingtools such as PortSentry to block port scans and vulnerability probes.''

Key files, terms, and utilities include:

/proc/sys/net/ipv4 /etc/services ipchains iptables routed

Configuring a router
There are numerous steps you should take to configure a router connected to insecure networks like the Internet First of all, identify what services you need, and have a policy of blocking everything else ! This minimize your exposure to security breaches.

Common steps for routers are :

Log all dropped/rejected packets (and limit the rate at which you log, to avoid logfiles size explosion) Use NAT whenever you can – unroutable addresses are more difficult to hack Define a default policy for TCP/UDP block ports answers: drop/reject/reset ?

Dropping isn't really helpful, scanners nowadays detect it easily. Rejecting may still show that a firewall is blocking access, resetting acts as if nothing is listening (i.e the « normal » way)

Unless you know you need it, drop (and log + limit) all ICMP packets except the most useful : dest-unreachable, time-exceeded and echo-reply

Protect against known attacks, i.e : anti-spoofing of IP addresses, disable source_route packets, disable icmp_redirect, log « martians » IP addresses (i.e addresses which appear on an interface they don't belong to), disable syn_cookies, disable ECN (Explicit Congestion Notification), disable TCP timestamps, ICMP broadcasts and ICMP bogus errors