Capítulo 10. Administraçã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.

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.

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.

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.

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.

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.

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

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

• 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
  ...	...

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

Recompile e instale o novo kernel.

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

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.

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.

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.

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.

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.

Use o comando killall(1).

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.

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.

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:

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

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

“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.

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).

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.

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.

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.

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.

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)

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.

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.