git: 6a086fefdd - main - [doc-es][articles/rc-scripting] Translate article.
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 04 Jan 2023 16:39:54 UTC
The branch main has been updated by fernape:
URL: https://cgit.FreeBSD.org/doc/commit/?id=6a086fefddf1a7e88c78a877cb0f3a03c68a6bc0
commit 6a086fefddf1a7e88c78a877cb0f3a03c68a6bc0
Author: Fernando Apesteguía <fernape@FreeBSD.org>
AuthorDate: 2022-12-29 18:54:59 +0000
Commit: Fernando Apesteguía <fernape@FreeBSD.org>
CommitDate: 2023-01-04 16:35:38 +0000
[doc-es][articles/rc-scripting] Translate article.
Full article translated.
---
.../content/es/articles/rc-scripting/_index.adoc | 623 ++++++
.../content/es/articles/rc-scripting/_index.po | 2344 ++++++++++++++++++++
2 files changed, 2967 insertions(+)
diff --git a/documentation/content/es/articles/rc-scripting/_index.adoc b/documentation/content/es/articles/rc-scripting/_index.adoc
new file mode 100644
index 0000000000..e06aeda3d3
--- /dev/null
+++ b/documentation/content/es/articles/rc-scripting/_index.adoc
@@ -0,0 +1,623 @@
+---
+authors:
+ -
+ author: 'Yar Tikhiy'
+ email: yar@FreeBSD.org
+copyright: '2005-2006, 2012 The FreeBSD Project'
+description: 'Una guía para escribir nuevos scripts rc.d y entender aquellos que ya están escritos'
+tags: ["rc.d", "scripting", "guide", "tutorial", "FreeBSD"]
+title: 'Scripting práctico rc.d en BSD'
+trademarks: ["freebsd", "netbsd", "general"]
+---
+
+= Scripting práctico rc.d en BSD
+:doctype: article
+:toc: macro
+:toclevels: 1
+:icons: font
+:sectnums:
+:sectnumlevels: 6
+:source-highlighter: rouge
+:experimental:
+:images-path: articles/rc-scripting/
+
+ifdef::env-beastie[]
+ifdef::backend-html5[]
+include::shared/authors.adoc[]
+include::shared/mirrors.adoc[]
+include::shared/releases.adoc[]
+include::shared/attributes/attributes-{{% lang %}}.adoc[]
+include::shared/{{% lang %}}/teams.adoc[]
+include::shared/{{% lang %}}/mailing-lists.adoc[]
+include::shared/{{% lang %}}/urls.adoc[]
+:imagesdir: ../../../images/{images-path}
+endif::[]
+ifdef::backend-pdf,backend-epub3[]
+include::../../../../shared/asciidoctor.adoc[]
+endif::[]
+endif::[]
+
+ifndef::env-beastie[]
+include::../../../../../shared/asciidoctor.adoc[]
+endif::[]
+
+[.abstract-title]
+Resumen
+
+Los principiantes pueden tener dificultades para relacionar los hechos de la documentación formal del framwork [.filename]#rc.d# de BSD con las tareas prácticas de scripting de [.filename]#rc.d#. En este artículo, consideramos algunos casos típicos de complejidad creciente, mostramos [.filename]#rc.d# características adecuadas para cada caso y comentamos cómo funcionan. Dicho examen debe proporcionar puntos de referencia para un estudio más detallado del diseño y la aplicación eficiente de [.filename]#rc.d#.
+
+'''
+
+toc::[]
+
+[[rcng-intro]]
+== Introducción
+
+El BSD histórico tenía un script de arranque monolítico, [.filename]#/etc/rc#. Era invocado por man:init[8] durante el arranque del sistema y realizaba todas las tareas en modo usuario que se requerían para operar en modo multi-usuario: comprobar y montar los sistemas de ficheros, configurar la red, arrancar demonios y demás. La lista precisa de tareas no era la misma en cada sistema; los administradores necesitaban personalizarla. Salvo en unas pocas excepciones, se tenía que modificar [.filename]#/etc/rc#, y a los verdaderos hackers les gustaba.
+
+El verdadero problema con el enfoque monolítico era que no proporcionaba control sobre los componentes individuales a partir de [.filename]#/etc/rc#. Por ejemplo, [.filename]#/etc/rc# no podía reiniciar un solo demonio. El administrador del sistema tenía que encontrar el proceso del demonio a mano, matarlo, esperar hasta que realmente terminara y luego examinar [.filename]#/etc/rc# para los flags, y finalmente escribir la línea de comando completa para iniciar el demonio nuevamente. La tarea se volvía aún más difícil y propensa a errores si el servicio a reiniciar consistía en más de un demonio o exigía acciones adicionales. En pocas palabras, el script único no cumplía con el propósito de los scripts: facilitar la vida del administrador del sistema.
+
+Posteriormente hubo un intento de separar algunas partes de [.filename]#/etc/rc# para poder arrancar los subsistemas más importantes de forma separada. Un ejemplo importante era [.filename]#/etc/netstart# para levantar la red. Permitía acceder a la red desde el modo de usuario único, pero no se integraba bien con el proceso de arranque automático debido a que algunas partes de su código necesitaban intercalarse con acciones que en esencia no estaban relacionadas con la red. Por eso [.filename]#/etc/netstart# se cambió a [.filename]#/etc/rc.network#. El segundo ya no era un script ordinario; estaba compuesto de funciones man:sh[1] grandes y entrelazadas que se llamaban desde [.filename]#/etc/rc# en diferentes fases del sistema de arranque. Sin embargo, a medida que las tareas de arranque se hicieron más diversas y sofisticadas, la aproximación "casi modular" se convirtió en un lastre casi más de lo que había sido el [.filename]#/etc/rc# monolítico.
+
+Sin un framework limpio y bien diseñado, los scripts de inicio tuvieron que hacer todo lo posible para satisfacer las necesidades de los sistemas operativos basados en BSD en rápido desarrollo. Por fin se hizo evidente que se necesitan más pasos en el camino hacia una sistema [.filename]#rc# refinado y extensible. Así nació el [.filename]#rc.d# de BSD. Sus padres reconocidos fueron Luke Mewburn y la comunidad NetBSD. Posteriormente se importó a FreeBSD. Su nombre se refiere a la ubicación de los scripts del sistema para servicios individuales, que se encuentra en [.filename]#/etc/rc.d#. Pronto conoceremos más componentes del sistema [.filename]#rc.d# y veremos cómo se invocan los scripts individuales.
+
+Las ideas básicas detrás del [.filename]#rc.d# de BSD son _modularidad fina_ y __reutilización de código__. _Modularidad fina_ significa que cada "servicio" básico tales como un demonio del sistema o una primitiva de arranque tienen su propio script man:sh[1] capaz de arrancar el servicio, pararlo, recargarlo y comprobar su estado. Se escoge una acción particular mediante un argumento en la línea de comando del script. El script [.filename]#/etc/rc# todavía dirige el sistema de arranque, pero ahora simplemente invoca scripts más pequeños uno a uno con el argumento `start`. También es fácil realizar tareas de parado ejecutando el mismo conjunto de scripts con el argumento `stop`, que es lo que hace [.filename]#/etc/rc.shutdown#. Date cuenta de cómo esto sigue de cerca la manera Unix de tener un conjunto pequeño de herramientas especializadas, cada una realizando su tarea lo mejor posible. _Reutilización de código_ significa que las operaciones comunes están implement
adas como funciones man:sh[1] y compiladas en [.filename]#/etc/rc.subr#. Ahora un script típico puede tener sólo unas pocas líneas de código man:sh[1]. Finalmente, una parte importante del framework [.filename]#rc.d# es man:rcorder[8], que ayuda a [.filename]#/etc/rc# a ejecutar los scripts pequeños de forma ordenada respecto a las dependencias entre ellos. También puede ayudar a [.filename]#/etc/rc.shutdown#, porque el orden adecuado de apagado es el opuesto al de arranque.
+
+El diseño del [.filename]#rc.d# de BSD se describe en <<lukem, el artículo original de Luke Mewburn>>, y los componentes de [.filename]#rc.d# están documentados con gran detalle en <<manpages, las respectivas páginas de manual>>. Sin embargo, puede que no parezca obvio para un novato de [.filename]#rc.d# cómo unir las numerosas partes y piezas para crear un script con estilo para una tarea en particular. Por lo tanto, este artículo intentará un enfoque diferente para describir [.filename]#rc.d#. Mostrará qué funciones deben usarse en varios casos típicos y por qué. Ten en cuenta que este no es un documento de instrucciones porque nuestro objetivo no es dar recetas listas para usar, sino mostrar algunas formas fáciles de introducirse en el reino de [.filename]#rc.d#. Este artículo tampoco sustituye a las páginas del manual correspondientes. No dudes en consultarlas para obtener documentación más formal y completa mientras lees este artículo.
+
+Hay prerequisitos para entender este artículo. Antes de nada, para dominar [.filename]#rc.d# deberías estar familiarizado con el lenguaje de scripting de man:sh[1]. Además deberías conocer cómo el sistema realiza las tareas de arranque y parada en modo usuario, que está descrito en man:rc[8].
+
+Este artículo se centra en la rama FreeBSD de [.filename]#rc.d#. Sin embargo, también puede ser útil para los desarrolladores de NetBSD, porque las dos ramas de [.filename]#rc.d# de BSD no solo comparten el mismo diseño, sino que también son similares en sus aspectos visibles para los creadores de scripts.
+
+[[rcng-task]]
+== Delineando la tarea
+
+Un poco de reflexión antes de arrancar `$EDITOR` no dolerá. Para escribir un script [.filename]#rc.d# bien hecho para un servicio del sistema, deberíamos poder responder las siguientes preguntas primero:
+
+* ¿El servicio es obligatorio u opcional?
+* ¿El script servirá a un solo programa, por ejemplo, un demonio, o realizará acciones más complejas?
+* ¿De qué otros servicios dependerá nuestro servicio y viceversa?
+
+De los ejemplos que siguen veremos por qué es importante conocer las respuestas a estas preguntas.
+
+[[rcng-dummy]]
+== Un guión ficticio
+
+El siguiente script simplemente emite un mensaje cada vez que se inicia el sistema:
+
+[.programlisting]
+....
+#!/bin/sh <.>
+
+. /etc/rc.subr <.>
+
+name="dummy" <.>
+start_cmd="${name}_start" <.>
+stop_cmd=":" <.>
+
+dummy_start() <.>
+{
+ echo "Nothing started."
+}
+
+load_rc_config $name <.>
+run_rc_command "$1" <.>
+....
+
+Las cosas a tener en cuenta son:
+
+➊ Un script interpretado debería empezar con la línea mágica "shebang". Esa línea especifica el programa intérprete para el script. Gracias a la línea shebang, el script se puede invocar exactamente igual que un programa binario si se ha establecido el bit de ejecución. (Consulta man:chmod[1].) Por ejemplo, un administrador puede ejecutar nuestro script de forma manual, desde la línea de comando:
+
+[source, shell]
+....
+# /etc/rc.d/dummy start
+....
+
+[NOTE]
+====
+Para que los scripts puedan ser gestionados por el framework [.filename]#rc.d# tienen que estar escritos en lenguaje man:sh[1]. Si tienes un servicio o port que usa una utilidad de control binaria o una rutina de arranque escrita en otro lenguaje, instala ese elemento en [.filename]#/usr/sbin# (para el sistema) o [.filename]#/usr/local/sbin# (para ports) e invócalo desde un script man:sh[1] en el directorio [.filename]#rc.d# apropiado.
+====
+
+[TIP]
+====
+Si quieres conocer los detalles acerca de por qué los scripts de [.filename]#rc.d# se tienen que escribir en lenguaje man:sh[1], consulta cómo [.filename]#/etc/rc# los invoca mediante `run_rc_script`, luego estudia la implementación de `run_rc_script` en [.filename]#/etc/rc.subr#.
+====
+
+➋ En [.filename]#/etc/rc.subr#, se definen un número de funciones man:sh[1] para que las use el script [.filename]#rc.d#. Las funciones están documentadas en man:rc.subr[8]. Aunque es teóricamente posible escribir un script [.filename]#rc.d# sin llegar a usar man:rc.subr[8], sus funciones han demostrado ser extremadamente útiles y hacen el trabajo un orden de magnitud más fácil. Así que no es una sorpresa que todo el mundo recurra a man:rc.subr[8] en los scripts de [.filename]#rc.d#. Nosotros no vamos a ser una excepción.
+
+Un script [.filename]#rc.d# debe incluir [.filename]#/etc/rc.subr# (utilizando "`.`") _antes_ de llamar a funciones de man:rc.subr[8] de forma que man:sh[1] tenga una oportunidad para saber acerca de las funciones. El estilo preferido es hacer "source" de [.filename]#/etc/rc.subr# antes de nada.
+
+[NOTE]
+====
+Algunas funciones útiles relacionadas con redes son proporcionadas por otro archivo de inclusión, [.filename]#/etc/network.subr#.
+====
+
+➌ [[name-var]] La variable obligatoria `name` especifica el nombre de nuestro script. Es un requisito de man:rc.subr[8]. Es decir, cada script [.filename]#rc.d# _debe establecer_ `name` antes de llamar a las funciones de man:rc.subr[8].
+
+Ahora es el momento adecuado para elegir un nombre único para nuestro script de una vez por todas. Lo usaremos en varios lugares mientras desarrollamos el script. Para empezar, démosle también el mismo nombre al archivo del script.
+
+[NOTE]
+====
+El estilo actual de los scripts [.filename]#rc.d# es englobar los valores asignados a variables entre comillas dobles. Ten en cuenta que esto es sólo una cuestión de estilo y que podría no ser aplicable siempre. Puedes omitir las comillas de forma segura alrededor de palabras sencillas que no contengan metacaracteres de man:sh[1], mientras que en ciertos casos necesitarás comillas simples para evitar cualquier interpretación del valor por parte de man:sh[1]. Un programador debería ser capaz de distinguir la sintaxis del lenguaje de las convenciones de estilo y aplicar ambas de forma apropiada.
+====
+
+➍ La idea principal detrás de man:rc.subr[8] es que un script [.filename]#rc.d# proporciona manejadores, o métodos, para que los invoque man:rc.subr[8]. En particular, `start`, `stop`, y otros argumentos pasados a un script [.filename]#rc.d# se manejan de esta forma. Un método es una expresión man:sh[1] que se almacena en una variable llamada `argument_cmd`, donde _argument_ corresponde a lo que se puede especificar en la línea de comando del script. Luego veremos cómo man:rc.subr[8] proporciona métodos por defecto para los argumentos estándar.
+
+[NOTE]
+====
+Para hacer el código en [.filename]#rc.d# más uniforme, es común usar `${name}` donde sea apropiado. Por tanto, es posible simplemente copiar varias líneas de un script a otro.
+====
+
+➎ Deberíamos tener en cuenta que man:rc.subr[8] proporciona métodos por defecto para los argumentos estándar. Consecuentemente, debemos sobrescribir un método con una expresión no-op de man:sh[1] si queremos que no haga nada.
+
+➏ El cuerpo de un método sofisticado se puede implementar como una función. Es una buena idea que el nombre de la función tenga un significado.
+
+[IMPORTANT]
+====
+Se recomienda encarecidamente añadir el prefijo `${name}` a los nombres de todas las funciones definidas en nuestro script de forma que nunca colisionen con funciones de man:rc.subr[8] o cualquier otro fichero que se incluya de forma habitual.
+====
+
+➐ Esta llamada a man:rc.subr[8] carga las variables de man:rc.conf[5]. Nuestro script no las utiliza todavía, pero aún así se recomienda cargar man:rc.conf[5] porque puede haber variables de man:rc.conf[5] controlando al propio man:rc.subr[8].
+
+➑ Normalmente este es el último comando en un script [.filename]#rc.d#. Invoca la maquinaria de man:rc.subr[8] para realizar la acción solicitada utilizando las variables y métodos que ha proporcionado nuestro script.
+
+[[rcng-confdummy]]
+== Un script ficticio configurable
+
+Ahora añadamos algunos controles a nuestro script de prueba. Como sabes, los scripts [.filename]#rc.d# están controlados por man:rc.conf[5]. Afortunadamente, man:rc.subr[8] nos oculta todas las complicaciones. El siguiente script usa man:rc.conf[5] mediante man:rc.subr[8] para ver en primer lugar si está habilitado, y para obtener un mensaje que mostrar en el momento del arranque. Estas dos tareas son de hecho independientes. En un lado, un script [.filename]#rc.d# puede simplemente soportar la activación y desactivación de su servicio. Por otro lado, un script [.filename]#rc.d# obligatorio puede tener las variables de configuración. Sin embargo, nosotros haremos ambas cosas en el mismo script:
+
+[.programlisting]
+....
+#!/bin/sh
+
+. /etc/rc.subr
+
+name=dummy
+rcvar=dummy_enable <.>
+
+start_cmd="${name}_start"
+stop_cmd=":"
+
+load_rc_config $name <.>
+: ${dummy_enable:=no} <.>
+: ${dummy_msg="Nothing started."} <.>
+
+dummy_start()
+{
+ echo "$dummy_msg" <.>
+}
+
+run_rc_command "$1"
+....
+
+¿Qué cambió en este ejemplo?
+
+➊ La variable `rcvar` especifica el nombre de la variable ON/OFF.
+
+➋ Ahora `load_rc_config` es invocado pronto en el script, antes de que se acceda a alguna variable de man:rc.conf[5].
+
+[NOTE]
+====
+Cuando examines scripts [.filename]#rc.d#, ten en cuenta que man:sh[1] retrasa la evaluación de expresiones en una función hasta que ésta es invocada. Por lo tanto, no es un error invocar `load_rc_config` tan tarde como justo antes de `run_rc_command` y aún así acceder a variables de man:rc.conf[5] desde los métodos exportados a `run_rc_command`. Esto es porque los métodos se llaman desde `run_rc_command`, que es invocado _después_ de `load_rc_config`.
+====
+
+➌ Se emitirá un aviso desde `run_rc_command` si `rcvar` está establecida, pero la variable en sí no lo está. Si tu script [.filename]#rc.d# es para el sistema base, deberías añadir un valor por defecto para la variable en [.filename]#/etc/defaults/rc.conf# y documentarlo en man:rc.conf[5]. De lo contrario tu script debería proporcionar un valor por defecto para la variable. La aproximación canónica para el último caso se muestra en el ejemplo.
+
+[NOTE]
+====
+Puedes hacer que man:rc.subr[8] actúe como si la variable estuviera a `ON`, independientemente de su estado actual, poniendo como prefijo del argumento del script `one` o `force`, como en `onestart` o `forcestop`. Ten en cuenta sin embargo que `force` tiene otros efectos peligrosos que mencionaremos abajo, mientras que `one` simplemente tiene preferencia sobre la variable ON/OFF. Por ejemplo, asume que `dummy_enable` es `OFF`. El siguiente comando ejecutará el método `start` a pesar de esa configuración:
+
+[source, shell]
+....
+# /etc/rc.d/dummy onestart
+....
+
+====
+
+➍ Ahora el mensaje que se mostrará en el arranque ya no está inmutable en el script. Se especifica en una variable de man:rc.conf[5] llamada `dummy_msg`. Este es un ejemplo trivial de cómo un script de [.filename]#rc.d# puede ser controlado por variables de man:rc.conf[5].
+
+[IMPORTANT]
+====
+Los nombres de todas las variables man:rc.conf[5] usadas en exclusiva por nuestro script _deben tener_ el mismo prefijo: `${name}_`. Por ejemplo: `dummy_mode`, `dummy_state_file`, y así sucesivamente.
+====
+
+[NOTE]
+====
+Aunque es posible utilizar internamente un nombre más corto, por ejemplo simplemente `msg`, añadir el prefijo único `${name}_` a todos los nombres globales introducidos por nuestro script nos evitará posibles colisiones en el espacio de nombres de man:rc.subr[8].
+
+Como norma, los scripts [.filename]#rc.d# del sistema base no necesitan proporcionar valores por defecto para sus variables en man:rc.conf[5] porque estos deberían establecerse en cambio en [.filename]#/etc/defaults/rc.conf#. Por otro lado, los scripts [.filename]#rc.d# para ports deberían proporcionar los valores por defecto como se muestra en el ejemplo.
+====
+
+➎ Aquí utilizamos `dummy_msg` en realidad para controlar nuestro script, es decir, para emitir un mensaje variable. Utilizar una función de shell para esto es demasiado ya que sólo ejecuta un comando. Una alternativa igualmente válida es:
+
+[.programlisting]
+....
+start_cmd="echo \"$dummy_msg\""
+....
+
+[[rcng-daemon]]
+== Arranque y parada de un demonio simple
+
+Dijimos antes que man:rc.subr[8] podía proporcionar métodos por defecto. Obviamente, estos no pueden ser muy generales. Se adaptan bien al caso común de arrancar y parar un programa tipo demonio que sea sencillo. Asumamos ahora que necesitamos escribir un script [.filename]#rc.d# para dicho demonio llamado `mumbled`. Aquí está:
+
+[.programlisting]
+....
+#!/bin/sh
+
+. /etc/rc.subr
+
+name=mumbled
+rcvar=mumbled_enable
+
+command="/usr/sbin/${name}" <.>
+
+load_rc_config $name
+run_rc_command "$1"
+....
+
+Agradablemente simple, ¿no? Examinemos nuestro pequeño script. Lo único nuevo a tener en cuenta es lo siguiente:
+
+➊ La variable `command` tiene sentido para man:rc.subr[8]. Si está establecida, man:rc.subr[8] actuará en consecuencia con el escenario de servir un demonio convencional. En particular, se proporcionarán los métodos por defecto para los argumentos: `start`, `stop`, `restart`, `poll`, y `status`.
+
+El demonio se arrancará ejecutando `$command` con los flags especificados por `$mumbled_flags`. Por lo tanto todos los datos de entrada para el método `start` por defecto están disponibles en las variables establecidas por nuestro script. A diferencia de `start`, otros métodos podrían requerir información adicional acerca del proceso arrancado. Por ejemplo, `stop` debe saber el PID del proceso para poder terminarlo. En el caso actual, man:rc.subr[8] escaneará la lista de todos los procesos, buscando un proceso cuyo nombre sea `procname`. Esto último es otra variable que tiene significado para man:rc.subr[8] y su valor por defecto es el valor de `command`. En otras palabras, cuando establecemos `command`, `procname` se establece al mismo valor. Esto posibilita que nuestro script pueda matar el demonio y así como comprobar en primer lugar si se está ejecutando.
+
+[NOTE]
+====
+Algunos programas son de hecho scripts ejecutables. El sistema ejecuta dichos scripts iniciando su intérprete y pasándole el nombre del script como un argumento en línea de comandos. Esto se refleja en la lista de procesos, que puede confundir a man:rc.subr[8]. Deberías establecer además `command_interpreter` para que man:rc.subr[8] sepa cuál es el verdadero nombre del proceso si `$command` es un script.
+
+Para cada script [.filename]#rc.d#, hay una variable opcional en man:rc.conf[5] que tiene preferencia sobre `command`. Su nombre se construye de la siguiente manera: `${name}_program`, donde `name` es la variable obligatoria que discutimos <<name-var, anteriormente>>. Ejemplo, en este caso será `mumbled_program`. Es man:rc.subr[8] quien hace que `${name}_program` tenga más prioridad que `command`.
+
+Por supuesto, man:sh[1] te permitirá establecer `${name}_program` desde man:rc.conf[5] o incluso desde el propio script si `command` no está establecido. En ese caso, las propiedades especiales de `${name}_program` se pierden y se convierte en una variable ordinaria que tu script puede usar para sus propios fines. Sin embargo, el uso aislado de `${name}_program` está desaconsejado porque usarlo junto con `command` se ha convertido en algo idiomático en los scripts de [.filename]#rc.d#.
+====
+
+Para una información más detallada acerca de los métodos por defecto, consulta man:rc.subr[8].
+
+[[rcng-daemon-adv]]
+== Arranque y parada de un demonio avanzado
+
+Agreguemos un poco de carne a los huesos del guión anterior y hagámoslo más complejo y más rico en características. Los métodos predeterminados pueden hacer un buen trabajo por nosotros, pero es posible que necesitemos ajustar algunos de sus aspectos. Ahora aprenderemos cómo ajustar los métodos predeterminados a nuestras necesidades.
+
+[.programlisting]
+....
+#!/bin/sh
+
+. /etc/rc.subr
+
+name=mumbled
+rcvar=mumbled_enable
+
+command="/usr/sbin/${name}"
+command_args="mock arguments > /dev/null 2>&1" <.>
+
+pidfile="/var/run/${name}.pid" <.>
+
+required_files="/etc/${name}.conf /usr/share/misc/${name}.rules" <.>
+
+sig_reload="USR1" <.>
+
+start_precmd="${name}_prestart" <.>
+stop_postcmd="echo Bye-bye" <.>
+
+extra_commands="reload plugh xyzzy" <.>
+
+plugh_cmd="mumbled_plugh" <.>
+xyzzy_cmd="echo 'Nothing happens.'"
+
+mumbled_prestart()
+{
+ if checkyesno mumbled_smart; then <.>
+ rc_flags="-o smart ${rc_flags}" <.>
+ fi
+ case "$mumbled_mode" in
+ foo)
+ rc_flags="-frotz ${rc_flags}"
+ ;;
+ bar)
+ rc_flags="-baz ${rc_flags}"
+ ;;
+ *)
+ warn "Invalid value for mumbled_mode" <.>
+ return 1 <.>
+ ;;
+ esac
+ run_rc_command xyzzy <.>
+ return 0
+}
+
+mumbled_plugh() <.>
+{
+ echo 'A hollow voice says "plugh".'
+}
+
+load_rc_config $name
+run_rc_command "$1"
+....
+
+➊ Se pueden pasar argumentos adicionales a `$command` mediante `command_args`. Se añadirán a la línea de comando después de `$mumbled_flags`. Como la línea de comando final se pasa a `eval` para su ejecución, se pueden especificar redirecciones de entrada y salida en `command_args`.
+
+[NOTE]
+====
+_Nunca_ incluyas opciones con guiones, como `-X` o `--foo`, en `command_args`. El contenido de `command_args` aparecerá al final de la línea de comando, por lo tanto seguramente aparezcan después que los argumentos presentes en `${name}_flags`; pero la mayoría de los comandos no reconocen opciones con guiones que aparezcan después de los argumentos ordinarios. Una forma mejor de pasar opciones adicionales a `$command` es añadirlas al principio de `${name}_flags`. Otra forma es modificar `rc_flags` <<rc-flags, como se muestra más adelante>>.
+====
+
+➋ Un demonio con buenos modales debería crear un _pidfile_ de forma que su proceso se pueda encontrar de forma más fácil y segura. La variable `pidfile`, si está establecida, le dice a man:rc.subr[8] dónde puede encontrar el pidfile para que lo usen sus métodos por defecto.
+
+[NOTE]
+====
+De hecho, man:rc.subr[8] también usará el pidfile para ver si el demonio está corriendo antes de arrancarlo. Esta comprobación se puede omitir utilizando el argumento `faststart`.
+====
+
+➌ Si el demonio no puede ejecutarse a menos que exista cierto fichero, tan solo inclúyelos en la lista `required_files`, y man:rc.subr[8] comprobará que esos ficheros existen antes de arrancar el demonio. También existen `required_dirs` y `required_vars` para directorios y variables de entorno respectivamente. Todas ellas están descritas con detalle en man:rc.subr[8].
+
+[NOTE]
+====
+Se puede forzar el método por defecto de man:rc.subr[8] para que se salte las comprobaciones de prerequisitos utilizando `forcestart` como argumento del script.
+====
+
+➍ Podemos personalizar qué señales enviar al demonio en caso de que difieran de las que son bien conocidas. En particular, `sig_reload` especifica la señal que hace que el demonio recargue su configuración; es SIGHUP por defecto. Otra señal se envía para parar el proceso del demonio; por defecto es SIGTERM, pero se puede cambiar estableciendo `sig_stop` de forma apropiada.
+
+[NOTE]
+====
+Los nombres de las señales se tienen que especificar a man:rc.subr[8] sin el prefijo `SIG`, como se muestra en el ejemplo. La versión de man:kill[1] de FreeBSD puede reconocer el prefijo `SIG`, pero versiones de otros tipos de OS podrían no hacerlo.
+====
+
+➎➏ Realizar tareas adicionales antes o después de los métodos por defecto es fácil. Para cada comando-argumento soportado por nuestro script, podemos definir `argument_precmd` y `argument_postcmd`. Estos comandos man:sh[1] se invocan antes y después del método respectivo, como es evidente por sus nombres.
+
+[NOTE]
+====
+Sobrescribir un método por defecto con un `argument_cmd` personalizado no nos impide usar `argument_precmd` o `argument_postcmd` si lo necesitamos. En particular, el primero es bueno para comprobar condiciones sofisticadas, personalizadas que se deberían cumplir antes de ejecutar el comando. Usar `argument_precmd` junto con `argument_cmd` nos permite realizar una separación lógica de las comprobaciones y la acción.
+
+No olvides que puedes poner cualquier expresión man:sh[1] válida dentro de los métodos, pre-, y post-commands que defines. Invocar simplemente una función que realiza el trabajo es un buen estilo en la mayoría de los casos, pero nunca dejes que el estilo limite tu entendimiento de lo que sucede por debajo.
+====
+
+➐ Si quieres implementar argumentos personalizados, que también se pueden entender como _comandos_ para nuestro script, necesitamos listarlos en `extra_commands` y proporcionar métodos para manejarlos.
+
+[NOTE]
+====
+El comando `reload` es especial. Por un lados tiene un método preestablecido en man:rc.subr[8]. Por otro, `reload` no se ofrece por defecto. El motivo es que no todos los demonios usan el mismo mecanismo de recarga y algunos no tienen nada que recargar. De forma que tenemos que pedir explícitamente que se proporcione la funcionalidad. Podemos hacerlo mediante `extra_commands`.
+
+¿Qué obtenemos del método por defecto para `reload`? A menudo los demonios recargan su configuración al recibir una señal - típicamente, SIGHUP. Por lo tanto man:rc.subr[8] intenta recargar el demonio enviándole una señal. La están señal está preestablecida a SIGHUP pero se puede cambiar mediante `sig_reload` si es necesario.
+====
+
+➑⓮ Nuestro script soporta dos comandos no estándar, `plugh` y `xyzzy`. Los hemos visto listados en `extra_commands`, y ahora es momento de proporcionarles métodos. El método para `xyzzy` está entre líneas mientras que el de `plugh` se implementa en la función `mumbled_plugh`.
+
+Los comandos no estándar no se invocan durante el arranque o el apagado. Normalmente están ahí por conveniencia para los administradores. También se pueden usar desde otros subsistemas, por ejemplo, man:devd[8] si se especifica en man:devd.conf[5].
+
+Se puede encontrar la lista completa de comandos disponibles en la línea de uso imprimida por man:rc.subr[8] cuando se invoca el script sin argumentos. Por ejemplo, esta es la línea de uso para el script que estamos estudiando:
+
+[source, shell]
+....
+# /etc/rc.d/mumbled
+Usage: /etc/rc.d/mumbled [fast|force|one](start|stop|restart|rcvar|reload|plugh|xyzzy|status|poll)
+....
+
+⓭ Un script puede invocar sus comandos estándar y no estándar si lo necesita. Esto parece similar a llamar a funciones, pero sabemos que los comandos y funciones del shell no son siempre la misma cosa. Por ejemplo, `xyzzy` aquí no se implementa como una función. Además, puede haber pre-comandos y post-comandos, que se deberían invocar en orden. De modo que la forma apropiada para que un script ejecute sus propios comandos es mediante man:rc.subr[8], como se muestra en el ejemplo.
+
+➒ man:rc.subr[8] proporciona una función útil llamada `checkyesno`. Admite una variable como argumento y devuelve cero si y sólo si la variable está establecida a `YES`, o `TRUE`, o `ON`, o `1`, sin considerar mayúsculas y minúsculas; devuelve un valor distinto de cero en caso contrario. En el último caso, la función comprueba que la variable esté establecida a `NO`, `FALSE`, `OFF`, o `0`, sin distinguir entre mayúsculas y minúsculas; imprime un aviso si la variable contiene cualquier otra cosa, es decir, basura.
+
+Ten en cuenta que para man:sh[1] un código de salida igual a cero significa verdadero y distinto de cero significa falso.
+
+[IMPORTANT]
+====
+La función `checkyesno` admite un __nombre de variable__. No pases el _valor_ expandido de una variable; no funcionará como se espera.
+
+Lo siguiente es un uso correcto de `checkyesno`:
+
+[.programlisting]
+....
+if checkyesno mumbled_enable; then
+ foo
+fi
+....
+
+Por el contrario, llamar a `checkyesno` como se muestra abajo no funcionará - al menos no como se espera:
+
+[.programlisting]
+....
+if checkyesno "${mumbled_enable}"; then
+ foo
+fi
+....
+
+====
+
+➓ [[rc-flags]]Podemos alterar los flags que se pasan a `$command` modificando `rc_flags` en `$start_precmd`.
+
+⓫ En algunos casos podríamos necesitar emitir un mensaje importante que debería ir también a `syslog`. Se puede hacer fácilmente con las siguientes funciones de man:rc.subr[8]: `debug`, `info`, `warn`, y `err`. La última función sale del script con el código especificado.
+
+⓬ Los códigos de salida de los métodos y sus pre-comandos no se ignoran simplemente por defecto. Si `argument_precmd` devuelve un código de salida distinto de cero, el método principal no se ejecutará. Del mismo modo, `argument_postcmd` no será invocado a menos que el método principal devuelva un código de salida igual a cero.
+
+[NOTE]
+====
+Sin embargo, desde la línea de comando se puede indicar a man:rc.subr[8] que ignore esos códigos de salida e invoque todos los comandos añadiendo el prefijo `force` a los argumentos, como en `forcestart`.
+====
+
+[[rcng-hookup]]
+== Conectando un script al framework rc.d
+
+Después de que se ha escrito un script, es necesario integrarlo en [.filename]#rc.d#. El paso crucial es instalar el script en [.filename]#/etc/rc.d# (para el sistema base) o [.filename]#/usr/local/etc/rc.d# (para los ports). Tanto [.filename]#bsd.prog.mk# como [.filename]#bsd.port.mk# proporcionan los hooks necesarios para ello, y normalmente no tienes que preocuparte acerca de los permisos y el propietario. Los scripts de sistema deberían instalarse desde [.filename]#src/libexec/rc/rc.d# mediante el [.filename]#Makefile# que se encuentra allí. Los scripts de ports se pueden instalar con `USE_RC_SUBR` como se describe extref:{porters-handbook}[en el Porter's Handbook, rc-scripts].
+
+Sin embargo, debemos considerar de antemano el lugar de nuestro script en la secuencia de inicio del sistema. Es probable que el servicio manejado por nuestro script dependa de otros servicios. Por ejemplo, un demonio de red no puede funcionar sin las interfaces de red y enrutamiento en funcionamiento. Incluso si un servicio parece no exigir nada, difícilmente puede iniciarse antes de que se hayan verificado y montado los sistemas de archivos básicos.
+
+Ya hemos mencionado man:rcorder[8]. Ahora es momento de mirarlo detenidamente. En pocas palabras, man:rcorder[8] toma un conjunto de ficheros, examina el contenido e imprime una lista ordenada de dependencias de ficheros del conjunto a `stdout`. El objetivo es mantener la información de dependencia _dentro_ de los ficheros de forma que cada uno de ellos sólo habla por sí mismo. Un fichero puede especificar la siguiente información:
+
+* los nombres de las "condiciones" (lo que para nosotros significa servicios) que __proporciona__;
+* los nombres de las "condiciones" que __requiere__;
+* los nombres de las "condiciones" para las cuales este fichero debería ejecutarse _con anterioridad_;
+* _palabras clave_ adicionales que se pueden usar para seleccionar un subconjunto de todo el conjunto de ficheros (se puede indicar a man:rcorder[8] mediante opciones que incluya u omita ficheros que contengan determinadas palabras clave)
+
+No es sorprendente que man:rcorder[8] pueda manejar sólo ficheros de texto con una sintaxis similar a la de man:sh[1]. Es decir, las líneas especiales entendidas por man:rcorder[8] se parecen a comentarios de man:sh[1]. La sintaxis de dichas líneas especiales es bastante rígida para simplificar su procesamiento. Lee man:rcorder[8] para más detalles.
+
+Además de utilizar líneas especiales de man:rcorder[8], un script puede incidir en sus dependencias de otro servicio forzando su arranque. Esto podría ser necesario cuando el otro servicio es opcional y no arrancará por sí mismo porque el administrador lo ha deshabilitado por error en man:rc.conf[5].
+
+Con este conocimiento general en mente, consideremos el script demonio simple mejorado con información de dependencia:
+
+[.programlisting]
+....
+#!/bin/sh
+
+# PROVIDE: mumbled oldmumble <.>
+# REQUIRE: DAEMON cleanvar frotz <.>
+# BEFORE: LOGIN <.>
+# KEYWORD: nojail shutdown <.>
+
+. /etc/rc.subr
+
+name=mumbled
+rcvar=mumbled_enable
+
+command="/usr/sbin/${name}"
+start_precmd="${name}_prestart"
+
+mumbled_prestart()
+{
+ if ! checkyesno frotz_enable && \
+ ! /etc/rc.d/frotz forcestatus 1>/dev/null 2>&1; then
+ force_depend frotz || return 1 <.>
+ fi
+ return 0
+}
+
+load_rc_config $name
+run_rc_command "$1"
+....
+
+Como antes, sigue un análisis detallado:
+
+➊ Esa línea declara los nombres de las "condiciones" que proporciona nuestro script. Ahora otros scripts pueden registrar una dependencia de nuestro script usando dichos nombres.
+
+[NOTE]
+====
+Por lo general, un script especifica una sola condición proporcionada. Sin embargo, nada nos impide enumerar varias condiciones allí, por ejemplo, por razones de compatibilidad.
+
+En cualquier caso, el nombre de la condición `PROVIDE:` principal, o única, debería ser el mismo que `${name}`.
+====
+
+➋➌ Nuestro script indica de qué "condiciones" depende que son proporcionadas por otros scripts. Según esas líneas nuestro script pide a man:rcorder[8] situarlo después del script (o los scripts) que proporcionan [.filename]#DAEMON# y [.filename]#cleanvar#, pero antes de los que proporcionan [.filename]#LOGIN#.
+
+[NOTE]
+====
+No se debería abusar de la línea `BEFORE:` para evitar una lista de dependencias incompleta en el otro script. El caso apropiado para usar `BEFORE:` es cuando el otro script no se preocupa por el nuestro, pero nuestro script puede hacer mejor su tarea si se ejecuta antes que el otro. Un ejemplo típico de la vida real son las interfaces de red frente al firewall: si bien las interfaces no dependen del firewall para hacer su trabajo, la seguridad del sistema se beneficiará de que el firewall esté listo antes de que haya tráfico de red.
+
+Además de las condiciones que se corresponden con un solo servicio, hay meta-condiciones y sus scripts tipo "placeholder" para asegurar que ciertos grupos de operaciones se ejecutan antes que otras. Se distinguen por sus nombres en [.filename]#MAYÚSCULAS#. Su listado y propósito se puede encontrar en man:rc[8].
+
+Ten en cuenta que poner un nombre de servicio en la línea `REQUIRE:` no garantiza que el servicio se esté ejecutando cuando nuestro script arranque. El servicio podría fallar al arrancar o estar deshabilitado en man:rc.conf[5]. Obviamente, man:rcorder[8] no puede controlar esos detalles y man:rc[8] tampoco lo hará. Por lo tanto, la aplicación arrancada por nuestro script debería ser capaz de lidiar con situaciones en las que algún servicio requerido no esté disponible. En ciertos casos, podemos evitarlo como se discute <<forcedep, abajo>>
+====
+
+[[keywords]]➍ Como recordamos del texto anterior, las palabras clave de man:rcorder[8] se pueden utilizar para seleccionar o excluir algunos scripts. Cualquier consumidor de man:rcorder[8] puede especificar mediante las opciones `-k` y `-s` qué palabras clave están en la lista "a mantener" y la lista "a omitir", respectivamente. De todos los ficheros que serán ordenados como dependencias, man:rcorder[8] escogerá sólo aquellos que tengan las palabras clave de la lista "a mantener" (a menos que esté vacía) y que no tenga la palabra clave en la lista "a omitir".
+
+En FreeBSD, [.filename]#/etc/rc# y [.filename]#/etc/rc.shutdown# usan man:rcorder[8]. Estos dos scripts definen la lista estándar de palabras clave del [.filename]#rc.d# de FreeBSD y su significado es el que sigue:
+
+nojail:: El servicio no es para un entorno man:jail[8]. Los procedimientos automáticos de arranque y parada ignorarán el script si está dentro de un jail.
+
+nostart:: El servicio se tiene que arrancar manualmente o no se arrancará. El procedimiento de arranque automático ignorará el script. Esto se puede usar, junto con la palabra clave [.filename]#shutdown#, para escribir scripts que hace algo sólo cuando se para el sistema.
+
+shutdown:: Esta palabra clave se especifica __explícitamente__ si se necesita parar el servicio antes de la parada del sistema.
+
+[NOTE]
+====
+Cuando el sistema se va a apagar, se ejecuta [.filename]#/etc/rc.shutdown#. Asume que la mayoría de los scripts [.filename]#rc.d# no tienen nada que hacer la mayoría del tiempo. Por lo tanto [.filename]#/etc/rc.shutdown# invoca los scripts de [.filename]#rc.d# de forma selectiva con la palabra clave [.filename]#shutdown#, ignorando de forma efectiva el resto de los scripts. Para hacer un apagado incluso más rápido [.filename]#/etc/rc.shutdown# pasa el comando [.filename]#faststop# a los scripts que ejecuta de forma que se salten las comprobaciones preliminares, por ejemplo la comprobación del pidfile. Como los servicios dependientes se deberían parar antes que sus prerequisitos, [.filename]#/etc/rc.shutdown# ejecuta los scripts en orden inverso de dependencia. Si escribes un script [.filename]#rc.d#, deberías considerar si es relevante en el momento del apagado. Por ejemplo, si tu script hace su trabajo como respuesta sólo al comando [.filename]#start#, entonces no necesitas
incluir esta palabra clave. Sin embargo, si tu script gestiona un servicio, probablemente es una buena idea pararlo antes de que el sistema proceda a la fase final de su secuencia de apagado descrito en man:halt[8]. En particular, un servicio se debería parar de forma explícita si necesita un tiempo considerable o acciones especiales para pararse de forma limpia. Un ejemplo típico de dicho servicio es un motor de bases de datos.
+====
+
+[[forcedep]]➎ Para empezar, `force_depend` debería usarse con mucho cuidado. Normalmente es mejor revisar la jerarquía de variables de configuración para tu script de [.filename]#rc.d# si son interdependientes.
+
+Si aún así no puedes evitar usar `force_depend`, el ejemplo ofrece una forma habitual de cómo invocarlo de forma condicional. En el ejemplo, nuestro demonio `mumbled` requiere que otro, `frotz`, se arranque con antelación. Sin embargo, `frotz` también es opcional; y man:rcorder[8] no sabe nada acerca de ese detalle. Afortunadamente, nuestro script tiene acceso a todas las variables de man:rc.conf[5]. Si `frotz_enable` es verdadero, esperamos lo mejor y confiamos en que [.filename]#rc.d# haya arrancado `frotz`. De lo contrario comprobamos el estado de `frotz`. Finalmente, forzamos nuestra dependencia de `frotz` si se constata que no se está ejecutando. `force_depend` emitirá un mensaje de aviso porque se debería invocar sólo si se ha detectado una mala configuración.
+
+[[rcng-args]]
+== Dar más flexibilidad a un script rc.d
+
+Cuando se invoca durante el arranque o la parada, un script [.filename]#rc.d# se supone que actúa en todo el subsistema del que es responsable. Por ejemplo, [.filename]#/etc/rc.d/netif# debería arrancar o parar todas las interfaces de red descritas en man:rc.conf[5]. Se puede indicar cualquiera de los dos comandos utilizando un argumento como `start` o `stop`. Entre el arranque y la parada, los scripts [.filename]#rc.d# ayudan al administrador a controlar el sistema en ejecución, y es cuando surge la necesidad de mayor flexibilidad y precisión. Por ejemplo, el administrador podría querer añadir la configuración de una nueva interfaz de red a man:rc.conf[5] y luego arrancarla sin interferir con la operación de las interfaces existentes. La siguiente vez el administrador podría necesitar parar una interfaz de red concreta. Siguiendo el espíritu de la línea de comandos, el script respectivo de [.filename]#rc.d# necesita un argumento extra, el nombre de la interfaz.
+
+Afortunadamente, man:rc.subr[8] permite pasar un número arbitrario de argumentos a los métodos del script (dentro de los límites del sistema). Debido a esto, los cambios en el script pueden ser mínimos.
+
+¿Cómo puede man:rc.subr[8] obtener acceso a los argumentos extra de la línea de comando? ¿Debería simplemente obtenerlos? De ningún modo. Primero, una función de man:sh[1] no tiene acceso a los parámetros posicionales del llamante, pero man:rc.subr[8] es simplemente una pila de dichas funciones. Segundo, las buenas maneras de [.filename]#rc.d# dictan que es el script principal el encargado de decidir qué argumentos se pasan a sus métodos.
+
+De modo que la aproximación de man:rc.subr[8] es como sigue: `run_rc_command` pasa todos sus argumentos salvo el primero de forma literal al método respectivo. El primer argumento, omitido, es el nombre del método en sí: `start`, `stop`, etc. `run_rc_commad` lo desplazará de forma que lo que es `$2` en la línea de comandos original se presentará como `$1` al método y así sucesivamente.
+
+Para ilustrar esta oportunidad, modifiquemos el script ficticio primitivo para que sus mensajes dependan de los argumentos adicionales proporcionados. Aquí vamos:
+
+[.programlisting]
+....
+#!/bin/sh
+
+. /etc/rc.subr
+
+name="dummy"
+start_cmd="${name}_start"
+stop_cmd=":"
+kiss_cmd="${name}_kiss"
+extra_commands="kiss"
+
+dummy_start()
+{
+ if [ $# -gt 0 ]; then <.>
+ echo "Greeting message: $*"
+ else
+ echo "Nothing started."
+ fi
+}
+
+dummy_kiss()
+{
+ echo -n "A ghost gives you a kiss"
+ if [ $# -gt 0 ]; then <.>
+ echo -n " and whispers: $*"
+ fi
+ case "$*" in
+ *[.!?])
+ echo
+ ;;
+ *)
+ echo .
+ ;;
+ esac
+}
+
+load_rc_config $name
+run_rc_command "$@" <.>
+....
+
+¿Qué cambios esenciales podemos notar en el script?
+
+➊ Todos los argumentos que escribas después de `start` terminan como parámetros posicionales en el método respectivo. Podemos utilizarlos de cualquier forma de acuerdo con nuestra tarea, habilidades e imaginación. En el ejemplo actual, simplemente los pasamos todos a man:echo[1] como una cadena en la siguiente línea - fíjate en `$*` dentro de las comillas dobles. Aquí se ve cómo se puede invocar ahora el script:
+
+[source, shell]
+....
+# /etc/rc.d/dummy start
+Nothing started.
+
+# /etc/rc.d/dummy start Hello world!
+Greeting message: Hello world!
+....
+
+➋ Lo mismo aplica a cualquier método proporcionado por nuestro script, no sólo a los estándar. Hemos añadido un método personalizado llamado `kiss` y puede aprovecharse de los argumentos extra del mismo modo que lo hace `start`. Ejemplo:
+
+[source, shell]
+....
+# /etc/rc.d/dummy kiss
+A ghost gives you a kiss.
+
+# /etc/rc.d/dummy kiss Once I was Etaoin Shrdlu...
+A ghost gives you a kiss and whispers: Once I was Etaoin Shrdlu...
+....
+
+➌ Si queremos pasar todos los argumentos extra a cualquier método, podemos simplemente sustituir `"$@"` por `"$1"` en la última línea de nuestro script, cuando invocamos `run_rc_command`.
+
+[IMPORTANT]
+====
+Un programador de man:sh[1] tiene que entender la sutil diferencia entre `$*` y `$@` como formas de designar todos los parámetros posicionales. Para una discusión en profundidad, consulta un buen manual de script de man:sh[1]. _No_ uses las expresiones hasta que las entiendas completamente porque un uso inadecuado puede resultar en scripts defectuosos e inseguros.
+====
+
+[NOTE]
+====
+Actualmente `run_rc_command` podría tener un bug que impide que mantenga los límites originales entre los argumentos. Es decir, los argumentos con espacios en blanco podrían no procesarse correctamente. El bug nace de un uso inadecuado de `$*`.
+====
+
+[[rcng-furthur]]
+== Otras lecturas
+
+[[lukem]]http://www.mewburn.net/luke/papers/rc.d.pdf[El artículo original de Luke Mewburn] ofrece una visión general de [.filename]#rc.d# y una explicación detallada de las decisiones de diseño. Proporciona información sobre todo el framework de [.filename]#rc.d# y su lugar de un sistema operativo BSD moderno.
+
+[[manpages]] Las páginas del manual de man:rc[8], man:rc.subr[8], y man:rcorder[8] documentan los componentes de [.filename]#rc.d# en gran detalle. No puedes usar toda la potencia de [.filename]#rc.d# sin estudiar las páginas del manual y hacer referencia a ellas mientras escribes tus propios scripts.
+
+La mayor fuente de ejemplos de la vida real en funcionamiento es [.filename]#/etc/rc.d# en un sistema real. Su contenido es fácil y agradable de leer porque la mayoría de los asuntos espinosos están escondidos en man:rc.subr[8]. De cualquier forma ten en cuenta que los scripts de [.filename]#/etc/rc.d# no han sido escritos por los ángeles, así que podrían tener bugs y decisiones de diseño subóptimas. ¡Ahora puedes mejorarlos!
diff --git a/documentation/content/es/articles/rc-scripting/_index.po b/documentation/content/es/articles/rc-scripting/_index.po
new file mode 100644
index 0000000000..ffdfef0f16
--- /dev/null
+++ b/documentation/content/es/articles/rc-scripting/_index.po
@@ -0,0 +1,2344 @@
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR The FreeBSD Project
+# This file is distributed under the same license as the FreeBSD Documentation package.
+# Fernando Apesteguía <fernando.apesteguia@gmail.com>, 2021, 2022.
+msgid ""
+msgstr ""
+"Project-Id-Version: FreeBSD Documentation VERSION\n"
+"POT-Creation-Date: 2022-07-07 23:23-0300\n"
+"PO-Revision-Date: 2022-12-29 18:47+0000\n"
+"Last-Translator: Fernando Apesteguía <fernando.apesteguia@gmail.com>\n"
+"Language-Team: Spanish <https://translate-dev.freebsd.org/projects/"
+"documentation/articlesrc-scripting_index/es/>\n"
+"Language: es\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=2; plural=n != 1;\n"
+"X-Generator: Weblate 4.10.1\n"
+
+#. type: YAML Front Matter: description
+#: documentation/content/en/articles/rc-scripting/_index.adoc:1
+#, no-wrap
+msgid "A guide to writing new rc.d scripts and understanding those already written"
+msgstr ""
+"Una guía para escribir nuevos scripts rc.d y entender aquellos que ya están "
+"escritos"
+
+#. type: Title =
+#: documentation/content/en/articles/rc-scripting/_index.adoc:1
+#: documentation/content/en/articles/rc-scripting/_index.adoc:12
+#, no-wrap
+msgid "Practical rc.d scripting in BSD"
+msgstr "Scripting práctico rc.d en BSD"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:45
+msgid "Abstract"
+msgstr "Resumen"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:49
+msgid ""
+"Beginners may find it difficult to relate the facts from the formal "
+"documentation on the BSD [.filename]#rc.d# framework with the practical "
+"tasks of [.filename]#rc.d# scripting. In this article, we consider a few "
+"typical cases of increasing complexity, show [.filename]#rc.d# 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#."
+msgstr ""
+"Los principiantes pueden tener dificultades para relacionar los hechos de la "
+"documentación formal del framwork [.filename]#rc.d# de BSD con las tareas "
+"prácticas de scripting de [.filename]#rc.d#. En este artículo, consideramos "
+"algunos casos típicos de complejidad creciente, mostramos [.filename]#rc.d# "
+"características adecuadas para cada caso y comentamos cómo funcionan. Dicho "
+"examen debe proporcionar puntos de referencia para un estudio más detallado "
+"del diseño y la aplicación eficiente de [.filename]#rc.d#."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:51
+msgid "'''"
+msgstr "'''"
+
+#. type: Title ==
+#: documentation/content/en/articles/rc-scripting/_index.adoc:55
+#, no-wrap
+msgid "Introduction"
+msgstr "Introducción"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:61
+msgid ""
+"The historical BSD had a monolithic startup script, [.filename]#/etc/rc#. "
+"It was invoked by man:init[8] 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# had to be modified, and true hackers "
+"liked it."
+msgstr ""
+"El BSD histórico tenía un script de arranque monolítico, [.filename]#/etc/rc#"
+". Era invocado por man:init[8] durante el arranque del sistema y realizaba "
+"todas las tareas en modo usuario que se requerían para operar en modo multi-"
+"usuario: comprobar y montar los sistemas de ficheros, configurar la red, "
+"arrancar demonios y demás. La lista precisa de tareas no era la misma en "
+"cada sistema; los administradores necesitaban personalizarla. Salvo en unas "
+"pocas excepciones, se tenía que modificar [.filename]#/etc/rc#, y a los "
+"verdaderos hackers les gustaba."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:67
+msgid ""
+"The real problem with the monolithic approach was that it provided no "
+"control over the individual components started from [.filename]#/etc/rc#. "
+"For instance, [.filename]#/etc/rc# 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# 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."
+msgstr ""
+"El verdadero problema con el enfoque monolítico era que no proporcionaba "
+"control sobre los componentes individuales a partir de [.filename]#/etc/rc#. "
+"Por ejemplo, [.filename]#/etc/rc# no podía reiniciar un solo demonio. El "
+"administrador del sistema tenía que encontrar el proceso del demonio a mano, "
+"matarlo, esperar hasta que realmente terminara y luego examinar [.filename]#/"
+"etc/rc# para los flags, y finalmente escribir la línea de comando completa "
+"para iniciar el demonio nuevamente. La tarea se volvía aún más difícil y "
+"propensa a errores si el servicio a reiniciar consistía en más de un demonio "
+"o exigía acciones adicionales. En pocas palabras, el script único no cumplía "
+"con el propósito de los scripts: facilitar la vida del administrador del "
+"sistema."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:74
+msgid ""
+"Later there was an attempt to split out some parts of [.filename]#/etc/rc# "
+"for the sake of starting the most important subsystems separately. The "
+"notorious example was [.filename]#/etc/netstart# 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# mutated into [.filename]#/etc/rc."
+"network#. The latter was no longer an ordinary script; it comprised of "
+"large, tangled man:sh[1] functions called from [.filename]#/etc/rc# at "
+"different stages of system startup. However, as the startup tasks grew "
+"diverse and sophisticated, the \"quasi-modular\" approach became even more "
+"of a drag than the monolithic [.filename]#/etc/rc# had been."
+msgstr ""
+"Posteriormente hubo un intento de separar algunas partes de [.filename]#/etc/"
+"rc# para poder arrancar los subsistemas más importantes de forma separada. "
+"Un ejemplo importante era [.filename]#/etc/netstart# para levantar la red. "
+"Permitía acceder a la red desde el modo de usuario único, pero no se "
+"integraba bien con el proceso de arranque automático debido a que algunas "
+"partes de su código necesitaban intercalarse con acciones que en esencia no "
+"estaban relacionadas con la red. Por eso [.filename]#/etc/netstart# se "
+"cambió a [.filename]#/etc/rc.network#. El segundo ya no era un script "
+"ordinario; estaba compuesto de funciones man:sh[1] grandes y entrelazadas "
+"que se llamaban desde [.filename]#/etc/rc# en diferentes fases del sistema "
+"de arranque. Sin embargo, a medida que las tareas de arranque se hicieron "
+"más diversas y sofisticadas, la aproximación \"casi modular\" se convirtió "
+"en un lastre casi más de lo que había sido el [.filename]#/etc/rc# "
+"monolítico."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:82
+msgid ""
+"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# system. Thus "
+"BSD [.filename]#rc.d# 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#. Soon we will learn about more components of the "
+"[.filename]#rc.d# system and see how the individual scripts are invoked."
+msgstr ""
+"Sin un framework limpio y bien diseñado, los scripts de inicio tuvieron que "
+"hacer todo lo posible para satisfacer las necesidades de los sistemas "
+"operativos basados en BSD en rápido desarrollo. Por fin se hizo evidente que "
+"se necesitan más pasos en el camino hacia una sistema [.filename]#rc# "
+"refinado y extensible. Así nació el [.filename]#rc.d# de BSD. Sus padres "
+"reconocidos fueron Luke Mewburn y la comunidad NetBSD. Posteriormente se "
+"importó a FreeBSD. Su nombre se refiere a la ubicación de los scripts del "
+"sistema para servicios individuales, que se encuentra en [.filename]#/etc/rc."
+"d#. Pronto conoceremos más componentes del sistema [.filename]#rc.d# y "
+"veremos cómo se invocan los scripts individuales."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:93
+msgid ""
+"The basic ideas behind BSD [.filename]#rc.d# are _fine modularity_ and "
+"__code reuse__. _Fine modularity_ means that each basic \"service\" such as "
+"a system daemon or primitive startup task gets its own man:sh[1] 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# script still drives system startup, but now it merely "
+"invokes the smaller scripts one by one with the `start` argument. It is "
+"easy to perform shutdown tasks as well by running the same set of scripts "
+"with the `stop` argument, which is done by [.filename]#/etc/rc.shutdown#. "
+"Note how closely this follows the Unix way of having a set of small "
+"specialized tools, each fulfilling its task as well as possible. _Code "
+"reuse_ means that common operations are implemented as man:sh[1] functions "
+"and collected in [.filename]#/etc/rc.subr#. Now a typical script can be "
+"just a few lines' worth of man:sh[1] code. Finally, an important part of "
+"the [.filename]#rc.d# framework is man:rcorder[8], which helps [.filename]#/"
+"etc/rc# to run the small scripts orderly with respect to dependencies "
+"between them. It can help [.filename]#/etc/rc.shutdown#, too, because the "
+"proper order for the shutdown sequence is opposite to that of startup."
+msgstr ""
+"Las ideas básicas detrás del [.filename]#rc.d# de BSD son _modularidad fina_ "
+"y __reutilización de código__. _Modularidad fina_ significa que cada "
+"\"servicio\" básico tales como un demonio del sistema o una primitiva de "
+"arranque tienen su propio script man:sh[1] capaz de arrancar el servicio, "
+"pararlo, recargarlo y comprobar su estado. Se escoge una acción particular "
+"mediante un argumento en la línea de comando del script. El script [."
+"filename]#/etc/rc# todavía dirige el sistema de arranque, pero ahora "
+"simplemente invoca scripts más pequeños uno a uno con el argumento `start`. "
+"También es fácil realizar tareas de parado ejecutando el mismo conjunto de "
+"scripts con el argumento `stop`, que es lo que hace [.filename]#/etc/rc."
+"shutdown#. Date cuenta de cómo esto sigue de cerca la manera Unix de tener "
+"un conjunto pequeño de herramientas especializadas, cada una realizando su "
+"tarea lo mejor posible. _Reutilización de código_ significa que las "
+"operaciones comunes están implementadas como funciones man:sh[1] y "
+"compiladas en [.filename]#/etc/rc.subr#. Ahora un script típico puede tener "
+"sólo unas pocas líneas de código man:sh[1]. Finalmente, una parte importante "
+"del framework [.filename]#rc.d# es man:rcorder[8], que ayuda a [.filename]#/"
+"etc/rc# a ejecutar los scripts pequeños de forma ordenada respecto a las "
+"dependencias entre ellos. También puede ayudar a [.filename]#/etc/rc."
+"shutdown#, porque el orden adecuado de apagado es el opuesto al de arranque."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:101
+msgid ""
+"The BSD [.filename]#rc.d# design is described in <<lukem, the original "
+"article by Luke Mewburn>>, and the [.filename]#rc.d# components are "
+"documented in great detail in <<manpages, the respective manual pages>>. "
+"However, it might not appear obvious to an [.filename]#rc.d# newbie how to "
+"tie the numerous bits and pieces together in order to create a well-styled "
+"script for a particular task. Therefore this article will try a different "
+"approach to describe [.filename]#rc.d#. It will show which features should "
+"be used in a number of typical cases, and why. Note that this is not a how-"
+"to document because our aim is not at giving ready-made recipes, but at "
+"showing a few easy entrances into the [.filename]#rc.d# realm. Neither is "
+"this article a replacement for the relevant manual pages. Do not hesitate "
+"to refer to them for more formal and complete documentation while reading "
+"this article."
+msgstr ""
+"El diseño del [.filename]#rc.d# de BSD se describe en <<lukem, el artículo "
+"original de Luke Mewburn>>, y los componentes de [.filename]#rc.d# están "
+"documentados con gran detalle en <<manpages, las respectivas páginas de "
+"manual>>. Sin embargo, puede que no parezca obvio para un novato de [."
+"filename]#rc.d# cómo unir las numerosas partes y piezas para crear un script "
+"con estilo para una tarea en particular. Por lo tanto, este artículo "
+"intentará un enfoque diferente para describir [.filename]#rc.d#. Mostrará "
+"qué funciones deben usarse en varios casos típicos y por qué. Ten en cuenta "
+"que este no es un documento de instrucciones porque nuestro objetivo no es "
+"dar recetas listas para usar, sino mostrar algunas formas fáciles de "
+"introducirse en el reino de [.filename]#rc.d#. Este artículo tampoco "
+"sustituye a las páginas del manual correspondientes. No dudes en "
+"consultarlas para obtener documentación más formal y completa mientras lees "
+"este artículo."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:105
+msgid ""
+"There are prerequisites to understanding this article. First of all, you "
+"should be familiar with the man:sh[1] scripting language in order to master "
+"[.filename]#rc.d#. In addition, you should know how the system performs "
+"userland startup and shutdown tasks, which is described in man:rc[8]."
+msgstr ""
+"Hay prerequisitos para entender este artículo. Antes de nada, para dominar [."
+"filename]#rc.d# deberías estar familiarizado con el lenguaje de scripting de "
+"man:sh[1]. Además deberías conocer cómo el sistema realiza las tareas de "
+"arranque y parada en modo usuario, que está descrito en man:rc[8]."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:108
+msgid ""
+"This article focuses on the FreeBSD branch of [.filename]#rc.d#. "
+"Nevertheless, it may be useful to NetBSD developers, too, because the two "
+"branches of BSD [.filename]#rc.d# not only share the same design but also "
+"stay similar in their aspects visible to script authors."
+msgstr ""
+"Este artículo se centra en la rama FreeBSD de [.filename]#rc.d#. Sin "
+"embargo, también puede ser útil para los desarrolladores de NetBSD, porque "
+"las dos ramas de [.filename]#rc.d# de BSD no solo comparten el mismo diseño, "
+"sino que también son similares en sus aspectos visibles para los creadores "
+"de scripts."
+
+#. type: Title ==
+#: documentation/content/en/articles/rc-scripting/_index.adoc:110
+#, no-wrap
+msgid "Outlining the task"
+msgstr "Delineando la tarea"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:114
+msgid ""
+"A little consideration before starting `$EDITOR` will not hurt. In order to "
+"write a well-tempered [.filename]#rc.d# script for a system service, we "
+"should be able to answer the following questions first:"
+msgstr ""
+"Un poco de reflexión antes de arrancar `$EDITOR` no dolerá. Para escribir un "
+"script [.filename]#rc.d# bien hecho para un servicio del sistema, deberíamos "
+"poder responder las siguientes preguntas primero:"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:116
+msgid "Is the service mandatory or optional?"
+msgstr "¿El servicio es obligatorio u opcional?"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:117
+msgid ""
+"Will the script serve a single program, e.g., a daemon, or perform more "
+"complex actions?"
+msgstr ""
+"¿El script servirá a un solo programa, por ejemplo, un demonio, o realizará "
+"acciones más complejas?"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:118
+msgid "Which other services will our service depend on, and vice versa?"
+msgstr "¿De qué otros servicios dependerá nuestro servicio y viceversa?"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:120
+msgid ""
+"From the examples that follow we will see why it is important to know the "
+"answers to these questions."
+msgstr ""
+"De los ejemplos que siguen veremos por qué es importante conocer las "
+"respuestas a estas preguntas."
+
+#. type: Title ==
+#: documentation/content/en/articles/rc-scripting/_index.adoc:122
+#, no-wrap
+msgid "A dummy script"
+msgstr "Un guión ficticio"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:125
+msgid ""
+"The following script just emits a message each time the system boots up:"
+msgstr ""
+"El siguiente script simplemente emite un mensaje cada vez que se inicia el "
+"sistema:"
+
+#. type: delimited block . 4
+#: documentation/content/en/articles/rc-scripting/_index.adoc:129
+#, no-wrap
*** 2010 LINES SKIPPED ***