Linux Standard Base Core Specification, Generic Part | ||
---|---|---|
<<< Previous | Chapter 18. File System Hierarchy | Next >>> |
In addition to the requirements for /etc in the Filesystem Hierarchy Standard, an LSB conforming system shall also provide the following directories or symbolic links to directories:
/etc/cron.d | A directory containing extended crontab files; see Cron Jobs. | |
/etc/cron.daily | A directory containing shell scripts to be executed once a day; see Cron Jobs. | |
/etc/cron.hourly | A directory containing shell scripts to be executed once per hour; see Cron Jobs. | |
/etc/cron.monthly | A directory containing shell scripts to be executed once per month; see Cron Jobs. | |
/etc/cron.weekly | A directory containing shell scripts to be executed once a week; see Cron Jobs. | |
/etc/init.d | A directory containing system initialization scripts; see Installation and Removal of Init Scripts. | |
/etc/profile.d | A directory containing shell scripts. Script names should follow the same conventions as specified for cron jobs (see Cron Jobs, but should have the suffix .sh. The behavior is unspecified if a script is installed in this directory that does not have the suffix .sh. The sh utility shall read and execute commands in its current execution environment from all the shell scripts in this directory that have the suffix .sh when invoked as an interactive login shell, or if the -l (the letter ell) is specified (see Shell Invocation). |
Future Directions: These directories are required at this version of the LSB since there is not yet an agreed method for abstracting the implementation so that applications need not be aware of these locations during installation.
Conforming implementations and applications installing files into any of the above locations under /etc may only use filenames from the following managed namespaces:
Assigned names. Such names must be chosen from the character set [a-z0-9]. In order to avoid conflicts these names shall be registered. This specification establishes a registry of provider, package and script names which is maintained at the Linux Assigned Names and Numbers Authority (LANANA). See www.lanana.org to register names or look up already registered names.
Note: Commonly used names should be registered to avoid conflicts and promote name reuse across distributions. Project developers are encouraged to reserve names with the LANANA as early as possible as registration is on a first-come, first-served basis.
Hierarchical names. Script names in this category take the form: <hier1>-<hier2>-...-<name>, where name is taken from the character set [a-z0-9], and where there may be one or more <hier-n> components. <hier1> may either be an LSB provider name registered with the LANANA, or it may be a domain name registered to the provider in the DNS system, containing at least one '.' (e.g. "debian.org", "staroffice.sun.com"). The LSB provider name registered with the LANANA shall only consist of the ASCII characters [a-z0-9].
Reserved names. Names that begin with the character '_' are reserved for distribution use only. Names in this form should be used for essential system packages only.
Note: As this specification cannot enforce rules for applications which do not choose to conform to it, conforming applications need to be aware that the managed namespaces may have been polluted with unregistered filenames and should check for namespace collisions and take appropriate steps if they occur.
In general, if a package or system script is likely to be used on multiple systems, the package developers or the distribution should register the name through the LANANA, and distributions should strive to use the same name whenever possible. For applications which may not be essential or may not be commonly installed, the hierarchical namespace may be more appropriate. An advantage to the hierarchical namespace is that there is no need to consult with the LANANA before using a specific name.
Short names are highly desirable, since system administrators may wish to manually start and stop services. Given this, they should be standardized on a per-package basis. This is the rationale behind having the LANANA organization assign these names. The LANANA may be called upon to handle other namespace issues, such as package/prerequisites naming.
<<< Previous | Home | Next >>> |
File System Hierarchy | Up | User Accounting Databases |