1325 lines
68 KiB
Plaintext
1325 lines
68 KiB
Plaintext
|
Designing Integrated High Quality Linux Applications
|
|||
|
|
|||
|
Avi Alkalay
|
|||
|
|
|||
|
|
|||
|
avi at br.ibm.com
|
|||
|
avi at unix.sh
|
|||
|
Senior IT and Software Architect :: Linux Market Developer
|
|||
|
IBM Linux Impact Team :: [http://ibm.com/linux] ibm.com/linux
|
|||
|
|
|||
|
Copyright <20> 2002 by Avi Alkalay
|
|||
|
|
|||
|
v2.1, 2002-08-24
|
|||
|
Revision History
|
|||
|
Revision 2.1 24 Aug 2002 Revised by: avi
|
|||
|
Rewrite of the /opt /usr/local section.Cosmetics on graphical user interface
|
|||
|
and plugins sections.Fixed screens and programlistings width.
|
|||
|
Revision 2.0 07 May 2002 Revised by: avi
|
|||
|
Final XML conversion. Files reorganization.
|
|||
|
Revision 1.9.9 20 Apr 2002 Revised by: avi
|
|||
|
Included other document locations.
|
|||
|
Revision 1.98 14 Apr 2002 Revised by: avi
|
|||
|
Title changed from "Creating" to "Designing".
|
|||
|
Revision 1.97 09 Apr 2002 Revised by: avi
|
|||
|
Converted to XML 4.1.2, and started to use real XSLT. Spell checked the
|
|||
|
english version.
|
|||
|
Revision 1.96 23 Mar 2002 Revised by: avi
|
|||
|
Better HTML style sheets.
|
|||
|
Revision 1.95 17 Mar 2002 Revised by: avi
|
|||
|
Last chapter: One Body, Many Souls. Created appendix. Still have to translate
|
|||
|
some words here and there.
|
|||
|
Revision 1.9 16 Mar 2002 Revised by: avi
|
|||
|
Added universal software table with FHS.
|
|||
|
Revision 1.7 16 Mar 2002 Revised by: avi
|
|||
|
Everything is now translated except some words.
|
|||
|
Revision 1.3 27 Feb 2002 Revised by: avi
|
|||
|
Translated and reviewed the most important section of the article: The /opt
|
|||
|
and /usr/local section.
|
|||
|
Revision 1.2 23 Feb 2002 Revised by: avi
|
|||
|
English translation at 65%. Doing some corrections to potuguese version also.
|
|||
|
Revision 1.1 17 Feb 2002 Revised by: avi
|
|||
|
Started english translation.
|
|||
|
Revision 1.0 16 Feb 2002 Revised by: avi
|
|||
|
First final version of proposed skeleton.
|
|||
|
Revision 0.9.6 16 Feb 2002 Revised by: avi
|
|||
|
Finished Plugin chapter.
|
|||
|
Revision 0.9.5 15 Feb 2002 Revised by: avi
|
|||
|
Finished chapter about boot and subsystems.
|
|||
|
Revision 0.9.4 14 Feb 2002 Revised by: avi
|
|||
|
Finished chapter describing the boot process.
|
|||
|
Revision 0.9.3 08 Feb 2002 Revised by: avi
|
|||
|
Text and style updates.
|
|||
|
Revision 0.9.2 07 Feb 2002 Revised by: avi
|
|||
|
Text updates.
|
|||
|
Revision 0.9 06 Feb 2002 Revised by: avi
|
|||
|
First translation to DocBook.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
Table of Contents
|
|||
|
1. Introduction
|
|||
|
2. User Friendly: Guaranteed Success
|
|||
|
2.1. Embrace the Install-and-Use Paradigm
|
|||
|
|
|||
|
|
|||
|
3. The Four Universal Parts of Any Software
|
|||
|
3.1. Practical Examples
|
|||
|
3.2. The Importance of Clear Separation Between Four Parts
|
|||
|
3.3. One Body, Many Souls
|
|||
|
|
|||
|
|
|||
|
4. Linux Directory Hierarchy: Oriented to the Software Parts
|
|||
|
4.1. FHS Summary
|
|||
|
4.2. Examples Using the FHS
|
|||
|
4.3. Developer, Do Not Install in /opt or /usr/local !
|
|||
|
|
|||
|
|
|||
|
5. Provide Architecture for Extensions and Plugins
|
|||
|
5.1. Abstracting About Plugins
|
|||
|
|
|||
|
|
|||
|
6. Allways Provide RPM Packages of Your Softwares
|
|||
|
6.1. Software Package Modularization
|
|||
|
|
|||
|
|
|||
|
7. Security: The Omnipresent Concept
|
|||
|
8. Graphical User Interface
|
|||
|
8.1. KDE, GNOME, Java or Motif?
|
|||
|
8.2. Web Interface: Access from Anywhere
|
|||
|
8.3. Wizards and Graphical Installers
|
|||
|
|
|||
|
|
|||
|
9. Starting Your Software Automatically on Boot
|
|||
|
9.1. From BIOS to Subsystems
|
|||
|
9.2. Runlevels
|
|||
|
9.3. The Subsystems
|
|||
|
9.4. Turning Your Software Into a Subsystem
|
|||
|
9.5. Packaging Your Boot Script
|
|||
|
|
|||
|
|
|||
|
A. Red Hat, About the Filesystem Structure
|
|||
|
B. About this Document
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
Linux is becoming more and more popular, and many Software vendors are
|
|||
|
porting their products from other platformas. This document (article) tries
|
|||
|
to clarify some issues and give tips on how to create Linux applications
|
|||
|
highly integrated to the Operating System, security and easy of use.
|
|||
|
|
|||
|
The examples run on [http://www.redhat.com/] Red Hat Linux, and should be
|
|||
|
compatible with other distributions based on Red Hat ([http://
|
|||
|
www.conectiva.com.br/] Conectiva, [http://www.turbolinux.com/] Turbolinux,
|
|||
|
[http://www.calderasys.com/] Caldera, [http://www.pld.org.pl/] PLD, [http://
|
|||
|
www.mandrakelinux.com/] Mandrake, etc).
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
2. User Friendly: Guaranteed Success
|
|||
|
|
|||
|
The user-friendly concept is missassociated with a good GUI (graphical user
|
|||
|
interface). In fact, it is much more than that. In systems like Linux (with
|
|||
|
more server-like characteristics), the user measures how easy a Software is,
|
|||
|
mainly in the installation and initial configuration. He can even forget how
|
|||
|
easy were to install and use a certain product, but it will never forget that
|
|||
|
a Software package has a complex configuration and installation process. A
|
|||
|
migration or new installation allways will be a nightmare, making the user
|
|||
|
avoid it.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
2.1. Embrace the Install-and-Use Paradigm
|
|||
|
|
|||
|
Imagine you'll install that expansive product your company bought from ACME,
|
|||
|
and realized you'll have to do the following:
|
|||
|
|
|||
|
1. To have a manual that shows the installation process step-by-step. We
|
|||
|
know that a manual is the last thing the user reads
|
|||
|
|
|||
|
2. Read some README files
|
|||
|
|
|||
|
3. Uncompress huge files in your disk (after downloading them from net our
|
|||
|
CD), to create the installation environment
|
|||
|
|
|||
|
4. Read more README files that appeared in the installation environment
|
|||
|
|
|||
|
5. Comprehend that the installation requires you to execute in a special way
|
|||
|
some provided script (the inconvenient ./install.sh)
|
|||
|
|
|||
|
6. Uncomfortably answer some questions that the script does, like target
|
|||
|
directory, user for the installation, etc. To make it worse, it
|
|||
|
frequently happens in a terminal that has a missconfigured backspace
|
|||
|
|
|||
|
7. After the installation, configure some environment variables in your
|
|||
|
profile, like $PATH, $LIBPATH, $ACMEPROGRAM_DATA_DIR,
|
|||
|
$ACMEPROGRAM_BIN_DIR, etc
|
|||
|
|
|||
|
8. Edit OS files to include the presence of the new product (e.g. /etc/
|
|||
|
inetd.conf, /etc/inittab)
|
|||
|
|
|||
|
9. And the worse: Change security permissions of OS directories and files to
|
|||
|
let the product run OK
|
|||
|
|
|||
|
|
|||
|
Sounds familiar? Who never faced this sad situation, that inducts the user to
|
|||
|
make mistakes? If your products' installation process sound like
|
|||
|
Uncompress-Copy-Configure-ConfigureMore-Use, like this one, you have a
|
|||
|
problem, and the user won't like it.
|
|||
|
|
|||
|
Users like to feel that your Product integrates well with the OS. You should
|
|||
|
not demand that the OS adapt himself to your Product (changing environment
|
|||
|
variables, etc). It must let the user Install-and-Use.
|
|||
|
|
|||
|
The Install-And-Use glory is easily achieved using a 3 ingredients receipt:
|
|||
|
|
|||
|
1. Understanding the Four Universal Parts of Any Software
|
|||
|
|
|||
|
2. Understanding how they are related to Linux's directory hierarchy
|
|||
|
|
|||
|
3. Aggressively use a package system, for process automation and leverage
|
|||
|
first items. In our case is RPM.
|
|||
|
|
|||
|
|
|||
|
We'll discuss here what are these ingredients and how to implement them.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
3. The Four Universal Parts of Any Software
|
|||
|
|
|||
|
The file set of any Application Software, graphical, server-side, commercial,
|
|||
|
open/free, monolithic etc, has allways four universal parts:
|
|||
|
|
|||
|
1st :: The Software on its own: the body
|
|||
|
|
|||
|
The executables, libraries, static-data files, examples, manuals and
|
|||
|
documentation, etc. Regular users must have read-only access to these files.
|
|||
|
They are changed only when the system administrator makes an upgrade in this
|
|||
|
Software.
|
|||
|
|
|||
|
2nd :: Configuration Files: the soul
|
|||
|
|
|||
|
These are files that define how the Software will run, how to use the Content
|
|||
|
, security, performance etc. Without them, the Software on its own is usually
|
|||
|
useless.
|
|||
|
|
|||
|
Depending on your Software, specific privileged users may change these files,
|
|||
|
to make the Software behave as they want.
|
|||
|
|
|||
|
It is important to provide documentation about the configuration files.
|
|||
|
|
|||
|
3rd :: Content
|
|||
|
|
|||
|
Is what receives all the user attention. Is what the user delegated to be
|
|||
|
managed by your Product. Is what makes a user throw away your product and use
|
|||
|
the competitors', if it gets damaged.
|
|||
|
|
|||
|
Are the tables of a database system, the documents for a text editor, the
|
|||
|
images and HTML pages of a web-server, the servlets and EJBs of an
|
|||
|
Application Server, etc.
|
|||
|
|
|||
|
4th :: Logs, Dumps etc
|
|||
|
|
|||
|
Server Software use to generate access logs, trace files problem
|
|||
|
determination, temporary files etc. Other types of softwares also use this
|
|||
|
files, but it is less common.
|
|||
|
|
|||
|
It is the last class of file, but many times they are the most problem
|
|||
|
generator for a system administrator, because their volume can surpass even
|
|||
|
the content size. Due this fact, it is important for you to think in some
|
|||
|
methodology or facility for this issue, while you are in design time.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
3.1. Practical Examples
|
|||
|
|
|||
|
Let's see how universal is this concept analyzing some types of softwares:
|
|||
|
|
|||
|
|
|||
|
Table 1. Universality of 4 Parts
|
|||
|
+---------+---------------+--------------+-----------------+----------------+
|
|||
|
|<7C> |Software on its|Configurations|Content |Logs, Dumps etc |
|
|||
|
| |Own | | | |
|
|||
|
+---------+---------------+--------------+-----------------+----------------+
|
|||
|
|Data Base|Binaries, |Files that |Table files, |For DBs, there |
|
|||
|
|Server |libraries, |define the |index files, etc.|are the backup, |
|
|||
|
| |documentations.|directory of |This software use|generated in a |
|
|||
|
| | |the data |to have whole |daily basis. And|
|
|||
|
| | |files. For |trees under the |the logs are |
|
|||
|
| | |this type of |same directory. |used by the DBA |
|
|||
|
| | |Software, the |And many times |to define |
|
|||
|
| | |remaining |they need several|indexing |
|
|||
|
| | |configurations|filesystems to |strategy. His |
|
|||
|
| | |usually are in|guarantee |local on the |
|
|||
|
| | |special tables|performance. |system is also |
|
|||
|
| | |inside the |Their local in |defined by the |
|
|||
|
| | |database. |the system is |Configurations. |
|
|||
|
| | | |defined by they | |
|
|||
|
| | | |Configurations. | |
|
|||
|
+---------+---------------+--------------+-----------------+----------------+
|
|||
|
|Text |The same, |As a |The documents |They show as |
|
|||
|
|Processor|templates, |user-oriented |generated by the |temporary files |
|
|||
|
| |modular file |Software, its |user, and they go|that can be |
|
|||
|
| |format filters,|configurations|some place in his|huge. User can |
|
|||
|
| |etc |must be put in|$HOME |define their |
|
|||
|
| | |each user's | |location with a |
|
|||
|
| | |$HOME | |user-friendly |
|
|||
|
| | |directory, and| |dialog (that |
|
|||
|
| | |are files that| |saves it in some|
|
|||
|
| | |defines | |Configuration |
|
|||
|
| | |standard fonts| |file) |
|
|||
|
| | |and | | |
|
|||
|
| | |tabulation, | | |
|
|||
|
| | |etc. | | |
|
|||
|
+---------+---------------+--------------+-----------------+----------------+
|
|||
|
|MP3 |Same, audio |Each user has |Similar to Text |Similar to Text |
|
|||
|
|generator|modular filters|a |Editor |Editor |
|
|||
|
| | |configuration | | |
|
|||
|
| | |file in his | | |
|
|||
|
| | |$HOME, and | | |
|
|||
|
| | |contains | | |
|
|||
|
| | |bitrate | | |
|
|||
|
| | |preferences | | |
|
|||
|
| | |etc | | |
|
|||
|
+---------+---------------+--------------+-----------------+----------------+
|
|||
|
|Web |Similar to Data|Files that |Directories where|Preciouses |
|
|||
|
|Server |Base |define the |the webmaster |access logs, |
|
|||
|
| | |Content |deposits his |vital for |
|
|||
|
| | |directory, |creativity. Again|Marketing |
|
|||
|
| | |network and |defined by the |Intelligence, |
|
|||
|
| | |performance |Configurations |that are |
|
|||
|
| | |parameters, | |generated in a |
|
|||
|
| | |security, etc | |location and |
|
|||
|
| | | | |format defined |
|
|||
|
| | | | |by |
|
|||
|
| | | | |Configurations |
|
|||
|
+---------+---------------+--------------+-----------------+----------------+
|
|||
|
|e-Mail |Similar to |Files that |The preciouses |Mail transfer |
|
|||
|
|Server |Database and |define how to |users mail boxes.|log, virus |
|
|||
|
| |Web-Server |access user |Again defined by |detection log, |
|
|||
|
| | |database, mail|the |etc. Again |
|
|||
|
| | |routing rules,|Configurations |defined by the |
|
|||
|
| | |etc | |Configurations |
|
|||
|
+---------+---------------+--------------+-----------------+----------------+
|
|||
|
|
|||
|
Pay attention that the Software on its Own contains all your product business
|
|||
|
logic, which could be useless if you hadn't a Configuration to define how to
|
|||
|
work with a data bundle, provided by the user. So, Configurations are what
|
|||
|
connects your product to the user.
|
|||
|
|
|||
|
We can use a metaphor about a Sculptor (business logic), that needs Bronze (
|
|||
|
content) and a Theme or Inspiration (configuration) from a Mecenas (user), to
|
|||
|
produce a beautiful work (content). He make annotations in his Journal (logs)
|
|||
|
about his day-by-day activities, to report to his Mecenas (user).
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
3.2. The Importance of Clear Separation Between Four Parts
|
|||
|
|
|||
|
OK, so let's be more practical. The fact is, if we correctly use the
|
|||
|
universal parts concept, we greatly improve the quality of our Product. We'll
|
|||
|
do that simply separating, encapsulating, each one of these parts in
|
|||
|
different system directories (having only different files for each part is
|
|||
|
not sufficient). There is a standard called [http://www.pathname.com/fhs/]
|
|||
|
FHS that defines the Linux directories for each part, and we'll discuss it
|
|||
|
later in Section 4.
|
|||
|
|
|||
|
By now let's see the value of this separation to the user:
|
|||
|
|
|||
|
1. He gains a clear vision about where is each part, specially his
|
|||
|
Configurations and Content, and he feels your Product as something
|
|||
|
completely under control. The clareza brings ease of use, security and
|
|||
|
confidence in your Product. And in practice it permits him manipulate
|
|||
|
each part independently
|
|||
|
|
|||
|
2. It is clear now that, for instance, when backing up, user action is
|
|||
|
needed only for Configurations and Content (the puritans will also backup
|
|||
|
some logs). The user don't have to care about Software on its Own,
|
|||
|
because it is safe, original, on the product CD, in his shelf.
|
|||
|
|
|||
|
3. For upgrades, the new package will overwrite only the business logic,
|
|||
|
leaving intact the user's precious Configurations and Content. Here is
|
|||
|
very important to keep old content and configuration compatible, or to
|
|||
|
provide some tools help migration of data
|
|||
|
|
|||
|
4. The logs being kept in a separate filesystem (obviously suggested in your
|
|||
|
documentation), avoids that their exaggerated growth interfere with the
|
|||
|
Content, or with the stability of the whole system
|
|||
|
|
|||
|
5. If your Software follows some directory standards, the user don't have to
|
|||
|
reconfigure his system or environment to use it. He will simply
|
|||
|
Install-and-Use.
|
|||
|
|
|||
|
|
|||
|
Let's make some exercise with separation using as example a system called
|
|||
|
MySoftware, in which the business logic is in Example 1 and the configuration
|
|||
|
is in Example 2.
|
|||
|
|
|||
|
|
|||
|
Example 1. A Shell program referring an external configuration file
|
|||
|
#!/bin/sh
|
|||
|
|
|||
|
#############################################################################
|
|||
|
##
|
|||
|
## /usr/bin/MySoftware
|
|||
|
##
|
|||
|
## Business logic of MyProgram system.
|
|||
|
## Do not change nothing in this file. All configuration can be
|
|||
|
## made on /etc/MySoftware.conf
|
|||
|
##
|
|||
|
## We'll not support any modifications made here.
|
|||
|
##
|
|||
|
|
|||
|
# Default configuration file
|
|||
|
CONF=/etc/MySoftware.conf (1)
|
|||
|
|
|||
|
# Minimal content directories
|
|||
|
MIN_CONTENT_PATH=/var/www:/var/MySoftware/www (2)
|
|||
|
|
|||
|
if [ -r "$CONF"]; then
|
|||
|
. "$CONF" (3)
|
|||
|
fi
|
|||
|
|
|||
|
# All the content I'll serve are the "minimal" plus the ones provided
|
|||
|
# by the user in the configuration file $CONF
|
|||
|
CONTENT_PATH=$MIN_CONTENT_PATH:$CONF_CONTENT_PATH (4)
|
|||
|
|
|||
|
.
|
|||
|
.
|
|||
|
.
|
|||
|
|
|||
|
(1) Definition of the configuration file name.
|
|||
|
(2) Definition of some static parameters.
|
|||
|
(3) The configuration is readed from an external file, if exists.
|
|||
|
(4) After reading the configuration file, all content directories -- user's +
|
|||
|
product's -- goes together in the $CONTENT_PATH, that will be used from
|
|||
|
now on.
|
|||
|
|
|||
|
Example 2. File containing only the configurations for MySoftware
|
|||
|
#############################################################################
|
|||
|
##
|
|||
|
## /etc/MySoftware.conf
|
|||
|
##
|
|||
|
## Configuration parameters for MySoftware.
|
|||
|
## Change as much as you want.
|
|||
|
##
|
|||
|
|
|||
|
# Content directory.
|
|||
|
# A ':' separated list of directories for your content.
|
|||
|
# The directories /var/www and /var/MySofware are already there, so
|
|||
|
# include here your special directories, if any.
|
|||
|
CONF_CONTENT_PATH=/var/NewInstance:/var/NewInstance2 (1)
|
|||
|
|
|||
|
# Your e-mail address, for notifications.
|
|||
|
EMAIL=john@mycompany.com (2)
|
|||
|
|
|||
|
# Logs directory
|
|||
|
LOG_DIR=/var/log/myInstance (3)
|
|||
|
|
|||
|
(1) (2) (3)
|
|||
|
These are user defined parameters.
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
3.3. One Body, Many Souls
|
|||
|
|
|||
|
When I was a system administrator for IBM e-business Hosting Services, I was
|
|||
|
fascinated by [http://httpd.apache.org/] Apache's flexibility letting us do
|
|||
|
things like this:
|
|||
|
bash# /usr/sbin/httpd &
|
|||
|
bash# /usr/sbin/httpd -f /etc/httpd/dom1.com.br.conf &
|
|||
|
bash# /usr/sbin/httpd -f /etc/httpd/dom2.com.br.conf &
|
|||
|
bash# /usr/sbin/httpd -f /etc/httpd/dom3.com.br.conf &
|
|||
|
|
|||
|
If we don't pass any parameter (like the first example), Apache loads its
|
|||
|
default, hardcoded configuration file from /etc/httpd/conf/httpd.conf. We
|
|||
|
built other configs, one for each customer, with a completely different
|
|||
|
structure, IP address, loaded modules, content directory, passwords, domains,
|
|||
|
log strategy etc.
|
|||
|
|
|||
|
This same concept is used by a text editor of a multiuser desktop (like
|
|||
|
Linux). When the code is loaded, it looks for a configuration file on the
|
|||
|
user's $HOME, and depending who invoked him (user A or B), it will appear
|
|||
|
differently because each user has its own personal configuration.
|
|||
|
|
|||
|
The obvious conclusion is that the Software's body (business logic) is pure e
|
|||
|
completely oriented by his manipulator's spirit (configuration). But the
|
|||
|
competitive advantage lays on how easy we switch from one spirit to another,
|
|||
|
like in Apache's example. It is very healthy to promote it to your user.
|
|||
|
You'll be letting him create intimacy, reliability, confort with your
|
|||
|
Product.
|
|||
|
|
|||
|
We used this approach with many different Softwares in that e-business
|
|||
|
Hosting time, and it was extremely usefull for maintenance etc. In a version
|
|||
|
migration we had total control over where were each of its parts, and
|
|||
|
upgraded and downgraded Software with no waste of time, with obvious success.
|
|||
|
|
|||
|
But there were some Products that refused to work this way. They had so many
|
|||
|
hardcoded parameters, that we couldn't see what divided the body from their
|
|||
|
spirit (or other parts). These Softwares were marked as bad guys and
|
|||
|
discarded/replaced as soon as possible.
|
|||
|
|
|||
|
We concluded that the good guys Softwares were intuitively blessed by their
|
|||
|
developer's four parts vision. And they made our life easyer. In fact, in
|
|||
|
that time we formulated this theory, that continues to prove itself.
|
|||
|
|
|||
|
Do you want to deploy bad guy or good guy Software?
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
4. Linux Directory Hierarchy: Oriented to the Software Parts
|
|||
|
|
|||
|
By now, all discussion are OS independent. On Linux, the Four Software Parts
|
|||
|
theory is expressed in his directory structure, which is classified and
|
|||
|
documented in the [http://www.pathname.com/fhs/] Filesystem Hierarchy
|
|||
|
Standard. The FHS is part of the LSB (Linux Standard Base), which makes him a
|
|||
|
good thing because all the industry is moving thowards it, and is a constant
|
|||
|
preoccupation to all distributions. FHS defines in which directories each
|
|||
|
peace of Apache, Samba, Mozilla, KDE and your Software must go, and you don't
|
|||
|
have any other reason to not use it while thinking in developing your
|
|||
|
Software, but I'll give you some more:
|
|||
|
|
|||
|
1. FHS is a standard, and we can't live without standards
|
|||
|
|
|||
|
2. This is the most basic OS organization, that are related to access levels
|
|||
|
and security, where users intuitively find each type of file, etc
|
|||
|
|
|||
|
3. Makes user's life easyer
|
|||
|
|
|||
|
|
|||
|
This last reason already justifies FHS adoption, so allways use the FHS !!!
|
|||
|
|
|||
|
More about FHS importance and sharing the same directory structure can be
|
|||
|
found in [http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/ref-guide/
|
|||
|
ch-filesystem.html] Red Hat website.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
4.1. FHS Summary
|
|||
|
|
|||
|
So let's summarize what the FHS has to say about Linux directories:
|
|||
|
|
|||
|
Linux system directories
|
|||
|
|
|||
|
/usr/bin
|
|||
|
Directory for the executables that are accessed by all users (everybody
|
|||
|
have this directory in their $PATH). The main files of your Software will
|
|||
|
probably be here. You should never create a subdirectory under this
|
|||
|
folder.
|
|||
|
|
|||
|
/bin
|
|||
|
Like /usr/bin, but here you'll find only boot process vital executables,
|
|||
|
that are simple and small. Your Software (being high-level) probably
|
|||
|
doesn't have nothing to install here.
|
|||
|
|
|||
|
/usr/sbin
|
|||
|
Like /usr/bin, but contains only the executables that must be accessed by
|
|||
|
the administrator (root user). Regular users should never have this
|
|||
|
directory in their $PATH. If your Software is a daemon, This is the
|
|||
|
directory for some of executables.
|
|||
|
|
|||
|
/sbin
|
|||
|
Like /usr/sbin, but only for the boot process vital executables, and that
|
|||
|
will be accessed by sysadmin for some system maintaining. Commands like
|
|||
|
fsck (filesystem check), init (father of all processes), ifconfig
|
|||
|
(network configuration), mount, etc can be found here. It is the system's
|
|||
|
most vital directory.
|
|||
|
|
|||
|
/usr/lib
|
|||
|
Contains dynamic libraries and support static files for the executables
|
|||
|
at /usr/bin and /usr/sbin. You can create a subdirectory like /usr/lib/
|
|||
|
myproduct to contain your helper files, or dynamic libraries that will be
|
|||
|
accessed only by your Software, without user intervention. A subdirectory
|
|||
|
here can be used as a container for plugins and extensions.
|
|||
|
|
|||
|
/lib
|
|||
|
Like /usr/lib but contains dynamic libraries and support static files
|
|||
|
needed in the boot process. You'll never find an executable at /bin or /
|
|||
|
sbin that needs a library that is outside this directory. Kernel modules
|
|||
|
(device drivers) are under /lib.
|
|||
|
|
|||
|
/etc
|
|||
|
Contains configuration files. If your Software uses several files, put
|
|||
|
them under a subfolder like /etc/myproduct/
|
|||
|
|
|||
|
/var
|
|||
|
The name comes from "variable", because everything that is under this
|
|||
|
directory changes frequently, and the package system (RPM) doesn't keep
|
|||
|
control of. Usually /var is mounted over a separate high-performance
|
|||
|
partition. In /var/log logfiles grow up. For web content we use /var/www,
|
|||
|
and so on.
|
|||
|
|
|||
|
/home
|
|||
|
Contains the user's (real human beings) home directories. Your Software
|
|||
|
package should never install files here (in installation time). If your
|
|||
|
business logic requires a special UNIX user (not a human being) to be
|
|||
|
created, you should assign him a home directory under /var or other place
|
|||
|
outside /home. Please, never forget that.
|
|||
|
|
|||
|
/usr/share/doc, /usr/share/man
|
|||
|
The "share" word is used because what is under /usr/share is platform
|
|||
|
independent, and can be shared among several machines across a network
|
|||
|
filesystem. Therefore this is the place for manuals, documentations,
|
|||
|
examples etc.
|
|||
|
|
|||
|
/usr/local, /opt
|
|||
|
These are obsolete folders. When UNIX didn't have a package system (like
|
|||
|
RPM), sysadmins needed to separate an optional (or local) Software from
|
|||
|
the main OS. These were the directories used for that.
|
|||
|
|
|||
|
|
|||
|
You may think is a bad idea to break your Software (as a whole) in many
|
|||
|
pieces, instead of keeping it all under a self-contained directory. But a
|
|||
|
package system (RPM) has a database that manages it all for you in a very
|
|||
|
professional way, taking care of configuration files, directories etc. And if
|
|||
|
you spread your Software using the FHS, beyond the user friendliness, you'll
|
|||
|
bring an intuitive way to the sysadmin configure it, and work better with
|
|||
|
performance and security.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
4.2. Examples Using the FHS
|
|||
|
|
|||
|
Now that we know where each part of our software must be installed, lets
|
|||
|
review the Universal Parts Table applied to the FHS.
|
|||
|
|
|||
|
|
|||
|
Table 2. Same Software, applying FHS
|
|||
|
+---------+-----------------+---------------+---------+---------------------+
|
|||
|
|<7C> |Software on its |Configurations |Content |Logs, Dumps etc |
|
|||
|
| |Own | | | |
|
|||
|
+---------+-----------------+---------------+---------+---------------------+
|
|||
|
|Data Base|/usr/bin/, /usr/ |/etc/mydb/ |/var/db/ |/var/db/instance1/ |
|
|||
|
|Server |lib/, /usr/share/| |instance1|transactions/, /var/ |
|
|||
|
| |doc/mydb/, /usr/ | |/, /var/ |log/db/ |
|
|||
|
| |share/doc/mydb/ | |db/ |access-instance1.log,|
|
|||
|
| |examples/ | |instance2|/var/log/db/ |
|
|||
|
| | | |/, etc |access-instance2.log |
|
|||
|
+---------+-----------------+---------------+---------+---------------------+
|
|||
|
|Text |/usr/bin/, /usr/ |$HOME |$HOME/ |$HOME/.myeditor-tmp/ |
|
|||
|
|Editor |lib/, /usr/lib/ |/.myeditor.conf|Docs/ | |
|
|||
|
| |myeditor/plugins | | | |
|
|||
|
| |/, /usr/share/ | | | |
|
|||
|
| |myeditor/ | | | |
|
|||
|
| |templates/, /usr/| | | |
|
|||
|
| |share/doc/ | | | |
|
|||
|
| |myeditor/ | | | |
|
|||
|
+---------+-----------------+---------------+---------+---------------------+
|
|||
|
|MP3 |/usr/bin/, /usr/ |$HOME |$HOME/ |$HOME/.mymp3-tmp/ |
|
|||
|
|Generator|lib/, /usr/lib/ |/.mymp3.conf |Music/ | |
|
|||
|
| |mymp3/plugins/, /| | | |
|
|||
|
| |usr/share/doc/ | | | |
|
|||
|
| |mymp3/ | | | |
|
|||
|
+---------+-----------------+---------------+---------+---------------------+
|
|||
|
|Web |/usr/sbin/, /usr/|/etc/httpd/, / |/var/www |/var/logs/httpd/, / |
|
|||
|
|Server |bin/, /usr/lib/ |etc/httpd/ |/, /var/ |var/logs/httpd/ |
|
|||
|
| |httpd-modules/, /|instance1/, / |www/ |instance1/, /var/logs|
|
|||
|
| |usr/share/doc/ |etc/httpd/ |instance1|/httpd/instance2/ |
|
|||
|
| |httpd/, /usr/ |instance2/ |/, /var/ | |
|
|||
|
| |share/doc/httpd/ | |www/ | |
|
|||
|
| |examples/ | |instance2| |
|
|||
|
| | | |/ | |
|
|||
|
+---------+-----------------+---------------+---------+---------------------+
|
|||
|
|E-Mail |/usr/sbin/, /usr/|/etc/mail/, / |/var/mail|/var/spool/mailqueue |
|
|||
|
|Server |bin/, /usr/lib/, |etc/ |/ |/, /var/logs/mail.log|
|
|||
|
| |/usr/share/doc/ |mailserver.cf | | |
|
|||
|
| |mymail/ | | | |
|
|||
|
+---------+-----------------+---------------+---------+---------------------+
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
4.3. Developer, Do Not Install in /opt or /usr/local !
|
|||
|
|
|||
|
If you are a systems administrator, this section is not for you. This is a
|
|||
|
subject for developers and packagers, to make sysadmin's life easyer.
|
|||
|
|
|||
|
The /opt and /usr/local directories are used by sysadmins to manualy
|
|||
|
non-packaged files (without RPM) of a software, precisely to not loose
|
|||
|
control over those files. Notice how separated this folder are from the rest
|
|||
|
of the system.
|
|||
|
|
|||
|
A manual installation process (without RPM, or based on simple file copy) is
|
|||
|
documented in forgoten document inside a drawer (if it was documented), and
|
|||
|
inside the head of who made installation. If he moves to another job, that
|
|||
|
installations becomes obscure to the rest of the team, and is a time bomb.
|
|||
|
|
|||
|
With RPM is different. RPM (or any other package system) is an installation
|
|||
|
"process" by itself. It is self-documented in his database and pre and
|
|||
|
post-install actions, which permits total control. Turns installations
|
|||
|
independent from who did it, turning installtions in a business process.
|
|||
|
|
|||
|
Installations based on coping files into /opt or /usr/local are far from
|
|||
|
providing the organization, system visibility and control that RPM provides.
|
|||
|
I can say /opt and /usr/local would be obsoleted when all softwares become
|
|||
|
RPMized.
|
|||
|
|
|||
|
It is very important to Linux evolution and popularization (especially in the
|
|||
|
desktop battlefield), that developers stop using this hell directories, and
|
|||
|
start using the FHS. After reading this section, if you still think this
|
|||
|
folders are good business, please drop me an e-mail.
|
|||
|
|
|||
|
Products that are entirely installed under one directory, use the
|
|||
|
self-contained approach, that has several problems:
|
|||
|
|
|||
|
1. Forces the user to change environment variables like $PATH and
|
|||
|
$LD_LIBRARY_PATH to use your product easily.
|
|||
|
|
|||
|
2. Puts files in non-standard places, complicating system integration, and
|
|||
|
future installation of extensions to your product.
|
|||
|
|
|||
|
3. The sysadmin probably didn't prepared disk space in these partitions,
|
|||
|
generating problems in installation time.
|
|||
|
|
|||
|
4. It is an accepted approach only for pure graphical application, without
|
|||
|
the command line concept. This is why it were well accepted in Windows.
|
|||
|
But...
|
|||
|
|
|||
|
5. ...even using this approach, you can't avoid installing or changing files
|
|||
|
in standard locations to, for instance, make your icons appear in the
|
|||
|
user desktop.
|
|||
|
|
|||
|
|
|||
|
Many developers believe that the "self-contained" approach let them work with
|
|||
|
several versions of the same product, for testing purposes, or whatever. Yes,
|
|||
|
agree, with this or any good reason in the planet. But remember that a High
|
|||
|
Quality Software (or Commercial Grade Software) objective is to be practical
|
|||
|
for the final user, and not to be easy to their developers and testers.
|
|||
|
Invite yourself to visit an unexperienced user (but potential customer) and
|
|||
|
watch him installing your product.
|
|||
|
|
|||
|
Developer, don't be afraid of spreading your files according to FHS because
|
|||
|
RPM will keep an eye on them.
|
|||
|
|
|||
|
If you have a business reason to let the user work with several versions of
|
|||
|
your Product simultaneously (or any other reason), make a [http://www.rpm.org
|
|||
|
/max-rpm/ch-rpm-reloc.html] relocatable package, which is described in the
|
|||
|
[http://www.rpm.org/max-rpm/] Maximum RPM book. Be also aware about the
|
|||
|
implications of using this feature, [http://www.rpm.org/max-rpm/
|
|||
|
s1-rpm-reloc-wrinkles.html] described in the same book.
|
|||
|
|
|||
|
Red Hat and derivated distributions allways use the directory standard,
|
|||
|
instead of /opt or /usr/local. Read what Red Hat says about this subject, and
|
|||
|
think about it.
|
|||
|
|
|||
|
Note The Makefiles of an OpenSource Software that is portable to other UNICES
|
|||
|
must have the standard installation in /usr/local for compatibility
|
|||
|
reasons. But must also give the option, and induct the packager, to
|
|||
|
create the package using FHS specifications.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
5. Provide Architecture for Extensions and Plugins
|
|||
|
|
|||
|
You'll probably let other Software vendors plug extensions to your product.
|
|||
|
Since you are the author of the initial Software, is your responsability to
|
|||
|
organize it in such a way that the user can simply install the extension RPM
|
|||
|
and use it, without forcing him modify any configuration file. It is again
|
|||
|
the famous Install-and-Use that guarantees ease-of-use.
|
|||
|
|
|||
|
Well, and extension is nothing more that some files in a right format (DLLs
|
|||
|
that implements the API your Software defined), put in the right folders
|
|||
|
(directories your Software looks for extensions).
|
|||
|
|
|||
|
We can see many applications requesting the user to change configuration
|
|||
|
files to "declare" the presence of a new plugin. This is a bad approach that
|
|||
|
must be avoided because makes user's or plugin provider's life harder.
|
|||
|
|
|||
|
The most important thing to consider in your plugin architecture is to not
|
|||
|
share files between plugins and your Software. You should provide an
|
|||
|
architecture where plugins will be able to fully install and uninstall
|
|||
|
themselves by simply putting and removing files in specific directories,
|
|||
|
documented in you Software. Good candidates are /usr/lib/myproduct/plugins as
|
|||
|
the plugins directory, and /etc/myproduct/plugins as the plugins
|
|||
|
configuration files directory. Your Software and plugins must be sufficient
|
|||
|
intelligent to know how to find files, specially configurations, in these
|
|||
|
directories.
|
|||
|
|
|||
|
Using this approach, no post-install procedures is required from the user,
|
|||
|
and from the plugin provider.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
5.1. Abstracting About Plugins
|
|||
|
|
|||
|
I would like to close this subject inviting the reader a se abstratir and
|
|||
|
think about any Software can be treated as an extension to the lower level
|
|||
|
Software. In the same way a third party plugin is an extension to your
|
|||
|
Software, your Software is also an extension to the OS (lower level). This is
|
|||
|
where all the Integration (from the title of this document) magic lives. So
|
|||
|
we can apply all the ease-of-use concepts we discussed before to the plugin
|
|||
|
architecture design of your Software.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
6. Allways Provide RPM Packages of Your Softwares
|
|||
|
|
|||
|
This is extremely important for many reasons:
|
|||
|
|
|||
|
1. Ease-of-use. This is allways the primordial motivation.
|
|||
|
|
|||
|
2. Automates some tasks that must be made before and after the installation
|
|||
|
of your Software. Again bringing ease-of-use.
|
|||
|
|
|||
|
3. Intelligently manages configuration files, documentation etc, providing
|
|||
|
more control in an upgrade
|
|||
|
|
|||
|
4. Manages interdependencies with other packages and versions, guaranteeing
|
|||
|
good functionality.
|
|||
|
|
|||
|
5. Lets you distribute Software with your company's digital signature, and
|
|||
|
makes integrity checks (MD5) in each file, guaranteeing precedence, and
|
|||
|
reporting unwanted file modification.
|
|||
|
|
|||
|
6. Provides tools to let interact with your graphic installer.
|
|||
|
|
|||
|
|
|||
|
But a good package is not only put together your files in a RPM. FHS must be
|
|||
|
followed, configuration and documentation files must be marked as is, and
|
|||
|
pre- and post-install scripts must be robust, to not let them damage the
|
|||
|
system (remember that installation processes is done by root).
|
|||
|
|
|||
|
Know well RPM because it can bring much power and facilities to you and your
|
|||
|
user. There are a lot of documentation available about RPM on the Internet:
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>The book [http://www.redhat.com/docs/books/max-rpm/] Maximum RPM, also
|
|||
|
available [http://www.rpm.org/max-rpm/] on-line and in printable [http://
|
|||
|
www.rpm.org/local/maximum-rpm.ps.gz] PostScript format.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>[http://www.rpm.org/RPM-HOWTO/] RPM-HOWTO which is smaller and more
|
|||
|
straight-forward.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>[http://www.rpm.org/] www.rpm.org
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
6.1. Software Package Modularization
|
|||
|
|
|||
|
You should give user the option to install only the part of your Software he
|
|||
|
wants. Imagine your Software has a client part and a server part, and both
|
|||
|
use files and libraries in common. You should break them in 3 RPMs. For
|
|||
|
instance, lets say the name of your product is MyDB, so you'll provide the
|
|||
|
packages:
|
|||
|
|
|||
|
1. MyDB-common-1.0-3.i386.rpm
|
|||
|
|
|||
|
2. MyDB-server-1.0-3.i386.rpm
|
|||
|
|
|||
|
3. MyDB-client-1.0-3.i386.rpm
|
|||
|
|
|||
|
|
|||
|
and last 2 packages depends on the first. If the user is installing a client
|
|||
|
profile, he will use:
|
|||
|
|
|||
|
1. MyDB-common-1.0-3.i386.rpm
|
|||
|
|
|||
|
2. MyDB-client-1.0-3.i386.rpm
|
|||
|
|
|||
|
|
|||
|
If he is installing a server profile:
|
|||
|
|
|||
|
1. MyDB-common-1.0-3.i386.rpm
|
|||
|
|
|||
|
2. MyDB-server-1.0-3.i386.rpm
|
|||
|
|
|||
|
|
|||
|
This approach will help the user save disk space, and be aware of how your
|
|||
|
Software is organized.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
7. Security: The Omnipresent Concept
|
|||
|
|
|||
|
From a very general perspective, security is synonym of order, conscience.
|
|||
|
And insecure is everything that makes a system stop without the user wish. So
|
|||
|
besides open network ports, or weak cryptography (that are beyond the scope
|
|||
|
of this document), applications that inducts the user to use it only as root,
|
|||
|
or make him change files in inappropriate places, is considered insecure. We
|
|||
|
can say the same for the apps that fills a filesystem that is vital to the
|
|||
|
OS.
|
|||
|
|
|||
|
Many standards appeared from good practices discussed and developed in
|
|||
|
conjunction for a long time. So you should know and use them when you'll
|
|||
|
package your software, because they are key for you to achieve a good
|
|||
|
organization (security) level.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
8. Graphical User Interface
|
|||
|
|
|||
|
Everybody loves graphical interfaces. Many times they make our life easyer,
|
|||
|
and this way helps to popularize a Software, because the learning curve get
|
|||
|
smaller. But for the everyday use, a command with many options and a good
|
|||
|
manual becomes much more practical, making scripts easy, remote access, etc.
|
|||
|
So the suggestion is, whenever is possible, to provide both interfaces:
|
|||
|
graphical for the beginners, and the powerfull command line for the expert.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
8.1. KDE, GNOME, Java or Motif?
|
|||
|
|
|||
|
Better then a simple graphical interface is a consistent integrated desktop.
|
|||
|
So developer, please do not reinvent the wheel using proprietary libraries.
|
|||
|
Today's Linux desktop is full-featured, complete APIs that makes your life
|
|||
|
easier.
|
|||
|
|
|||
|
The desktops today in Linuxland are KDE and GNOME. Try to allways use one of
|
|||
|
them, or both.
|
|||
|
|
|||
|
[http://www.kde.org/] KDE is the most outstanding, offering a true consistent
|
|||
|
desktop, flexible, with an extremely elegant architecture, using components
|
|||
|
(like Microsoft's COM and COM+), intercommunication, performance etc. It is
|
|||
|
constantly evolving, and is developed in C++. Its applications have an
|
|||
|
familiar integrated look-and-feel, is light and mature. People say that KDE 3
|
|||
|
is shiny diamond, ready to be used, and is my first suggestion to you.
|
|||
|
|
|||
|
[http://www.gnome.org/] GNOME also brings the integrated desktop proposal,
|
|||
|
but it is far from the maturity and ease-of-use of KDE. From the other side,
|
|||
|
is very well supported by the comunity, and good improvements are appearing.
|
|||
|
|
|||
|
Motif isn't an integrated desktop. It is a widgets library (button, scrollbar
|
|||
|
etc), plus a window-manager. It was born commercial, is mature and popular in
|
|||
|
commercial applications. But is considered obsolete in front of KDE and
|
|||
|
GNOME, that integrates the desktop. Motif source code was opened by the
|
|||
|
[http://www.opengroup.org/] OpenGroup and because that was renamed to [http:/
|
|||
|
/www.openmotif.org/] OpenMotif.
|
|||
|
|
|||
|
[http://java.sun.com/] Java is being used more and more for graphical
|
|||
|
interfaces, specially in server Software, where the graphics are only helpers
|
|||
|
to configuration and administration.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
8.2. Web Interface: Access from Anywhere
|
|||
|
|
|||
|
Nowadays every desktop has a browser, and if your Product is a server
|
|||
|
application, the Web Interface is the right choice, because it lets a user
|
|||
|
administer it from anywhere. But keep in mind the security and organization
|
|||
|
of your CGIs, because they use to be front doors for crackers. Web interface
|
|||
|
(CGI) is completely different programming paradigm. Try to understand it
|
|||
|
conceptually first, starting from "how a web-server works", "what is a URL",
|
|||
|
etc, to get on this without compromising your Product's security.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
8.3. Wizards and Graphical Installers
|
|||
|
|
|||
|
Specially for a commercial Product, your Software must provide a graphical
|
|||
|
installer. Believe me, they are impressive in a demonstration, and CIOs love
|
|||
|
them.
|
|||
|
|
|||
|
More then just installation, a wizard helps in the initial configuration of
|
|||
|
your Product, collects info like activation key etc, and shows the developer
|
|||
|
license.
|
|||
|
|
|||
|
A wizard should not do more than this:
|
|||
|
|
|||
|
1. Ask which modules to install, experienced by the user as checkboxes.
|
|||
|
|
|||
|
2. Get the necessary info to build an initial configuration (the soul) for
|
|||
|
the Software.
|
|||
|
|
|||
|
3. Install the selected modules, that are in fact RPM files. Each checkbox
|
|||
|
must represent one or more RPMs, because each RPM is a indivisible
|
|||
|
(atomic) portion of a Software.
|
|||
|
|
|||
|
4. After RPMs installation, change the configuration (soul) files (marked
|
|||
|
this way in the RPMs), or create some content, based on the data the user
|
|||
|
gave to the wizard.
|
|||
|
|
|||
|
|
|||
|
So the wizard hides the RPM installation and writes initial personalization.
|
|||
|
RPM is still responsable for putting all your software files in the correct
|
|||
|
places. This role should never be of your installer. Think that an
|
|||
|
experienced user (there are a lot of them in the Linux world) should be able
|
|||
|
to reproduce your Product installation without the graphical help, using only
|
|||
|
RPM commands. In fact, in big data centers, where people make mass
|
|||
|
installations, a graphical installer only disturbs.
|
|||
|
|
|||
|
RPM provides tools that help your graphical installer interact with them,
|
|||
|
like installation percentage viewer. Documentation for use are allways in the
|
|||
|
RPM manual (man rpm) and in the [http://www.rpm.org/max-rpm/] Maximum RPM
|
|||
|
book.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
9. Starting Your Software Automatically on Boot
|
|||
|
|
|||
|
The way Linux starts (and stops) all its subsystems is very simple and
|
|||
|
modular. Lets you define initialization order, runlevels etc
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
9.1. From BIOS to Subsystems
|
|||
|
|
|||
|
Lets review what happens when we boot Linux:
|
|||
|
|
|||
|
1. The BIOS or a bootloader (lilo, zlilo, grub, etc) loads Linux Kernel from
|
|||
|
disk to memory, with some parameters defined in the bootloader
|
|||
|
configuration. We can see this process watching the dots that appear in
|
|||
|
the screen. Kernel file stays in the /boot directory, and is accessed
|
|||
|
only at this moment.
|
|||
|
|
|||
|
2. In memory, Kernel code starts to run, detecting a series of vital
|
|||
|
devices, disk partitions etc.
|
|||
|
|
|||
|
3. On of the last things Kernel does is to mount the / (root) filesystem,
|
|||
|
that obrigatoriamente must contain the /etc, /sbin, /bin and /lib
|
|||
|
directories.
|
|||
|
|
|||
|
4. Immediately behind, calls the program called init (/sbin/init) and passes
|
|||
|
the control to him.
|
|||
|
|
|||
|
5. The init command will read his configuration file (/etc/inittab) which
|
|||
|
defines the system runlevel, and some Shell scripts to be run.
|
|||
|
|
|||
|
6. These scripts will continue the setup of system's minimal infrastructure,
|
|||
|
mounting other filesystems (according to /etc/fstab), activating swap
|
|||
|
space (virtual memory), etc.
|
|||
|
|
|||
|
7. The last step, and most interesting for you, is the execution of the
|
|||
|
special script called /etc/rc.d/rc, which initializes the subsystems
|
|||
|
according to a directory structure under /etc/rc.d. The name rc comes
|
|||
|
from run commands.
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
9.2. Runlevels
|
|||
|
|
|||
|
The runlevels mechanism lets Linux initialize itself in different ways. And
|
|||
|
also lets us change from one profile (runlevel) to another without rebooting.
|
|||
|
|
|||
|
The default runlevel is defined in /etc/inittab with a line like this:
|
|||
|
|
|||
|
|
|||
|
Example 3. Default runlevel (3, in this case) line in /etc/inittab
|
|||
|
id:3:initdefault:
|
|||
|
|
|||
|
Runlevels are numbers from 0 to 6 and each one of them is used following this
|
|||
|
standard:
|
|||
|
|
|||
|
0
|
|||
|
Halts the system. Turning to this runlevel, all subsystems are softly
|
|||
|
deactivated before the shutdown. Don't use it in the initdefault line of
|
|||
|
/etc/inittab.
|
|||
|
|
|||
|
1
|
|||
|
Mono-user mode. Only vital subsystems are initialized because it is used
|
|||
|
for system maintenance. No user authentication (login) is required in
|
|||
|
this runlevel. A command line is directly returned to the user.
|
|||
|
|
|||
|
3, 2
|
|||
|
3 is used when a system is in full production. Take it as the runlevel
|
|||
|
your software will run. 2 is historical and is like 3, but without NFS.
|
|||
|
|
|||
|
4
|
|||
|
Not used. You can define it as you want, but is uncommon.
|
|||
|
|
|||
|
5
|
|||
|
Like 3 plus a graphical login. It is ideal for a desktop workstation. Use
|
|||
|
3 if the machine will be used as a server, for security and performance
|
|||
|
reasons.
|
|||
|
|
|||
|
6
|
|||
|
Like runlevel 0, but after complete stop, the machine is rebooted. Don't
|
|||
|
use it in the initdefault line of /etc/inittab.
|
|||
|
|
|||
|
|
|||
|
You can switch from one runlevel to another using the telinit command. And
|
|||
|
you can see the current runlevel and the last one with the runlevel command.
|
|||
|
See bellow how we switched from runlevel 3 to 5.
|
|||
|
bash# runlevel
|
|||
|
N 3
|
|||
|
bash# telinit 5
|
|||
|
bash# runlevel
|
|||
|
3 5
|
|||
|
bash#
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
9.3. The Subsystems
|
|||
|
|
|||
|
Subsystems examples are a web-server, data base server, OS network layer etc.
|
|||
|
We'll not consider a user oriented application (like a text editor) as a
|
|||
|
subsystem.
|
|||
|
|
|||
|
Linux provides an elegant and modular way to organize the subsystems
|
|||
|
initialization. An important fact to think is about subsystems
|
|||
|
interdependencies. For instance, it makes no sense to start a web-server
|
|||
|
before basic networking subsystem is active.
|
|||
|
|
|||
|
Subsystems are organized under the /etc/init.d and /etc/rc.d/rcN.d
|
|||
|
directories:
|
|||
|
|
|||
|
/etc/init.d
|
|||
|
All installed Subsystems put in this directory a control program, which
|
|||
|
is a script that follows a simple standard described bellow. This is a
|
|||
|
simplified listing of this directory:
|
|||
|
|
|||
|
|
|||
|
Example 4. Subsystems installed in /etc/init.d
|
|||
|
bash:/etc/init.d# ls -l
|
|||
|
-rwxr-xr-x 1 root root 9284 Aug 13 2001 functions
|
|||
|
-rwxr-xr-x 1 root root 4984 Sep 5 00:18 halt
|
|||
|
-rwxr-xr-x 1 root root 5528 Nov 5 09:44 firewall
|
|||
|
-rwxr-xr-x 1 root root 1277 Sep 5 21:09 keytable
|
|||
|
-rwxr-xr-x 1 root root 487 Jan 30 2001 killall
|
|||
|
-rwxr-xr-x 1 root root 7958 Aug 15 17:20 network
|
|||
|
-rwxr-xr-x 1 root root 1490 Sep 5 07:54 ntpd
|
|||
|
-rwxr-xr-x 1 root root 2295 Jan 30 2001 rawdevices
|
|||
|
-rwxr-xr-x 1 root root 1830 Aug 31 09:29 httpd
|
|||
|
-rwxr-xr-x 1 root root 1311 Aug 15 14:18 syslog
|
|||
|
|
|||
|
/etc/rc.d/rcN.d (N is the runlevel indicator)
|
|||
|
These directories must contain only special symbolic links to the scripts
|
|||
|
in /etc/init.d. This is how it looks:
|
|||
|
|
|||
|
|
|||
|
Example 5. /etc/rc3.d listing
|
|||
|
bash:/etc/rc3.d# ls -l
|
|||
|
lrwxrwxrwx 1 root root 18 Jan 14 11:59 K92firewall -> ../init.d/firewall
|
|||
|
lrwxrwxrwx 1 root root 17 Jan 14 11:59 S10network -> ../init.d/network
|
|||
|
lrwxrwxrwx 1 root root 16 Jan 14 11:59 S12syslog -> ../init.d/syslog
|
|||
|
lrwxrwxrwx 1 root root 18 Jan 14 11:59 S17keytable -> ../init.d/keytable
|
|||
|
lrwxrwxrwx 1 root root 20 Jan 14 11:59 S56rawdevices -> ../init.d/rawdevices
|
|||
|
lrwxrwxrwx 1 root root 16 Jan 14 11:59 S56xinetd -> ../init.d/xinetd
|
|||
|
lrwxrwxrwx 1 root root 18 Jan 14 11:59 S75httpd -> ../init.d/httpd
|
|||
|
lrwxrwxrwx 1 root root 11 Jan 13 21:45 S99local -> ../rc.local
|
|||
|
|
|||
|
Pay attention that all link names has a prefix starting with letter K
|
|||
|
(from Kill, to deactivate) or S (from Start, to activate), and a 2 digit
|
|||
|
number that defines the boot activation priority. In our example we have
|
|||
|
HTTPd (priority 75) starting after the Network (priority 10) subsystem.
|
|||
|
And the Firewalling subsystem will be deactivated (K) in this runlevel.
|
|||
|
|
|||
|
|
|||
|
So to make your Software start automatically in the boot process, it must be
|
|||
|
a subsystem, and we'll see how to do it in the following section.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
9.4. Turning Your Software Into a Subsystem
|
|||
|
|
|||
|
Your Software's files will spread across the filesystems, but you'll want to
|
|||
|
provide a simple and consistent interface to let the user at least start and
|
|||
|
stop it. Subsystems architecture promotes this ease-of-use, also providing a
|
|||
|
way (non obrigatoria) to be automatically started on system initialization.
|
|||
|
You just have to create your /etc/init.d script following a standard to make
|
|||
|
it functional.
|
|||
|
|
|||
|
|
|||
|
Example 6. Skeleton of a Subsystem control program in /etc/init.d
|
|||
|
#!/bin/sh
|
|||
|
#
|
|||
|
# /etc/init.d/mysystem
|
|||
|
# Subsystem file for "MySystem" server
|
|||
|
#
|
|||
|
# chkconfig: 2345 95 05 (1)
|
|||
|
# description: MySystem server daemon
|
|||
|
#
|
|||
|
# processname: MySystem
|
|||
|
# config: /etc/MySystem/mySystem.conf
|
|||
|
# config: /etc/sysconfig/mySystem
|
|||
|
# pidfile: /var/run/MySystem.pid
|
|||
|
|
|||
|
# source function library
|
|||
|
. /etc/rc.d/init.d/functions
|
|||
|
|
|||
|
# pull in sysconfig settings
|
|||
|
[ -f /etc/sysconfig/mySystem ] && . /etc/sysconfig/mySystem (2)
|
|||
|
|
|||
|
RETVAL=0
|
|||
|
prog="MySystem"
|
|||
|
.
|
|||
|
. (3)
|
|||
|
.
|
|||
|
|
|||
|
start() { (4)
|
|||
|
echo -n $"Starting $prog:"
|
|||
|
.
|
|||
|
. (5)
|
|||
|
.
|
|||
|
RETVAL=$?
|
|||
|
[ "$RETVAL" = 0 ] && touch /var/lock/subsys/$prog
|
|||
|
echo
|
|||
|
}
|
|||
|
|
|||
|
stop() { (6)
|
|||
|
echo -n $"Stopping $prog:"
|
|||
|
.
|
|||
|
. (7)
|
|||
|
.
|
|||
|
killproc $prog -TERM
|
|||
|
RETVAL=$?
|
|||
|
[ "$RETVAL" = 0 ] && rm -f /var/lock/subsys/$prog
|
|||
|
echo
|
|||
|
}
|
|||
|
|
|||
|
reload() { (8)
|
|||
|
echo -n $"Reloading $prog:"
|
|||
|
killproc $prog -HUP
|
|||
|
RETVAL=$?
|
|||
|
echo
|
|||
|
}
|
|||
|
|
|||
|
case "$1" in (9)
|
|||
|
start)
|
|||
|
start
|
|||
|
;;
|
|||
|
stop)
|
|||
|
stop
|
|||
|
;;
|
|||
|
restart)
|
|||
|
stop
|
|||
|
start
|
|||
|
;;
|
|||
|
reload)
|
|||
|
reload
|
|||
|
;;
|
|||
|
condrestart)
|
|||
|
if [ -f /var/lock/subsys/$prog ] ; then
|
|||
|
stop
|
|||
|
# avoid race
|
|||
|
sleep 3
|
|||
|
start
|
|||
|
fi
|
|||
|
;;
|
|||
|
status)
|
|||
|
status $prog
|
|||
|
RETVAL=$?
|
|||
|
;;
|
|||
|
*) (10)
|
|||
|
echo $"Usage: $0 {start|stop|restart|reload|condrestart|status}"
|
|||
|
RETVAL=1
|
|||
|
esac
|
|||
|
exit $RETVAL
|
|||
|
|
|||
|
(1) Although these are comments, they are used by chkconfig command and must
|
|||
|
be present. This particular line defines that on runlevels 2,3,4 and 5,
|
|||
|
this subsystem will be activated with priority 95 (one of the lasts), and
|
|||
|
deactivated with priority 05 (one of the firsts).
|
|||
|
(2) Besides your Software's own configuration, this script can also have a
|
|||
|
configuration file. The standard place for it is under /etc/sysconfig
|
|||
|
directory, and in our case we call it mySystem. This code line reads this
|
|||
|
configuration file.
|
|||
|
(4) (6) (8)
|
|||
|
Your script can have many functions, but it is obrigatorios the
|
|||
|
implementation of start and stop methods, because they are responsible
|
|||
|
for (de)activation of your Subsystem on boot. Other methods can be called
|
|||
|
from the command line, and you can define as much as you want.
|
|||
|
(9) After defining the script actions, the command line is analyzed and the
|
|||
|
requested method (action) is called.
|
|||
|
(10)
|
|||
|
If this script is executed without any parameter, it will return a help
|
|||
|
message like this:
|
|||
|
bash# /etc/init.d/mysystem
|
|||
|
Usage: mysystem {start|stop|restart|reload|condrestart|status}
|
|||
|
|
|||
|
(3) (5) (7)
|
|||
|
Here you put your Software's specific command.
|
|||
|
|
|||
|
The mysystem subsystem methods you implemented will be called by users with
|
|||
|
the service command like this example:
|
|||
|
|
|||
|
|
|||
|
Example 7. service command usage
|
|||
|
bash# service mysystem start
|
|||
|
Starting MySystem: [ OK ]
|
|||
|
bash# service mysystem status
|
|||
|
Subsysten MySystem is active with pid 1234
|
|||
|
bash# service mysystem reload
|
|||
|
Reloading MySystem: [ OK ]
|
|||
|
bash# service mysystem stop
|
|||
|
Stopping MySystem: [ OK ]
|
|||
|
bash#
|
|||
|
|
|||
|
You don't have to worry about managing the symbolic links in /etc/rc.d/rcN.d.
|
|||
|
The chkconfig command makes it for you, based on the control comments defined
|
|||
|
in the beginning of your script.
|
|||
|
|
|||
|
|
|||
|
Example 8. Using the chkconfig command
|
|||
|
bash# chkconfig --add mysystem
|
|||
|
bash# chkconfig --del mysystem
|
|||
|
|
|||
|
Read the chkconfig manual page to see what more it can do for you.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
9.5. Packaging Your Boot Script
|
|||
|
|
|||
|
When you'll create the RPM, put your Subsystem script in /etc/init.d and do
|
|||
|
not include any /etc/rc.d/rcN.d link, because it is a user decision to make
|
|||
|
your subsystem automatic or not. If you include them and the user makes any
|
|||
|
change, the RPM file inventory will become inconsistent.
|
|||
|
|
|||
|
The symbolic links must be created and removed dynamically by the
|
|||
|
post-installation and pre-uninstallation process of your package, using the
|
|||
|
chkconfig command. This approach guarantees 100% package and filesystem
|
|||
|
consistency.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
A. Red Hat, About the Filesystem Structure
|
|||
|
|
|||
|
This text was taken from [http://www.redhat.com/docs/manuals/linux/
|
|||
|
RHL-7.2-Manual/ref-guide/ch-filesystem.html] The Official Red Hat Linux
|
|||
|
Reference Guide
|
|||
|
|
|||
|
Why Share a Common Structure?
|
|||
|
|
|||
|
An operating system's filesystem structure is its most basic level of
|
|||
|
organization. Almost all of the ways an operating system interacts with its
|
|||
|
users, applications, and security model are dependent upon the way it stores
|
|||
|
its files on a primary storage device (normally a hard disk drive). It is
|
|||
|
crucial for a variety of reasons that users, as well as programs at the time
|
|||
|
of installation and beyond, be able to refer to a common guideline to know
|
|||
|
where to read and write their binary, configuration, log, and other necessary
|
|||
|
files.
|
|||
|
|
|||
|
A filesystem can be seen in terms of two different logical categories of
|
|||
|
files:
|
|||
|
|
|||
|
1. Shareable vs. unsharable files
|
|||
|
|
|||
|
2. Variable vs. static files
|
|||
|
|
|||
|
|
|||
|
Shareable files are those that can be accessed by various hosts; unsharable
|
|||
|
files are not available to any other hosts. Variable files can change at any
|
|||
|
time without system administrator intervention (whether active or passive);
|
|||
|
static files, such as documentation and binaries, do not change without an
|
|||
|
action from the system administrator or an agent that the system
|
|||
|
administrator has placed in motion to accomplish that task.
|
|||
|
|
|||
|
The reason for looking at files in this way has to do with the type of
|
|||
|
permissions given to the directory that holds them. The way in which the
|
|||
|
operating system and its users need to utilize the files determines the
|
|||
|
directory where those files should be placed, whether the directory is
|
|||
|
mounted read-only or read-write, and the level of access allowed on each
|
|||
|
file. The top level of this organization (/ directory)is crucial, as the
|
|||
|
access to the underlying directories can be restricted or security problems
|
|||
|
may manifest themselves if the top level is left disorganized (security=
|
|||
|
organization) or without a widely-utilized structure.
|
|||
|
|
|||
|
However, simply having a structure does not mean very much unless it is a
|
|||
|
standard. Competing structures can actually cause more problems than they
|
|||
|
fix. Because of this, Red Hat has chosen the most widely-used filesystem
|
|||
|
structure and extended it only slightly to accommodate special files used
|
|||
|
within Red Hat Linux.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
B. About this Document
|
|||
|
|
|||
|
This document must be distributed under the terms of [http://www.gnu.org/
|
|||
|
copyleft/fdl.html] GNU Free Documentation License, which makes him
|
|||
|
sufficiently free. Everybody in invited to contribute to his content and
|
|||
|
ideas.
|
|||
|
|
|||
|
Copyright 2002, Avi Alkalay.
|
|||
|
|
|||
|
This document is published in the following locations:
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>[http://avi.alkalay.net/linux/docs/HighQuality/] Main distribution
|
|||
|
[[http://avi.alkalay.net/linux/docs/HighQuality/HighQuality.pt.html]
|
|||
|
pt_BR] [[http://avi.alkalay.net/linux/docs/HighQuality/
|
|||
|
highquality.tar.gz] XML Source]
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>[http://en.tldp.org/HOWTO/HighQuality-Apps-HOWTO/] LinuxDoc, as a HOWTO
|
|||
|
[[http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/
|
|||
|
HighQuality-Apps-HOWTO.html] single page] [[http://www.ibiblio.org/pub/
|
|||
|
Linux/docs/HOWTO/other-formats/pdf/HighQuality-Apps-HOWTO.pdf] PDF]
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>[http://www.linuxandmain.org/essay/avi.html] Linux and Main essay (24th
|
|||
|
March 2002)
|
|||
|
|
|||
|
|
|||
|
It was written originally in brazilian portuguese, and then translated to
|
|||
|
english. SGML and the more-then-incredible DocBook was used, that made
|
|||
|
possible this document being distributed in other formats, found in website.
|
|||
|
|
|||
|
It got ready (potuguese+english) in mid march 2002. Everything changed after
|
|||
|
this epoch is cosmetics.
|
|||
|
|
|||
|
I wrote it to help commercial companies and OpenSource developers make
|
|||
|
plug-and-play, easy-to-use software for Linux, and this way improve Linux
|
|||
|
usability and popularity.
|
|||
|
|
|||
|
All concepts (from a high level perspective) described here, can be used in
|
|||
|
any UNIX flavor, or even other OS, like Windows. Maybe some day I'll write
|
|||
|
one of these for Windows....or Mac....
|