Perguntas mais freqüentes sobre FreeBSD 2.X, 3.X e 4.X
Anterior |  | Próxima

# Capítulo 10 Administração do Sistema

10.1. Onde estão os arquivos que configuram a inicialização do sistema ?
10.2. Como posso adicionar um usuário de forma simples?
10.3. Depois de editar o crontab, mensagens como “`root: not found`” ficam aparecendo sempre. Por que?
10.4. Porque o erro “`you are not in the correct group to su root`” ocorre, quando eu tento virar `root` com o su ?
10.5. Cometi um erro no `rc.conf`, ou em algum outro arquivo de inicialização, e agora não posso corrigir essa alteração porque o sistema de arquivos é apenas-leitura. O que devo fazer?
10.6. Porque estou tendo problemas ao configurar minha impressora?
10.7. Como posso corrigir o mapeamento de teclados do meu sistema?
10.8. O que causa mensagens como: “`unknown: <PNP0303> can't assign resources`” na inicialização do sistema?
10.9. Porque eu não consigo fazer as quotas de usuários funcionarem de forma correta?
10.10. O FreeBSD suporta as primitivas de IPC do System V?
10.11. Como posso usar o sendmail para entregar mensagens com UUCP?
10.12. Como eu configuro e-mail em uma conexão dialup com a rede?
10.13. Que outros servidores de correio eletrônico posso usar no lugar do Sendmail?
10.14. Esqueci a senha de root! O que eu faço?
10.15. Como posso evitar que a seqüência de teclas Control+Alt+Delete reinicie o sistema?
10.16. Como posso converter arquivos de texto do DOS para o formato do Unix?
10.17. Como eu mato processos pelo seu nome?
10.18. Por que motivos o su está me atazanando pelo fato de não pertencer à ACL do `root`?
10.19. Como eu desinstalo o Kerberos?
10.20. Como posso adicionar pseudo-terminais ao sistema?
10.21. Por que motivo não consigo criar a device snd0?
10.22. Como posso reler o `/etc/rc.conf` e reiniciar o `/etc/rc` sem rebootar o sistema?
10.23. O que é uma sandbox?
10.24. O que é `securelevel` (nível de segurança do sistema)?
10.25. Tentei atualizar meu sistema para o último -STABLE, mas ele se tornou -RC ou -PRERELEASE! O que está havendo?
10.26. Tentei instalar um novo kernel, mas a rotina de chflags falhou. O que posso fazer?
10.27. Não consigo alterar mais de um segundo na hora no meu sistema. O que posso fazer?
10.28. Por que motivo o `rpc.statd` está usando 256 megabytes de memória?
10.29. Por que eu não posso retirar a flag `schg` dos arquivos?
10.30. Por que a autenticação do SSH via `.shosts` não funciona por padrão nas versões recentes do FreeBSD?
10.31. O que é o `vnlru`?

10.1. Onde estão os arquivos que configuram a inicialização do sistema ?

Do FreeBSD 2.0.5R até o 2.2.1R, o arquivo de configurações primário é o `/etc/sysconfig`. Todas as opções devem ser definidas nesse arquivo ou então em outros, como o `/etc/rc` (veja o manual para o rc(8)) e o `/etc/netstart`

Dê uma olhada no `/etc/sysconfig` e altere as variáveis de acordo com o que você quer configurar no seu sistema. O arquivo é repleto de comentários que auxiliam a correta definição dos valores a serem definidos.

A partir do 2.2.1 até o 3.0, o `/etc/sysconfig` foi renomeado para rc.conf(5), que é auto-descritivo, e cuja sintaxe foi melhorada no processo de substituição. O `/etc/netstart` agora se chama `/etc/rc.network`, de forma que todos os arquivos possam ser copiados com um simples comando como um `cp /usr/src/etc/rc* /etc`

E depois, a partir do FreeBSD 3.1, o `/etc/rc.conf` foi alterado para o `/etc/defaults/rc.conf`. Não edite esse arquivo! Ao invés disso, para todas as entradas que você queira alterar no `/etc/defaults/rc.conf`, basta apenas copiar a linha relativa à essa entrada para o `/etc/rc.conf` e depois modificar seu valor.

Por exemplo, caso deseje iniciar o named, o servidor DNS disponível no FreeBSD, a partir do FreeBSD 3.1 basta fazer isso:

    # echo named_enable="YES" >> /etc/rc.conf

Para iniciar serviços locais no FreeBSD 3.1 e posteriores, basta colocar os scripts shell de inicialização desses serviços no diretório `/usr/local/etc/rc.d`. Tais shell scripts devem ser executáveis e terminarem com a extensão .sh. No FreeBSD 3.0 ou anteriores, o arquivo `/etc/rc.local` era a única opção para iniciar serviços/processos locais automaticamente.

O arquivo `/etc/rc.serial` é usado para a inicialização de portas seriais (por exemplo, para definir as características das portas, e assim por diante).

O arquivo `/etc/rc.i386` é usado para configurações específicas de sistemas Intel e compatíveis, como por exemplo, emulação iBCS2 ou definições do sistema de console dos PC.

10.2. Como posso adicionar um usuário de forma simples?

Use o comando adduser(8). Caso prefira uma forma mais complexa (e mais completa), use o comando pw(8).

Para remover o usuário do sistema, use o comando rmuser(8). Mais uma vez, o pw(8) também funciona muito bem nesse caso.

10.3. Depois de editar o crontab, mensagens como “`root: not found`” ficam aparecendo sempre. Por que?

Normalmente esse é um problema causado ao se editar o crontab do sistema (`/etc/crontab`) e depois usar o crontab(1) para instala-lo:

    # crontab /etc/crontab

Essa não é a forma correta de fazer as coisas. O crontab do sistema tem um formato distinto do crontab dos usuários, o qual o crontab(1) atualiza (o manual do crontab(5) explica tais diferenças de forma mais detalhada).

Caso você tenha cometido esse engano, o novo crontab é uma simples cópia do `/etc/crontab`, ou seja, com um formato errado. Apague-o com o comando:

    # crontab -r

Da próxima vez que editar o `/etc/crontab`, nenhuma ação precisa ser tomada para avisar o cron(8) das alterações. Ele vai perceber as mudanças automaticamente.

Caso queira executar alguma tarefa diária, semanal ou mensal, é mais indicado adicionar alguns scripts de shell sob o `/usr/local/etc/periodic` e deixar o programa periodic(8), chamado a partir da tabela cron do sistema, cuidar das suas tarefas assim como ele faz com as outras tarefas pertinentes ao sistema.

A única razão para esse erro é que a tabela de cron do sistema tem um campo a mais, que especifica o usuário que deve executar o comando. No crontab do sistema padrão do FreeBSD, esse usuário é o `root`, em todas as entradas. Quando essa crontab é usada como a tabela de cron do `root` (que é diferente da tabela de cron do sistema), o cron(8) assume que a string `root` fosse um primeiro comando, mas esse comando não existe, por isso ocorre o erro.

10.4. Porque o erro “`you are not in the correct group to su root`” ocorre, quando eu tento virar `root` com o su ?

Essa é uma característica de segurança do FreeBSD. Para se tornar `root` com o su (ou qualquer outro usuário com privilégios de super usuário), é preciso fazer parte do grupo `wheel`. Sem essa característica, qualquer usuário com uma conta válida no sistema que soubesse a senha de `root` poderia obter privilégios de super usuário. Por causa do comportamento atual, essa afirmação não é verdadeira, uma vez que o su não vai nem permitir que o usuário dê a senha de `root`, caso ele não esteja no grupo `wheel`.

Para permitir que algum usuário se torne `root`, basta que ele faça parte do grupo `wheel`.

10.5. Cometi um erro no `rc.conf`, ou em algum outro arquivo de inicialização, e agora não posso corrigir essa alteração porque o sistema de arquivos é apenas-leitura. O que devo fazer?

Nessa situação, o comportamento esperado é que o sistema entre em modo monousuário e peça o caminho completo para o seu interpretador de comandos (sua shell). Basta confirmar a shell padrão, que ele oferece, com um simples `ENTER`, e depois executar um `mount /` para remontar o sistema de arquivos raiz ( / ) em modo leitura/escrita (rw). Também pode ser necessário executar um `mount -a -t ufs` para montar o sistema de arquivos onde o seu editor de texto preferido vai estar disponível. Caso seu editor esteja em um sistema de arquivos da rede, será necessário configurar a rede manualmente, ou usar um editor disponível localmente, como o ed(1).

Caso queira usar um editor de tela inteira como o vi(1) ou emacs(1), será necessário definir a variável de ambiente TERM como do tipo cons25, bastando um simples export TERM=cons25, de forma que tais editores possam carregar as informações corretas da base de dados do termcap(5).

Depois disso, o `/etc/rc.conf` pode ser editado normalmente, e a sintaxe problemática, corrigida. A mensagem de erro apresentada imediatamente após o carregamento do kernel indica o número da linha e o arquivo onde o erro aconteceu.

10.6. Porque estou tendo problemas ao configurar minha impressora?

Por gentileza, dê uma olhada nas páginas sobre impressão do Manual do FreeBSD. O documento deve responder a maioria de suas dúvidas. Veja a entrada sobre Impressão no Manual do FreeBSD.

Algumas impressoras precisam de um driver local, baseado em estações, para prover qualquer tipo de impressão. Essas impressoras são chamadas de “WinPrinters” e não são suportadas nativamente pelo FreeBSD. Se sua impressora não funciona sob DOS ou com Windows NT 4.0, provavelmente ela é uma WinPrinter. A única esperança de se obter uma impressora desse tipo funcionando, é verificar se o `port` `print/pnm2ppa` tem suporte para ela.

10.7. Como posso corrigir o mapeamento de teclados do meu sistema?

Por gentileza, refira-se à seção usando localização do Manual do FreeBSD, mais precisamente na parte sobre a configuração do console.

10.8. O que causa mensagens como: “`unknown: <PNP0303> can't assign resources`” na inicialização do sistema?

O trecho a seguir é citação de uma mensagem enviada na lista freebsd-current.

A mensagem “can't assign resources” indica que os equipamentos em questão são do tipo ISA, e que não existem entradas indicando drivers não-PnP compiladas no kernel. Esses equipamentos podem ser controladoras de teclados, controladora de interrupção programável e várias outras peças da infra-estrutura padrão do sistema. Os recursos não podem ser atribuídos por já existirem drivers usando tais endereços.

--Garrett Wollman `<wollman@FreeBSD.org>`, 24 Abril 2001 |

10.9. Porque eu não consigo fazer as quotas de usuários funcionarem de forma correta?

- Não habilite quotas na `/`,

- Coloque o arquivo de quotas indicando o sistema de arquivos onde se deseja estabelecer as quotas, por exemplo:

  Sistemas de arquivos | Arquivos de quotas
  --- | ---
  `/usr` | `/usr/admin/quotas`
  `/home` | `/home/admin/quotas`
  … | …

10.10. O FreeBSD suporta as primitivas de IPC do System V?

Sim, o FreeBSD suporta IPC ao estilo do System V. Esse suporte inclui compartilhamento de memória, mensagens e semáforos. É necessário adicionar as seguintes linhas no arquivo de configurações do seu kernel, para ativar o suporte:

    options    SYSVSHM	  # habilita memória compartilhada
    options    SYSVSEM          # habilita semáforos
    options    SYSVMSG          # habilita mensagens

> Nota: No FreeBSD 3.2 e posteriores, tais opções já fazem parte do kernel GENERIC, o que significa que tal suporte já deve estar compilado no seu sistema.

Recompile e instale o novo kernel.

10.11. Como posso usar o sendmail para entregar mensagens com UUCP?

A configuração do sendmail disponível por padrão no FreeBSD é direcionada para sites que estejam conectados à Internet. Servidores que pretendem entregar suas mensagens via UUCP devem instalar um novo arquivo de configurações do sendmail.

Alterar o `/etc/mail/sendmail.cf` manualmente é considerado tarefa para os mais puristas. A versão 8 do sendmail tem uma nova abordagem de arquivos de configuração por meio de pré processamento com o m4(1), onde os modelos de configuração são manipulados em um nível mais alto de abstração. Use os arquivos de configuração disponíveis sob /usr/src/usr.sbin/sendmail/cf.

Caso seu sistema não tenha sido instalado com os fontes, os arquivos de configuração do sendmail foram divididos em pacotes separados. Assumindo que você tenha o CDROM do FreeBSD montado, faça o seguinte:

    # cd /cdrom/src
    # cat scontrib.?? | tar xzf - -C /usr/src contrib/sendmail

Não se desespere, são apenas algumas centenas de Kilobytes em tamanho. O arquivo README no diretório cf serve de introdução básica ao uso do m4.

Para entregar mensagens via UUCP, o melhor conselho é usar o `mailtertable`. Trata-se de uma base de dados que o sendmail usa para basear suas decisões de roteamento de mensagens.

Primeiro, é necessário criar seu arquivo `.mc`. O diretório `/usr/src/usr.sbin/sendmail/cf/cf` é o diretório home para esse tipo de arquivo. Dê uma olhada, já existem alguns exemplos disponíveis por lá. Se assumirmos que você chamou o arquivo de `foo.mc`, para converte-lo para um arquivo `sendmail.cf` válido basta:

    # cd /usr/src/usr.sbin/sendmail/cf/cf
    # make foo.cf
    # cp foo.cf /etc/mail/sendmail.cf

Um arquivo `.mc` típico, se parece com algo mais ou menos assim:

    VERSIONID(`Número da sua versão')
    OSTYPE(bsd4.4)

    FEATURE(accept_unresolvable_domains)
    FEATURE(nocanonify)
    FEATURE(mailertable, `hash -o /etc/mail/mailertable')

    define(`UUCP_RELAY', your.uucp.relay)
    define(`UUCP_MAX_SIZE', 200000)
    define(`confDONT_PROBE_INTERFACES')

    MAILER(local)
    MAILER(smtp)
    MAILER(uucp)

    Cw    your.alias.host.name
    Cw    youruucpnodename.UUCP

As linhas contendo as entradas `accept_unresolvable_domains`, `nocanonify`, e `confDONT_PROBE_INTERFACES` previnem o uso do DNS durante a entrega das mensagens. A cláusula `UUCP_RELAY` é necessária por razões bizarras, nem pergunte quais. Apenas coloque o nome de uma estação que possa manipular endereços com pseudo-domínio .UUCP; normalmente o endereço de relay de e-mail do seu Provedor de Serviço Internet deve servir.

Depois disso, é necessário usar o arquivo `/etc/mail/mailertable`. Caso exista apenas um link para fora, por onde todos os e-mails são roteados, as seguintes definições são o bastante:

    #
    # makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable
    .	 uucp-dom:your.uucp.relay

Um exemplo mais complexo, se pareceria com:

    #
    # makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable
    #
    horus.interface-business.de   uucp-dom:horus
    .interface-business.de        uucp-dom:if-bus
    interface-business.de         uucp-dom:if-bus
    .heep.sax.de                  smtp8:%1
    horus.UUCP                    uucp-dom:horus
    if-bus.UUCP                   uucp-dom:if-bus
    .                             uucp-dom:

Como pode-se perceber, se trata de um arquivo usado na vida real. As primeiras três linhas tratam situações especiais onde as mensagens endereçadas aquele domínio não devem ser roteadas pela saída padrão, mas ao invés disso, ser entregues para algum servidor UUCP vizinho, de forma a encurtar o caminho para entrega dos e-mails. A linha seguinte trata mensagens para rede Ethernet local, para domínios onde os mails possam ser entregues via SMTP. Finalmente, os vizinhos UUCP são mencionados na notação do pseudo-domínio .UUCP, que permite um ``uucp-neighbor`!`recipient`` sobrescrever as regras padrão. A última linha é sempre um ponto, que indica que todos os e-mails que não foram tratados pelas entradas anteriores cuja entrega seja do tipo UUCP, devem ser tratados por um dos vizinhos UUCP que sirva como gateway universal com o resto do mundo. Todas as estações antecedendo a entrada `uucp-dom:` devem ser nomes de vizinhos UUCP válidos, que podem ser checados com o comando `uuname`.

Para lembrar que esse arquivo precisa ser convertido em base de dados do tipo DBM, o comando necessário para tomar essa ação está comentado no início do arquivo mailertable. Esse comando deve ser executado sempre que o mailertable for alterado.

Dica final: caso tenha dúvidas se uma rota de e-mail em particular irá funcionar, lembre-se que a opção `-bt` do sendmail permite que ele seja iniciado em modo de testes de endereço; simplesmente digite `3,0` seguido do endereço que você quer testar o roteamento de mensagens. A última linha irá indicar o agente de transferência interno que foi usado, a estação de destino com a qual esse agente de entrega irá se comunicar, e o seu endereço. Para sair desse modo, digite Control-D.

    % sendmail -bt
    ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
    Enter <ruleset> <address>
    > 3,0 foo@example.com
    canonify           input: foo @ example . com
    ...
    parse            returns: $# uucp-dom $@ your.uucp.relay $: foo < @ example . com . >
    > ^D

10.12. Como eu configuro e-mail em uma conexão dialup com a rede?

Se a sua conexão discada lhe atribui um endereço IP estático, não é necessário configurar nenhuma opção extra. Ajuste o nome da sua estação para o nome que a identifica na Internet, e o sendmail fará o resto.

Mas se a conexão PPP lhe atribui endereços dinâmicos, provavelmente o seu Provedor de Serviço Internet oferece uma conta de correio eletrônico em seus servidores. Vamos assumir que o nome do domínio do seu provedor é `example.net`, e que o nome do seu usuário é `user`. Vamos assumir também que o nome da sua estação seja `bsd.home` e que o Provedor de Serviço Internet defina que o endereço `relay.example.net` deva ser usado para relay de mensagens eletrônicas.

Para acessar as mensagens da sua caixa de correio, é necessário usar um agente de busca. O Fetchmail é uma boa escolha, já que ele suporta vários protocolos distintos. Normalmente o provedor em questão oferece serviço de POP3. Caso sua conexão PPP seja estabelecida à nível de usuário (user-PPP), para acessar suas mensagens automaticamente ao estabelecer-se uma conexão com a rede, basta adicionar a seguinte entrada no arquivo `/etc/ppp/ppp/linkup`:

    MYADDR:
      !bg su user -c fetchmail

Caso esteja usando o sendmail (como foi descrito anteriormente) para entregar suas mensagens para endereços não-locais, insira o comando:

      !bg su user -c "sendmail -q"

depois da entrada apresentada anteriormente. Esse comando irá forçar o sendmail a processar sua fila de e-mail tão logo uma conexão com a rede seja estabelecida.

Assumindo que exista uma conta para o `user` na máquina `bsd.home`. No diretório home do `user` na estação `bsd.home`, crie um arquivo `.fetchmailrc` com o seguinte conteúdo:

    poll example.net protocol pop3 fetchall pass MySecret

Esse arquivo não deve ter permissão de leitura para nenhum outro usuário, a não ser o `user` já que ele contém a `sua senha`.

Para garantir que o cabeçalho `from:` esteja sempre correto, é necessário indicar ao sendmail que o endereço `user@example.net` deve ser usado ao invés de `user@bsd.home`. Também é interessante configurar o sendmail para entregar suas mensagens via `relay.example.net`, permitindo transmissão de mensagens de forma mais rápida.

O seguinte arquivo `.mc` deve ser o bastante:

    VERSIONID(`bsd.home.mc version 1.0')
    OSTYPE(bsd4.4)dnl
    FEATURE(nouucp)dnl
    MAILER(local)dnl
    MAILER(smtp)dnl
    Cwlocalhost
    Cwbsd.home
    MASQUERADE_AS(`example.net')dnl
    FEATURE(allmasquerade)dnl
    FEATURE(masquerade_envelope)dnl
    FEATURE(nocanonify)dnl
    FEATURE(nodns)dnl
    define(`SMART_HOST', `relay.example.net')
    Dmbsd.home
    define(`confDOMAIN_NAME',`bsd.home')dnl
    define(`confDELIVERY_MODE',`deferred')dnl

Por gentileza, refira-se à seção anterior para obter detalhes sobre como transformar esse arquivo `.mc` em um arquivo `sendmail.cf`. Não se esqueça também de reiniciar o sendmail depois de alterar o `sendmail.cf`.

10.13. Que outros servidores de correio eletrônico posso usar no lugar do Sendmail?

O Sendmail é o programa servidor de correio eletrônico padrão no FreeBSD, mas ele pode ser facilmente substituído por qualquer outro MTA (por instância, um MTA instalado a partir do `ports`).

Existem vários MTA's que servem de alternativa ao Sendmail na Coleção de `Ports` do FreeBSD, sendo o `mail/exim`, `mail/postfix`, `mail/qmail`, `mail/zmailer`, os mais populares.

A diversidade é sempre uma boa indicação, e o fato de ter vários servidores de e-mail disponíveis é ótimo. Conteúdo, evite perguntas como “O Sendmail é melhor que o Qmail?” nas listas de discussão. Se você realmente quer saber, procure no histórico das listas. As vantagens e desvantagens de cada MTA já foram discutidas inúmeras vezes.

10.14. Esqueci a senha de root! O que eu faço?

Em primeiro lugar, não entre em pânico! Reinicie o seu FreeBSD, digite `boot -s` na tela do Boot: (ou apenas `-s` para as versões anteriores à 3.2 do FreeBSD) para entrar e modo monousuário. Quando o sistema perguntar sobre que shell usar, aperte ENTER. Você estará em uma prompt de comandos; digite `mount -u /` para montar o sistema de arquivos raiz com leitura/escrita, e depois `mount -a` para remontar todos os seus sistemas de arquivos. Execute o comando `passwd root` para modificar a senha de root do sistema, e depois digite exit(1) para continuar a inicialização em modo multiusuário.

10.15. Como posso evitar que a seqüência de teclas Control+Alt+Delete reinicie o sistema?

Caso esteja usando o syscons (o driver padrão para o console) em um sistema FreeBSD 2.2.7 ou posterior, construa e instale um novo kernel com a opção:

    options SC_DISABLE_REBOOT

Caso use o driver de console PCVT em um FreeBSD 2.2.5 ou posterior, use a seguinte linha:

    options PCVT_CTRL_ALT_DEL

Em versões anteriores às citadas, edite o mapeamento do seu teclado, usado para o console, e substitua a palavra `boot` por `nop`. O mapeamento de teclado padrão está em `/usr/share/syscons/keymaps/us.iso.kbd`. O `/etc/rc.conf` deve ser instruído de forma que esse arquivo seja lido. Se você estiver usando um outro mapa específico para o seu país, edite esse mapa ao invés do padrão.

10.16. Como posso converter arquivos de texto do DOS para o formato do Unix?

Use esse comando do perl:

    % perl -i.bak -npe 's/\r\n/\n/g' file...

onde `file` indica o arquivo ou arquivos a serem processados. As modificações são feitas no próprio arquivo e o original é salvo com a extensão .bak.

O comando tr(1) também pode ser usado:

    % tr -d '\r' < dos-text-file > unix-file

Onde `dos-text-file` é o arquivo com o texto em formato DOS, enquanto o `unix-file` armazenará a saída convertida. Usar o tr(1) é um pouco mais rápido do que usar o perl.

10.17. Como eu mato processos pelo seu nome?

Use o comando killall(1).

10.18. Por que motivos o su está me atazanando pelo fato de não pertencer à ACL do `root`?

Esse erro é proveniente do sistema de autenticação da distrição do Kerberos. O problema não é uma perturbação fatal. Basta executar o su com a opção -K ou então desinstalar o Kerberos, como será descrito na próxima questão.

10.19. Como eu desinstalo o Kerberos?

Para remover o Kerberos do sistema, reinstale a distribuição `bin` da versão que está sendo usada. Caso tenha o CDROM do FreeBSD, monte-o (vamos assumir, em /cdrom) e execute os comandos:

    # cd /cdrom/bin
    # ./install.sh

Ou então, apague todas as opções “MAKE_KERBEROS” do `/etc/make.conf` e recompile todo o sistema com um build world.

10.20. Como posso adicionar pseudo-terminais ao sistema?

Caso tenha inúmeras conexões telnet, ssh, X, ou tela de usuário, é provável que você atingirá o limite dos seus pseudo-terminais. Aqui estão as instruções de como adicionar mais pseudo-terminais:

1. Construa e instale um novo kernel com a linha

       pseudo-device pty 256

   em seu arquivo de configurações.

2. Execute os comandos

       # cd /dev
       # sh MAKEDEV pty{1,2,3,4,5,6,7}

   de forma a criar 256 novos devices para os novos terminais.

3. Edite o `/etc/ttys` e adicione uma linha para cada um dos 256 terminais. Tais entradas devem ter o formato correspondente às entradas já existentes, por exemplo:

       ttyqc none network

   A ordem de definição das letras é expressa como `tty[pqrsPQRS][0-9a-v]`, ao ilustrarmos em expressões regulares.

4. Reinicie o sistema com o novo kernel, e pronto.

10.21. Por que motivo não consigo criar a device snd0?

Simples, porque não existe a device `snd`. Esse nome é usado para identificar o conjunto de devices que compõem os drivers de som do FreeBSD, como as devices `mixer`, `sequencer`, e `dsp`.

Para criar tais devices, basta executar:

    # cd /dev
    # sh MAKEDEV snd0

10.22. Como posso reler o `/etc/rc.conf` e reiniciar o `/etc/rc` sem rebootar o sistema?

Vá para o modo monousuário e volte para o modo multiusuário.

É simples; no console, faça:

    # shutdown now
    (Note: without -r or -h)

    # return
    # exit

10.23. O que é uma sandbox?

“Sandbox” é um jargão usado em discussões pertinentes à segurança de sistemas. Pode significar duas coisas:

- Um processo enquadrado em um conjunto de paredes virtuais que são criadas para prevenir que algum usuário, ao explorar alguma inconformidade do processo, possa também explorar e obter privilégios no sistema operacional como um todo.

  O processo deve conseguir “rodar” dentro dessas paredes, ou seja, nada que o processo possa fazer ao executar seu código, pode ser capaz de violar tais paredes. Dessa forma não é necessária uma auditoria detalhada do código e das ações do processo para que se possa realizar algumas afirmações pertinentes à segurança de tal sistema.

  Tais paredes podem ser a identificação de um usuário (userid), por exemplo. Essa é a definição de sandbox usada nas páginas de manuais do named e de security.

  Observe o serviço `ntalk`, como exemplo (veja o /etc/inetd.conf). Esse serviço costumava ser executado com userid do `root`. Hoje em dia o processo roda com o userid do `tty`. O usuário `tty`, portanto, é uma sandbox criada para dificultar qualquer atividade de um usuário malicioso que por ventura consiga acesso ao sistema por meio do ntalk. Com essa sandbox, uma violação de segurança bem sucedida via `ntalk` dificultaria qualquer ação tomada além das possíveis com o userid do `tty`.

- Um processo criado dentro de um ambiente de simulação. Essa é uma situação mais complexa. Basicamente implica que qualquer pessoa má intencionada que consiga explorar tal processo, acreditará que pode obter acesso à todo o ambiente, nas na verdade, estará apenas acessando um sistema de simulação, não alterando nenhum dado real.

  A forma mais comum de conseguir criar um ambiente simulado como esse, é criando um subdiretório à partir de onde o processo consiga acessar (uma cópia de) qualquer arquivo do sistema que por ventura ele precise, e executar esse processo simulando um diretório raiz (ou seja, para o processo, o `/` será o subdiretório determinado, e não o verdadeiro `/` do sistema).

  Outra situação comum é montar um sistema de arquivos base com apenas permissão de leitura, e depois criar um outro sistema de arquivos em uma camada superior, com acesso de escrita/leitura, dando ao processo a impressão de poder ler/escrever em todo o sistema de arquivos. Apenas o processo em questão percebe esse ambiente, enquanto os outros não são necessariamente ludibriados.

  A intenção é que tais sandbox sejam tão transparentes que qualquer usuário (ou hacker) não consiga perceber que está dentro de uma.

Os sistemas Unix costumam implementar esses dois principais tipos de sandbox, um em nível de processo e o outro, muito comum, em nível de userid.

Cada processo Unix é completamente separado dos outros, por meio de algum tipo de parede de segurança. Um processo nunca modifica o espaço de endereçamento de outro, diferente do ambiente Windows onde cada processo pode facilmente sobrescrever endereços de outros processos, fazendo o sistema travar.

Cada processo Unix é de propriedade de um userid em particular. Caso o userid não seja do `root`, ele serve de parede de segurança em relação aos processos pertencentes a outros usuários. Os userid também são usados para proteger dados armazenados em disco.

10.24. O que é `securelevel` (nível de segurança do sistema)?

`securelevel` (nível de segurança do sistema) é um mecanismo de segurança implementado no kernel do FreeBSD. Basicamente, quando o `securelevel` é positivo, o kernel restringe algumas tarefas do sistema; nem mesmo o superusuário (por exemplo, o `root`) tem permissão de realizar tais tarefas. Na data que este `FAQ` foi escrito, o mecanismo de `securelevel` do FreeBSD era capaz de, entre outras coisas, limitar as habilidades de:

- retirar algumas flags de arquivos, como a `schg` (flag de imutabilidade do sistema),

- escrever na memória do kernel por meio do `/dev/mem` e `/dev/kmem`,

- carregar módulos do kernel, e

- alterar regras de Firewall do ipfirewall(4).

Para verificar o estado do `securelevel` (nível de segurança do sistema) em um sistema em funcionando, simplesmente execute o seguinte comando:

    # sysctl kern.securelevel

A saída apresentará o nome da variável do sysctl(8) (nesse caso, `kern.securelevel`) e um número. Esse último será o valor atual do nível de segurança do kernel do FreeBSD. Caso esse valor seja positivo (maior que 0), ao menos algumas das características dos níveis de segurança estarão habilitadas.

Os níveis de segurança não podem ser diminuídos em um sistema que está funcionando se isso fosse possível o `securelevel` (nível de segurança do sistema) perderia sua funcionalidade. Caso seja necessário executar alguma tarefa que necessite que o nível de segurança seja não-positivo (por exemplo, um `installworld` ou alterar a data do sistema) será preciso alterar as definições de `securelevel` (nível de segurança do sistema) no `/etc/rc.conf` (mais precisamente, as variáveis `kern_securelevel` e `kern_securelevel_enable`) e reiniciar o sistema.

Para obter mais informações quanto aos níveis de segurança e sobre as funções específicas de cada nível, por gentileza, consulte a página de manual do init(8).

> Atenção: O `securelevel` (nível de segurança do sistema) não é uma bala de prata; ele tem várias deficiências óbvias. A mais frequênte é provocar uma falsa sensação de segurança.

> Um dos maiores problemas, e portanto que deve ser bem observada pelo administrador do sistema, é que, para que o `securelevel` (nível de segurança do sistema) se torne efetivo, todos os arquivos usados pelo processo de inicialização até que os níveis de segurança se tornem positivos, devem estar seguros. Se um usuário que deseja atacar o sistema, conseguir que seu código seja executado antes que o nível de segurança seja definido (o que ocorre pouco depois do processo de inicialização, visto que algumas funções que o sistema precisa realizar, não podem ser iniciadas com um nível elevado de segurança), a proteção do `securelevel` (nível de segurança do sistema) será invalidada. Por outro lado, a tarefa de assegurar que todos os arquivos necessários pelo processo de inicialização estejam em conformidade, não é tecnicamente impossível, mas, O processo de manutenção de um ambiente em tais condições se tornaria um pesadelo, visto que seria necessário baixar o sistema, no mínimo para modo monousuário sempre que fosse necessário modificar os arquivos de configuração do mesmo.

> Esse e outros pontos são freqüentemente discutidos nas listas do FreeBSD, em especial na freebsd-security. Por gentileza, queira fazer uma busca no histórico da lista, clicando aqui, para uma discussão extensa sobre o assunto. Algumas pessoas estão esperançosas de que o securelevel logo será afastado, em favor de um mecanismo de segurança mais refinado, mas as coisas ainda estão confusas a este respeito.

> Considere-se advertido.

10.25. Tentei atualizar meu sistema para o último -STABLE, mas ele se tornou -RC ou -PRERELEASE! O que está havendo?

A resposta mais curta: É só um nome, RC é um acrônimo para “Release Candidate”. Significa que uma nova versão está eminente. No FreeBSD, -PRERELEASE é tipicamente um sinonimo de código congelado antes de uma nova versão. (Em algumas versões, o título -BETA foi usado sob as mesmas circunstâncias em que o -PRERELEASE seria).

A resposta longa: O FreeBSD normalmente deriva suas versões de duas fontes de origem. As versões principais, ponto-zero, como o 3.0-RELEASE e o 4.0-RELEASE que são marcadas inicialmente como o topo da cadeia de desenvolvimento, normalmente chamados de -CURRENT. As versões menores (como 3.1-RELEASE ou 4.2-RELEASE), são criados a partir do snapshot mais recente da ramificação ativa marcada como -STABLE. A partir do 4.3-RELEASE, cada versão conta também com sua própria ramificação, que pode ser acessada por usuários que queiram apenas um nível extremamente conservador de desenvolvimento (tipicamente, apenas consultores de segurança).

Quando uma versão está para ser criada, a ramificação de onde ela se derivará deve passar por um certo processo. Parte desse processo é o congelamento do código. Quando o processo de congelamento do código se inicia, o nome desta ramificação é alterado para indicar que ela está para se tornar uma versão. Por exemplo, se a ramificação usada chamava-se 4.5-STABLE, ela passa a se chamar 4.6-PRERELEASE para indicar que o código está congelado, e indicar que testes extras, pré versão, estão acontecendo. Durante esse período alterações pertinentes a correções de problemas são realizadas. Quando o novo código está pronto para ser lançado, ele passa a ser chamado de -RC (nesse exemplo, 4.6-RC), indicando que provavelmente a nova versão será criada a partir do código atual. Nesse estágio, apenas os problemas mais sérios são corrigidos. Depois que a versão é finalmente lançado (4.6-RELEASE nesse exemplo) e a nova ramificação com o nome dessa versão foi criada, ela passa a se chamar -STABLE; 4.6-STABLE no nosso exemplo.

Para obter mais informações sobre a numeração das versões e sobre as várias ramificações CVS, por gentileza, refira-se ao artigo sobre a Engenharia de Releases.

10.26. Tentei instalar um novo kernel, mas a rotina de chflags falhou. O que posso fazer?

A resposta curta: provavelmente você está com o `securelevel` (nível de segurança do sistema) acima do 0. Reinicie o sistema em modo mono usuário e instale o kernel.

A resposta mais completa: O FreeBSD não permite que as flags do sistema sejam alteradas caso o `securelevel` (nível de segurança do sistema) seja maior que 0. O nível atual do `securelevel` (nível de segurança do sistema) pode ser verificado com o comando:

    # sysctl kern.securelevel

O `securelevel` (nível de segurança do sistema) não pode ser diminuído; é necessário iniciar o sistema em modo mono usuário, ou alterar o nível de segurança em `/etc/rc.conf`, depois reiniciar. Veja a página de manual do init(8) para obter informações mais detalhadas sobre o `securelevel` (nível de segurança do sistema), e veja também o `/etc/defaults/rc.conf` e a página de manual do rc.conf(5) para obter mais informações quanto ao rc.conf.

10.27. Não consigo alterar mais de um segundo na hora no meu sistema. O que posso fazer?

A resposta curta: provavelmente o sistema está com `securelevel` (nível de segurança do sistema) acima do 1. Reinicie o sistema em modo mono usuário e altere a data.

A resposta mais completa: O FreeBSD não permite que a hora do sistema seja alterada por mais de um segundo quando o `securelevel` (nível de segurança do sistema) do kernel é maior que 1. O nível atual do `securelevel` (nível de segurança do sistema) pode ser verificado com o comando:

    # sysctl kern.securelevel

O `securelevel` (nível de segurança do sistema) não pode ser diminuído; é necessário iniciar o sistema em modo mono usuário, ou alterar o nível de segurança em `/etc/rc.conf`, depois reiniciar. Veja a página de manual do init(8) para obter informações mais detalhadas sobre o `securelevel` (nível de segurança do sistema), e veja também o `/etc/defaults/rc.conf` e a página de manual do rc.conf(5) para obter mais informações quanto ao rc.conf.

10.28. Por que motivo o `rpc.statd` está usando 256 megabytes de memória?

Não, mão existe nenhuma falha no uso da memória, e ele nã é usando 256MB de RAM. Ele simplesmente gosta de (ele sempre faz isso) mapear uma quantia obscena de memória em seu endereçamento, simplesmente por conveniência. Não existe nada terrivelmente errado com esse comportamento, de um ponto de vista técnico; a única questão é que assim o top(1) e o ps(1) ficam completamente perdidos.

O rpc.statd(8) mapeia seu arquivo de status (localizado sob o `/var`) no seu endereçamento para economiza preocupações sobre esse remapeamento em um segundo momento, quando o arquivo precisa crescer. O mapeamento é feito a um valor enorme. Analisando o código fonte, podemos evidenciar que o tamanho do argumento do mmap(2) é `0x10000000`, ou exatos 256MB em sistemas de arquitetura IA32.

10.29. Por que eu não posso retirar a flag `schg` dos arquivos?

O sistema está sendo executado em um nível de segurança elevado (maior que 0). Diminua o nível de segurança e tente novamente. Para obter mais informações, por gentileza, refira-se à seção sobre `securelevel` (nível de segurança do sistema) do `FAQ`, e à página de manual do init(8)

10.30. Por que a autenticação do SSH via `.shosts` não funciona por padrão nas versões recentes do FreeBSD?

O motivo é simples. A autenticação via `.shosts` não funciona mais por padrão porque o ssh(1) não está instalado com suid de root por padrão. Razões óbvias de segurança. Para “corrigir” isto, pode-se fazer o seguinte:

- Para uma alteração permanente, defina `ENABLE_SUID_SSH` como `true` no arquivo `/etc/make.conf` e recompile o ssh (ou execute um make world).

- Uma correção temporária pode ser mudar os modos de permissão do `/usr/bin/ssh` para `4555` simplesmente executando o comando `chmod 4555 /usr/bin/ssh` logado como `root`. Depois, defina `ENABLE_SUID_SSH= true` no `/etc/make.conf` para que as alterações tenham efeito todas as vezes que um make world for feito.

10.31. O que é o `vnlru`?

O `vnlru` limpa e libera os vnodes quando o sistema atinge o limite do `kern.maxvnodes`. Essa thread do kernel se mantém inativa a maior parte do tempo, e só se inicia caso exista uma grande quantidade de memória RAM, e o sistema esteja acessando dezenas de milhares de arquivos pequenos.

Anterior | Principal | Próxima
Discos, Sistemas de Arquivos e Carregadores de Inicialização (Boot Loaders) |  | O sistema X, sistema de interface gráfica e os Consoles Virtuais

Este, e outros documentos, podem ser obtidos em ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

Para perguntas sobre FreeBSD, leia a documentação antes de contatar <questions@FreeBSD.org>.
Para perguntas sobre esta documentação, envie e-mail para <doc@FreeBSD.org>.