Advanced.Linux.Networking..Roderick.Smith [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Advanced.Linux.Networking..Roderick.Smith [Electronic resources] - نسخه متنی

Roderick W. Smith

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








Using Local
Startup Scripts


Most Linux distributions start the majority
of their standard servers through either SysV startup scripts or a super
server. One notable exception to this rule is the X server, which is often
started through a line near the end of /etc/inittab , which
launches the X server only in a particular runlevel. Slackware also does things
a bit differently, using /etc/rc.d/rc.inet2 to start most of its servers. Most distributions provide a
"local" startup script, which is intended to be modified by the
system administrator to handle starting unusual system-specific servers,
running initialization utilities, and so on. href="http:// /?xmlid=0-201-77423-2/ch04lev1sec1#ch04table01"> Table 4.1 lists the
local startup scripts for several common Linux distributions.

The usual reason to use a local startup
script is that you're adding a server that you don't want to run via a super
server and that doesn't come with an appropriate SysV startup script. Because
SysV startup scripts are closely tied to specific distributions, you might not
have an appropriate SysV startup script if you obtained a server from a source
other than your own distribution. For instance, if you're running Mandrake but
install a server intended for SuSE, the SuSE SysV startup script may not work
on your Mandrake system. You may also run into this problem if you obtain the
server in source code form from the server's author; an original source such as
this is unlikely to include customizations for specific Linux distributions. The
code may compile and run just fine, but you'll need to start the server
yourself.

Of course, it's possible to write your own
SysV startup scripts for such servers. You can do this by modifying a working
SysV startup script. You might try modifying the startup script for an
equivalent tool (such as an earlier version of the server you're installing, if
you've resorted to a third-party source because your distribution's official
tool is out of date), or some randomly selected startup script. This process
can be tricky, though, particularly if you're not familiar with your
distribution's startup script format or with shell scripting in general. (SysV
startup scripts are written in the bash shell scripting language.) If you run
into problems, or if you're in a hurry and don't want to put forth the effort
to create or modify a SysV startup script, you can start it in the local
startup script.

You can modify the local startup script using
your favorite text editor. To start a server, simply include lines in the file
that are the same as the commands you'd type at a command prompt to launch the
program. For instance, the following line starts a Telnet server:

/usr/sbin/in.telnetd
If the server doesn't start up in daemon mode by default (that is, if it doesn't run in
the background, relinquishing control of your shell if you launch it directly),
you should use an ampersand ( & ) at the end of the command line to tell the server to run in the
background. Failure to do this will cause the execution of the startup script
to halt at the call to the server. This may be acceptable if it's the last line
in the script, but if you want to start additional servers, the subsequent
servers won't start if you omit the ampersand.

You may, of course, do something more complex
than launching a server using a single line. You could use the bash shell's
conditional expressions to test that the server file exists, or launch it only
under certain circumstances. These are the sorts of tasks that are usually
performed in SysV startup scripts, though, so if you want to go to that sort of
effort, you might prefer writing your own SysV startup script.

One important point to keep in mind is that
different distributions' local startup scripts aren't exactly equivalent to one
another. For instance, SuSE runs its boot.local script earlier
in the boot process than Red Hat runs its rc.local . Therefore,
SuSE's local startup script is more appropriate for bringing up interfaces or
doing other early startup tasks, whereas Red Hat's script is better for
launching servers that rely on an already-up network connection. If the tasks
you want to perform in the startup script are very dependent upon the presence
or absence of other servers, you may be forced to create a SysV startup script
with a sequence number that's appropriate for the tasks you want to perform.

The usual reason for using a local startup
script is to create a quick-and-dirty method of launching a server or running
some other program. Once launched, the local startup script provides no easy
way to shut down the server (as does the stop parameter to most
SysV startup scripts); you'll have to use kill , killall , or a
similar tool to stop the server, if you need to do so.



/ 201