Capítulo 11. Configuração e Ajuste

Esta tradução pode estar desatualizada. Para ajudar com as traduções, acesse a ferramenta de traduções do FreeBSD.

11.1. Sinopse

Um dos aspectos importantes do FreeBSD é a configuração adequada do sistema. Este capítulo explica muito do processo de configuração do FreeBSD, incluindo alguns dos parâmetros que podem ser configurados para ajustar um sistema FreeBSD.

Depois de ler este capítulo, você saberá:

  • O básico da configuração do rc.conf e dos scripts de inicialização /usr/local/etc/rc.d.

  • Como configurar e testar uma placa de rede.

  • Como configurar hosts virtuais em dispositivos de rede.

  • Como usar os vários arquivos de configuração em /etc.

  • Como ajustar o FreeBSD usando variáveis sysctl(8).

  • Como ajustar o desempenho do disco e modificar as limitações do kernel.

Antes de ler este capítulo, você deve:

11.2. Inicialização de Serviços

Muitos usuários instalam software de terceiros no FreeBSD a partir da coleção de Ports e precisam que os serviços instalados sejam iniciados durante a inicialização do sistema. Serviços como mail/postfix ou www/apache22 são apenas dois dos muitos pacotes de software que podem ser iniciados durante a inicialização do sistema. Esta seção explica os procedimentos disponíveis para iniciar o software de terceiros.

No FreeBSD, a maioria dos serviços incluídos, como o cron(8), são iniciados através dos scripts de inicialização do sistema.

11.2.1. Configuração Estendida dos Aplicativos

Agora que o FreeBSD inclui o rc.d, a configuração da inicialização do aplicativo é mais fácil e fornece mais recursos. Usando as palavras-chave discutidas em Gerenciando Serviços no FreeBSD, os aplicativos podem ser configurados para iniciar depois de certos outros serviços e flags extras poderem ser passadas através do /etc/rc.conf no lugar de sinalizadores codificados no script de inicialização. Um script básico pode ser semelhante ao seguinte:

#!/bin/sh
#
# PROVIDE: utility
# REQUIRE: DAEMON
# KEYWORD: shutdown

. /etc/rc.subr

name=utility
rcvar=utility_enable

command="/usr/local/sbin/utility"

load_rc_config $name

#
# DO NOT CHANGE THESE DEFAULT VALUES HERE
# SET THEM IN THE /etc/rc.conf FILE
#
utility_enable=${utility_enable-"NO"}
pidfile=${utility_pidfile-"/var/run/utility.pid"}

run_rc_command "$1"

Este script irá garantir que o utilitário fornecido será iniciado após o pseudo-serviço DAEMON. Ele também fornece um método para definir e rastrear o ID do processo (PID).

Esta aplicação poderia então ter a seguinte linha colocada no /etc/rc.conf:

utility_enable="YES"

Este método permite a manipulação mais fácil de argumentos de linha de comando, inclusão das funções padrões fornecidas em /etc/rc.subr, compatibilidade com o rcorder(8), e fornece uma configuração mais fácil via rc.conf.

11.2.2. Usando o Services para Inicializar Serviços

Outros serviços podem ser iniciados usando o inetd(8). O uso do inetd(8) e sua configuração é descrita em profundidade em O super-servidor inetd.

Em alguns casos, pode fazer mais sentido usar o cron(8) para iniciar os serviços do sistema. Esta abordagem tem várias vantagens, pois o cron(8) executa estes processos como o proprietário do crontab(5). Isto permite que usuários regulares iniciem e mantenham seus próprios aplicativos.

O recurso @reboot do cron(8), pode ser usado no lugar da especificação de hora. Isso faz com que o job seja executado quando cron(8) é iniciado, normalmente durante a inicialização do sistema.

11.3. Configurando o cron(8)

Um dos utilitários mais úteis no FreeBSD é o cron. Este utilitário é executado em segundo plano e verifica regularmente o /etc/crontab para que as tarefas sejam executadas e procura /var/cron/tabs para arquivos crontab personalizados. Estes arquivos são usados para planejar tarefas que o cron executa nos horários especificados. Cada entrada em um crontab define uma tarefa para ser executada e é conhecida como uma tarefa do cron.

Dois tipos diferentes de arquivos de configuração são usados: o crontab do sistema, que não deve ser modificado, e crontabs de usuário, que podem ser criados e editados conforme necessário. O formato usado por esses arquivos está documentado em crontab(5). O formato do sistema crontab, /etc/crontab inclui uma coluna who que não existe nos crontabs de usuário. No crontab do sistema , o cron executa o comando como o usuário especificado nesta coluna. Em um crontab de usuário, todos os comandos são executados como o usuário que criou o crontab.

Os crontabs de usuário permitem que usuários individuais programem suas próprias tarefas. O usuário root também pode ter um crontab de usuário que pode ser usado para agendar tarefas que não existem no crontab do sistema .

Aqui está uma entrada de amostra do crontab do sistema, /etc/crontab:

# /etc/crontab - root's crontab for FreeBSD
#
# $FreeBSD: head/pt_BR.ISO8859-1/books/handbook/book.xml 53984 2020-03-15 16:03:31Z dbaio $
#(1)
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin (2)
#
#minute	hour	mday	month	wday	who	command (3)
#
*/5	*	*	*	*	root	/usr/libexec/atrun (4)
1Linhas que começam com o caractere # são comentários. Um comentário pode ser colocado no arquivo como um lembrete do que uma ação faz e do porque a sua execução é desejada. Comentários não podem estar na mesma linha que um comando ou então serão interpretados como parte do comando; eles devem estar em uma nova linha. Linhas em branco são ignoradas.
2O caractere igual (=) é usado para definir qualquer configuração de ambiente. Neste exemplo, ele é usado para definir o SHELL e o PATH. Se o SHELL for omitido, o cron usará o shell Bourne padrão. Se o PATH for omitido, o caminho completo deverá ser fornecido ao comando ou script a ser executado.
3Esta linha define os sete campos usados em um crontab do sistema: minute, hora, mday, month, wday, who e command. O campo minute é o tempo em minutos quando o comando especificado será executado, a hour é a hora em que o comando especificado será executado, o mday é o dia do mês, month é o mês e wday é o dia da semana. Estes campos devem ser valores numéricos, representando o relógio de vinte e quatro horas, ou um *, representando todos os valores desse campo. O campo who existe somente no crontab do sistema e especifica com qual usuário o comando deve ser executado. O último campo é o comando a ser executado.
4Esta entrada define os valores para este trabalho do cron. O /5, seguido por vários outros caracteres , especifica que /usr/libexec/atrun é invocado pelo root a cada cinco minutos de cada hora, de cada dia e dia da semana, de cada mês.Comandos podem incluir qualquer número de opções. No entanto, os comandos que se estendem a várias linhas precisam ser quebrados com o caractere de continuação da barra invertida "\".

11.3.1. Criando um Crontab de Usuário

Para criar um crontab de usuário, invoque o crontab no modo editor:

% crontab -e

Isto irá abrir o crontab do usuário usando o editor de texto padrão. A primeira vez que um usuário executa este comando, ele abre um arquivo vazio. Depois que um usuário cria um crontab, esse comando abrirá este arquivo para edição.

É útil adicionar estas linhas a parte superior do arquivo crontab para configurar as variáveis de ambiente e lembrar os significados dos campos no crontab:

SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
# Order of crontab fields
# minute	hour	mday	month	wday	command

Em seguida, adicione uma linha para cada comando ou script a ser executado, especificando o horário para executar o comando. Este exemplo executa o script de shell Bourne personalizado especificado todos os dias às duas da tarde. Como o caminho para o script não está especificado em PATH, o caminho completo para o script é fornecido:

0	14	*	*	*	/usr/home/dru/bin/mycustomscript.sh

Antes de usar um script personalizado, verifique se ele é executável e teste-o com o conjunto limitado de variáveis de ambiente definidas pelo cron. Para replicar o ambiente que seria usado para executar a entrada do cron acima, use:

env -i SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin HOME=/home/dru LOGNAME=dru /usr/home/dru/bin/mycustomscript.sh

O ambiente definido pelo cron é discutido em crontab(5). Verificar se os scripts operam corretamente em um ambiente cron é especialmente importante se incluírem quaisquer comandos que excluam arquivos usando curingas.

Quando terminar de editar o crontab, salve o arquivo. Ele será instalado automaticamente e o cron lerá o crontab e executará seus cron jobs nos horários especificados. Para listar as tarefas agendadas em um crontab, use este comando:

% crontab -l
0	14	*	*	*	/usr/home/dru/bin/mycustomscript.sh

Para remover todas as tarefas cron em um crontab de usuário:

% crontab -r
remove crontab for dru? y

11.4. Gerenciando Serviços no FreeBSD

O FreeBSD usa o sistema rc(8) de scripts de inicialização durante a inicialização do sistema e para gerenciar serviços. Os scripts listados em /etc/rc.d fornecem serviços básicos que podem ser controlados com start, stop e restart opções para service(8). Por exemplo, sshd(8) pode ser reiniciado com o seguinte comando:

# service sshd restart

Este procedimento pode ser usado para iniciar serviços em um sistema em execução. Os serviços serão iniciados automaticamente no momento da inicialização, conforme especificado em rc.conf(5). Por exemplo, para ativar o natd(8) na inicialização do sistema, adicione a seguinte linha ao /etc/rc.conf:

natd_enable="YES"

Se uma linha natd_enable="NO" já estiver presente, altere o NO para YES. Os scripts rc(8) carregarão automaticamente todos os serviços dependentes durante a próxima inicialização, conforme descrito abaixo.

Como o sistema rc(8) é destinado principalmente a iniciar e parar serviços na inicialização do sistema e no tempo de desligamento, o start, as opções stop e restart somente executarão suas ações se a variável apropriada estiver configurada no /etc/rc.conf. Por exemplo, o sshd restart só funcionará se sshd_enable estiver definido como YES em /etc/rc.conf. Para iniciar, parar ou reiniciar um serviço independente das configurações em /etc/rc.conf, estes comandos deve ser prefixado com "one". Por exemplo, para reiniciar sshd(8) independentemente da configuração atual do /etc/rc.conf, execute o seguinte comando:

# service sshd onerestart

Para verificar se um serviço está habilitado em /etc/rc.conf, execute o script apropriado rc(8) com rcvar. Este exemplo verifica se o sshd(8) está habilitado no /etc/rc.conf:

# service sshd rcvar
# sshd
#
sshd_enable="YES"
#   (default: "")

A linha # sshd é gerada pelo comando acima, não pelo console do root.

Para determinar se um serviço está ou não em execução, use status. Por exemplo, para verificar se o sshd(8) está em execução:

# service sshd status
sshd is running as pid 433.

Em alguns casos, também é possível fazer o reload denum serviço. Isso tenta enviar um sinal para um serviço individual, forçando o serviço a recarregar seus arquivos de configuração. Na maioria dos casos, isso significa enviar ao serviço um sinal SIGHUP. O suporte para esse recurso não está incluído para todos os serviços.

O sistema rc(8) é usado para serviços de rede e também contribui para a maior parte da inicialização do sistema. Por exemplo, quando o script /etc/rc.d/bgfsck é executado, ele imprime a seguinte mensagem:

Starting background file system checks in 60 seconds.

Esse script é usado para verificações do sistema de arquivos em segundo plano, que ocorrem apenas durante a inicialização do sistema.

Muitos serviços do sistema dependem de outros serviços para funcionar corretamente. Por exemplo, o yp(8) e outros serviços baseados em RPC podem falhar ao iniciar até que o rpcbind(8) seja iniciado. Para resolver esse problema, informações sobre dependências e outros meta-dados são incluídas nos comentários na parte superior de cada script de inicialização. O programa rcorder(8) é usado para analisar esses comentários durante a inicialização do sistema para determinar a ordem na qual os serviços do sistema devem ser invocados para satisfazer as dependências.

A seguinte palavra-chave deve ser incluída em todos os scripts de inicialização, conforme exigido pelo rc.subr(8) para "habilitar" o script de inicialização:

  • PROVIDE: Especifica os serviços que este arquivo fornece.

As seguintes palavras-chave podem ser incluídas na parte superior de cada script de inicialização. Eles não são estritamente necessárias, mas são úteis como sugestões para rcorder(8):

  • REQUIRE: lista os serviços necessários para este serviço. O script que contém esta palavra chave será executado após os serviços especificados.

  • BEFORE: lista os serviços que dependem deste serviço. O script que contém esta palavra chave será executado antes dos serviços especificados.

Ao definir cuidadosamente essas palavras-chave para cada script de inicialização, um administrador passa a ter um nível refinado de controle da ordem de inicialização dos scripts, sem a necessidade dos "runlevels" usados por alguns sistemas operacionais UNIX™.

Informações adicionais podem ser encontradas em rc(8) e rc.subr(8). Consulte este artigo para obter instruções sobre como criar um script rc(8) personalizado.

11.4.1. Gerenciando a configuração específica do sistema

A localização principal das informações de configuração do sistema é arquivo /etc/rc.conf. Este arquivo contém uma ampla gama de informações de configuração e é lido na inicialização do sistema para configurar o sistema. Ele fornece as informações de configuração para os arquivos rc*.

As entradas em /etc/rc.conf substituem as configurações padrões em /etc/defaults/rc.conf. O arquivo contendo as configurações padrões não deve ser editado. Ao invés disso, todas as alterações específicas do sistema devem ser feitas em /etc/rc.conf.

Várias estratégias podem ser aplicadas em aplicativos em cluster para separar as configurações que afetam todo o site da configuração específica do sistema para reduzir a sobrecarga de administração. A abordagem recomendada é colocar a configuração específica do sistema em /etc/rc.conf.local. Por exemplo, estas entradas em /etc/rc.conf aplicam-se a todos os sistemas:

sshd_enable="YES"
keyrate="fast"
defaultrouter="10.1.1.254"

Considerando que estas entradas em /etc/rc.conf.local se aplicam somente a este sistema:

hostname="node1.example.org"
ifconfig_fxp0="inet 10.1.1.1/8"

Distribua o /etc/rc.conf para cada sistema usando um aplicativo como o rsync ou o puppet, enquanto o /etc/rc.conf.local permanece único.

A atualização do sistema não sobrescreverá o /etc/rc.conf, portanto as informações de configuração do sistema não serão perdidas.

Ambos /etc/rc.conf e /etc/rc.conf.local são analisados pelo sh(1). Isto permite que os operadores do sistema criem cenários de configuração complexos. Consulte rc.conf(5) para obter mais informações sobre este tópico.

11.5. Configurando Placas de Interface de Rede

Adicionar e configurar uma placa de interface de rede (NIC) é uma tarefa comum para qualquer administrador do FreeBSD.

11.5.1. Localizando o Driver Correto

Primeiro, determine o modelo da NIC e o chip utilizado. O FreeBSD suporta uma ampla variedade de NICs. Verifique a lista de compatibilidade de hardware para a release do FreeBSD para ver se a NIC é suportada.

Se a NIC é suportada, determine o nome do driver do FreeBSD para a NIC. Consulte /usr/src/sys/conf/NOTES e /usr/src/sys/arch/conf/NOTES para a lista de Drivers NIC com algumas informações sobre os chipsets suportados. Em caso de dúvida, leia a página de manual do driver, pois ele fornecerá mais informações sobre o hardware suportado e quaisquer limitações conhecidas do driver.

Os drivers para as NICs comuns já estão presentes no kernel GENERIC, o que significa que a NIC deve ser verificada durante a inicialização. As mensagens de inicialização do sistema podem ser visualizadas digitando more /var/run/dmesg.boot e usando a barra de espaço para percorrer o texto. Neste exemplo, duas NICs Ethernet que utilizam o driver dc(4) estão presentes no sistema:

dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xd3800000-0xd38
000ff irq 15 at device 11.0 on pci0
miibus0: <MII bus> on dc0
bmtphy0: <BCM5201 10/100baseTX PHY> PHY 1 on miibus0
bmtphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc0: Ethernet address: 00:a0:cc:da:da:da
dc0: [ITHREAD]
dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30
000ff irq 11 at device 12.0 on pci0
miibus1: <MII bus> on dc1
bmtphy1: <BCM5201 10/100baseTX PHY> PHY 1 on miibus1
bmtphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc1: Ethernet address: 00:a0:cc:da:da:db
dc1: [ITHREAD]

Se o driver da NIC não estiver presente em GENERIC, mas houver um driver disponível, o driver precisará ser carregado antes que a NIC possa ser configurada e usada. Isso pode ser feito de duas maneiras:

  • A maneira mais fácil é carregar um módulo do kernel para a NIC usando o kldload(8). Para carregar automaticamente o driver no momento da inicialização, adicione a linha apropriada ao /boot/loader.conf. Nem todos os drivers NIC estão disponíveis como módulos.

  • Como alternativa, compile estaticamente o suporte para a NIC em um kernel personalizado. Consulte /usr/src/sys/conf/NOTES, /usr/src/sys/arch/conf/NOTES e a página de manual do driver para determinar qual linha adicionar ao arquivo de configuração do kernel personalizado. Para mais informações sobre como recompilar o kernel, consulte Configurando o kernel do FreeBSD. Se a NIC foi detectada na inicialização, o kernel não precisa ser recompilado.

11.5.1.1. Utilizando os Drivers Windows™NDIS

Infelizmente, ainda existem muitos fornecedores que não fornecem esquemas para seus drivers para a comunidade de código aberto porque consideram essas informações como segredos comerciais. Consequentemente, os desenvolvedores do FreeBSD e de outros sistemas operacionais são deixados com duas opções: desenvolver os drivers por um processo longo e complexo de engenharia reversa ou usar os binários de drivers existentes disponíveis para plataforma Microsoft™ Windows™.

O FreeBSD fornece suporte "nativo" para a especificação de interface de driver de rede (NDIS). Ele inclui o ndisgen(8) que pode ser utilizado para converter um driver Windows™ XP num formato que pode ser usado no FreeBSD. Como o driver ndis(4) usa um binário Windows™ XP, ele só é executado em sistemas i386™ e amd64. Dispositivos PCI, CardBus, PCMCIA e USB são suportados.

Para usar o ndisgen(8), três coisas são necessárias:

  1. Código-fonte do kernel do FreeBSD.

  2. Um binário do driver do Windows™ XP com uma extensão .SYS.

  3. Um arquivo de configuração do driver do Windows™ XP com uma extensão .INF.

Faça o download dos arquivos .SYS e .INF para a NIC específica. Geralmente, eles podem ser encontrados no CD do driver ou no site do fornecedor. Os exemplos a seguir usam o W32DRIVER.SYS e o W32DRIVER.INF.

A largura do bit do driver deve corresponder à versão do FreeBSD. Para FreeBSD/i386, use um driver de 32 bits Windows™. Para o FreeBSD/amd64, é necessário um driver de 64 bits do Windows™.

O próximo passo é compilar o binário do driver em um módulo do kernel carregável. Como root, use ndisgen(8):

# ndisgen /path/to/W32DRIVER.INF /path/to/W32DRIVER.SYS

Este comando é interativo e solicita qualquer informação extra necessária. Um novo módulo do kernel será gerado no diretório atual. Use kldload(8) para carregar o novo módulo:

# kldload ./W32DRIVER_SYS.ko

Além do módulo do kernel gerado, os módulos ndis.ko e if_ndis.ko devem ser carregados. Isso deve acontecer automaticamente quando qualquer módulo que dependa do ndis(4) for carregado. Caso contrário, carregue-os manualmente, usando os seguintes comandos:

# kldload ndis
# kldload if_ndis

O primeiro comando carrega o wrapper do driver da miniporta ndis(4) e o segundo carrega o driver NIC gerado.

Execute o comando dmesg(8) para ver se houve algum erro de carregamento. Se tudo correu bem, a saída deve ser semelhante à seguinte:

ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1
ndis0: NDIS API version: 5.0
ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5
ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps

A partir daqui, o ndis0 pode ser configurado como qualquer outra NIC.

Para configurar o sistema para carregar os módulos ndis(4) no momento da inicialização, copie o módulo gerado, W32DRIVER_SYS.ko, para /boot/modules. Em seguida, adicione a seguinte linha ao /boot/loader.conf:

W32DRIVER_SYS_load="YES"

11.5.2. Configurando a placa de rede

Quando o driver correto é carregado para a NIC, a placa precisa ser configurada. Ele pode ter sido configurado no momento da instalação por bsdinstall(8).

Para exibir a configuração da NIC, digite o seguinte comando:

% ifconfig
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80008<VLAN_MTU,LINKSTATE>
        ether 00:a0:cc:da:da:da
        inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
dc1: flags=8802<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80008<VLAN_MTU,LINKSTATE>
        ether 00:a0:cc:da:da:db
        inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
        media: Ethernet 10baseT/UTP
        status: no carrier
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

Neste exemplo, os seguintes dispositivos foram exibidos:

  • dc0: A primeira interface Ethernet.

  • dc1: A segunda interface Ethernet.

  • lo0: o dispositivo de loopback.

O FreeBSD usa o nome do driver seguido da ordem em que a placa é detectada na inicialização para nomear a NIC. Por exemplo, sis2 é a terceira NIC no sistema usando driver sis(4).

Neste exemplo, o dc0 está ativo e em execução. Os principais indicadores são:

  1. UP significa que a placa está configurada e pronta.

  2. A placa tem um endereço da Internet (inet), 192.168.1.3.

  3. Ela tem uma máscara de sub-rede válida (netmask), onde 0xffffff00 é o mesmo que 255.255.255.0 .

  4. Tem um endereço de broadcast válido, 192.168.1.255.

  5. O endereço MAC da placa (ether) é 00:a0:cc:da:da:da.

  6. A seleção de mídia física está no modo de seleção automática (media:Ethernet autoselect (100baseTX <full-duplex>)). Neste exemplo, o dc1 está configurado para ser executado com a mídia 10baseT/UTP. Para obter mais informações sobre tipos de mídia disponíveis para um driver, consulte sua página de manual.

  7. O status do link (status) é active, indicando que o sinal da portadora foi detectado. Para dc1, o status status: no carrier é normal quando um cabo Ethernet não está conectado à placa.

Se a saída ifconfig(8) tivesse mostrado algo semelhante a:

dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=80008<VLAN_MTU,LINKSTATE>
	ether 00:a0:cc:da:da:da
	media: Ethernet autoselect (100baseTX <full-duplex>)
	status: active

isso indicaria que a placa não foi configurada.

A placa deve ser configurada como root. A configuração da NIC pode ser realizada a partir da linha de comando com o ifconfig(8), mas não persistirá após uma reinicialização, a menos que a configuração também seja adicionada ao /etc/rc.conf. Se um servidor DHCP estiver presente na LAN, basta adicionar esta linha:

ifconfig_dc0="DHCP"

Substitua dc0 com o valor correto para o sistema.

A linha adicionada, então, segue as instruções dadas em Teste e solução de problemas.

Se a rede foi configurada durante a instalação, algumas entradas para a NIC podem já estar presentes. Verifique novamente o /etc/rc.conf antes de adicionar novas linhas.

Se não existir um servidor DHCP, a NIC deve ser configurada manualmente. Adicione uma linha para cada NIC presente no sistema, conforme mostrado neste exemplo:

ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0"
ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP"

Substitua dc0 e dc1 e as informações de endereço IP com os valores corretos para o sistema. Consulte a man page do driver, ifconfig(8) e rc.conf(5) para maiores detalhes sobre as opções permitidas e a sintaxe de /etc/rc.conf.

Se a rede não estiver usando DNS, edite o /etc/hosts para adicionar os nomes e endereços IP dos hosts na LAN, se eles ainda não estiverem lá. Para maiores informações, consulte hosts(5) e /usr/shared/examples/etc/hosts.

Se não houver um servidor DHCP e o acesso à Internet for necessário, configure manualmente o gateway padrão e o nameserver:

# echo 'defaultrouter="your_default_router"' >> /etc/rc.conf
# echo 'nameserver your_DNS_server' >> /etc/resolv.conf

11.5.3. Teste e solução de problemas

Uma vez que as alterações necessárias no /etc/rc.conf sejam salvas, uma reinicialização pode ser usada para testar a configuração de rede e verificar se o sistema é reiniciado sem nenhum erro. Como alternativa, aplique as configurações ao sistema de rede com este comando:

# service netif restart

Se um gateway padrão foi configurado no /etc/rc.conf, também execute este comando:

# service routing restart

Uma vez que o sistema de rede tiver sido reiniciado, teste as NIC.

11.5.3.1. Testando uma placa Ethernet

Para verificar se uma placa Ethernet está configurada corretamente, execute um ping(8) na própria interface e, em seguida, ping(8) outra máquina na LAN:

% ping -c5 192.168.1.3
PING 192.168.1.3 (192.168.1.3): 56 data bytes
64 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=0.082 ms
64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.074 ms
64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.076 ms
64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.108 ms
64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.076 ms

--- 192.168.1.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.074/0.083/0.108/0.013 ms
% ping -c5 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.726 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.766 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.700 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.747 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.704 ms

--- 192.168.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms

Para testar a resolução da rede, use o nome do host em vez do endereço IP. Se não houver nenhum servidor DNS na rede, o /etc/hosts deve ser configurado primeiro. Para este propósito, edite o /etc/hosts para adicionar os nomes e os endereços IP dos hosts na LAN, se eles ainda não estiverem lá . Para maiores informações, consulte hosts(5) e /usr/shared/examples/etc/hosts.

11.5.3.2. Solução de problemas

Ao solucionar problemas de configurações de hardware e software, verifique primeiro as coisas simples. O cabo de rede está conectado? Os serviços de rede estão configurados corretamente? O firewall está configurado corretamente? A NIC é suportada pelo FreeBSD? Antes de enviar um relatório de bug, sempre verifique as Notas de Hardware, atualize a versão do FreeBSD para a versão mais recente do STABLE, verifique os arquivos da lista de discussão e pesquise na Internet.

Se a placa funcionar, mas o desempenho for ruim, leia tuning(7). Além disso, verifique a configuração da rede, pois configurações de rede incorretas podem causar conexões lentas.

Alguns usuários experimentam uma ou duas mensagens de device timeout, o que é normal para algumas placas. Se eles continuarem ou forem incômodos, verifique se o dispositivo está em conflito com outro. Verifique novamente as conexões dos cabos. Considere tentar outra placa.

Para resolver erros de watchdog timeout, primeiro verifique o cabo de rede. Muitas placas requerem um slot PCI que suporte a masterização de barramento. Em algumas placas-mãe antigas, apenas um slot PCI permite, normalmente o slot 0. Verifique a NIC e a documentação da placa-mãe para determinar se esse pode ser o problema.

As mensagens No route to host ocorrem se o sistema não puder rotear um pacote para o host de destino. Isso pode acontecer se nenhuma rota padrão for especificada ou se um cabo for desconectado. Verifique a saída do netstat -rn e certifique-se de que haja uma rota válida para o host. Se não houver, leia Gateways e Rotas.

As mensagens de erro ping: sendto: Permission denied são geralmente causadas por um firewall mal configurado. Se um firewall está habilitado no FreeBSD, mas nenhuma regra foi definida, a política padrão é negar todo o tráfego, mesmo o ping(8). Consulte Firewalls para maiores informações.

Às vezes, o desempenho da placa é ruim ou abaixo da média. Nesses casos, tente configurar o modo de seleção de mídia de autoselect para a seleção de mídia correta. Embora isso funcione para a maioria dos hardwares, isso pode ou não resolver o problema. Novamente, verifique todas as configurações de rede e consulte tuning(7).

11.6. Hosts Virtuais

Um uso comum do FreeBSD é a hospedagem de sites virtuais, onde um servidor aparece na rede como muitos servidores. Isso é conseguido atribuindo vários endereços de rede a uma única interface.

Uma determinada interface de rede tem um endereço "real" e pode ter qualquer número de endereços "alias". Esses aliases são normalmente adicionados colocando entradas de alias no /etc/rc.conf, como mostrado neste exemplo:

ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx"

As entradas de alias devem começar com alias_0_ usando um número sequencial como alias0, alias1 e assim por diante. O processo de configuração será interrompido no primeiro número ausente.

O cálculo de máscaras de alias é importante. Para uma determinada interface, deve haver um endereço que represente corretamente a máscara de rede da rede. Qualquer outro endereço dentro dessa rede deve ter uma máscara de rede toda de 1s, expressa como 255.255.255.255 ou 0xffffffff.

Por exemplo, considere o caso em que a interface fxp0 está conectada a duas redes: 10.1.1.0 com uma máscara de rede de 255.255.255.0 e 202.0.75.16 com uma máscara de rede de 255.255.255.240. O sistema deve ser configurado para aparecer nos intervalos 10.1.1.1 até 10.1.1.5 e 202.0.75.17 até 202.0.75.20. Somente o primeiro endereço em um determinado intervalo de rede deve ter uma máscara de rede real. Todo o resto de (10.1.1.2 até 10.1.1.5 e de 202.0.75.18 até 202.0.75.20) deve ser configurado com uma máscara de rede 255.255.255.255.

As seguintes entradas /etc/rc.conf configuram o adaptador corretamente para este cenário:

ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0"
ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255"
ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255"
ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255"
ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255"
ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240"
ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255"
ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255"
ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255"

Uma maneira mais simples de expressar isso é com uma lista separada por espaço de intervalos de endereços IP. O primeiro endereço receberá a máscara de sub-rede indicada e os endereços adicionais terão uma máscara de sub-rede 255.255.255.255.

ifconfig_fxp0_aliases="inet 10.1.1.1-5/24 inet 202.0.75.17-20/28"

11.7. Configurando o log do sistema

Gerar e ler logs do sistema é um aspecto importante da administração do sistema. As informações nos registros do sistema podem ser usadas para detectar problemas de hardware e software, bem como erros de configuração dos aplicativos e do sistema. Essas informações também desempenham um papel importante na auditoria de segurança e na resposta a incidentes. A maioria dos daemons e aplicativos do sistema geram entradas de log.

O FreeBSD fornece um registrador de sistema, o syslogd, para gerenciar o registro. Por padrão, o syslogd é iniciado quando o sistema é inicializado. Isto é controlado pela variável syslogd_enable no /etc/rc.conf. Existem vários argumentos de aplicação que podem ser definidos usando syslogd_flags no /etc/rc.conf. Consulte syslogd(8) para obter maiores informações sobre os argumentos disponíveis.

Esta seção descreve como configurar o criador de logs do sistema FreeBSD para log local e remoto e como executar a rotação de log e o gerenciamento de log.

11.7.1. Configurando os logs locais

O arquivo de configuração, /etc/syslog.conf, controla o que o syslogd faz com as entradas de log à medida que são recebidas. Existem vários parâmetros para controlar o tratamento de eventos recebidos. O facility descreve qual subsistema gerou a mensagem, como o kernel ou um daemon, e o level descreve a gravidade do evento que ocorreu. Isso possibilita configurar onde uma mensagem de log é registrada, dependendo da instalação e do nível. Também é possível executar uma ação dependendo do aplicativo que enviou a mensagem e, no caso de log remoto, o nome do host da máquina que gera o evento de log.

Este arquivo de configuração contém uma linha por ação, em que a sintaxe de cada linha é um campo seletor seguido por um campo de ação. A sintaxe do campo seletor é facility.level, que corresponderá às mensagens de log de facility no nível level ou superior. Também é possível adicionar um sinalizador de comparação opcional antes do nível para especificar mais precisamente o que está registrado. Vários campos seletores podem ser usados para a mesma ação e são separados por um ponto-e-vírgula (;). Usar * irá corresponder a tudo. O campo de ação indica para onde enviar a mensagem de log, como para um arquivo ou host de log remoto. Por exemplo, aqui está o syslog.conf padrão do FreeBSD:

# $FreeBSD: head/pt_BR.ISO8859-1/books/handbook/book.xml 53984 2020-03-15 16:03:31Z dbaio $
#
#       Spaces ARE valid field separators in this file. However,
#       other *nix-like systems still insist on using tabs as field
#       separators. If you are sharing this file between systems, you
#       may want to use only tabs as field separators here.
#       Consult the syslog.conf(5) manpage.
*.err;kern.warning;auth.notice;mail.crit                /dev/console
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err   /var/log/messages
security.*                                      /var/log/security
auth.info;authpriv.info                         /var/log/auth.log
mail.info                                       /var/log/maillog
lpr.info                                        /var/log/lpd-errs
ftp.info                                        /var/log/xferlog
cron.*                                          /var/log/cron
!-devd
*.=debug                                        /var/log/debug.log
*.emerg                                         *
# uncomment this to log all writes to /dev/console to /var/log/console.log
#console.info                                   /var/log/console.log
# uncomment this to enable logging of all log messages to /var/log/all.log
# touch /var/log/all.log and chmod it to mode 600 before it will work
#*.*                                            /var/log/all.log
# uncomment this to enable logging to a remote loghost named loghost
#*.*                                            @loghost
# uncomment these if you're running inn
# news.crit                                     /var/log/news/news.crit
# news.err                                      /var/log/news/news.err
# news.notice                                   /var/log/news/news.notice
# Uncomment this if you wish to see messages produced by devd
# !devd
# *.>=info
!ppp
*.*                                             /var/log/ppp.log
!*

Neste exemplo:

  • A linha 8 combina todas as mensagens com um nível de err ou superior, bem como kern.warning, auth.notice e mail.crit, e envia essas mensagens de log para o console (/dev/console).

  • A linha 12 combina todas as mensagens do recurso mail no nível info ou acima e registra as mensagens em /var/log/maillog.

  • A linha 17 usa um sinalizador de comparação (=) para corresponder apenas as mensagens no nível debug e registrá-las em /var/log/debug.log.

  • A linha 33 é um exemplo de uso de uma especificação de programa. Isso faz com que as regras que a seguem apenas sejam válidas para o programa especificado. Neste caso, somente as mensagens geradas pelo ppp são registradas em /var/log/ppp.log.

Os níveis disponíveis, na ordem dos mais para o menos críticos, são emerg, alert, crit, err, warning, notice, info, and debug.

As facilities, em nenhuma ordem particular, são auth, authpriv, console, cron, daemon, ftp, kern, lpr, mail, mark, news, security, syslog, user, uucp, and local0 through local7. Esteja ciente de que outros sistemas operacionais podem ter recursos diferentes.

Para registrar tudo do nível notice e superior para /var/log/daemon.log, adicione a seguinte entrada:

daemon.notice                                        /var/log/daemon.log

Para obter mais informações sobre os diferentes níveis e facilities, consulte syslog(3) e syslogd(8). Para maiores informações sobre /etc/syslog.conf, sua sintaxe e exemplos de uso mais avançados, veja syslog.conf(5).

11.7.2. Gerenciamento de log e rotação

Os arquivos de log podem crescer rapidamente, ocupando espaço em disco e dificultando a localização de informações úteis. O gerenciamento de log tenta atenuar isso. No FreeBSD, o newsyslog é usado para gerenciar arquivos de log. Este programa interno rotaciona e comprime periodicamente arquivos de log e, opcionalmente, cria arquivos de log ausentes e sinaliza os programas quando os arquivos de log são movidos. Os arquivos de log podem ser gerados pelo syslogd ou por qualquer outro programa que gere arquivos de log. Enquanto o newsyslog é normalmente executado a partir do cron(8), ele não é um daemon do sistema. Na configuração padrão, ele é executado a cada hora.

Para saber quais ações executar, o newsyslog lê seu arquivo de configuração, /etc/newsyslog.conf. Este arquivo contém uma linha para cada arquivo de log que o newsyslog gerencia. Cada linha indica o proprietário do arquivo, suas permissões, quando rotacionar esse arquivo, flags opcionais que afetam a rotação do log, como compactação, e programas para sinalizar quando o log é rotacionado. Aqui está a configuração padrão no FreeBSD:

# configuration file for newsyslog
# $FreeBSD: head/pt_BR.ISO8859-1/books/handbook/book.xml 53984 2020-03-15 16:03:31Z dbaio $
#
# Entries which do not specify the '/pid_file' field will cause the
# syslogd process to be signalled when that log file is rotated.  This
# action is only appropriate for log files which are written to by the
# syslogd process (ie, files listed in /etc/syslog.conf).  If there
# is no process which needs to be signalled when a given log file is
# rotated, then the entry for that file should include the 'N' flag.
#
# The 'flags' field is one or more of the letters: BCDGJNUXZ or a '-'.
#
# Note: some sites will want to select more restrictive protections than the
# defaults.  In particular, it may be desirable to switch many of the 644
# entries to 640 or 600.  For example, some sites will consider the
# contents of maillog, messages, and lpd-errs to be confidential.  In the
# future, these defaults may change to more conservative ones.
#
# logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
/var/log/all.log                        600  7     *    @T00  J
/var/log/amd.log                        644  7     100  *     J
/var/log/auth.log                       600  7     100  @0101T JC
/var/log/console.log                    600  5     100  *     J
/var/log/cron                           600  3     100  *     JC
/var/log/daily.log                      640  7     *    @T00  JN
/var/log/debug.log                      600  7     100  *     JC
/var/log/kerberos.log                   600  7     100  *     J
/var/log/lpd-errs                       644  7     100  *     JC
/var/log/maillog                        640  7     *    @T00  JC
/var/log/messages                       644  5     100  @0101T JC
/var/log/monthly.log                    640  12    *    $M1D0 JN
/var/log/pflog                          600  3     100  *     JB    /var/run/pflogd.pid
/var/log/ppp.log        root:network    640  3     100  *     JC
/var/log/devd.log                       644  3     100  *     JC
/var/log/security                       600  10    100  *     JC
/var/log/sendmail.st                    640  10    *    168   B
/var/log/utx.log                        644  3     *    @01T05 B
/var/log/weekly.log                     640  5     1    $W6D0 JN
/var/log/xferlog                        600  7     100  *     JC

Cada linha começa com o nome do log a ser rotacionado, seguido opcionalmente por um proprietário e um grupo para arquivos rotacionados e recém-criados. O campo mode define as permissões no arquivo de log e count indica quantos arquivos de log rotacionados devem ser mantidos. Os campos size e when informam o newsyslog quando rotacionar o arquivo. Um arquivo de log é rotacionado quando seu tamanho é maior que o campo size ou quando o tempo no campo when tiver terminado. Um asterisco (*) significa que este campo é ignorado. O campo flags fornece instruções adicionais, por exemplo, como compactar o arquivo rotacionado ou criar o arquivo de log se ele estiver ausente. Os dois últimos campos são opcionais e especificam o nome do arquivo de ID de Processo (PID) e um número de sinal para enviar a esse processo quando o arquivo é rotacionado.

Para obter maiores informações sobre todos os campos, sinalizadores válidos e como sobre especificar o tempo de rotação, consulte newsyslog.conf(5). Como o newsyslog é executado a partir do cron(8), ele não pode rotacionar arquivos com mais frequência do que a que está planejada para ser executada no cron(8).

11.7.3. Configurando o log remoto

Monitorar os arquivos de log de vários hosts pode se tornar difícil à medida que o número de sistemas aumenta. Configurar o log centralizado pode reduzir parte da carga administrativa da administração dos arquivos de log.

No FreeBSD, a agregação, a fusão e a rotação centralizada de arquivos de log podem ser configuradas usando o syslogd e o newsyslog. Esta seção demonstra um exemplo de configuração, em que host o A, chamado logserv.example.com, coletará informações de log para a rede local. O host B, denominado logclient.example.com, será configurado para transmitir informações de log para o servidor de registro em log.

11.7.3.1. Configuração do servidor de log

Um servidor de log é um sistema que foi configurado para aceitar informações de log de outros hosts. Antes de configurar um servidor de log, verifique o seguinte:

  • Se houver um firewall entre o servidor de log e qualquer cliente de log, certifique-se de que o conjunto de regras do firewall permita a porta 514 do UDP para os clientes e o servidor.

  • O servidor de log e todas as máquinas clientes devem ter entradas de nome diretas e reversas no DNS local. Se a rede não tiver um servidor DNS, crie entradas no /etc/hosts de cada sistema. A resolução adequada de nomes é necessária para que as entradas de log não sejam rejeitadas pelo servidor de log.

No servidor de log, edite o /etc/syslog.conf para especificar o nome do cliente para receber as entradas de log, o recurso de log a ser usado e o nome do log para armazenar as entradas de log do host. Este exemplo adiciona o nome do host de B, registra todos os recursos e armazena as entradas de log em /var/log/logclient.log.

Exemplo 1. Configuração do servidor de log de exemplo
+logclient.example.com
*.*     /var/log/logclient.log

Ao adicionar vários clientes de log, adicione uma entrada semelhante de duas linhas para cada cliente. Maiores informações sobre os recursos disponíveis podem ser encontradas em syslog.conf(5).

Em seguida, configure o /etc/rc.conf:

syslogd_enable="YES"
syslogd_flags="-a logclient.example.com -v -v"

A primeira entrada inicia o syslogd na inicialização do sistema. A segunda entrada permite entradas de log do cliente especificado. A opção -v -v aumenta a verbosidade das mensagens registradas. Isso é útil para ajustar os recursos, pois os administradores podem ver o tipo de mensagens que estão sendo registradas em cada facility.

Múltiplas opções -a podem ser especificadas para permitir o registro de múltiplos clientes. Endereços IP e netblocks inteiros também podem ser especificados. Consulte syslogd(8) para obter uma lista completa de opções possíveis.

Finalmente, crie o arquivo de log:

# touch /var/log/logclient.log

Neste ponto, o syslogd deve ser reiniciado e verificado:

# service syslogd restart
# pgrep syslog

Se um PID for retornado, o servidor será reiniciado com êxito e a configuração do cliente poderá ser iniciada. Se o servidor não reiniciar, consulte /var/log/messages para visualizar o erro.

11.7.3.2. Configuração do cliente de log

Um cliente de log envia entradas de log para um servidor de log na rede. O cliente também mantém uma cópia local de seus próprios logs.

Uma vez que o servidor de log foi configurado, edite o /etc/rc.conf no cliente de registro:

syslogd_enable="YES"
syslogd_flags="-s -v -v"

A primeira entrada ativa o syslogd na inicialização. A segunda entrada impede que os logs sejam aceitos por esse cliente de outros hosts (-s) e aumenta a verbosidade das mensagens registradas.

Em seguida, defina o servidor de log no /etc/syslog.conf do cliente. Neste exemplo, todos os facilities registrados são enviados para um sistema remoto, indicado pelo símbolo @, com o nome do host especificado:

*.*		@logserv.example.com

Depois de salvar a edição, reinicie o syslogd para que as alterações entrem em vigor:

# service syslogd restart

Para testar se as mensagens de log estão sendo enviadas pela rede, use o logger(1) no cliente para enviar uma mensagem para syslogd:

# logger "Test message from logclient"

Esta mensagem agora deve existir tanto no /var/log/messages do cliente e no /var/log/logclient.log do servidor de log.

11.7.3.3. Debugando servidores de log

Se nenhuma mensagem estiver sendo recebida no servidor de log, a causa provavelmente é um problema de conectividade de rede, um problema de resolução de nome de host ou um erro de digitação em um arquivo de configuração. Para isolar a causa, certifique-se de que o servidor de log e o cliente de log sejam capazes de comunicarem através do ping usando o nome do host especificado em seu /etc/rc.conf. Se isso falhar, verifique o cabeamento da rede, o conjunto de regras do firewall e as entradas de nome de host no servidor DNS ou /etc/hosts no servidor de log e nos clientes. Repita até que o ping seja bem-sucedido em ambos os hosts.

Se o ping for bem-sucedido em ambos os hosts, mas as mensagens de log ainda não estiverem sendo recebidas, aumente temporariamente o detalhamento do log para diminuir o problema de configuração. No exemplo a seguir, o /var/log/logclient.log no servidor de log está vazio e o /var/log/messages no cliente de log não indica uma razão para a falha. Para aumentar a saída de debug, edite a entrada syslogd_flags no servidor de log e execute uma reinicialização:

syslogd_flags="-d -a logclient.example.com -v -v"
# service syslogd restart

Dados de debug semelhantes aos seguintes irão aparecer no console imediatamente após a reinicialização:

logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
syslogd: restarted
logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
Logging to FILE /var/log/messages
syslogd: kernel boot file is /boot/kernel/kernel
cvthname(192.168.1.10)
validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
rejected in rule 0 due to name mismatch.

Neste exemplo, as mensagens de log estão sendo rejeitadas devido a um erro de digitação que resulta em uma incompatibilidade de nome de host. O nome do host do cliente deve ser logclient, não logclien. Corrija o erro de digitação, execute uma reinicialização e verifique os resultados:

# service syslogd restart
logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
syslogd: restarted
logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
syslogd: kernel boot file is /boot/kernel/kernel
logmsg: pri 166, flags 17, from logserv.example.com,
msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2
cvthname(192.168.1.10)
validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
accepted in rule 0.
logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2
Logging to FILE /var/log/logclient.log
Logging to FILE /var/log/messages

Neste ponto, as mensagens estão sendo recebidas e colocadas corretamente no arquivo correto.

11.7.3.4. Considerações de segurança

Como com qualquer serviço de rede, os requisitos de segurança devem ser considerados antes de implementar um servidor de log. Os arquivos de log podem conter dados confidenciais sobre serviços ativados no host local, contas de usuário e dados de configuração. Os dados enviados pela rede do cliente para o servidor não serão criptografados nem protegidos por senha. Se houver necessidade de criptografia, considere o uso do security/stunnel, que transmitirá os dados de log em um túnel criptografado.

A segurança local também é um problema. Os arquivos de log não são criptografados durante o uso ou após a rotação do log. Usuários locais podem acessar arquivos de log para obter informações adicionais sobre a configuração do sistema. Definir permissões adequadas nos arquivos de log é crítico. O rotacionador de log integrado, newsyslog, suporta a configuração de permissões em arquivos de log recém-criados e rotacionados. A configuração de arquivos de log no modo 600 deve impedir o acesso indesejado por usuários locais. Consulte newsyslog.conf(5) para obter informações adicionais.

11.8. Arquivos de Configuração

11.8.1. Layout do /etc

Existem vários diretórios nos quais as informações de configuração são mantidas. Estes incluem:

/etc

Informações de configuração específica do sistema genérico.

/etc/defaults

Versões padrão dos arquivos de configuração do sistema.

/etc/mail

Configuração extra do sendmail(8) e outros arquivos de configuração MTA.

/etc/ppp

Configuração para ambos os programas, user- e kernel-ppp.

/usr/local/etc

Arquivos de configuração para aplicativos instalados. Pode conter subdiretórios para cada aplicativo.

/usr/local/etc/rc.d

scripts rc(8) para os aplicativos instalados.

/var/db

Arquivos de banco de dados específicos do sistema gerados automaticamente, como o banco de dados de pacotes e o banco de dados locate(1).

11.8.2. Hostnames

11.8.2.1. /etc/resolv.conf

Como um sistema FreeBSD acessa o Sistema de Nomes de Domínio da Internet (Internet Domain Name System - DNS) é controlado por resolv.conf(5).

As entradas mais comuns para o /etc/resolv.conf são:

nameserver

O endereço IP de um servidor de nomes que o resolvedor deve consultar. Os servidores são consultados na ordem listada com um máximo de três.

search

Lista de pesquisa, para busca de nomes de host. Isso é normalmente determinado pelo domínio do nome do host local.

domain

O nome do domínio local.

Um típico /etc/resolv.conf é assim:

search example.com
nameserver 147.11.1.11
nameserver 147.11.100.30

Apenas uma das opções search e domain deve ser usada.

Ao usar o DHCP, o dhclient(8) geralmente reescreve o /etc/resolv.conf com informações recebidas do servidor DHCP.

11.8.2.2. /etc/hosts

O /etc/hosts é um banco de dados de texto simples que funciona em conjunto com o DNS e o NIS para fornecer o nome do host aos mapeamentos de endereços IP. Entradas para computadores locais conectados através de uma LAN podem ser adicionadas a este arquivo para propósitos simplistas de nomeação em vez de configurar um servidor named(8). Além disso, o /etc/hosts pode ser usado para fornecer um registro local de nomes da Internet, reduzindo a necessidade de consultar servidores DNS externos para nomes comumente acessados.

# $FreeBSD: head/pt_BR.ISO8859-1/books/handbook/book.xml 53984 2020-03-15 16:03:31Z dbaio $
#
#
# Host Database
#
# This file should contain the addresses and aliases for local hosts that
# share this file.  Replace 'my.domain' below with the domainname of your
# machine.
#
# In the presence of the domain name service or NIS, this file may
# not be consulted at all; see /etc/nsswitch.conf for the resolution order.
#
#
::1			localhost localhost.my.domain
127.0.0.1		localhost localhost.my.domain
#
# Imaginary network.
#10.0.0.2		myname.my.domain myname
#10.0.0.3		myfriend.my.domain myfriend
#
# According to RFC 1918, you can use the following IP networks for
# private nets which will never be connected to the Internet:
#
#	10.0.0.0	-   10.255.255.255
#	172.16.0.0	-   172.31.255.255
#	192.168.0.0	-   192.168.255.255
#
# In case you want to be able to connect to the Internet, you need
# real official assigned numbers.  Do not try to invent your own network
# numbers but instead get one from your network provider (if any) or
# from your regional registry (ARIN, APNIC, LACNIC, RIPE NCC, or AfriNIC.)
#

O formato do /etc/hosts é o seguinte:

[Internet address] [official hostname] [alias1] [alias2] ...

Por exemplo:

10.0.0.1 myRealHostname.example.com myRealHostname foobar1 foobar2

Consulte hosts(5) para obter maiores informações.

11.9. Efetuando ajustes com o sysctl(8)

O sysctl(8) é usado para fazer mudanças em um sistema FreeBSD em execução. Isso inclui muitas opções avançadas da stack TCP/IP e do sistema de memória virtual as quais podem melhorar drasticamente o desempenho do FreeBSD para um administrador de sistema experiente. Mais de quinhentas variáveis do sistema podem ser lidas e definidas usando o sysctl(8).

Em sua essência, o sysctl(8) serve duas funções: ler e modificar as configurações do sistema.

Para ver todas as variáveis legíveis:

% sysctl -a

Para ler uma variável específica, especifique seu nome:

% sysctl kern.maxproc
kern.maxproc: 1044

Para definir uma variável específica, use a sintaxe variable=value:

# sysctl kern.maxfiles=5000
kern.maxfiles: 2088 -> 5000

As configurações das variáveis sysctl são geralmente strings, números ou booleanos, onde um booleano é 1 para sim 0 para não.

Para definir automaticamente algumas variáveis sempre que a máquina inicializar, adicione-as ao /etc/sysctl.conf. Para maiores informações, consulte sysctl.conf(5) e sysctl.conf.

11.9.1. sysctl.conf

O arquivo de configuração para o sysctl(8), /etc/sysctl.conf, se parece muito com o /etc /rc.conf. Os valores são definidos na forma variable=value. Os valores especificados são definidos após o sistema entrar no modo multiusuário. Nem todas as variáveis são configuráveis neste modo.

Por exemplo, para desativar o log de saídas de sinais fatais e impedir que os usuários vejam processos iniciados por outros usuários, os seguintes ajustes podem ser configurados em /etc/sysctl.conf:

# Do not log fatal signal exits (e.g., sig 11)
kern.logsigexit=0

# Prevent users from seeing information about processes that
# are being run under another UID.
security.bsd.see_other_uids=0

11.9.2. Variáveis sysctl(8) apenas de leitura

Em alguns casos, pode ser desejável modificar os valores de variáveis do sysctl(8) que são somente de leitura, o que exigirá uma reinicialização do sistema.

Por exemplo, em alguns modelos de laptops, o dispositivo cardbus(4) não examinará os intervalos de memória e falhará com erros semelhantes a:

cbb0: Could not map register memory
device_probe_and_attach: cbb0 attach returned 12

A correção requer a modificação de uma configuração definida por uma variável do sysctl(8) que é somente de leitura. Adicione hw.pci.allow_unsupported_io_range=1 ao arquivo /boot/loader.conf e reinicie. Agora o cardbus(4) deve funcionar corretamente.

11.10. Otimização de Discos

A seção a seguir discutirá vários mecanismos e opções de ajuste que podem ser aplicados a dispositivos de disco. Em muitos casos, discos com partes mecânicas, como unidades SCSI, serão o gargalo que reduz o desempenho geral do sistema. Embora a solução seja instalar uma unidade sem peças mecânicas, como uma unidade de estado sólido, as unidades mecânicas não irão desaparecer num futuro próximo. Quando estiver otimizando discos, é aconselhável utilizar os recursos do comando iostat(8) para testar várias mudanças no sistema. Este comando permitirá ao usuário obter informações valiosas sobre o sistema IO.

11.10.1. Variáveis Sysctl

11.10.1.1. vfs.vmiodirenable

A variável vfs.vmiodirenable sysctl(8) pode ser definida como 0 (off ) ou 1 (on). Está definida para 1 por padrão. Esta variável controla como os diretórios são armazenados em cache pelo sistema. A maioria dos diretórios é pequena, usando apenas um único fragmento (normalmente 1K) no sistema de arquivos e, normalmente, 512 bytes no cache de buffer. Com esta variável desativada, o cache de buffer armazenará apenas um número fixo de diretórios, mesmo que o sistema tenha uma quantidade enorme de memória. Quando ativado, este sysctl(8) permite que o cache de buffer use o cache de página VM para armazenar em cache os diretórios, disponibilizando toda a memória para fazer cache dos diretórios. No entanto, a memória mínima no núcleo usada para armazenar em cache um diretório é o tamanho da página física (geralmente 4K) em vez de 512 bytes. Manter esta opção ativada é recomendado se o sistema estiver executando quaisquer serviços que manipulem um grande número de arquivos. Esses serviços podem incluir caches da web, grandes sistemas de correio e sistemas de notícias. Manter essa opção geralmente não reduz o desempenho, mesmo com a memória desperdiçada, mas deve-se experimentar para descobrir.

11.10.1.2. vfs.write_behind

A variável vfs.write_behind sysctl(8) é padronizada para 1 (ligada). Isso informa ao sistema de arquivos para emitir gravações de mídia à medida que clusters completos são coletados, o que normalmente ocorre ao gravar arquivos sequenciais grandes. Isso evita saturar o cache de buffer com buffers sujos quando não beneficia o desempenho de I/O. No entanto, isso pode atrasar os processos e, sob certas circunstâncias, deve ser desativado.

11.10.1.3. vfs.hirunningspace

A variável vfs.hirunningspace sysctl(8) determina quanto de I/O de gravação pendente pode ser enfileirado no sistema de controladores de disco como um todo em qualquer instância. O padrão é geralmente suficiente, mas em máquinas com muitos discos, tente aumentar para quatro ou cinco megabytes. Definir um valor muito alto, que exceda o limite de gravação do cache de buffer, pode levar a um mau desempenho de cluster. Não defina esse valor arbitrariamente alto, pois valores de gravação mais altos podem adicionar latência a leituras que ocorrem ao mesmo tempo.

Há vários outros caches de buffer e valores de cache de página VM relacionados a sysctl(8). Modificar esses valores não é recomendado, pois o sistema VM faz um bom trabalho de ajuste automático.

11.10.1.4. vm.swap_idle_enabled

A variável vm.swap_idle_enabled sysctl(8) é útil em grandes sistemas multiusuários com muitos usuários ativos, e muitos processos ociosos. Tais sistemas tendem a gerar pressão contínua nas reservas de memória livre. Ativar esse recurso e aprimorar a histerese de troca (em segundos ociosos) por meio de vm.swap_idle_threshold1 e vm.swap_idle_threshold2 reduz a prioridade das páginas de memória associadas aos processos inativos mais rapidamente do que no algoritmo de pageout normal. Isso dá uma ajuda ao daemon de pageout. Apenas ative essa opção se necessário, porque a compensação é essencialmente fazer o pre-page da memoria mais cedo, o que consome mais swap e largura de banda de disco. Em um sistema pequeno, esta opção terá um efeito determinável, mas em um sistema grande que já está paginando moderadamente, esta opção permite que o sistema VM instale processos inteiros dentro e fora da memória facilmente.

11.10.1.5. hw.ata.wc

Desativar o cache de gravação IDE reduz a largura de banda de gravação em discos IDE, mas às vezes pode ser necessário devido a problemas de consistência de dados introduzidos por fornecedores de disco rígido. O problema é que algumas unidades IDE mentem sobre quando uma gravação é concluída. Com o cache de gravação IDE ativado, os discos rígidos IDE gravam os dados fora de ordem e às vezes atrasam a gravação de alguns blocos indefinidamente quando estão sob carga pesada de disco. Uma falha ou falha de energia pode causar corrupção séria do sistema de arquivos. Verifique o padrão no sistema observando a variável hw.ata.wc sysctl(8). Se o cache de gravação IDE estiver desativado, pode-se definir essa variável somente leitura como 1 em /boot/loader.conf para ativar no momento da inicialização.

Para maiores informações, consulte ata(4).

11.10.1.6. SCSI_DELAY (kern.cam.scsi_delay)

A opção de configuração do kernel SCSI_DELAY pode ser usada para reduzir os tempos de inicialização do sistema. Os padrões são razoavelmente altos e podem ser responsáveis por 15 segundos de atraso no processo de inicialização. Reduzindo-o para 5 segundos geralmente funciona com unidades modernas. A variável de tempo de inicialização kern.cam.scsi_delay deve ser usada. A opção de configuração ajustável e a configuração do kernel aceitam valores em termos de milissegundos e não__segundos.

11.10.2. Soft Updates

Para ajustar um sistema de arquivos, use tunefs(8). Este programa tem muitas opções diferentes. Para ativar e desativar o Soft Updates, use:

# tunefs -n enable /filesystem
# tunefs -n disable /filesystem

Um sistema de arquivos não pode ser modificado com tunefs(8) enquanto estiver montado. Um bom momento para ativar o Soft Updates é antes que qualquer partição tenha sido montada, no modo de single-user.

O Soft Updates é recomendado para sistemas de arquivos UFS, pois melhora drasticamente o desempenho de metadados, principalmente a criação e exclusão de arquivos, através do uso de um cache em memória. Há duas desvantagens no Soft Updates que você deve conhecer. Primeiro, o Soft Updates garante a consistência do sistema de arquivos no caso de uma falha, mas pode facilmente levar vários segundos ou até um minuto para atualizar o disco físico. Se o sistema falhar, os dados não gravados poderão ser perdidos. Em segundo lugar, os Soft Updates atrasam a liberação de blocos do sistema de arquivos. Se o sistema de arquivos raiz estiver quase cheio, a execução de uma atualização importante, como make installworld, poderá causar a falta de espaço do sistema de arquivos e a atualização falhará.

11.10.2.1. Mais detalhes sobre soft updates

As atualizações de metadados são atualizações para dados que não são de conteúdo, como inodes ou diretórios. Existem duas abordagens tradicionais para gravar os metadados de um sistema de arquivos em disco.

Historicamente, o comportamento padrão era gravar atualizações de metadados de forma síncrona. Se um diretório fosse alterado, o sistema aguardava até que a alteração fosse gravada no disco. Os buffers de dados do arquivo (conteúdo do arquivo) foram passados pelo cache de buffer e foram copiados para o disco posteriormente de maneira assíncrona. A vantagem dessa implementação é que ela opera com segurança. Se houver uma falha durante uma atualização, os metadados estarão sempre em um estado consistente. Um arquivo é criado completamente ou não é de todo. Se os blocos de dados de um arquivo não encontrarem saída do cache de buffer para o disco no momento da falha, o fsck(8) reconhece isso e repara o sistema de arquivos definindo o comprimento do arquivo como 0. Além disso, a implementação é clara e simples. A desvantagem é que as alterações nos metadados são lentas. Por exemplo, rm -r toca todos os arquivos em um diretório sequencialmente, mas cada alteração de diretório será gravada de forma síncrona no disco. Isso inclui atualizações para o próprio diretório, para a tabela de inode e possivelmente para blocos indiretos alocados pelo arquivo. Considerações semelhantes aplicam-se ao desenrolar hierarquias grandes usando tar -x.

A segunda abordagem é usar atualizações de metadados assíncronas. Este é o padrão para um sistema de arquivos UFS montado com mount -o async. Como todas as atualizações de metadados também são passadas pelo cache de buffer, elas serão mescladas com as atualizações dos dados de conteúdo do arquivo. A vantagem dessa implementação é que não há necessidade de esperar até que cada atualização de metadados seja gravada no disco, portanto, todas as operações que causam grandes quantidades de atualizações de metadados funcionam muito mais rápido do que no caso síncrono. Essa implementação ainda é clara e simples, portanto, há um baixo risco de erros se infiltrarem no código. A desvantagem é que não há garantia para um estado consistente do sistema de arquivos. Se houver uma falha durante uma operação que atualizou grandes quantidades de metadados, como uma falha de energia ou alguém pressionando o botão de reinicialização, o sistema de arquivos será deixado em um estado imprevisível. Não há oportunidade de examinar o estado do sistema de arquivos quando o sistema é reativado, pois os blocos de dados de um arquivo já podem ter sido gravados no disco enquanto as atualizações da tabela de inodes ou do diretório associado não foram. É impossível implementar um fsck(8) que é capaz de limpar o caos resultante porque as informações necessárias não estão disponíveis no disco. Se o sistema de arquivos foi danificado além do reparo, a única opção é reformatá-lo e restaurá-lo a partir do backup.

A solução usual para este problema é implementar dirty region logging, que também é chamado de journaling. As atualizações de metadados ainda são gravadas de forma síncrona, mas apenas em uma pequena região do disco. Mais tarde, eles são movidos para o local apropriado. Como a área de registro é uma região pequena e contígua no disco, não há longas distâncias para as cabeças de disco se moverem, mesmo durante operações pesadas, portanto, essas operações são mais rápidas do que as atualizações síncronas. Além disso, a complexidade da implementação é limitada, portanto, o risco de erros estarem presentes é baixo. Uma desvantagem é que todos os meta-dados são gravados duas vezes, uma vez na região de registro e uma vez no local apropriado, portanto, pode resultar em "piora" na performance. Por outro lado, em caso de falha, todas as operações de metadados pendentes podem ser rapidamente recuperadas ou concluídas a partir da área de registro depois que o sistema for ativado novamente, resultando em uma inicialização rápida do sistema de arquivos.

Kirk McKusick, o desenvolvedor do Berkeley FFS, resolveu esse problema com o Soft Updates. Todas as atualizações de meta-dados pendentes são mantidas na memória e gravadas no disco em uma sequência ordenada ("atualizações de metadados ordenadas"). Isso tem o efeito de que, no caso de operações pesadas de meta-dados, atualizações posteriores em um item "catch" as anteriores que ainda estão na memória e ainda não foram gravadas no disco. Todas as operações são geralmente executadas na memória antes da atualização ser gravada no disco e os blocos de dados são classificados de acordo com sua posição, de modo que não estarão no disco antes de seus meta-dados. Se o sistema travar, um "reenvio de log" implícito faz com que todas as operações que não foram gravadas no disco apareçam como se nunca tivessem acontecido. Um estado consistente do sistema de arquivos é mantido e parece ser o de 30 a 60 segundos antes. O algoritmo usado garante que todos os recursos em uso sejam marcados como tal em seus blocos e inodes. Após uma falha, o único erro de alocação de recursos que ocorre é que os recursos são marcados como "used", que são, na verdade, "free". O fsck(8) reconhece essa situação e libera os recursos que não são mais usados. É seguro ignorar o estado sujo do sistema de arquivos após uma falha forçando a montagem com mount -f. Para liberar recursos que podem não ser utilizados, O fsck(8) precisa ser executado posteriormente. Esta é a idéia por trás do fsck(8) em background: no momento da inicialização do sistema, apenas um snapshot do sistema de arquivos é gravado e o fsck(8) é executado posteriormente. Todos os sistemas de arquivos podem ser montados "sujos", para que a inicialização do sistema prossiga no modo multiusuário. Em seguida, o fsck(8) em background é planejado para todos os sistemas de arquivos em que isso é necessário, para liberar recursos que podem não ser utilizados. Os sistemas de arquivos que não usam Soft Updates ainda precisam executar o fsck(8) em primeiro plano de forma usual .

A vantagem é que as operações de meta-dados são quase tão rápidas quanto as atualizações assíncronas e são mais rápidas que o logging, que precisa escrever os meta-dados duas vezes. As desvantagens são a complexidade do código, um maior consumo de memória e algumas idiosincrasias. Depois de uma falha, o estado do sistema de arquivos parece ser um pouco mais "velho". Em situações onde a abordagem síncrona padrão teria causado a existencia de alguns arquivos de comprimento zero após o fsck(8), esses arquivos sequer chegam a existir com Soft Updates porque nem os metadados e nem o conteúdo do arquivo foram gravados no disco. O espaço em disco não é liberado até que as atualizações tenham sido gravadas no disco, o que pode ocorrer algum tempo depois de executar rm(1). Isso pode causar problemas ao instalar grandes quantidades de dados em um sistema de arquivos que não tenha espaço livre suficiente para armazenar todos os arquivos duas vezes.

11.11. Ajustando os Limites do Kernel

11.11.1. Limites de arquivos/processos

11.11.1.1. kern.maxfiles

A variável kern.maxfiles sysctl(8) pode ser aumentada ou diminuída com base nos requisitos do sistema. Essa variável indica o número máximo de descritores de arquivos no sistema. Quando a tabela do descritor de arquivos estiver cheia, o erro file: table is full aparecerá repetidamente no buffer de mensagem do sistema, que pode ser visualizado usando dmesg(8).

Cada arquivo aberto, socket ou fifo usa um descritor de arquivo. Um servidor de produção em larga escala pode facilmente exigir muitos milhares de descritores de arquivos, dependendo do tipo e número de serviços executados simultaneamente.

Em versões mais antigas do FreeBSD, o valor padrão de kern.maxfiles é derivado do maxusers no arquivo de configuração do kernel. O kern.maxfiles cresce proporcionalmente ao valor do maxusers. Ao compilar um kernel personalizado, considere configurar esta opção de configuração do kernel de acordo com o uso do sistema. A partir desse número, o kernel recebe a maioria dos seus limites predefinidos. Mesmo que uma máquina de produção não tenha 256 usuários simultâneos, os recursos necessários podem ser semelhantes a um servidor da Web de alta escala.

A variável read-only sysctl(8)kern.maxusers é dimensionada automaticamente na inicialização com base na quantidade de memória disponível no sistema, e pode ser determinado em tempo de execução, inspecionando o valor de kern.maxusers. Alguns sistemas requerem valores maiores ou menores de kern.maxusers e valores de 64, 128, e 256 não são incomuns. Ir acima de 256 não é recomendado, a menos que seja necessário um grande número de descritores de arquivos. Muitos dos valores ajustáveis definidos para seus padrões por kern.maxusers podem ser individualmente sobrescritos no tempo de inicialização ou em tempo de execução no /boot/loader.conf. Consulte loader.conf(5) e /boot/defaults/loader.conf para mais detalhes e algumas dicas.

Em versões mais antigas, o sistema ajustará automaticamente o maxusers se ele estiver definido como 0. . Ao configurar esta opção, configure o maxusers para pelo menos 4, especialmente se o sistema executar o Xorg ou se for usado para compilar software. A tabela mais importante definida por maxusers é o número máximo de processos, que é definido como 20 + 16 * maxusers. Se maxusers for definido como 1, só podem existir 36 processos simultâneos, incluindo 18 ou mais para que o sistema seja iniciado no boot ou 15 usado pelo Xorg. Até mesmo uma tarefa simples, como ler uma página de manual, iniciará nove processos para filtrar, descompactar e visualizar. Configurar o maxusers para 64 permite até 1044 processos simultâneos, o que deve ser suficiente para quase todos os usos. Se, no entanto, o erro for exibido ao tentar iniciar outro programa ou se um servidor estiver sendo executado com um grande número de usuários simultâneos, aumente o número e recompile.

O maxusers não limita o número de usuários que podem logar na máquina. Em vez disso, ele configura vários tamanhos de tabela para valores razoáveis, considerando o número máximo de usuários no sistema e quantos processos cada usuário executará.

11.11.1.2. kern.ipc.soacceptqueue

A variável kern.ipc.soacceptqueue do sysctl(8) limita o tamanho da fila de escuta para aceitar novas conexões TCP. O valor padrão de 128 é normalmente muito baixo para o manuseio robusto de novas conexões em um servidor Web com carga pesada. Para tais ambientes, recomenda-se aumentar este valor para 1024 ou superior. Um serviço como o sendmail(8), ou Apache pode limitar por ele mesmo o tamanho da fila de escuta, mas frequentemente terá uma diretiva em seu arquivo de configuração para ajustar o tamanho da fila. Filas de escuta grandes fazem um trabalho melhor evitando ataques de negação de serviço (Denial of Service - DoS).

11.11.2. Limites de rede

A opção de configuração do kernel NMBCLUSTERS determina a quantidade de Mbufs de rede disponível para o sistema. Um servidor com muito tráfego e um baixo número de Mbufs prejudicará o desempenho. Cada cluster representa aproximadamente 2K de memória, portanto, um valor de 1024 representa 2 megabytes de memória do kernel reservada para buffers de rede. Um cálculo simples pode ser feito para descobrir quantos são necessários. Um servidor web que suporte um maximo de 1000 conexões simultâneas onde cada conexão usa um buffer de envio de 16K e recebe 6K, requer aproximadamente 32 MB de buffers de rede para cobrir o servidor web. Uma boa regra é multiplicar por 2, então 2x32MB / 2KB = 64MB / 2kB = 32768. Valores entre 4096 e 32768 são recomendados para máquinas com maiores quantidades de memória. Nunca especifique um valor arbitrariamente alto para este parâmetro, pois isso pode levar a uma falha no tempo de inicialização. Para observar o uso do cluster de rede, use a opção -m com o netstat(1).

A variável kern.ipc.nmbclusters deve ser usada para configurar isso no momento da inicialização. Apenas as versões mais antigas do FreeBSD irão requerer o uso da opção NMBCLUSTERS no config(8) do kernel.

Para servidores ocupados que fazem uso extensivo da chamada de sistema sendfile(2), pode ser necessário aumentar o número de buffers sendfile(2) através da opção de configuração do kernel NSFBUFS ou definindo seu valor no /boot/loader.conf (veja loader(8) para detalhes). Um indicador comum de que esse parâmetro precisa ser ajustado é quando os processos são vistos no estado sfbufa. A variável sysctl(8)kern.ipc.nsfbufs é somente de leitura. Este parâmetro nominalmente escala com o kern.maxusers, no entanto, pode ser necessário ajustar de acordo.

Mesmo que um socket tenha sido marcado como non-blocking, chamar o sendfile(2) em um socket non-blocking pode resultar no bloqueio do sendfile(2) até que sejam disponibilizados struct sf_buf suficientes.

11.11.2.1. net.inet.ip.portrange.*

As variáveis net.inet.ip.portrange.* do sysctl(8) controlam os intervalos de números de porta automaticamente ligados a sockets TCP e UDP. Existem três intervalos: um intervalo baixo, um intervalo padrão e um intervalo alto. A maioria dos programas de rede usam o intervalo padrão que é controlado por net.inet.ip.portrange.first e net.inet.ip.portrange.last, cujo padrão é 1024 e 5000, respectivamente. Intervalos de porta ligados são usados para conexões de saída e é possível executar o sistema fora das portas sob certas circunstâncias. Isso ocorre mais comumente ao executar um proxy web com muita carga. O intervalo de portas não é um problema ao executar um servidor que lida principalmente com conexões de entrada, como um servidor Web, ou que tenha um número limitado de conexões de saída, como um mail relay. Para situações em que há falta de portas, é recomendado aumentar modestamente o net.inet.ip.portrange.last. Um valor de 10000, 20000 ou 30000 pode ser razoável. Considere os efeitos do firewall ao alterar o intervalo de portas. Alguns firewalls podem bloquear grandes intervalos de portas, geralmente portas de numeração baixa, e esperam que os sistemas usem intervalos mais altos de portas para conexões de saída. Por esta razão, não é recomendado que o valor de net.inet.ip.portrange.first seja diminuído.

11.11.2.2. Produto de atraso de largura de banda TCP

A limitação do produto de atraso de largura de banda TCP pode ser ativada configurando a variável net.inet.tcp.inflight.enable do sysctl(8) para 1. Isso instrui o sistema a tentar calcular o produto de atraso de largura de banda para cada conexão e a limitar a quantidade de dados na fila para envio à rede para a quantidade necessária para manter o rendimento ideal.

Esse recurso é útil ao servir dados sobre modems, Gigabit Ethernet, links WAN de alta velocidade ou qualquer outro link com um produto de atraso de largura de banda alta, especialmente quando também estiver usando dimensionamento de janela ou quando uma janela de envio grande tiver sido configurado. Ao habilitar essa opção, defina também a variável net.inet.tcp.inflight.debug para 0 para desabilitar a depuração. Para uso em produção, definir a variável net.inet.tcp.inflight.min para pelo menos 6144 pode ser benéfico. Definir valores mínimos altos pode efetivamente desabilitar a limitação de largura de banda, dependendo do link. O recurso de limitação reduz a quantidade de dados acumulados nas rotas intermediárias e nas filas de pacotes de switchs e reduz a quantidade de dados acumulados na fila de interface do host local. Com menos pacotes enfileirados, as conexões interativas, especialmente os modems lentos, funcionarão com menores Round Trip Times. Esse recurso afeta apenas a transmissão de dados do lado do servidor, como o upload. Não tem efeito na recepção ou download de dados.

Ajustar o valor da variável net.inet.tcp.inflight.stab não é recomendado. Este parâmetro é padronizado para 20, representando 2 pacotes máximos adicionados ao cálculo da janela de produto de atraso de largura de banda. A janela adicional é necessária para estabilizar o algoritmo e melhorar a capacidade de resposta às mudanças de condições, mas também pode resultar em um ping(8) mais alto em links lentos , embora ainda muito menor do que sem o algoritmo inflight. Nesses casos, tente reduzir esse parâmetro para 15, 10 ou 5 e reduza a variável net.inet.tcp.inflight.min para um valor como 3500 para obter o efeito desejado. A redução desses parâmetros deve ser feita apenas como último recurso.

11.11.3. Memória virtual

11.11.3.1. kern.maxvnodes

Um vnode é a representação interna de um arquivo ou diretório. Aumentar o número de vnodes disponíveis para o sistema operacional reduz a I/O do disco. Normalmente, isso é tratado pelo sistema operacional e não precisa ser alterado. Em alguns casos em que o I/O de disco é um gargalo e o sistema está ficando sem vnodes, essa configuração precisa ser aumentada. A quantidade de RAM inativa e livre precisará ser levada em conta.

Para ver o número atual de vnodes em uso:

# sysctl vfs.numvnodes
vfs.numvnodes: 91349

Para ver o máximo de vnodes:

# sysctl kern.maxvnodes
kern.maxvnodes: 100000

Se o uso atual do vnode estiver próximo do máximo, tente aumentar o kern.maxvnodes por um valor de 1000. Fique de olho no número de vfs.numvnodes. Se subir até o máximo novamente, o kern.maxvnodes precisará ser aumentado ainda mais. Caso contrário, uma mudança no uso da memória como reportado pelo top(1) deve estar visível e mais memória deve estar ativa.

11.12. Adicionando Espaço de Swap

Às vezes, um sistema requer mais espaço de swap. Esta seção descreve dois métodos para aumentar o espaço de troca: adicionar swap a uma partição existente ou em um novo disco rígido e criar um arquivo de swap em uma partição existente.

Para obter informações sobre como criptografar o espaço de swap, quais opções existem e por que isso deve ser feito, consulte Criptografando Swap.

11.12.1. Swap em um novo disco rígido ou partição existente

Adicionar um novo disco rígido para swap resulta em um melhor desempenho do que usando uma partição em uma unidade existente. A configuração de partições e discos rígidos é explicada em Adicionando Discos enquanto Criando o layout da partição discute layouts de partições e considerações sobre o tamanho de partições de swap.

Use o swapon para adicionar uma partição swap ao sistema. Por exemplo:

# swapon /dev/ada1s1b

É possível usar qualquer partição que não esteja atualmente montada, mesmo que já contenha dados. O uso do swapon em uma partição que contém dados sobrescreverá e destruirá esses dados. Certifique-se de que a partição a ser incluída como swap seja realmente a partição pretendida antes de executar o swapon.

Para adicionar automaticamente essa partição swap na inicialização, adicione uma entrada ao /etc/fstab:

/dev/ada1s1b	none	swap	sw	0	0

Veja fstab(5) para uma explicação das entradas do /etc/fstab. Maiores informações sobre swapon podem ser encontradas em swapon(8).

11.12.2. Criando um arquivo de swap

Esses exemplos criam um arquivo de swap de 512M chamado /usr/swap0 em vez de usar uma partição.

O uso de arquivos de swap requer que o módulo necessário pelo md(4) tenha sido embutido no kernel ou tenha sido carregado antes do swap ser ativado. Veja Configurando o kernel do FreeBSD para informações sobre como compilar um kernel customizado.

Exemplo 2. Criando um arquivo de swap
  1. Crie o arquivo de swap:

    # dd if=/dev/zero of=/usr/swap0 bs=1m count=512
  2. Defina as permissões adequadas no novo arquivo:

    # chmod 0600 /usr/swap0
  3. Informe o sistema sobre o arquivo de swap adicionando uma linha ao /etc/fstab:

    md99	none	swap	sw,file=/usr/swap0,late	0	0

    O dispositivo md99 do md(4) é usado, deixando números de dispositivos inferiores disponíveis para uso interativo.

  4. O espaço de swap será adicionado na inicialização do sistema. Para adicionar espaço de swap imediatamente, use o swapon(8):

    # swapon -aL

11.13. Gerenciamento de energia e recursos

É importante utilizar recursos de hardware de maneira eficiente. O gerenciamento de energia e recursos permite que o sistema operacional monitore os limites do sistema e, possivelmente, forneça um alerta se a temperatura do sistema aumentar inesperadamente. Uma especificação anterior para fornecer gerenciamento de energia foi o recurso Gerenciamento Avançado de Energia (Advanced Power Management - APM). O APM controla o uso de energia de um sistema com base em sua atividade. No entanto, era difícil e inflexível para os sistemas operacionais gerenciar o uso de energia e as propriedades térmicas de um sistema. O hardware era gerenciado pelo BIOS e o usuário tinha configuração e visibilidade limitadas nas configurações de gerenciamento de energia. O APMBIOS fornecido é específico da plataforma de hardware. Um driver APM no sistema operacional intermedia o acesso à interface do software APM, que permite o gerenciamento dos níveis de energia.

Existem quatro problemas principais no APM. Primeiro, o gerenciamento de energia é feito pelo BIOS específico do fornecedor, separado do sistema operacional. Por exemplo, o usuário pode definir valores de tempo ocioso para um disco rígido no APMBIOS para que, quando excedido, o BIOS diminua o disco rígido sem o consentimento do sistema operacional. Segundo, a lógica do APM é incorporada no BIOS e opera fora do escopo do sistema operacional. Isso significa que os usuários só podem corrigir problemas no APMBIOS, fazendo o flash de um novo ROM, que é um procedimento perigoso com potencial para deixar o sistema em um estado irrecuperável se falhar. Terceiro, o APM é uma tecnologia específica do fornecedor, o que significa que há muita duplicidade de esforços e que os erros encontrados no BIOS de um fornecedor podem não serem resolvidos em outros. Por fim, o APMBIOS não tinha espaço suficiente para implementar uma política de energia sofisticada ou que pudesse se adaptar bem ao propósito da máquina.

O BIOS plug and play (PNPBIOS) não era confiável em muitas situações. O PNPBIOS é uma tecnologia de 16 bits, portanto, o sistema operacional precisa usar a emulação de 16 bits para fazer interface com os métodos PNPBIOS. O FreeBSD fornece um driver APM, pois o APM ainda deve ser usado para sistemas fabricados antes do ano 2000. O driver está documentado em apm(4).

O sucessor do APM é a Interface Avançada de Configuração e Energia (Advanced Configuration and Power Interface - ACPI). O ACPI é um padrão escrito por uma aliança de fornecedores para fornecer uma interface para recursos de hardware e gerenciamento de energia. É um elemento-chave na configuração direcionada do sistema operacional e gerenciamento de energia, pois proporciona mais controle e flexibilidade ao sistema operacional.

Este capítulo demonstra como configurar o ACPI no FreeBSD. Em seguida, ele oferece algumas dicas sobre como depurar o ACPI e como enviar um relatório de problemas contendo informações de depuração para que os desenvolvedores possam diagnosticar e corrigir problemas no ACPI.

11.13.1. Configurando o ACPI

No FreeBSD, o driver acpi(4) é carregado por padrão na inicialização do sistema e não deve ser compilado no kernel. Este driver não pode ser descarregado após a inicialização porque o barramento do sistema o utiliza para várias interações de hardware. No entanto, se o sistema estiver com problemas, o ACPI pode ser desativado completamente ao reinicializar após a configurar hint.acpi.0.disabled="1" no /boot/loader.conf ou definindo esta variável no prompt do loader, como descrito em Estágio três.

O ACPI e o APM não podem coexistir e devem ser usados separadamente. O último a ser carregado terminará se o driver perceber que o outro já está sendo executado.

O ACPI pode ser usado para colocar o sistema em modo de suspensão com o acpiconf, a opção -s e um número de 1 a 5. A maioria dos usuários só precisa de 1 (suspensão rápida para RAM) ou 3 (suspender para RAM). A opção 5 executa um soft-off que é o mesmo que executar halt -p.

Outras opções estão disponíveis usando o sysctl. Consulte acpi(4) e acpiconf(8) para maiores informações.

11.13.2. Problemas comuns

O ACPI está presente em todos os computadores modernos que estão em conformidade com as arquiteturas ia32 (x86) e amd64 (AMD). O padrão completo tem muitos recursos, incluindo gerenciamento de desempenho da CPU, controle de planos de energia, zonas térmicas, vários sistemas de bateria, controladores incorporados e enumeração de barramento. A maioria dos sistemas implementa menos que o padrão completo. Por exemplo, um sistema de desktop geralmente só implementa a enumeração de barramento, enquanto um laptop também pode ter suporte a refrigeração e gerenciamento de bateria. Os laptops também têm suspensão e retomada, com sua própria complexidade associada.

Um sistema compatível com ACPI possui vários componentes. Os fornecedores de BIOS e chipset fornecem várias tabelas fixas, como FADT, na memória que especificam coisas como o mapa APIC (usado para SMP), registros de configuração e valores simples de configuração. Além disso, uma tabela de bytecode, a Tabela de Descrição de Sistema Diferenciada DSDT, especifica um espaço de nome de dispositivos e métodos em forma de árvore.

O driver ACPI deve analisar as tabelas fixas, implementar um interpretador para o bytecode e modificar os drivers de dispositivos e o kernel para aceitar informações do subsistema ACPI. Para o FreeBSD, a Intel™ forneceu um interpretador (ACPI-CA) que é compartilhado com o Linux™ e o NetBSD. O caminho para o código-fonte ACPI-CA é src/sys/contrib/dev/acpica. O código especifico que permite que o ACPI-CA funcione no FreeBSD está em src/sys/dev/acpica/Osd. Finalmente, drivers que implementam vários dispositivos ACPI são encontrados em src/sys/dev/acpica.

Para que o ACPI funcione corretamente, todas as partes devem funcionar corretamente. Aqui estão alguns problemas comuns, em ordem de freqüência em que ocorrem, e algumas possíveis soluções ou correções. Se uma correção não resolver o problema, consulte Obtendo e enviando informações de depuração para obter instruções sobre como enviar um relatório de bug.

11.13.2.1. Problemas do mouse

Em alguns casos, retomar a partir de uma operação de suspensão fará com que o mouse falhe. Um work around conhecido é adicionar hint.psm.0.flags="0x3000" ao /boot/loader.conf.

11.13.2.2. Suspend/Resume

O ACPI tem três estados de suspensão para RAM (STR), S1-S3, e um de suspensão de estado para disco (STD), chamado S4. O STD pode ser implementado de duas maneiras separadas. O S4 BIOS é uma suspensão para disco auxiliada pelo BIOSe o S4OS é implementado inteiramente pelo sistema operacional. O estado normal em que o sistema se encontra quando conectado, mas não ligado, é "soft off" (S5).

Use o sysctl hw.acpi para verificar os itens relacionados à suspensão. Estes resultados de exemplo são de um Thinkpad:

hw.acpi.supported_sleep_state: S3 S4 S5
hw.acpi.s4bios: 0

Use o acpiconf -s para testar os estados S3, S4 e S5. Um s4bios de um (1) indica suporte ao S4 BIOS em vez do S4 suportado pelo sistema operacional.

Ao testar as ações de suspend/resume, inicie com o S1, se suportado. É mais provável que esse estado funcione, pois não requer muito suporte ao driver. Ninguém implementou S2, que é similar ao S1. Em seguida, tente o S3. Este é o estado mais profundo do STR e requer muito suporte ao driver para reinicializar corretamente o hardware.

Um problema comum com suspend/resume é que muitos drivers de dispositivo não salvam, restauram ou reinicializam seu firmware, registros ou memória do dispositivo adequadamente. Como primeira tentativa de depuração do problema, tente:

# sysctl debug.bootverbose=1
# sysctl debug.acpi.suspend_bounce=1
# acpiconf -s 3

Esse teste emula o ciclo de suspend/resume de todos os drivers de dispositivo sem entrar realmente no estado S3. Em alguns casos, problemas como perder o estado do firmware, tempo limite do watchdog do dispositivo e tentar novamente para sempre podem ser capturados com esse método. Note que o sistema não entrará realmente no estado S3, o que significa que os dispositivos não perderão energia, e muitos funcionarão bem mesmo se os métodos suspend/resume estiverem totalmente ausentes, ao contrário do real estado S3.

Casos mais difíceis requerem hardware adicional, como uma porta serial e um cabo para depuração através de um console serial, uma porta Firewire e um cabo para o uso do dcons(4) e habilidades de depuração do kernel.

Para ajudar a isolar o problema, descarregue o maior número possível de drivers. Se funcionar, diminua o driver que é o problema carregando os drivers até que ele falhe novamente. Normalmente, drivers binários como nvidia.ko, drivers de exibição e USB terão mais problemas, enquanto as interfaces Ethernet normalmente funcionam bem. Se os drivers puderem ser carregados e descarregados adequadamente, automatize isso colocando os comandos apropriados em /etc/rc.suspend e /etc/rc.resume. Tente configurar o hw.acpi.reset_video para 1 se a tela estiver desarrumada após a retomada. Tente definir valores mais longos ou mais curtos para hw.acpi.sleep_delay para ver se isso ajuda.

Tente carregar uma distribuição recente do Linux™ para ver se o suspend/resume funciona no mesmo hardware. Se funciona no Linux™, é provável que seja um problema no driver do FreeBSD. Descobrir qual driver causa o problema ajudará os desenvolvedores a corrigir o problema. Como os mantenedores do ACPI raramente mantêm outros drivers, como som ou ATA, qualquer problema de driver também deve ser postado na lista freebsd-current e enviada para o mantenedor do driver. Os usuários avançados podem incluir os printf(3)s de debug do driver problemático para rastrear onde, em sua função de reinício, ele é interrompido.

Por fim, tente desativar o ACPI e ativar o APM. Se o comando suspend/resume funcionar com APM, use o APM, especialmente em hardware mais antigo (anterior a 2000). Demorou algum tempo para que os fornecedores obtivessem suporte ACPI correto e os hardwares antigos são mais prováveis de terem problemas de BIOS com ACPI.

11.13.2.3. Travamentos do sistema

A maioria dos travamentos do sistema é resultado de interrupções perdidas ou de uma tempestade de interrupções. Chipsets podem ter problemas com base na inicialização, como o BIOS configura as interrupções antes da correção da tabela APIC (MADT) e o roteamento do sistema de controle de interrupções (SCI).

Tempestades de interrupção podem ser distinguidas de interrupções perdidas, verificando a saída do vmstat -i e observando a linha que possui acpi0. Se o contador está aumentando em mais de um par por segundo, há uma tempestade de interrupção. Se o sistema parece travado, tente acessar o DDB (CTRL+ALT+ESC no console) e digite show interrupts.

Ao lidar com problemas de interrupção, tente desativar o suporte ao APIC com hint.apic.0.disabled="1" no /boot/loader.conf .

11.13.2.4. Panics

Os panics são relativamente raros para ACPI e são a prioridade máxima a ser corrigida. O primeiro passo é isolar as etapas para reproduzir o panic, se possível, e obter um backtrace. Siga as instruções para habilitar options DDB e configurar um console serial em Entrando no Depurador DDB da Linha Serial ou configurar uma partição de despejo. Para obter um backtrace no DDB, use tr. Ao escrever o backtrace, obtenha pelo menos as cinco últimas e as cinco principais linhas do rastro.

Em seguida, tente isolar o problema inicializando com ACPI desabilitado. Se isso funcionar, isole o subsistema ACPI usando vários valores de debug.acpi.disable. Veja acpi(4) para alguns exemplos.

11.13.2.5. O sistema é ativado após a sua suspensão ou desligamento

Primeiro, tente definir hw.acpi.disable_on_poweroff="0" no /boot/loader.conf. Isso impede que a ACPI desative vários eventos durante o processo de desligamento. Alguns sistemas precisam desse valor definido como 1 (o padrão) pelo mesmo motivo. Isso geralmente corrige o problema de um sistema ser ativado espontaneamente após uma suspensão ou desligamento.

11.13.2.6. BIOS contém Bytecode com bugs

Alguns fornecedores de BIOS fornecem bytecode incorreto ou com bugs. Isso geralmente é manifestado por mensagens do console do kernel como esta:

ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\
(Node 0xc3f6d160), AE_NOT_FOUND

Geralmente, esses problemas podem ser resolvidos com a atualização do BIOS para a revisão mais recente. A maioria das mensagens do console é inofensiva, mas se houver outros problemas, como o status da bateria não estar funcionando, essas mensagens são um bom lugar para começar a procurar por problemas.

11.13.3. Substituindo o padrão AML

O bytecode do BIOS, conhecido como ACPI Machine Language (AML), é compilado de uma linguagem de origem chamada ACPI Source Language (ASL). O AML é encontrado na tabela conhecida como Tabela de Descrição do Sistema Diferenciado (Differentiated System Description Table - DSDT).

O objetivo do FreeBSD é que todos trabalhem com ACPI sem qualquer intervenção do usuário. Soluções alternativas ainda estão sendo desenvolvidas para erros comuns feitos pelos fornecedores de BIOS. O interpretador Microsoft™ (acpi.sys e acpiec.sys) não verifica rigorosamente a conformidade com o padrão e, portanto, muitos fornecedores de BIOS que testam apenas ACPI sob Windows™ nunca corrigem seu ASL. Os desenvolvedores do FreeBSD continuam a identificar e documentar qual comportamento não padrão é permitido pelo interpretador da Microsoft™ para replicá-lo para que o FreeBSD possa funcionar sem forçar os usuários a corrigir o ASL.

Para ajudar a identificar o comportamento de bugs e possivelmente corrigi-lo manualmente, uma cópia pode ser feita do ASL do sistema. Para copiar o ASL do sistema para um nome de arquivo especificado, use acpidump com -t, para mostrar o conteúdo das tabelas fixas e -d, para desmontar o AML:

# acpidump -td > my.asl

Algumas versões de AML assumem que o usuário está executando o Windows™. Para sobrescrever isto, defina hw.acpi.osname="Windows 2009" no /boot/loader.conf, usando a mais recente versão do Windows™ listada no ASL.

Outras soluções alternativas podem exigir que o my.asl seja personalizado. Se este arquivo for editado, compile o novo ASL usando o seguinte comando. Os avisos geralmente podem ser ignorados, mas erros são bugs que geralmente impedem que o ACPI funcione corretamente.

# iasl -f my.asl

Incluir -f força a criação do AML, mesmo que haja erros durante a compilação. Alguns erros, como a falta de declarações de retorno, são automaticamente contornados pelo interpretador do FreeBSD.

O nome do arquivo de saída padrão para iasl é DSDT.aml. Carregue este arquivo em vez da cópia com bugs do BIOS, que ainda está presente na memória flash, editando o /boot/loader.conf como segue:

acpi_dsdt_load="YES"
acpi_dsdt_name="/boot/DSDT.aml"

Certifique-se de copiar o DSDT.aml para /boot e, em seguida, reinicialize o sistema. Se isso resolver o problema, envie um diff(1) do antigo e novo ASL para a lista freebsd-acpi para que os desenvolvedores possam contornar o comportamento de bugs no acpica.

11.13.4. Obtendo e enviando informações de depuração

O driver ACPI possui um recurso de depuração flexível. Um conjunto de subsistemas e o nível de detalhamento podem ser especificados. Os subsistemas a serem depurados são especificados como camadas e são divididos em componentes (ACPI_ALL_COMPONENTS) e suporte de hardware ACPI (ACPI_ALL_DRIVERS). O detalhamento da saída de depuração é especificado como o nível e varia de apenas erros de relatório (ACPI_LV_ERROR) para tudo (ACPI_LV_VERBOSE). O nível é uma máscara de bits, por isso, várias opções podem ser definidas de uma só vez, separadas por espaços. Na prática, um console serial deve ser usado para registrar a saída para que ela não seja perdida quando o buffer de mensagem do console for liberado. Uma lista completa das camadas e níveis individuais é encontrada em acpi(4).

A saída de depuração não está ativada por padrão. Para ativá-la, adicione as opções ACPI_DEBUG ao arquivo de configuração do kernel personalizado se ACPI estiver compilado no kernel. Adicione ACPI_DEBUG=1 ao /etc/make.conf para ativá-lo globalmente. Se um módulo for usado em vez de um kernel personalizado, recompile apenas o módulo acpi.ko como segue:

# cd /sys/modules/acpi/acpi && make clean && make ACPI_DEBUG=1

Copie o acpi.ko compilado para /boot/kernel e adicione o nível e camada desejados ao /boot/loader.conf. As entradas neste exemplo permitem mensagens de depuração para todos os componentes e drivers de hardware ACPI e mensagens de erro de saída no nível menos detalhado:

debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
debug.acpi.level="ACPI_LV_ERROR"

Se as informações necessárias forem acionadas por um evento específico, como suspend e resume, não modifique o /boot/loader.conf. Em vez disso, use o sysctl para especificar o layer e o nível após inicializar e preparar o sistema para o evento específico. As variáveis que podem ser definidas usando sysctl são nomeadas da mesma forma que os parâmetros no /boot/loader.conf.

Depois que as informações de depuração forem coletadas, elas podem ser enviadas para a lista freebsd-acpi para que possam ser usadas pelos mantenedores do FreeBSD ACPI para identificar a causa raiz do problema e desenvolver uma solução.

Antes de enviar as informações de depuração para esta lista, certifique-se de que a versão mais recente do BIOS esteja instalada e, se disponível, a versão do firmware do controlador incorporado.

Ao enviar um relatório de problemas, inclua as seguintes informações:

  • Descrição do comportamento de bugs, incluindo tipo de sistema, modelo e qualquer coisa que faça com que o erro apareça. Explique com a maior precisão possível quando o bug começou a ocorrer se for novo.

  • A saída do dmesg após executar boot -v, incluindo quaisquer mensagens de erro geradas pelo bug.

  • A saída dmesg do boot -v com o ACPI desabilitado, se a desativação do ACPI ajudar a corrigir o problema.

  • Saída do sysctl hw.acpi. Isso lista quais recursos o sistema oferece.

  • A URL para uma versão do ASL do sistema hospedada na web. Não envie o ASL diretamente para a lista, pois pode ser muito grande. Gere uma cópia do ASL executando este comando:

    # acpidump -dt > name-system.asl

    Substitua o nome de login para name e fabricante/modelo para system. Por exemplo, use njl-FooCo6000.asl.

A maioria dos desenvolvedores do FreeBSD assina a lista de discussão FreeBSD-CURRENT, mas deve-se enviar os problemas para a lista freebsd-acpi para ter certeza de que ele será visto. Seja paciente ao esperar por uma resposta. Se o bug não for imediatamente aparente, envie um relatório de bug. Ao inserir um PR, inclua as mesmas informações solicitadas acima. Isso ajuda os desenvolvedores a rastrear o problema e resolvê-lo. Não envie um PR sem enviar primeiro um e-mail para a lista freebsd-acpi pois é provável que o problema já tenha sido relatado antes.

11.13.5. Referências

Mais informações sobre ACPI podem ser encontradas nos seguintes locais:


Última alteração em: 9 de março de 2024 por Danilo G. Baio