Documentação
Iniciações - Inicialização, configuração e preseed do sistema
O nosso objectivo é manter esta documentação actualizada, mas Fonte de documentação Inithooks (em GitHub) deve estar sempre atualizado.
Introdução
Antes de expormos um sistema TurnKey a uma Internet hostil, precisamos inicializá-lo. Isso configurará senhas, instalará atualizações de segurança e configurará as configurações das aplicações chave.
Este processo de inicialização pode ser interativo ou não-interativo dependendo do que funciona melhor dado onde e como o sistema é implantado.
Inicialização do sistema interativo
Um assistente de configuração mostra uma sequência curta de diálogos de texto simples que parecem primitivos, mas fornecem um processo passo a passo rápido que funciona em qualquer lugar e requer apenas o desnudo mínimo de dependências de software - uma grande vantagem para aplicações sensíveis à segurança:
Todo o software é potencialmente buggy, mas podemos minimizar o risco, intencionalmente favorecendo a simplicidade sobre doces de olhos extravagantes.
As janelas de configuração são executadas em um de dois lugares:
A consola de arranque na primeira inicialização Em tipos de compilação (por exemplo, ISO, VM, VMDK) onde a máquina real ou virtual normalmente fornece acesso a uma consola de sistema interativa.
O primeiro login da administração sobre tipos de compilação em execução sem cabeça máquinas virtuais (por exemplo, mercado AWS, OpenStack, Xen). que não fornecem a opção de interagir com o sistema no momento do arranque.
Após o arranque, uma cerca virtual redireciona as tentativas de acesso a serviços potencialmente vulneráveis para uma página web explicando como para SSH na máquina pela primeira vez para inicializar o sistema. Após a inicialização a cerca virtual desce e todos os serviços podem ser acessados normalmente.
Inicialização do sistema não-interactivo
A TurnKey Hub simplifica a implantação através de configurações de inicialização do sistema de pré-seeding com valores que o usuário fornece antes de lançar uma instância através do aplicativo web de implantação em nuvem do Hub.
Isto significa que quando o sistema inicia pela primeira vez, ele não precisa interagir com o usuário através de diálogos de texto.
O preseeding está bem documentado e pode ser usado por outros provedores de hospedagem ou nuvens privadas de forma similar para simplificar a implantação.
Sob o capô: tudo o que você queria saber, mas tinha medo de perguntar
Pare! A introdução anterior explicou tudo que meros mortais precisam saber sobre o processo de inicialização do sistema.
O resto da documentação destina-se a:
Os hackers appliance interessados em aprender como o TurnKey funciona sob o capô e desenvolver seus próprios ganchos de configuração.
Usuários especialistas que querem entender como a inicialização do sistema funciona em profundidade.
Prestadores de hospedagem e ninjas fullstack de nuvem privada interessados em implementar uma integração apertada entre TurnKey e painéis de controle personalizados.
Isto não é um requisito, é apenas um bónus. Sem qualquer integração especial, as imagens TurnKey podem ser implantadas como qualquer outra imagem baseada em Debian ou Debian, usando seus scripts de implementações existentes. Se você pode implantar Debian ou Ubuntu, deve ser trivial para implantar TurnKey.
Objetivos de design de pacotes Inithooks
O pacote inithooks executa scripts de inicialização do sistema que:
- Regenerar chaves secretas (por exemplo, SSH, certificado SSL padrão): Isto não é apenas uma boa ideia, é necessário evitar o homem nos ataques do meio.
- Definir senhas (por exemplo, root, base de dados, aplicação)• necessário para evitar o risco de senhas padrão com ligação por fios
- Configurar as configurações básicas do aplicativo (por exemplo, domínio, e-mail de administrador): especialmente útil quando configurar o aplicativo exigiria a busca para baixo o formato de um arquivo de configuração.
Além disso, Inithooks fornece um mecanismo de pré-seeding projetado para tornar mais fácil integrar TurnKey com painéis de controle personalizados fornecidos por várias soluções de virtualização e nuvem prestadores de alojamento.
Como funciona
O Inithooks em si é o mais genérico e o mais simples possível, deixando a maior parte da funcionalidade para os scripts appliance específicos "hook" eles mesmos,
Estes scripts estão localizados em dois sub-diretórios sob /usr/lib/inithooks - everyboot.d e firstboot.d.
Eles são executados em ordem alfanumérica. Isto significa que um script chamado 1- foo seria executado antes de 2- bar, que seria executado em si antes de 3- foobar. É por isso que scripts nestes diretórios têm números engraçados no início.
O script de init de nível superior inithooks é executado no início da inicialização do sistema, no nível de execução 2 15. Isto permite a configuração do sistema antes de a maioria dos serviços começar. Isso deve ser levado em consideração ao desenvolver scripts de gancho.
scripts do 'inicialboot.d'
Os scripts no subdiretório do firstboot.d são executados sob as seguintes condições:
Se o usuário executar o "turnkey-init" de uma shell root. Este comando pode ser usado para repetir o primeiro buot.d inithooks interativamente para reconfigurar o appliance, se necessário. Certos scripts como aqueles que regeneram as teclas secretas são ignorados. Veja a variável BLACKLIST no /usr/sbin/turnkey-init para mais detalhes.
Quando o usuário faz login como root pela primeira vez em um sistema sem cabeça. Isto ativa o "turnkey-init" para executar para que o usuário possa completar interativamente a inicialização do appliance.
Quando um TurnKey appliance botas pela primeira vez
inithooks verifica se esta é ou não a primeira inicialização, verificando o valor da bandeira RUN_FIRSTBOOT no /etc/default/inithooks. Se o valor for falso, ele executa os scripts e alterna a bandeira para true.
Os scripts de primeira inicialização podem ser executados em um dos dois modos, interativos ou não-interativos, dependendo do tipo de compilação.
Modo interativo em compilações sem cabeça - Live CD ISO, VMDK e OVF: Com estes tipos de imagem o acesso interativo ao console virtual durante o boot é esperado para que alguns dos scripts de inicialização inithooks interaja com o usuário via texto dialoga a primeira vez que o sistema inicia (por exemplo, pedir senhas, configurações de aplicativos, etc.). Estes são os mesmos scripts que são executados se você executar "turnkey-init".
Modo não- interativo em compilações sem cabeça - OpenStack, OpenVZ, OpenNode, Xen: com estes tipos de imagem o acesso interativo ao console virtual durante o arranque não pode ser assumido. A primeira inicialização tem que ser capaz de rodar de forma não-interativa, caso contrário, arriscamos pendurar a inicialização enquanto espera pela interação do usuário que nunca acontece.
Assim, em vez de interagir com o usuário, o sistema pré-inicia as configurações de aplicação com padrões de dummy e definir todas as senhas para um valor aleatório. Se uma senha root já foi definida (por exemplo, em um script de pré- implantação) o script de preseeding sem cabeça não irá sobrescrevê-lo, então sua senha root deve funcionar perfeitamente.
A saída da execução não- interactiva dos scripts do primeiro arranque está registada no /var/log/inithooks.log.
A configuração interativa do appliance é adiada até a primeira vez que o usuário faz login como root. Isto é realizado com a ajuda do gancho /usr/lib/inithooks/firstboot.d/29preseed, que só existe em construções sem cabeça:
#!/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
Seca de inicialização: o gancho de preseeding sem cabeça acima também ativa o mecanismo de "inicialização da cerca" que usa iptables para redirecionar tentativas de acessar o servidor web local para uma web estática página servida por inithooks/bin/simplehttpd.py.
Esta página explica que você precisa fazer login como root primeiramente para terminar de inicializar o sistema. O objetivo da cerca é utilizado para impedir que os usuários acessem aplicações web não iniciadas, que em alguns casos podem representar um risco de segurança.
Depois que o usuário loga como root e completa o processo de inicialização a "cela de inicialização" é desligada. Os usuários podem então acessar aplicativos em execução no servidor web local.
O que o firstboot.d/30turnkey-init-fence faz:
habilita o turnkey-init-fence como um serviço e inicia-o
o serviço está habilitado / desativado através de update-rc.d
ativa ~$USERNAME/.profile.d/turnkey-init-fence
o script .profile.d lança uma sessão dtach com ligação a um soquete
se uma sessão já estiver ligada ao 'socket' anexar a ele
que comando estamos a executar na sessão de dtach?
turnkey-init -> desactivar a initfence (serviço e perfil.d)
scripts de todos os boot.d
Scripts que estão no sub-directório everyboot.d rodam em cada inicialização. Tentamos minimizar o número de scripts que vivem aqui porque eles são basicamente um script de init de um homem pobre e scripts de init reais são muitas vezes uma ideia melhor.
Definir a senha raiz numa implantação sem cabeça
Em implantações sem cabeça, o usuário precisa se autenticar como root para concluir o processo de inicialização do appliance, mas como você se autentica como root?
Não é um problema se você estiver usando OpenNode ou ProxMox - esses sistemas pedem que você escolha uma senha raiz antes de implantar uma imagem TurnKey.
No OpenStack você pode fazer login como root com seu keypair SSH configurado ou recuperar a senha root aleatória do "registro do sistema".
Outras soluções de virtualização / nuvem privada devem ser capazes de usar seus scripts de implantação existentes para definir a senha root, assim como já fazem com Debian e Ubuntu.
Outra opção mais avançada é "preseed" o arquivo /etc/inithooks.conf no sistema de arquivos do apliance antes de inicializá-lo pela primeira vez. Isso permite que você use inithooks para pré-configurar não apenas a senha do root, mas também o banco de dados e senhas de aplicativos, e-mail de administrador, nome de domínio, etc.
No entanto, note que usar preseed desativa a "esgrima de initilização". Se você estiver usando o preseed TurnKey assume que você já interagiu com o usuário de alguma outra forma (por exemplo, painel de controle web) para obter os valores de configuração preseed.
Preseeding
Por padrão, quando um appliance é executado pela primeira vez, os scripts de primeira inicialização solicitará ao usuário de forma interativa, através do console virtual, para escolher várias senhas e configurações básicas de configuração de aplicativos.
É possível contornar este processo de configuração interativa criando /etc/inithooks.conf no sistema de arquivos appliance e escrevendo variáveis de configuração inithooks nele antes da primeira inicialização do sistema. Por exemplo:
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
Não se preocupe em deixar senhas sensíveis lá dentro: após a primeira inicialização, inithooks em branco /etc/inithooks.conf para fora, então senhas importantes não são acidentalmente deixadas em claro.
Este mecanismo de pré-seeding torna relativamente fácil integrar TurnKey com painéis de controle personalizados, soluções de virtualização, etc.
Como exatamente você cria o /etc/inithooks.conf depende de você e das capacidades da plataforma de virtualização que você está usando. Por exemplo, muitas plataformas de virtualização fornecem uma facilidade através da qual você pode executar scripts ou adicionar arquivos ao sistema de arquivos antes da primeira inicialização.
Lista de ganchos de inicialização e parâmetros de configuração de preseeding
Abaixo está uma lista de ganchos interativos de primeira inicialização. Todos os ganchos interativos têm opções de preseeding para suportar a implantação na nuvem, hospedagem e integração ISV.
Note que quase todos os appliances têm seus próprios ganchos de regeneração secreta específicos de aplicação.
Frequentes de todos os 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 construções sem cabeça:
29preseed INITFENCE [ SKIP ]
Específico appliance:
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]
Se não for pré- seed, o usuário será perguntado interactivamente. As opções SKIP e FORCE devem ser autoexplicativas. Lembre- se que os secupdates são automaticamente ignorados quando estiverem em modo de demonstração ao vivo.
Notas de desenvolvimento
Então você está criando um novo appliance e quer adicionar ganchos de inicialização. Impressionante! Aqui estão alguns exemplos para fazê-lo ir.
Inithook não-interactivo
O exemplo a seguir é usado no Joomla15 appliance. Regenera o secreto, e define uma senha mysql aleatória para o usuário 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 interativo
O exemplo a seguir é usado para definir a senha raiz em todo o appliances. Se o ROOTPASS não estiver definido, o usuário será solicitado a inserir uma senha interativamente.
/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()