Documentación
Inicialización del sistema, configuración y preverización
Tenemos el objetivo de mantener esta documentación actualizada, pero la Fuente de documentación Inithooks (en GitHub) siempre debería estar al día.
Introducción
Antes de exponer un sistema TurnKey a una Internet hostil, primero tenemos que inicializarlo. Esto configurará contraseñas, instalará actualizaciones de seguridad y configurará la configuración de aplicaciones clave.
Este proceso de inicialización puede ser interactivo o no interactivo dependiendo de qué funciona mejor dado dónde y cómo se implementa el sistema.
Iniciación del sistema interactivo
Un asistente de configuración muestra una breve secuencia de diálogos de texto simples que parecen primitivos pero proporcionan un rápido proceso paso a paso que funciona en cualquier lugar y sólo requiere el desnudo mínimo de dependencias de software - una gran ventaja para aplicaciones sensibles a la seguridad:

Todo el software es potencialmente buggy pero podemos minimizar el riesgo favoreciendo intencionalmente la simplicidad sobre los dulces de ojos elegantes.
Los diálogos de configuración se ejecutan en uno de dos lugares:
La consola de arranque en la primera bota sobre los tipos de construcción (por ejemplo, ISO, VM, VMDK) donde la máquina real o virtual suele proporcionar acceso a una consola de sistema interactivo.
El primer login de la administración sobre los tipos de construcción que se ejecutan sin cabeza máquinas virtuales (por ejemplo, AWS marketplace, OpenStack, Xen). que no proporcionan la opción de interactuar con el sistema en el momento de arranque.
Después de la bota, una cerca virtual redirige los intentos de acceder a servicios potencialmente vulnerables a una página web explicando cómo SSH en la máquina por primera vez para inicializar la sistema. Después de la inicialización la cerca virtual baja y todos los servicios se pueden acceder normalmente.
Iniciación del sistema no interactivo
El TurnKey Hub simplifica el despliegue mediante ajustes de inicialización del sistema preverding con valores que el usuario proporciona antes de iniciar una instancia a través de la aplicación web de implementación de cloud del Hub.
Esto significa que cuando el sistema arranca por primera vez no necesita interactuar con el usuario a través de diálogos de texto.
La preverding está bien documentada y puede ser utilizada por otros proveedores de alojamiento o nubes privadas de una manera similar para simplificar el despliegue.
Bajo la capucha: todo lo que quería saber pero tenía miedo de preguntar
¡Para! La introducción anterior explicó todo lo que los mortales necesitan saber sobre el proceso de inicialización del sistema.
El resto de la documentación está destinada a:
hackers appliance interesados en aprender cómo TurnKey funciona bajo la capucha y desarrollar sus propios ganchos de configuración.
Usuarios expertos que quieren entender cómo funciona la inicialización del sistema en profundidad.
Proveedores de hospedaje y ninjas de nube privada interesados en implementar una integración estrecha entre TurnKey y paneles de control personalizados.
Esto no es un requisito, sólo un bono. Sin ninguna integración especial, las imágenes TurnKey pueden ser desplegadas como cualquier otra imagen basada en Debian o Debian, utilizando sus scripts de implementaciones existentes. Si puede desplegar Debian o Ubuntu, debería ser trivial desplegar TurnKey.
Inithooks objetivos de diseño de paquetes
El paquete inithooks ejecuta scripts de inicialización del sistema que:
- Claves secretas regeneradas (por ejemplo, SSH, certificado SSL predeterminado): Esto no es sólo una buena idea, es necesario evitar el hombre en los ataques medios.
- Establecer contraseñas (por ejemplo, root, base de datos, aplicación): necesario para evitar el riesgo de contraseñas predeterminadas de cableado duro
- Configurar los ajustes de aplicación básicos (por ejemplo, dominio, correo electrónico de administración): especialmente útil cuando se configura la aplicación requeriría la búsqueda del formato de un archivo de configuración.
Además, Inithooks ofrece un mecanismo de preverding diseñado para que sea fácil integrar TurnKey con paneles de control personalizados proporcionados por varias soluciones de virtualización y nube proveedores de alojamiento.
Cómo funciona
Inithooks es lo más genérico y barebones posible, dejando la mayor parte de la funcionalidad hasta los scripts específicos appliance "hook" en sí,
Estos scripts se encuentran en dos subdirectorios bajo /usr/lib/inithooks - cadaboot.d y firstboot.d.
Se ejecutan en orden alfanumérico, lo que significa que un script llamado 1-foo sería ejecutado antes de 2-bar, que en sí mismo sería ejecutado antes de 3-foobar. Por eso los guiones de estos directorios tienen números divertidos al principio.
El script de inicio de inicio inithooks se ejecuta temprano en la inicialización del sistema, en el nivel de ejecución 2 15. Esto permite la configuración del sistema antes de la mayoría de los servicios que comienzan. Esto debe tenerse en cuenta al desarrollar scripts de gancho.
scripts de primerboot.d
Los scripts en el subdirectorio de Firstboot.d se ejecutan bajo las siguientes condiciones:
Si el usuario ejecuta "turnkey-init" de una shell raíz. Este comando se puede utilizar para rehacer el primerboot.d inithooks de forma interactiva para reconfigurar el appliance si es necesario. Ciertos scripts como los que regeneran las teclas secretas se saltan. Ver la variable BLACKLIST en /usr/sbin/turnkey-init para detalles.
Cuando el usuario inicia como root por primera vez en un sistema sin cabeza. Esto activa "turnkey-init" para ejecutar de modo que el usuario pueda completar la inicialización appliance de forma interactiva.
Cuando un TurnKey appliance arranca por primera vez
inithooks comprueba si esta es o no la primera bota comprobando el valor de la bandera RUN_FIRSTBOOT en /etc/default/inithooks. Si el valor es falso, se ejecuta los scripts y se mueve la bandera a la verdad.
Los scripts de primer arranque pueden funcionar en uno de dos modos, interactivos o no interactivos, dependiendo del tipo de compilación.
Modo interactivo en construcciones no descabelladas - CD en vivo ISO, VMDK y OVF: Con estos tipos de imagen se espera acceso interactivo a la consola virtual durante el arranque, por lo que algunos de los scripts de inicialización inithooks interactuarán con el usuario a través del texto diálogos la primera vez que el sistema arranca (por ejemplo, pedir contraseñas, configuración de aplicaciones, etc.). Estos son los mismos scripts que se ejecutan si se ejecuta "turnkey-init".
Modo no interactivo en las construcciones sin cabeza - OpenStack, OpenVZ, OpenNode, Xen: con estos tipos de imagen no se puede asumir acceso interactivo a la consola virtual durante el arranque. La primera bota tiene que ser capaz de correr sin interactividad, de lo contrario nos arriesgamos a colgar la bota mientras espera la interacción del usuario que nunca sucede.
Así que en lugar de interactuar con el usuario el sistema pre-inicializa los ajustes de aplicación con defectos de borrado y establece todas las contraseñas a un valor aleatorio. Si ya se ha establecido una contraseña de raíz (por ejemplo, en un script de pre-desplegamiento) el script preverding sin cabeza no lo sobreescribirá, por lo que su contraseña raíz debe funcionar perfectamente.
La salida del funcionamiento no interactivo de los scripts de primerboot se ha conectado a /var/log/inithooks.log.
La configuración interactiva appliance se retrasa hasta la primera vez que el usuario inicia sesión como root. Esto se logra con la ayuda del gancho /usr/lib/inithooks/firstboot.d/29preseed, que sólo existe en las construcciones sin cabeza:
#!/bin/bash -e # generic preseeding of inithooks.conf if it doesn't exist [ -e $INITHOOKS_CONF ] && exit 0 MASTERPASS=$(mcookie | cut --bytes 1-8) cat>$INITHOOKS_CONF<<EOF export ROOT_PASS=$MASTERPASS export DB_PASS=$MASTERPASS export APP_PASS=$MASTERPASS export APP_EMAIL=admin@example.com export APP_DOMAIN=DEFAULT export HUB_APIKEY=SKIP export SEC_ALERTS=SKIP export SEC_UPDATES=FORCE EOF chmod +x /usr/lib/inithooks/firstboot.d/30turnkey-init-fence
Ancho de iniciación: el gancho preverding sin cabeza anterior también activa el mecanismo de "inicialización vallada" que utiliza iptables para redirigir intentos de acceder al servidor web local a una web estática página servida por inithooks/bin/simplehttpd.py.
Esta página explica que debe iniciar sesión como root primero para terminar la inicialización del sistema. El propósito de la valla se utiliza para evitar que los usuarios accedan a aplicaciones web no inicializadas, que en algunos casos pueden plantear un riesgo de seguridad.
Después de que el usuario inicie sesión como root y complete el proceso de inicialización se apaga la "cerca de inicialización". Los usuarios pueden acceder a aplicaciones que se ejecutan en el servidor web local.
Lo que el primerboot.d/30turnkey-init-fence hace:
permite turnkey-init-fence como un servicio y comienza
servicio está habilitado / deshabilitado mediante actualización-rc.d
activa ~$USERNAME/.profile.d/turnkey-init-fence
el script .profile.d lanza una sesión de parpadeo ligada a un socket
si una sesión ya está ligada a la toma de corriente adjunta a ella
¿Qué comando estamos corriendo en la sesión de separación?
turnkey-init - título desactivar la initfence (servicio y perfil.d)
cadaboot.d scripts
Los scripts que están en el subdirectorio de cada arranque.d funcionan en cada bota. Intentamos minimizar el número de scripts que viven aquí porque son básicamente un guión init de hombre pobre y los scripts de init real son a menudo una mejor idea.
Configurar la contraseña de raíz en un despliegue sin cabeza
En implementaciones sin cabeza el usuario necesita iniciar sesión como root para completar el proceso de inicialización appliance, pero ¿cómo se accede como root?
No es un problema si está usando OpenNode o ProxMox - esos sistemas le incitan a elegir una contraseña de raíz antes de desplegar una imagen TurnKey.
En OpenStack puede iniciar sesión como root con su teclado SSH configurado o recuperar la contraseña de raíz aleatoria del " log del sistema".
Otras soluciones de virtualización / nube privada deben poder utilizar sus scripts de implementación existentes para establecer la contraseña de raíz, como ya lo hacen con Debian y Ubuntu.
Otra opción más avanzada es "preseed" el archivo /etc/inithooks.conf en el sistema de archivos de la apliance antes de arrancarlo por primera vez. Esto le permite aprovechar inithooks para pre-configurar no sólo la contraseña de la raíz, sino también la base de datos y las contraseñas de aplicaciones, correo electrónico de administración, nombre de dominio, etc.
Sin embargo, tenga en cuenta que el uso preverding desactiva la "cerca de la instalación". Si utilizas TurnKey preverding supone que ya has interactuado con el usuario de otra manera (por ejemplo, panel de control web) para obtener los valores de configuración preseedidos.
Preverding
Por defecto, cuando se ejecuta por primera vez un appliance, los scripts de primer arranque le incitarán al usuario de forma interactiva, a través de la consola virtual, a elegir varias contraseñas y Configuración básica de configuración de aplicaciones.
Es posible pasar por alto este proceso de configuración interactivo creando /etc/inithooks.conf en el sistema de archivos appliance y escribiendo variables de configuración inithooks en él antes de la primera bota del sistema. Por ejemplo:
cat>/etc/inithooks.conf<<EOF export ROOT_PASS=supersecretrootpass export DB_PASS=supersecretmysqlpass export APP_EMAIL=admin@example.com export APP_PASS=webappadminpassword export SEC_ALERTS=admin@example.com export SEC_UPDATES=FORCE export HUB_APIKEY=SKIP EOF
No te preocupes por dejar contraseñas sensibles ahí: después de la primera bota, inithooks en blanco /etc/inithooks.conf fuera tan importantes contraseñas no se deja accidentalmente en la clara.
Este mecanismo de preverding hace que sea relativamente fácil integrar TurnKey con paneles de control personalizados, soluciones de virtualización, etc.
Cómo crear exactamente /etc/inithooks.conf depende de usted y de las capacidades de la plataforma de virtualización que está utilizando. Por ejemplo, muchas plataformas de virtualización proporcionan una instalación a través de la cual puede ejecutar scripts o añadir archivos al sistema de archivos antes de la primera bota.
Lista de ganchos de inicialización y parámetros de configuración preverding
A continuación se muestra una lista de ganchos interactivos de primer arranque. Todos los ganchos interactivos tienen opciones de preverding para apoyar el despliegue de la nube, alojamiento e integración ISV.
Tenga en cuenta que casi todos los appliances tienen su propia aplicación ganchos específicos de regeneración secreta.
Común a todo appliances:
30rootpass ROOT_PASS 50auto-apt-archive AUTO_APT_ARCHIVE [ SKIP ] 80tklbam HUB_APIKEY [ SKIP ] 85secalerts SEC_ALERTS [ SKIP ] 92etckeeper ETCKEEPER_COMMIT [ SKIP ] 95secupdates SEC_UPDATES [ SKIP | FORCE ]
Específico para construir sin cabeza:
29preseed INITFENCE [ SKIP ]
appliance específico:
35mysqlpass DB_PASS 35pgsqlpass DB_PASS 40ansible APP_PASS 40couchdb APP_PASS 40espocrm APP_PASS 40etherpad APP_PASS 40githttp APP_PASS 40icesecretset APP_PASS 40jenkins APP_PASS 40mediawiki APP_PASS 40mibew APP_PASS 40mongodb APP_PASS 40moodle APP_PASS 40mumblesupw APP_PASS 40observium APP_PASS 40odoo APP_PASS 40openvas APP_PASS 40orangehrm APP_PASS 40otrs APP_PASS 40phpmumbleadmin APP_PASS 40plone APP_PASS 40sugarcrm APP_PASS 40suitecrm APP_PASS 40torrentserver APP_PASS 40trac APP_PASS 40typo3 APP_PASS 40zoneminder APP_PASS 40nextcloud APP_PASS, APP_DOMAIN 40openldap APP_PASS, APP_DOMAIN 40owncloud APP_PASS, APP_DOMAIN 40zurmo APP_PASS, APP_DOMAIN 40domain-controller APP_PASS, APP_DOMAIN [, APP_REALM] 40b2evolution APP_PASS, APP_EMAIL 40collabtive APP_PASS, APP_EMAIL 40concrete5 APP_PASS, APP_EMAIL 40django APP_PASS, APP_EMAIL 40dokuwiki APP_PASS, APP_EMAIL 40drupal7 APP_PASS, APP_EMAIL 40e107 APP_PASS, APP_EMAIL 40ezplatform APP_PASS, APP_EMAIL 40gallery APP_PASS, APP_EMAIL 40joomla APP_PASS, APP_EMAIL 40kliqqi APP_PASS, APP_EMAIL 40limesurvey APP_PASS, APP_EMAIL 40mahara APP_PASS, APP_EMAIL 40mambo APP_PASS, APP_EMAIL 40mantis APP_PASS, APP_EMAIL 40mattermost APP_PASS, APP_EMAIL 40mayan APP_PASS, APP_EMAIL 40moinmoin APP_PASS, APP_EMAIL 40omeka APP_PASS, APP_EMAIL 40oscommerce APP_PASS, APP_EMAIL 40phpbb APP_PASS, APP_EMAIL 40processmaker APP_PASS, APP_EMAIL 40redmine APP_PASS, APP_EMAIL 40roundup APP_PASS, APP_EMAIL 40silverstripe APP_PASS, APP_EMAIL 40simpleinvoices APP_PASS, APP_EMAIL 40sitracker APP_PASS, APP_EMAIL 40twiki APP_PASS, APP_EMAIL 40ushahidi APP_PASS, APP_EMAIL 40vanilla APP_PASS, APP_EMAIL 40vtiger APP_PASS, APP_EMAIL 40wordpress APP_PASS, APP_EMAIL 40xoops APP_PASS, APP_EMAIL 40canvas APP_PASS, APP_EMAIL, APP_DOMAIN 40drupal8 APP_PASS, APP_EMAIL, APP_DOMAIN 40elgg APP_PASS, APP_EMAIL, APP_DOMAIN 40gitlab APP_PASS, APP_EMAIL, APP_DOMAIN 40gnusocial APP_PASS, APP_EMAIL, APP_DOMAIN 40icescrum APP_PASS, APP_EMAIL, APP_DOMAIN 40phplist APP_PASS, APP_EMAIL, APP_DOMAIN 40piwik APP_PASS, APP_EMAIL, APP_DOMAIN 40prestashop APP_PASS, APP_EMAIL, APP_DOMAIN 40punbb APP_PASS, APP_EMAIL, APP_DOMAIN 40simplemachines APP_PASS, APP_EMAIL, APP_DOMAIN 40zencart APP_PASS, APP_EMAIL, APP_DOMAIN 40magento APP_PASS, APP_EMAIL, APP_DOMAIN [, APP_PRIVKEY, APP_PUBKEY] 40bugzilla APP_PASS, APP_EMAIL [, APP_OUTMAIL] 40foodsoft APP_PASS, APP_EMAIL [, APP_VARIANT] 40ghost APP_PASS, APP_EMAIL, APP_DOMAIN [, APP_UNAME]
Si no está presidido, se le pedirá al usuario de forma interactiva. Las opciones SKIP y FORCE deben ser autoexplicativas. Tenga en cuenta que secupdates se salta automáticamente cuando se encuentra en modo de demostración en vivo.
Notas sobre el desarrollo
Así que estás creando un nuevo appliance y quieres añadir ganchos de inicialización. ¡Increíble! Aquí hay algunos ejemplos para conseguir que vayas.
Inithook no interactivo
El siguiente ejemplo se utiliza en el Joomla15 appliance. Regenera el secreto, y establece una contraseña mysql al azar para el usuario joomla.
/usr/lib/inithooks/firstboot.d/20regen-joomla-secrets
#!/bin/bash -e
# regenerate joomla secret key and mysql password
. /etc/default/inithooks
updateconf() {
CONF=/var/www/joomla/configuration.php
sed -i "s/var $1 = \(.*\)/var $1 = '$2';/" $CONF
}
updateconf '\$secret' $(mcookie)$(mcookie)
PASSWORD=$(mcookie)
updateconf '\$password' $PASSWORD
$INITHOOKS_PATH/bin/mysqlconf.py --user=joomla --pass="$PASSWORD"
Inithook interactivo
El siguiente ejemplo se utiliza para establecer la contraseña raíz en todo appliances. Si ROOTPASS no está establecido, se le pedirá al usuario que introduzca una contraseña de forma interactiva.
/usr/lib/inithooks/firstboot.d/30rootpass #!/bin/bash -e # set root password . /etc/default/inithooks [ -e $INITHOOKS_CONF ] && . $INITHOOKS_CONF $INITHOOKS_PATH/bin/setpasspass.py root --pass="$ROOTPASS"
/usr/lib/inithooks/bin/setpass.py
#!/usr/bin/python
# Copyright (c) 2010 Alon Swartz <alon@turnkeylinux.org>
"""Set account password
Arguments:
username username of account to set password for
Options:
-p --pass= if not provided, will ask interactively
"""
import sys
import getopt
import subprocess
from subprocess import PIPE
from dialog_wrapper import Dialog
def fatal(s):
print >> sys.stderr, "Error:", s
sys.exit(1)
def usage(e=None):
if e:
print >> sys.stderr, "Error:", e
print >> sys.stderr, "Syntax: %s <username> [options]" % sys.argv[0]
print >> sys.stderr, __doc__
sys.exit(1)
def main():
try:
opts, args = getopt.gnu_getopt(sys.argv[1:], "hp:", ['help', 'pass='])
except getopt.GetoptError, e:
usage(e)
if len(args) != 1:
usage()
username = args[0]
password = ""
for opt, val in opts:
if opt in ('-h', '--help'):
usage()
elif opt in ('-p', '--pass'):
password = val
if not password:
d = Dialog('TurnKey GNU/Linux - First boot configuration')
password = d.get_password(
"%s Password" % username.capitalize(),
"Please enter new password for the %s account." % username)
command = ["chpasswd"]
input = ":".join([username, password])
p = subprocess.Popen(command, stdin=PIPE, shell=False)
p.stdin.write(input)
p.stdin.close()
err = p.wait()
if err:
fatal(err)
if __name__ == "__main__":
main()