Salvando config / pkg dirs na instalação existente do BSD para reutilização em instalações limpas, e maneiras seguras de fazer isso?

5

Eu realmente não tenho experiência em sistemas anteriores * nix para desenhar, embora eu tentei configurar um Linux baseado em GUI alguns anos atrás; desta vez eu estou saltando diretamente para o BSD porque eu gosto de sua filosofia e atenção firme à qualidade e sua abordagem ligeiramente conservadora resultante para liberar ciclos de desenvolvimento, e porque eu tenho mais experiência com isso do que outros * nix.

Uma área na qual não estou realmente confiante é acompanhar as alterações de configuração que configurei. Tudo config é um caso de "edit /path/rc.things" ou "adicione estas linhas ao pkg-x.conf", ou "configure estas variáveis no ambiente ou pkg". Estou confortável com essas instruções; o que me incomoda é a manutenção e reutilização - como eu acompanho exatamente o que eu mudei enquanto o estava configurando e como eu o uso, e mantendo isso fácil para mim mesmo se eu quiser fazer essas alterações novamente no futuro em outro sistema sem 3 meses de DIFFing todos os arquivos à vista e revendo linha por linha. Espero que, no começo, eu tenha muito disso, porque aprenderei com a experiência.

Meu objetivo é que, se eu quiser configurar um segundo servidor com muito da configuração do sistema / pkg similar ou as mesmas configurações (como é comum em uma única LAN), ou para fazer backup, limpar e reinstalar como parte do meu curva de aprendizado, ou apenas para atualizar o sistema, eu realmente não quero uma lista de arquivos txt que eu mantive, que lista 400 arquivos com configuração fragmentada neles, todos para serem laboriosamente recriados manualmente ou para ter várias linhas editadas no console. Eu também não quero apenas restaurar todos os arquivos sem pensar, ou descobrir que existem arquivos que contêm config ou outras informações de histórico / atividade que eu não conhecia, ou dados ambientais ausentes, e gasto para sempre tentando descobrir onde O material pode estar oculto e precisa ser copiado ou editado no novo sistema.

Não tenho certeza se existe uma solução realmente fácil para isso (em qualquer SO principal) - mesmo com o Windows com uma GUI, teria que considerar arquivos e entradas armazenados em todos os tipos de diretórios, ramificações de registro e em breve. Mas pelo menos eu tenho muitos anos de tentativa e erro com o Windows, então eu tenho uma boa idéia do que pegar, dependendo de como a máquina foi usada e eu posso fazer isso rapidamente, pacote por pacote. Eu sei quais pacotes eu uso, posso apenas restabelecer seu diretório de configuração ou configurações de registro, e o que eu preciso fazer através de sua interface gráfica ou de alguma outra forma, e onde há ajustes de sistema úteis para adicionar.

Eu também sei em quais casos é seguro apenas copiar uma pasta para restabelecer minha configuração ou estado anterior, e em quais casos é melhor não fazer isso, já que outras coisas precisam ser configuradas também, e deixar o sistema / pkg faça o caminho mais longo.

Ainda não tenho esse conhecimento no BSD.

Em uma nota positiva, sinto que tenho conhecimento e experiência suficientes para trabalhar mais ou menos o que preciso fazer, como faço, e ter um senso de segurança e boas práticas suficientes para não causar um desastre completo. disso - ou eu espero fazer assim mesmo. Então, usar o hands-on do BSD é a única maneira real de aprender, neste ponto.

Como posso abordar essa área do uso / gerenciamento do BSD e quais soluções as pessoas que conhecem o BSD tendem a usar?

Em outras palavras, como posso rastrear, simplificar e restabelecer as configurações de uma maneira menos trabalhosa ou demorada (com vistas a restabelecimento seletivo sem dias de edição e correção do arquivo de console!), quando começo a me mover em usar o BSD corretamente, ou que conhecimento ou pkgs ajudarão se for uma questão de fluxo de trabalho e processo?

    
por Stilez 21.03.2017 / 01:50

1 resposta

2

Muito do trabalho pode ser isolado. Existem muitos dos arquivos normalmente editados em / etc, que podem ser espelhados em /usr/local/etc . Coloque suas alterações locais nelas e, geralmente, elas serão coletadas. rc.conf é um pouco confuso, mas você pode colocar uma linha lá para pegar coisas de outro lugar. periodic.conf funciona da mesma maneira.
rc.d arquivos (se houver) podem ir em /usr/local/etc/rc.d , separando-os dos do sistema.

Você não precisa editar syslog.conf ou newsyslog.conf porque pode usar arquivos pequenos em /usr/local/etc/{newsyslog,syslog}.conf.d para fazer o que quiser. Copiar esses diretórios é muito mais fácil do que editar os arquivos únicos originais. Existem vários outros diretórios que terminam em .d, onde você pode colocar pequenos arquivos que são executados como parte do arquivo único original. Cuidado com syslog.conf.d . Você tem que terminar todos os nomes de arquivos com .conf ou eles serão ignorados!

Existem também (por exemplo, em /etc e /boot ) arquivos terminados em .local . Estes incluem /boot/loader.conf.local . Eles não são bem separados dos principais diretórios do sistema, mas o fato de serem nomeados dessa maneira os torna mais fáceis de serem notados e mantidos.

Se você tiver arquivos de configuração do kernel, mantenha-os em (digamos) /root/config . Então, antes de um buildkernel, crie links simbólicos para eles em /sys/i386/conf (ou onde). Caso contrário, uma atualização para /usr/src irá eliminá-los - é mais fácil recriar o link simbólico do que recriar (ou até mesmo restaurar) o arquivo de configuração do kernel.

Lembre-se de que nem todos esses arquivos secundários úteis existem por padrão. É por isso que você precisa consultar as páginas de manual dos arquivos 'principais' para ver quais alternativas estão disponíveis.

Em resumo
Para cada um dos arquivos que você está editando, leia a man page cuidadosamente. Na maioria dos casos, você pode editar ou criar um arquivo local ou colocar arquivos em um diretório local. Isso centraliza quase tudo sob /usr/local/etc .

    
por 09.07.2017 / 01:09