Chapter 9 Application-level services

Application-level services
The way in which services are handled by most operating systems is to use the socket abstraction. Sockets are used for data transmission using TCP / IP. They are objects needed to be created at both ends of the connection. A server has a listening socket which responds to client requests by opening a new temporary socket at a random port number. Information is exchanged and then any connection is terminated.

A distributed system is a collection of computers and / or independent processors (with its own control unit), connected (able to exchange information between them). Communication between network components (or a distributed system) is the set of rules, called generic protocols.

Examples of protocols:
FTP (The File transfer protocol) - Passwords are normally sent in clear text HTTP (Hypertext transfer protocol) - for the transmission of data on the World Wide Web S-HTTP (Superset of HTTP) - Encapsulations include encryption, signing and MAC-based authentication HTTPS (The secure World Wide Web protocol) - for exchanging hypertext and multimedia data. SSH (The secure shell) - A replacement for the remote shell (rsh) Unix protocol. LDAP (Lightweight Directory Access Protocol) - looking up data in simple databases. NTP ( The network time protocol) IMAP (Internet Mail Access Protocol) SMTP (The Simple Mail Transfer Protocol)

Proxies
Proxy is an intermediary for requests from clients seeking resources from other servers. Proxies are used for security and for caching. When a client connects to the proxy server, requesting some service, such as a file, web page, or other resource available from a different server, these client requests are collected by the proxy and copied into local storage so that the next time the request is made, the data can be served from local storage. This improves both speed and traffic load, in principle.

Installing a new service Requires the system configuration by editing the file <</etc/services>>. The format of entries is like this: service portnumber/protocol aliases

Summoning daemons Network services are run by daemons. A daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user. There are two ways to start network daemons: 1. At system boots, by adding an appropriate shell-command to one of the systems startup scripts. 2. On demand: only at network request arrivel when an inetd daemon is used to monitor requests for a new service.

Summoning daemons
System 5 init This program starts the system in one of a number of run-levels. Run-levels decide how many services will be started when the system boots. When entering a run-level, init looks in a directory called <</etc/rc?.d>> that contains a new file which conforms to inits simple rules(S-for starting services and K are for killing them) and executes scripts. Advantage-this system provides that software packages can be added and removed transparently just by adding or removing a file. BSD init It starts executing a shell script called /etc/rc but adding our own local modifications, we have to edit the file /etc/rc.local inetd configuration is a daemon which listens on the network for messages to several services simultaneously. To add a new service, we edit the file /etc/inetd.conf and then send the inetd process the HUP signal. To do this, we find the process id: ps aux | grep inetd and then we type: kill -HUP process-id.

Summoning daemons

Binding to sockets At daemon startup, it creates a listening socket with an address that is the server IP address and port number chosen for communication. As a rule it is only possible to bind a socket port to an address once so if we try to start another daemon, we will get the error message <<host: Couldnt bind to socket bind: Address already in use.>> TCP wrapper security Beacause inetd accepts connections from any host and passes them to services registered, attacks on the system can happen. To solve this problem we use TCP wrappers(useful just for IPv4 connections) that allows us to add Access Control Lists (ACLs) to network services. TCP is in 2 forms: tcpd daemon and a library libwrap.a.

Setting up the DNS nameservice

Domain Name System (DNS) is an important internet service that converts host names, such as host.domain.tld, into IP addresses, such as 192.0.2.10, and vice versa. Each domain for its host registration needs a master name server relies on source files on the server-host, and a slave name server (or slave) that does not use source file data, but downloads its data second-hand from a master server. In practice, master and slave servers are identical except the source of the data: master server knows that it should propagate changes to all slave servers and slave server accept updates.

Setting up the DNS nameservice

To set up a master name server we need to create: a directory in our local files where the DNS domain data can be installed; subdirectories master and slave; a file master/domain.tld. for converting names into addresses (contains data identifying the IP addresses of hosts in our domain; it defines possible aliases for those names); files master/rev.128.39.89, master/rev.128.39.73 for converting addresses into official hostnames; a file for the loopback pseudo-network master/127.0.0 (in order to avoid problems with the loopback address, to register the Unix loopback address correctly within the DNS) a cache file named.cache or named.root (contains the data for the cache file and the names of root name servers) a configuration file named.conf.

Java web and enterprise services

An example of java services used for web are Java Server Pages(JSP). This technology is an extension of both servlets and HTML. Through private tags can insert statements, expressions, Java code sequences. Tomcat is an open source software implementation of the Java Servlet and JavaServer Pages technologies. Catalina is Tomcat's servlet container. Catalina implements Sun Microsystems specifications for servlet and JSP. JBoss Application Server (or JBoss AS) is an opensource Java EE-based application server and an examples of Enterprise Java Beans (EJB) containers.

Setting up a WWW server

The World Wide Web (or W3) service is provided by the daemon httpd. This description is based on the freely available Apache daemon which is widely regarded as the best and most up-to-date. It can be obtained from http://www.apache.org. An httpd server can be used for two purposes: Extranet: For publishing information which is intended to be open to the world. The more people who see this information, the better. Intranet: For publishing private information for internal use within an organization.

Unless we are going to operate within a firewall configuration, there is probably no need to separate these two services. They can run on the same server, with access control restricting information on a need-to-know basis.

The WWW is an open service: it gives access to file information, usually without requiring a password. For that reason it has the potential to be a security hazard: not with respect to itself, or the information which one intends to publish, but to the well-being of the host on which it runs.
To start a WWW service we need some html-files containing information we wish to publish and a server-daemon. We then need to edit configuration files which tell the daemon where to find the web pages it will be publishing. The security of the whole system can depend on which files and directories outsiders have access to.

Choosing a server host Personal data are accessed from users home directories, usually under a subdirectory called www. It makes considerable sense for the WWW server to be on the host which has the physically mounted disks. Otherwise, the WWW server would first have to access the files via NFS and then transmit them back to the requester. This would lead to an unnecessary doubling of network traffic. Installation The server is compiled in the usual way by unpacking a .tar.gz file and by running configure then make. This has support for many bells and whistles which enhance its performance. For instance, one can run an embedded language called PHP from within HTML pages to create active web pages. The httpd daemon must then be configured with special PHP support.

Apache uses a GNU autoconf configure program to prepare the compilation. As always, we have to choose a prefix for the software installation. If none is specified, the directory /usr/local is the default. There is no particular reason for installing the binaries elsewhere, however Apache does generate a convenient startup/shutdown script which compiles in the location of the configuration files. On the principle of separating files which we maintain ourselves from files installed by other sources, we almost certainly do not want to keep the true configuration files there, but rather would like to keep them together with other site-dependent configuration files.

The access.conf file

This file determines what rights various users will have when trying to access data on the server. It also implicitly determines whether httpd will search for .htaccess files in directories. Such files can be used to override the settings in the access.conf file. The Directory structure works like an access control list, granting or denying access to directories (and implicitly all subdirectories). In a Directory structure, we express rules which determine how httpd evaluates access rights. The ordering allow followed by deny means that files are allowed unless explicitly denied. The line which follows has the form allow from all, meaning that the data in /home (users home directories) are open to every caller. The Options directive is quite important. Indexes means that a browser will be able to present a directory listing of .html files which can be accessed, if a user browses a directory which does not contain a standard index.html file.

E-mail configuration Configuration of E-mail is one of the most complex issues for the system administrator, because it involves both nagging policy decisions and technical acrobatics. In the past, there were many different kinds of network protocol and many different ways of connecting up to different hosts. This made it quite a complex issue to relay messages all over the world.

Today things are much simpler: most sites use the Internet protocols and some of the technical aspects of mail configuration can be simplified. Some operating systems provide a program which automatically helps set up E-mail for simple host configurations, but these are no substitute for a carefully considered E-mail system.

Models of mail receipt and delivery E-mail comprises two separate challenges: the delivery of messages and user access to a mailbox. E-mail can be delivered either locally (where the sending host is the same as the destination host) or across a network (where the destination host is different from the sending host). Non-local delivery uses the SMTP (actually ESMTP) mail protocol. As soon as a network is involved in E-mail transmission, there are many choices to be made. Some of the basic choices involve deciding a logistic topology for the E-mail service: should we consolidate mail services to one host, or should we deliver mail to every host independently. The consequences of the latter are that users will have different E-mail on every host they have an account on. Usually, users require and desire only one mailbox per institution. One way to avoid having different E-mail on every host is to share an mbox filesystem between all hosts, using NFS.

Consolidated and distributed mail solutions There are two main models for handling electronic mail at a domain. One is that every host receives mail independently. Since users normally have the same password and account on all of the hosts on a network, this is not usually appropriate. The second approach is to have a mail hub, or central mail processor. In this model, all incoming mail is diverted to the hub and all outgoing mail is sent via the hub. With this approach, we focus all our effort into optimizing E-mail configuration on the hub, and all other machines have a simple configuration which simply collects or forwards mail on to the hub.

Spam and junk mail Spam or junk mail is E-mail where a message is sent to a large number of recipients. Spam has become a major problem since it is very easy to send Email and very hard to pick out what is useful from what is useless. There are two approaches to the filtering of spam, both of which are needed together: Site rules for rejecting mail (ACLs) Private user-rules for rejecting mail. The reason why both of these are needed is that what one user wants to reject, another user might be glad to receive. Users prospecting for financial opportunities or collecting the latest artwork might live for the messages which most of us get annoyed with.

Policy decisions In order to protect our site from E-mail attacks, even ones made in innocence, we might want to restrict mail by other criteria too. For example, multimedia attachments can now allow users to send huge files by E-mail. This is a very inefficient way of sending large amounts of data and it causes problems for mailbox storage space. A possibility is to limit the size of mail messages handled by sendmail so that mail which is too large will be rejected with an error message. Again, this must be a policy decision like garbage collection of users files. It is never desirable to restrict the personal freedom of users, but it becomes a matter of survival. If one provides an opening, it will be exploited either through ignorance or malice.

OpenLDAP directory service OpenLDAP is the open source implementation of the Lightweight Directory Access Protocol server (DSA). Installation is straightforward: after unpacking the distribution from www.openldap.org. The configuration file slapd.conf determines the local name space as well as the identity and password protection of the database manager. There is much that can be configured here, related to security and schema extensions. To begin with, it is important to set a password for the database manager. This password has to be encrypted manually and pasted into the configuration file. Note that the password is checked when adding data to the database. Password credential errors are reported if either the password is incorrect, or the dc components in the suffix are incorrect. Everything in the specification has to be correct.

Mounting NFS disks The sharing of disks over the network is the province of NFS (Network File System). Unix disks on one host may be accessed across the network by other Unix hosts, or by PCs running PC-NFS. A disk attached physically to a host called a server is said to be mounted on a client host. In order to maintain a certain level of security, the server must give other hosts permission to mount disks. This is called exporting or sharing disks. Clients may mount any subdirectory of the exported directory onto any local directory by becoming root and either executing a shell command of the form ount server: remote-directory local-directory or by adding a line to the filesystem table file, usually called /etc/fstab.

Trouble-shooting NFS If you get a message telling you Permission denied when you try to mount a remote filesystem, you may like to check the following: Did you remember to add the name of the client to the export or dfstab file on the server? Some systems require a fully qualified hostname (i.e. hostname with domainname appended) in the export file. Try using this. Did you mis-spell the name of the client or the server? Are the correct network daemons running which support nfs? On older systems there should be at least four of these daemons running to handle multiple requests. Modern systems use a multithreaded version of the program, so that only one daemon is required.

Samba Samba is a free software solution to the problem of making Unix filesystems available to Windows operating systems. Windows NT uses a system of network file sharing based on their own SMB (Server message block) protocol. Samba is a Unix daemon-based service which makes Unix disks visible to Windows NT. Samba maps usernames, so to use Samba we need an account with the same name on the NT server and on the Unix server. It maps usernames textually, without much security. Once the Samba server is active, the disks are available for use with the net use command.

The printer service Printing services vary from single printers coupled to private workstations to huge consolidated spooling services serving large organizations. Host print services need to be told about available printers by registering the printers in a local database. The way in which we register printers thus depends on What kind of operating system we are using Whether we are running any special network printer software. In order to register a printer with a BSD-like printer service, we do the following: Think of a name for the printer. Decide whether it is going to be connected directly to a host or stand alone on the network. Register the printer with the printing system so that the daemons which provide the print service know how to talk to it.

CUPS/LPRng The Common Unix Print System (CUPS) has emerged in the last few years as the favored printing solution on many desktops. It reads information from traditional Unix format files. LPRng is a rival attempt that is configured quite simply in a manner very similar to (but not identical to) the old Berkeley printcap system.

Environment variable PRINTER

The BSD print command and some application programs read the environment variable PRINTER to determine which printer destination to send data to. The System V print command lp does not.