Translation

Put one translator per line, in the form NAME <EMAIL>, YEAR1, YEAR2
_
English
translator-credits
0/1000
Context English Italian (it_IT) State
_ translator-credits
Practical rc.d scripting in BSD Guida pratica allo scripting rc.d in BSD
<email>yar@FreeBSD.org</email> <email>yar@FreeBSD.org</email>
<personname><firstname>Yar</firstname><surname>Tikhiy</surname></personname><affiliation> <_:address-1/> </affiliation> <personname><firstname>Yar</firstname><surname>Tikhiy</surname></personname><affiliation> <_:address-1/> </affiliation>
<year>2005</year> <year>2006</year> <year>2012</year> <holder>The FreeBSD Project</holder> <year>2005</year> <year>2006</year> <year>2012</year> <holder>The FreeBSD Project</holder>
FreeBSD is a registered trademark of the FreeBSD Foundation. FreeBSD è un marchio registrato della FreeBSD Foundation.
NetBSD is a registered trademark of the NetBSD Foundation. NetBSD è un marchio registrato dalla NetBSD Foundation.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the <quote>™</quote> or the <quote>®</quote> symbol. Molte denominazioni usate dai produttori e dai rivenditori per distinguere i loro prodotti sono rivendicati come marchi. Laddove queste denominazioni appaiono in questo documento e il Progetto FreeBSD è al corrente della rivendicazione del marchio, le denominazioni sono state fatte seguire dai simboli <quote>™</quote> o da <quote>®</quote>.
$FreeBSD: head/en_US.ISO8859-1/articles/rc-scripting/article.xml 44709 2014-04-29 21:39:27Z wblock $ $FreeBSD$
Beginners may find it difficult to relate the facts from the formal documentation on the BSD <filename>rc.d</filename> framework with the practical tasks of <filename>rc.d</filename> scripting. In this article, we consider a few typical cases of increasing complexity, show <filename>rc.d</filename> features suited for each case, and discuss how they work. Such an examination should provide reference points for further study of the design and efficient application of <filename>rc.d</filename>. I principiati potrebbero trovare difficile collegare i fatti tratti dalla documentazione formale sul framework BSD <filename>rc.d</filename> con le attività pratiche dello scripting <filename>rc.d</filename>. In questo articolo consideriamo alcuni casi tipici di complessità crescente, mostriamo caratteristiche di <filename>rc.d</filename> adatte a ciascuno di questi casi e discutiamo il loro funzionamento. Tale esame dovrebbe fornire dei punti di riferimento per uno studio ulteriore della progettazione e dell'applicazione efficiente di <filename>rc.d</filename>.
Introduction Introduzione
The historical BSD had a monolithic startup script, <filename>/etc/rc</filename>. It was invoked by <citerefentry><refentrytitle>init</refentrytitle><manvolnum>8</manvolnum></citerefentry> at system boot time and performed all userland tasks required for multi-user operation: checking and mounting file systems, setting up the network, starting daemons, and so on. The precise list of tasks was not the same in every system; admins needed to customize it. With few exceptions, <filename>/etc/rc</filename> had to be modified, and true hackers liked it. Il BSD storico aveva uno script di startup monolitico, <filename>/etc/rc</filename>. Era invocato da <citerefentry><refentrytitle>init</refentrytitle><manvolnum>8</manvolnum></citerefentry> al momento del boot e eseguiva tutte le attività nello spazio utente richieste per operazioni multiutente: controllare e montare file system, configurare la rete, avviare i demoni e così via. La lista precisa delle attività non era la stessa per tutti i sistemi; gli amministratori dovevano personalizzarla. Salvo poche eccezioni, bisognava modificare <filename>/etc/rc</filename>, e ai veri hacker ciò piaceva.
The real problem with the monolithic approach was that it provided no control over the individual components started from <filename>/etc/rc</filename>. For instance, <filename>/etc/rc</filename> could not restart a single daemon. The system admin had to find the daemon process by hand, kill it, wait until it actually exited, then browse through <filename>/etc/rc</filename> for the flags, and finally type the full command line to start the daemon again. The task would become even more difficult and prone to errors if the service to restart consisted of more than one daemon or demanded additional actions. In a few words, the single script failed to fulfil what scripts are for: to make the system admin's life easier.
Later there was an attempt to split out some parts of <filename>/etc/rc</filename> for the sake of starting the most important subsystems separately. The notorious example was <filename>/etc/netstart</filename> to bring up networking. It did allow for accessing the network from single-user mode, but it did not integrate well into the automatic startup process because parts of its code needed to interleave with actions essentially unrelated to networking. That was why <filename>/etc/netstart</filename> mutated into <filename>/etc/rc.network</filename>. The latter was no longer an ordinary script; it comprised of large, tangled <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> functions called from <filename>/etc/rc</filename> at different stages of system startup. However, as the startup tasks grew diverse and sophisticated, the <quote>quasi-modular</quote> approach became even more of a drag than the monolithic <filename>/etc/rc</filename> had been.
Without a clean and well-designed framework, the startup scripts had to bend over backwards to satisfy the needs of rapidly developing BSD-based operating systems. It became obvious at last that more steps are necessary on the way to a fine-grained and extensible <filename>rc</filename> system. Thus BSD <filename>rc.d</filename> was born. Its acknowledged fathers were Luke Mewburn and the NetBSD community. Later it was imported into FreeBSD. Its name refers to the location of system scripts for individual services, which is in <filename>/etc/rc.d</filename>. Soon we will learn about more components of the <filename>rc.d</filename> system and see how the individual scripts are invoked.
The basic ideas behind BSD <filename>rc.d</filename> are <emphasis>fine modularity</emphasis> and <emphasis>code reuse</emphasis>. <emphasis>Fine modularity</emphasis> means that each basic <quote>service</quote> such as a system daemon or primitive startup task gets its own <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> script able to start the service, stop it, reload it, check its status. A particular action is chosen by the command-line argument to the script. The <filename>/etc/rc</filename> script still drives system startup, but now it merely invokes the smaller scripts one by one with the <option>start</option> argument. It is easy to perform shutdown tasks as well by running the same set of scripts with the <option>stop</option> argument, which is done by <filename>/etc/rc.shutdown</filename>. Note how closely this follows the Unix way of having a set of small specialized tools, each fulfilling its task as well as possible. <emphasis>Code reuse</emphasis> means that common operations are implemented as <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> functions and collected in <filename>/etc/rc.subr</filename>. Now a typical script can be just a few lines' worth of <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> code. Finally, an important part of the <filename>rc.d</filename> framework is <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry>, which helps <filename>/etc/rc</filename> to run the small scripts orderly with respect to dependencies between them. It can help <filename>/etc/rc.shutdown</filename>, too, because the proper order for the shutdown sequence is opposite to that of startup.
Component Translation Difference to current string
This translation Not translated FreeBSD Doc/articles_rc-scripting
The following strings have the same context and source.
Not translated FreeBSD Doc/articles_explaining-bsd
Not translated FreeBSD Doc/articles_contributors
Translated FreeBSD Doc/articles_bsdl-gpl Lorenzo Salvadore, salvadore@Freebsd.org, 2020

Loading…

User avatar deleted-25

Translation changed

FreeBSD Doc / articles_rc-scripting — Italian (it_IT)

translator-credits
Lorenzo Salvadore, salvadore@Freebsd.org, 2020
7 months ago
User avatar deleted-25

New translation

FreeBSD Doc / articles_rc-scripting — Italian (it_IT)

translator-credits
Lorenzo Salvadore, salvadore@Freebsd.org, 2020
11 months ago
User avatar deleted-25

New contributor

FreeBSD Doc / articles_rc-scripting — Italian (it_IT)

New contributor 11 months ago
Browse all component changes

Things to check

Has been translated

Last translation was "Lorenzo Salvadore, salvadore@Freebsd.org, 2020".

Fix string

Reset

Glossary

English Italian (it_IT)
No related strings found in the glossary.

Source information

Context
_
Source string comment
Put one translator per line, in the form NAME <EMAIL>, YEAR1, YEAR2
Flags
max-length:1000
String age
11 months ago
Source string age
a year ago
Translation file
articles/it_IT/rc-scripting.po, string 1