![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[Índice da FAQ] [Seção 9 - Migração para OpenBSD] [Seção 11 - O sistema X Window]
No OpenBSD, usuários que estão no grupo wheel têm permissão para usar o su(1) para se tornarem root. Usuários que não estão no grupo "wheel" não podem usar o su(1). Caso contrário, o usuário receberá uma mensagem de erro como retorno.
Se você está criando um novo usuário com o adduser(8), você pode colocá-lo no grupo wheel adicionando o nome do grupo wheel como resposta para "Invite user into other groups:". Isso o adicionará ao grupo e o arquivo /etc/group ficará parecido com:
wheel:*:0:root,ericj
Se você está procurando uma maneira de permitir aos usuários acesso limitado aos privilégios de super usuário, sem colocá-los no grupo "wheel", use o sudo(8).
Para duplicar seu sistema de arquivos, use o dump(8) e o restore(8). Por exemplo, para duplicar tudo que esteja no diretório SRC para o diretório DST, faça um:
# cd /SRC; dump 0f - . | (cd /DST; restore -rf - )
dump é projetado para fornecer possibilidades de backup, e ele pode ser exagerado se você apenas quer duplicar uma parte de um (ou todo o) sistema de arquivos. O comando tar(1) pode ser mais rápido para essa operação. O formato é muito parecido com:
# cd /SRC; tar cf - . | (cd /DST; tar xpf - )
Os arquivos principais que o administrador de sistema deve se concentrar são: /etc/rc.conf (como guia), /etc/rc.conf.local (para alterações), /etc/rc.local e /etc/rc.shutdown. Para compreender o funcionamento do processo rc(8), veja o fluxo:
Depois que o kernel é inicializado, o /etc/rc é iniciado:
A maioria dos daemons e serviços contidos no OpenBSD são controlados na inicialização pelas variáveis definidas no arquivo de configuração /etc/rc.conf. Dê uma olhada no arquivo /etc/rc.conf. Você verá linhas similares a esta:
ftpd_flags=NO # for non-inetd use: ftpd_flags=""
Uma linha igual a essa mostra que o ftpd(8) não é carregado com o sistema (pelo menos não como um daemon através do rc(8); o ftpd na maioria das vezes é executado pelo inetd(8), veja a FAQ sobre FTP anônimo para ler mais sobre isso). Cada linha tem um comentário que mostra os sinalizadores para o uso normal daquele daemon ou serviço. Isso não significa que você deve executar aquele daemon ou serviço com aqueles sinalizadores. Leia a página de manual referente ao assunto para ver como você pode ter aquele daemon ou serviço carregando de qualquer forma que você quiser.
Nós recomendamos fortemente que você nunca toque no /etc/rc.conf. Ao invés disso, crie o arquivo /etc/rc.conf.local, copie de /etc/rc.conf apenas as linhas que você precisa alterar, e ajuste-as do modo que quiser. Isso torna as futuras atualizações de versão fáceis -- todas as modificações/atualizações estão em um arquivo que não foi modificado por você. De fato, o processo de atualização de versão padrão assume que você não modificou o /etc/rc.conf e sobrescreve-o com a nova versão do arquivo.
Por exemplo, esta é a linha padrão relacionada ao httpd(8).
httpd_flags=NO # for normal use: "" (or "-DSSL" after reading ssl(8))
Aqui você pode ver que para carregar o httpd normalmente nenhum sinalizador é necessário, então uma linha como httpd_flags="" adicionada ao /etc/rc.conf.local cumpre a tarefa. Mas para carregar o httpd com SSL ativo (consulte a FAQ sobre SSL ou ssl(8)), você começaria com uma linha como httpd_flags="-DSSL", embora você possa precisar adicionar outros parâmetros por outros motivos.
Para outros daemons que você deseja instalar no seu sistema através de pacotes ou outros meios, você pode usar o arquivo /etc/rc.local. Por exemplo, eu instalei um daemon que se situa em /usr/local/sbin/daemonx, e quero que ele carregue no momento da inicialização. Eu poderia adicionar uma entrada no /etc/rc.local igual a esta:
if [ -x /usr/local/sbin/daemonx ]; then echo 'Starting daemonx'; /usr/local/sbin/daemonx fi
(Se o daemon não se destaca automaticamente durante a inicialização, lembre-se de adicionar um "&" no fim da linha de comando.)
A partir de agora esse daemon será carregado no inicialização. Você será capaz de ver qualquer erro na inicialização, sendo que uma inicialização normal, sem erros, deve mostrar uma linha como esta:
Starting daemonx
Esses scripts (um para cada daemon) são chamados pelo rc. A ordem de execução dos daemons do sistema está presenta no código do rc, e a ordem de pacotes adicionais é controlada através da variável de ambiente pkg_scripts, que deve ser configurada no arquivo /etc/rc.conf.local. Note que o simples fato de adicionar um script no diretório /etc/rc.d não o faz ser carregado automaticamente no processo de boot; o nome do script deve, também, ser especificado na variável pkg_scripts para que ele seja carregado durante o processo de boot do OpenBSD.
The starting of system scripts is determined by entries in the /etc/rc.conf.local file. For example, /etc/rc.d/httpd does not start httpd(1) unless /etc/rc.conf or /etc/rc.conf.local contains a line defining the "httpd_flags" variable. To help make sure your system will come up as expected on the next boot, the rc.d scripts will not run their daemon if the appropriate variable is not defined. You can, of course, manually invoke /usr/sbin/httpd directly with whatever options you wish, if you wish to run the program manually.
Perceba que em vez de ter cada script em /etc/rc.d, controlando todas as operações de startup, shutdown, reload, restart e check pode ser reduzida a uma especificação com muito poucas variáveis¿¿ com o uso do rc.subr, que gerencia a maior parte dessas tarefas de forma padronizada no OpenBSD.
Por exemplo, o daemon de nossa aplicação daemonx pode ser iniciado através de um script presente em /etc/rc.d com o seguinte conteúdo:
Em seguida, adicionar o nome do script para gerenciamento do daemon a variável pkg_scripts em /etc/rc.conf.local.#!/bin/sh daemon="/usr/local/sbin/daemonx" . /etc/rc.d/rc.subr rc_cmd $1
/etc/rc.shutdown é um script que é executado no desligamento. Qualquer tarefa que você queira fazer antes do sistema ser desligado deve ser adicionada nesse arquivo. Se você usa o apm, você pode também definir "powerdown=YES". Isso é o equivalente do "shutdown -p".
Tente isto:
# grep relay-domains /etc/mail/sendmail.cf
A saída talvez se pareça com esta:
FR-o /etc/mail/relay-domains
Se esse arquivo não existe, crie-o. Você precisa especificar as máquinas que estão enviando correio eletrônico remotamente, com a seguinte sintaxe:
.domain.com #Allow relaying for/to any host in domain.com sub.domain.com #Allow relaying for/to sub.domain.com and any host in that domain 10.2 #Allow relaying from all hosts in the IP net 10.2.*.*
Não se esqueça de enviar um sinal 'HangUP' para o sendmail (um sinal que faz com que a maioria dos daemons leiam novamente seus arquivos de configuração):
# kill -HUP `head -1 /var/run/sendmail.pid`
A maioria dos problemas relacionados ao POP são problemas com arquivos temporários e arquivos bloqueados. Se seu servidor POP envia uma mensagem de erro do tipo:
-ERR Couldn't open temporary file, do you own it?
Tente configurar suas permissões do seguinte modo:
permissões em /var drwxrwxr-x 2 bin mail 512 May 26 20:08 mail permissões em /var/mail -rw------- 1 username username 0 May 26 20:08 username
Outra coisa para verificar é se o usuário é realmente o dono de seu arquivo em /var/mail. Normalmente esse deve ser o caso (por exemplo, o dono de /var/mail/joe deveria ser o próprio usuário joe), mas se não está definido corretamente, essa pode ser a causa do problema!
Normalmente, deixar o /var/mail com permissão de escrita para o grupo "mail" cria alguns problemas de segurança. É provável que você nunca terá problemas com ele, mas pode ter! (especialmente se seu sítio é de grande volume, como um "ISP", ...) Existem vários servidores POP que você pode instalar diretamente através da coleção de portes. Se possível, use o popa3d, que está disponível na instalação base do OpenBSD. Também poderia ser o caso de uma seleção incorreta das opções para o seu daemon pop. Ou você precisa apenas mudar o diretório em que ele faz o bloqueio (embora o bloqueio somente seria de valor para o daemon POP).
Nota: O OpenBSD não tem um grupo com o nome "mail". Você precisa criá-lo em seu arquivo /etc/group se você precisa dele. Uma entrada como:
mail:*:6:
seria o suficiente.
Por padrão, o Sendmail usa o serviço DNS para a resolução de nomes, e não o arquivo /etc/hosts. Esse comportamento pode ser alterado através do uso do arquivo /etc/mail/service.switch.
Se você deseja consultar o arquivo hosts antes dos servidores DNS, crie o arquivo /etc/mail/service.switch e coloque nele a seguinte linha:
hosts files dns
Se você deseja consultar SOMENTE o arquivo hosts, use o seguinte:
hosts files
Envie ao Sendmail um sinal HUP:
# kill -HUP `head -1 /var/run/sendmail.pid`
e as mudanças terão efeito.
O OpenBSD é distribuído com bibliotecas RSA e um servidor httpd que suporta SSL. Para o uso com o httpd(8), você primeiro precisa ter um certificado. O certificado será mantido em /etc/ssl/, com a chave correspondente em /etc/ssl/private/. As etapas descritas aqui são, em partes, retiradas da página de manual ssl(8); utilize-a para obter mais informação. Esta parte da FAQ é somente sobre a criação de um certificado RSA para servidores Web, ela não descreve certificados de servidores DSA. Para mais informações sobre como fazer isso, leia a página de manual ssl(8).
Para começar, você precisa criar o certificado e a chave do seu servidor usando o OpenSSL:
# openssl genrsa -out /etc/ssl/private/server.key 2048
Ou, se você deseja que a chave seja encriptada com uma frase secreta que você terá que digitar quando iniciar os servidores
# openssl genrsa -aes256 -out /etc/ssl/private/server.key 2048
O próximo passo é gerar uma Requisição de Assinatura de Certificado, que é utilizada para permitir que uma Autoridade de Certificação (CA - "Certifying Authority") assine seu certificado. Para fazer isso, use o comando:
# openssl req -new -key /etc/ssl/private/server.key -out /etc/ssl/private/server.csr
O arquivo server.csr pode então ser enviado a uma Autoridade de Certificação que assinará a chave. Uma das Autoridades de Certificação é a Thawte Certification, que você pode encontrar no endereço http://www.thawte.com/.
Se você não pode fazer isso, ou simplesmente quer assinar o certificado você mesmo, o seguinte comando pode ser usado.
# openssl x509 -sha256 -req -days 365 -in /etc/ssl/private/server.csr \
-signkey /etc/ssl/private/server.key -out /etc/ssl/server.crt
Com os arquivos /etc/ssl/server.crt e /etc/ssl/private/server.key no lugar certo, você deve então iniciar o httpd(8) com o sinalizador -DSSL (veja a seção sobre o rc(8) nesta faq), ativando assim as transações https na porta 443 da sua máquina.
Se você editou diretamente o arquivo /etc/passwd, suas mudanças serão perdidas. O OpenBSD gera dinamicamente o arquivo /etc/passwd com o pwd_mkdb(8). O arquivo de senhas principal no OpenBSD é o /etc/master.passwd. De acordo com o pwd_mkdb(8),
FILES
/etc/master.passwd current password file
/etc/passwd a 6th Edition-style password file
/etc/pwd.db insecure password database file
/etc/pwd.db.tmp temporary file
/etc/spwd.db secure password database file
/etc/spwd.db.tmp temporary file
Em um arquivo de senhas tradicional do Unix, como o /etc/passwd, tudo e inclusive a senha criptografada do usuário está disponível para qualquer um no sistema (e é o primeiro alvo para programas como o "Crack"). O 4.4BSD introduziu o arquivo master.passwd, que possui um formato estendido (com opções adicionais além daquelas fornecidas pelo /etc/passwd) e somente pode ser lido pelo usuário root. Para acesso rápido aos dados, as chamadas de bibliotecas que acessam esses dados normalmente leem os arquivos /etc/pwd.db e /etc/spwd.db.
O OpenBSD inclui uma ferramenta para a edição do arquivo de senhas. Essa ferramenta é chamada vipw(8). Vipw usa o vi (ou seu editor favorito definido por $EDITOR) para editar o arquivo /etc/master.passwd. Após a modificação, ele recria /etc/passwd, /etc/pwd.db e /etc/spwd.db, conforme as mudanças que você tenha feito. Vipw também se encarrega de bloquear esses arquivos, de modo que se alguém tentar mudá-los ao mesmo tempo, o acesso é negado.
O OpenBSD fornece dois comandos para a adição fácil de usuários no sistema:
Você também pode adicionar manualmente os usuários, usando o vipw(8), mas na maioria das operações isso é mais difícil.A forma mais fácil de adicionar um usuário no OpenBSD é usando o script adduser(8). Você pode configurar o adduser(8) através da edição do arquivo /etc/adduser.conf. O adduser(8) permite verificações consistentes em /etc/passwd, /etc/group e no banco de dados de shell. Ele cria as entradas e o diretório $HOME para você. É possível enviar uma mensagem de boas vindas ao usuário. Este é um exemplo de usuário, testuser, sendo adicionado no sistema. Ele(a) terá o diretório $HOME em /home/testuser, fará parte do grupo guest, e terá o shell /bin/ksh.
# adduser Use option ``-silent'' if you don't want to see all warnings and questions. Reading /etc/shells Check /etc/master.passwd Check /etc/group Ok, let's go. Don't worry about mistakes. There will be a chance later to correct any input. Enter username []: testuser Enter full name []: Test FAQ User Enter shell csh ksh nologin sh [ksh]: ksh Uid [1002]: Enter Login group testuser [testuser]: guest Login group is ``guest''. Invite testuser into other groups: guest no [no]: no Login class authpf daemon default staff [default]: Enter Enter password []: Digite a senha e tecle Enter Enter password again []: Digite a senha e tecle Enter Name: testuser Password: **** Fullname: Test FAQ User Uid: 1002 Gid: 31 (guest) Groups: guest Login Class: default HOME: /home/testuser Shell: /bin/ksh OK? (y/n) [y]: y Added user ``testuser'' Copy files from /etc/skel to /home/testuser Add another user? (y/n) [y]: n Goodbye!
Para excluir usuários você deve usar o utilitário rmuser(8). Este remove toda a existência de um usuário. Ele remove qualquer entrada no crontab(1), o diretório $HOME (se o usuário em questão for o proprietário do diretório) e suas mensagens de correio eletrônico. Naturalmente, ele também remove as entradas nos arquivos /etc/passwd e /etc/group. O próximo exemplo é a remoção do usuário que foi adicionado acima. Repare que você será perguntado pelo nome, e se quer ou não remover o diretório pessoal do usuário.
# rmuser Enter login name for user to remove: testuser Matching password entry: testuser:$2a$07$ZWnBOsbqMJ.ducQBfsTKUe3PL97Ve1AHWJ0A4uLamniLNXLeYrEie:1002 :31::0:0:Test FAQ User:/home/testuser:/bin/ksh Is this the entry you wish to remove? y Remove user's home directory (/home/testuser)? y Updating password file, updating databases, done. Updating group file: done. Removing user's home directory (/home/testuser): done.
Estas ferramentas são menos interativas que o comando adduser(8), o que as tornam fáceis de serem usadas em scripts.
A lista completa de ferramentas:
O comando /usr/sbin/user é apenas uma interface para o resto dos comandos /usr/sbin/user*. Portanto, os comandos seguintes podem ser utilizados como user add ou useradd, de modo que depende da sua escolha qual utilizar, e não altera o resultado dos comandos. Lembre-se que o comando user(8) não é interativo, a maneira mais fácil de adicionar eficientemente usuários é através do comando adduser(8).
O comando useradd(8) é menos assustador se você já sabe a configuração padrão antes de adicionar o usuário. Essas configurações estão localizadas em usermgmt.conf(5), e podem ser visualizadas com o comando:
$ user add -D group users base_dir /home skel_dir /etc/skel shell /bin/csh inactive 0 expire Null (unset) range 1000..60000
As configurações acima serão as utilizadas, a menos que você especifique uma configuração diferente com as opções da linha de comando. Por exemplo, no nosso caso, queremos que o usuário pertença ao grupo guest, e não ao grupo users. Um pequeno obstáculo ao adicionar usuários é que as senhas precisam ser especificadas na linha de comando. As senhas devem ser criptografadas, então primeiro você precisa usar o utilitário encrypt(1) para criar a senha. Por exemplo: as senhas do OpenBSD usam por padrão o algoritmo Blowfish em 6 "rounds". Esta é uma linha de exemplo para criar uma senha encriptada para ser especificada ao useradd(8).
$ encrypt -p -b 6 Enter string: $2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWX
Agora que temos nossa senha encriptada, já estamos prontos para adicionar o usuário. Vamos adicionar o mesmo usuário com as mesmas especificações que adicionamos acima, desta vez via adduser(8).
# user add -p '$2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWX' -u 1002 \ -s /bin/ksh -c "Test FAQ User" -m -g guest testuser
Nota: Tenha certeza que você está usando ' ' (aspas simples) em ambos os lados da senha, e não " " (aspas duplas), já que estas serão interpretadas pelo shell antes de serem enviadas para o user(8). Em adição, tenha certeza de especificar a opção -m se você quer que o diretório pessoal do usuário seja criado e os arquivos de /etc/skel sejam copiados para lá.
Para ver se o usuário foi criado corretamente, podemos usar vários utilitários diferentes. Abaixo estão alguns comandos que você pode usar para verificar rapidamente se tudo foi criado corretamente.
$ ls -la /home total 14 drwxr-xr-x 5 root wheel 512 May 12 14:29 . drwxr-xr-x 15 root wheel 512 Apr 25 20:52 .. drwxr-xr-x 24 ericj wheel 2560 May 12 13:38 ericj drwxr-xr-x 2 testuser guest 512 May 12 14:28 testuser $ id testuser uid=1002(testuser) gid=31(guest) groups=31(guest) $ finger testuser Login: testuser Name: Test FAQ User Directory: /home/testuser Shell: /bin/ksh Last login Sat Apr 22 16:05 (EDT) on ttyC2 No Mail. No Plan.
Em adição a tais comandos, o user(8) provê seu próprio utilitário para mostrar as características do usuário, chamado de userinfo(8).
$ userinfo testuser login testuser passwd * uid 1002 groups guest change Wed Dec 31 19:00:00 1969 class gecos Test FAQ User dir /home/testuser shell /bin/ksh expire Wed Dec 31 19:00:00 1969
Para remover usuários com a hierarquia de comandos user(8), você usa o comando userdel(8). Ele é muito simples, mas um comando útil. Para remover o usuário criado no último exemplo, basta executar:
# userdel -r testuser
Note a opção -r, que precisa ser especificada se você quer que o diretório pessoal do usuário também seja excluído. Alternativamente, você pode especificar -p e não -r, e assim a conta do usuário será bloqueada, mas nenhuma informação será eliminada.
Existem alguns meios de se fazer isso, mas um modo muito comum é adicionar "/usr/bin/false" no arquivo "/etc/shells". Então quando você configurar o shell dos usuários para "/usr/bin/false", eles não serão capazes de iniciar uma sessão interativa no sistema, mas serão capazes de usar o serviço ftp. Você talvez queira também restringir o acesso confinando os usuários em seus diretórios pessoais no ftpd.
Quotas são utilizadas para limitar o espaço de disco disponível para os usuários. O sistema pode ser muito útil em situações onde você tem recursos limitados. Quotas podem ser configuradas por usuário e/ou por grupo.
O primeiro passo para configurar as quotas é ter certeza que "option QUOTA" está na configuração do kernel. Essa opção está no kernel GENERIC. Depois disso, você precisa marcar no /etc/fstab os sistemas de arquivos que terão as quotas ativadas. As palavras-chave userquota e groupquota devem ser usadas para marcar cada sistema de arquivos que você vai utilizar quotas. Por padrão, os arquivos quota.user e quota.group serão criados na raiz daquele sistema de arquivo para guardar informações sobre quotas. Esse padrão pode ser modificado especificando o nome do arquivo com a opção quota em /etc/fstab, como em "userquota=/var/quotas/quota.user". Este é um exemplo de /etc/fstab que tem um sistema de arquivos com quotas ativas, e o arquivo de quotas em uma localização não padrão:
/dev/wd0a / ffs rw,userquota=/var/quotas/quota.user 1 1
Agora é hora de configurar as quotas do usuário. Para esse fim, nós utilizamos o utilitário edquota(8). Um uso simples é "edquota <usuário>". edquota(8) utiliza o vi(1) para editar as quotas, a menos que a variável de ambiente EDITOR esteja definida para um editor diferente. Por exemplo, o comando:
# edquota ericj
Mostra uma saída similar a esta:
Quotas for user ericj:
/: KBytes in use: 62, limits (soft = 0, hard = 0)
inodes in use: 25, limits (soft = 0, hard = 0)
Para adicionar limites, faça a edição para obter um resultado similar a este:
Quotas for user ericj:
/: KBytes in use: 62, limits (soft = 1000, hard = 1050)
inodes in use: 25, limits (soft = 0, hard = 0)
Note que a alocação de quotas está em blocos de 1k. Nesse caso, o limite mínimo está fixado em 1000k e o limite máximo em 1050k. Um limite mínimo é um limite onde o usuário é avisado quando o ultrapassa, e tem um período de graça para reduzir seu uso do disco para abaixo do seu limite. Os períodos de graça podem ser configurados usando a opção -t do edquota(8). Depois que o perído de graça termina, o limite mínimo é manipulado como limite máximo. O resultado é uma falha de alocação.
Agora que as quotas estão configuradas, você precisa ativá-las. Para fazer isso, use o comando quotaon(8). Por exemplo:
# quotaon -a
Esse comando lê o /etc/fstab para ativar os sistemas de arquivos com as opções de quota. Agora que as quotas estão funcionando, você pode vê-las usando o comando quota(1). O uso do comando "quota <usuário>" mostra-lhe a informação do usuário. Quando chamado sem nenhum argumento, o comando quota(1) mostra-lhe suas estatísticas de quota. Por exemplo:
# quota ericj
Mostra um resultado como este:
Disk quotas for user ericj (uid 1001):
Filesystem blocks quota limit grace files quota limit grace
/ 62 1000 1050 27 0 0
Por padrão, as quotas configuradas em /etc/fstab são carregadas na inicialização. Para desligá-las, use:
# quotaoff -a
O OpenBSD inclui o KerberosV como um componente pré-instalado do sistema padrão.
Para mais informações sobre o KerberosV a partir do seu sistema OpenBSD, use o comando:
# info heimdal
O FTP anônimo permite que usuários sem contas acessem arquivos no seu computador através do Protocolo de Transferência de Arquivos (FTP - "File Transfer Protocol"). Esta seção oferece um resumo sobre como configurar um servidor FTP anônimo, seu registro de dados, etc.
Para começar, você precisa ter uma conta ftp em seu sistema. Essa conta não deve ter uma senha usável. Neste exemplo, nós iremos configurar o diretório de início de sessão como /home/ftp, mas você pode colocá-lo em qualquer lugar que quiser. Quando o ftp anônimo é utilizado, o daemon ftp vai se confinar (chroot) no diretório pessoal do usuário ftp. Para saber mais sobre isso, leia as páginas de manual ftpd(8) e chroot(2). Este é um exemplo de como criar o usuário ftp. Para isso, usaremos o adduser(8). Nós também precisamos adicionar /usr/bin/false no nosso arquivo /etc/shells; esse será o "shell" que daremos ao usuário ftp. Isso não permite que ele inicie sessão, mesmo dando uma senha vazia. Para isso, você pode simplesmente fazer o seguinte:
Depois disso, você está pronto para adicionar o usuário ftp:echo /usr/bin/false >> /etc/shells
# adduser Use option ``-silent'' if you don't want to see all warnings and questions. Reading /etc/shells Check /etc/master.passwd Check /etc/group Ok, let's go. Don't worry about mistakes. There will be a chance later to correct any input. Enter username []: ftp Enter full name []: anonymous ftp Enter shell csh false ksh nologin sh [ksh]: false Uid [1002]: Enter Login group ftp [ftp]: Enter Login group is ``ftp''. Invite ftp into other groups: guest no [no]: no Login class authpf daemon default staff [default]: Enter Enter password []: Enter Set the password so that user cannot logon? (y/n) [n]: y Name: ftp Password: **** Fullname: anonymous ftp Uid: 1002 Gid: 1002 (ftp) Groups: ftp Login Class: default HOME: /home/ftp Shell: /usr/bin/false OK? (y/n) [y]: y Added user ``ftp'' Copy files from /etc/skel to /home/ftp Add another user? (y/n) [y]: n Goodbye!
Junto com o usuário, isso criou o diretório /home/ftp. É o que queremos, mas existem algumas mudanças que temos que fazer para torná-lo pronto para o ftp anônimo. Novamente, essas mudanças são explicadas na página de manual ftpd(8).
Você não precisa criar o diretório /home/ftp/usr ou /home/ftp/bin.
Note que todos esses diretórios devem ser de propriedade de ''root''. Esta é uma lista de como os diretórios devem se parecer após criados.
# pwd /home # ls -laR ftp total 5 dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 . drwxr-xr-x 7 root wheel 512 Jul 6 10:58 .. dr-x--x--x 2 root ftp 512 Jul 6 11:34 etc dr-xr-xr-x 2 root ftp 512 Jul 6 11:33 pub ftp/etc: total 43 dr-x--x--x 2 root ftp 512 Jul 6 11:34 . dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 .. -r--r--r-- 1 root ftp 316 Jul 6 11:34 group -r--r--r-- 1 root ftp 40960 Jul 6 11:34 pwd.db ftp/pub: total 2 dr-xr-xr-x 2 root ftp 512 Jul 6 11:33 . dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 ..
Você pode escolher como iniciar o ftpd, tanto pelo inetd(8) ou a partir dos scripts rc. Estes exemplos mostram nosso daemon sendo iniciado a partir do inetd.conf. Mas, antes, precisamos nos familiarizar com algumas das opções do ftpd. A linha padrão do /etc/inetd.conf é:
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -US
Como você pode ver, o ftpd é executado com -US. Isso registra as conexões anônimas em /var/log/ftpd e as sessões concorrentes em /var/run/utmp. Desse modo, poderemos ver essas sessões com o comando who(1). É possível que alguns queiram apenas ter um servidor anônimo, e desativar o ftp para usuários. Para isso, você deve executar o ftpd com a opção -A. Aqui temos uma linha que inicia o ftpd somente para conexões anônimas. Ele também usa -ll para fazer o registro de cada conexão usando o syslog, junto com os comandos "get", "retrive", etc. do ftp.
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -llUSA
Nota: Para aqueles que usam servidores ftp de ALTO tráfego, pode-se não querer executar o ftpd a partir do inetd.conf. A melhor opção é comentar a linha ftpd do inetd.conf e iniciar o ftpd a partir do rc.conf.local. Isso inicia o ftpd como um daemon, e será mais simples e rápido do que iniciar pelo inetd. Esta é uma linha de exemplo para iniciá-lo a partir do rc.conf.local:
ftpd_flags="llUSA" # for non-inetd use: ftpd_flags=""
Evidentemente, somente funciona se você retirou (comentou) o ftpd do /etc/inetd.conf e fez com que o inetd lesse novamente o arquivo de configuração.
Não é necessário passar opções de inicialização adicionais para o ftpd permitir conexões anônimas. As etapas anteriores de criação do usuário 'ftp' e configuração dos diretórios relevantes com as permissões corretas são suficientes. No entanto, para impedir conexões anônimas, não é necessário desfazer tudo. Basta reiniciar o ftpd com a opção -n e conexões anônimas serão, então, desabilitadas.
Por padrão, quando os usuários se conectam por ftp, eles podem ir para qualquer diretório que tenham acesso no sistema de arquivos. Isso pode não ser desejável em certas ocasiões. É possível restringir o que os usuários podem ver em uma sessão ftp, confinando os usuários em seus diretórios pessoais usando o chroot.
Se você quer permitir conexões ftp somente em chroot, utilize a opção -A do ftpd(8).
Se você quer usar o chroot de maneira mais fina, a infraestrutura de capacidades de início de sessão e o ftpd(8) do OpenBSD tornam isso fácil.
Os usuários em uma classe de início de sessão com a variável ftp-chroot definida são confinados automaticamente. Adicionalmente, você pode adicionar um nome de usuário no arquivo /etc/ftpchroot para confinar apenas os usuários que tenham seus nomes nesse arquivo. Um usuário somente precisa ser listado em um desses lugares.
Mesmo no OpenBSD, erros acontecem. Alguns problemas podem levar à problemas de confiabilidade (ou seja, algumas vezes pode fazer com que o sistema pare de funcionar como desejado). Outros problemas podem levar à vulnerabilidades de segurança (que pode permitir que outros "usem" seu computador de maneira não desejada e sem autorização). Quando uma falha crítica é encontrada, a correção é integrada na árvore de código fonte -current, e as correções são lançadas para as releases suportadas do OpenBSD. Essas correções aparecem na página Web das erratas, e são separadas em correções "commom", aplicáveis em todas as plataformas, e em correções aplicáveis em uma ou mais plataformas, mas não em todas.
Note, no entanto, que as correções não são publicadas de modo a fornecer novas funcionalidades ou suportes a novos hardwares ao OpenBSD, elas são feitas somente para correções importantes de confiabilidade ou problemas de segurança, que devem ser conduzidos de maneira correta nos sistemas afetados (que frequentemente NÃO são todos os sistemas, dependendo dos propósitos).
Existem três jeitos de atualizar seu sistema com código fonte corrigido:
Todas as correções postadas na página Web das erratas são correções feitas na árvore de código fonte da release indicada. Correções na árvore CVS atual também incluem outras mudanças que não são desejadas em um sistema de produção. Isto é importante: se você instalar uma snapshot, fizer o download da árvore de código fonte no momento em que você obteve a snapshot, e tentar aplicar uma correção usando um arquivo de correção publicado, você vai ver que ele não é aplicado, já que o código pode ter mudado.
As correções do OpenBSD são distribuídas em diffs unificados ("Unified diffs"), que são arquivos de texto que guardam as diferenças em relação ao código fonte original. Elas NÃO são distribuídas em formato binário. Isso significa que para aplicar as correções no seu sistema, você precisa ter o código fonte da versão RELEASE do OpenBSD à vossa disposição. Geralmente, você deve ter à disposição a árvore de código fonte completa. Se você está usando a versão release adquirida em um CD-ROM oficial, as árvores de código fonte estão disponíveis no disco 3, elas também estão disponíveis como arquivos nos servidores FTP. Iremos assumir que você tem a árvore de código fonte completa à disposição.
No nosso exemplo, nós vamos olhar a correção 001 para o OpenBSD 3.6, relacionada ao driver st(4), que controla drives de fitas magnéticas ("tape drives"). Sem esta correção, restaurar dados de backups seria um pouco difícil. As pessoas que usam um drive de fitas magnéticas precisam desta correção; no entanto, pessoas que não utilizem firas magnéticas podem não ter a necessidade de instalar esta correção. Vamos olhar a correção:
# more 001_st.patch
Apply by doing:
cd /usr/src
patch -p0 < 001_st.patch
Rebuild your kernel.
Index: sys/scsi/st.c
===================================================================
RCS file: /cvs/src/sys/scsi/st.c,v
retrieving revision 1.41
retrieving revision 1.41.2.1
diff -u -p -r1.41 -r1.41.2.1
--- sys/scsi/st.c 1 Aug 2004 23:01:06 -0000 1.41
+++ sys/scsi/st.c 2 Nov 2004 01:05:50 -0000 1.41.2.1
@@ -1815,7 +1815,7 @@ st_interpret_sense(xs)
u_int8_t skey = sense->flags & SSD_KEY;
int32_t info;
- if (((sense->flags & SDEV_OPEN) == 0) ||
+ if (((sc_link->flags & SDEV_OPEN) == 0) ||
(serr != 0x70 && serr != 0x71))
return (EJUSTRETURN); /* let the generic code handle it */
Note a mensagem "Hunk #1 succeeded" acima. Isso indica que a correção foi aplicada corretamente. Muitas correções são mais complexas que essa, e envolvem múltiplos "hunks" e múltiplos arquivos. Você deve se assegurar que todos os "hunks" foram aplicados com sucesso em todos os arquivos. Se eles não foram aplicados com sucesso, normalmente isso significa que sua árvore de código fonte não está em conformidade com a árvore utilizada para desenvolvimento do patch, você não seguiu as instruções com cuidado, ou seu arquivo de correção estava corrompido. As correções são sensíveis em relação aos espaços em branco -- copiar e colar a partir do seu navegador frequentemente transforma caracteres tab em espaços ou altera de outra forma o espaço em branco de um arquivo, tornando a correção inutilizável.# cd /usr/src # patch -p0 < 001_st.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Apply by doing: | cd /usr/src | patch -p0 < 001_st.patch | |Rebuild your kernel. | |Index: sys/scsi/st.c |=================================================================== |RCS file: /cvs/src/sys/scsi/st.c,v |retrieving revision 1.41 |retrieving revision 1.41.2.1 |diff -u -p -r1.41 -r1.41.2.1 |--- sys/scsi/st.c 1 Aug 2004 23:01:06 -0000 1.41 |+++ sys/scsi/st.c 2 Nov 2004 01:05:50 -0000 1.41.2.1 -------------------------- Patching file sys/scsi/st.c using Plan A... Hunk #1 succeeded at 1815. <-- Olhe essa mensagem! done
Neste ponto, você já pode compilar e instalar um novo kernel e reiniciar o sistema da maneira habitual.
Nem todas as correções são para o kernel. Em alguns casos, você terá que recompilar utilitários individualmente. Em outras vezes, será necessário recompilar todos os utilitários ligados estaticamente em uma biblioteca corrigida. Siga o guia no cabeçalho do arquivo de correção, e se você estiver em dúvida, recompile o sistema inteiro.
Correções que são irrelevantes ao seu sistema em particular não precisam ser aplicadas -- usualmente. Por exemplo, se você não tem um drive de fitas magnética no seu sistema, você não se beneficiará com a correção acima. No entanto, assume-se que as correções sejam aplicadas "em ordem" -- é possível que uma última correção dependa de uma correção aplicada anteriormente. Seja consciente a respeito disso se você selecionou o método de escolher quais correções aplicar, e, se está em dúvida, aplique todas elas, em ordem.
No OpenBSD, o servidor httpd(8) Apache é "chroot(2)ado" por padrão. Enquanto é um grande passo do ponto de vista da segurança, isso pode criar problemas se você não estiver preparado.
Para sermos diretos, "chroot(2)ar" o Apache é uma coisa que não é feita por padrão na maioria dos outros sistemas operacionais. Muitas aplicações e configurações do sistema não funcionam em chroot(2) sem algumas modificações. No mais, é preciso estar ciente que segurança e conveniência frequentemente não possuem objetivos compatíveis. A implementação do Apache no OpenBSD não sacrifica a segurança em favor das vantagens ou da "facilidade".
# apachectl stop
renomeie seus arquivos de registro
# apachectl start ; sleep 10 ; apachectl start
Primeiro, nós instalamos o pacote wwwcount. Nós configuramos e testamos, e descobrimos que ele parece não funcionar: o Apache nos retorna uma mensagem dizendo "Internal Server Error". O primeiro passo consiste em parar e reiniciar o Apache com o comutador -u para verificar se o problema vem do chroot(2), e não da configuração do sistema.
Após fazer isso, nós constatamos que o contador funciona corretamente, devido à mudança de dono em um diretório que o Apache (e os CGIs que ele executa) pode escrever nos arquivos. Assim, temos definitivamente um problema de chroot, então paramos e reiniciamos novamente o Apache, usando o chroot por padrão:# apachectl stop /usr/sbin/apachectl stop: httpd stopped # httpd -u
# apachectl stop /usr/sbin/apachectl stop: httpd stopped # httpd
Um bom ponto de partida pode ser supor que o wwwcount usa algumas bibliotecas e outros arquivos que ele não pode acessar estando em chroot. Nós podemos usar o comando ldd(1) para descobrir as dependências dinâmicas do CGI em questão:
# cd /var/www/cgi-bin/
# ldd Count.cgi
Count.cgi:
Start End Type Open Ref GrpRef Name
1c000000 3c007000 exe 1 0 0 /var/www/cgi-bin/Count.cgi
0c085000 2c0be000 rlib 0 1 0 /usr/lib/libc.so.57.0
08713000 08713000 rtld 0 1 0 /usr/libexec/ld.so
e tentamos usar o contador novamente.# mkdir -p /var/www/usr/lib /var/www/usr/libexec # cp /usr/lib/libc.so.57.0 /var/www/usr/lib # cp /usr/libexec/ld.so /var/www/usr/libexec
Bem, agora o programa está em execução e nos enviando as mensagens de erro diretamente: "Unable to open config file for reading". Nós fizemos um progresso, mas ainda não terminamos. O arquivo de configuração fica normalmente em /var/www/wwwcount/conf, mas dentro do ambiente chroot ele deve ser procurado em /wwwcount/conf. Nós temos duas opções: uma é recompilar o programa para fazer ele funcionar com a nova localização dos arquivos, a outra é mover os arquivos de dados. Como nós instalamos a partir de um pacote, vamos apenas mover os arquivos de dados. Para usar a mesma configuração em chroot(2) ou não, iremos usar uma ligação simbólica:
Repare que a ligação simbólica é pensada para funcionar dentro do chroot. Novamente, nós testamos... e descobrimos mais um problema. Agora o wwwcount está reclamando que não pode achar os arquivos "strip image" que ele utiliza para mostrar as mensagens. Após um pouco de pesquisa, descobrimos que aqueles arquivos são armazenados em /usr/local/lib/wwwcount, então nós temos que copiá-los no ambiente chroot, como de hábito.# mkdir -p /var/www/var/www # cd /var/www/var/www # ln -s ../../wwwcount wwwcount
nós testamos novamente... e ele funcionou!# tar cf - /usr/local/lib/wwwcount | (cd /var/www; tar xpf - )
Note que somente copiamos os arquivos que são absolutamente necessários para o bom funcionamento. Geralmente, somente o mínimo possível de arquivos necessários para executar uma aplicação deve ser copiado no ambiente chroot.
Nem toda aplicação pode ou deve ser "chroot(2)ada".
O objetivo é um servidor Web seguro, o chroot(2) é apenas uma ferramenta para alcançar isso, não é o objetivo por si só. Lembre-se, a configuração inicial do Apache em chroot(2) do OpenBSD é onde o usuário que está executando o programa httpd(8) não pode executar nenhum programa, não pode alterar nenhum arquivo, e não pode assumir outra identidade de usuário. Perdendo essas restrições, você perde parte da sua segurança, usando ou não o chroot.
Algumas aplicações são relativamente simples, e utilizar o chroot(2) faz sentido. Outras são muito complexas, e não valem o esforço necessário para colocá-las em chroot(2), ou o tempo que você vai levar para copiar uma boa parte do sistema para o chroot, e no final acaba-se perdendo o benefício do ambiente chroot(2). Por exemplo, o programa OpenWebMail precisa ser capaz de ler e escrever no diretório de correio eletrônico, no diretório pessoal do usuário, e também precisa ser capaz de funcionar usando qualquer usuário no sistema. Tentar colocá-lo em chroot será inútil, já que você será obrigado a desativar todos os benefícios do uso do chroot(2). Mesmo com uma aplicação tão simples como o contador, ele precisa escrever no disco (para guardar sua contagem), então parte do benefício do chroot(2) é perdida.
Qualquer aplicação que deve funcionar com privilégios de root é inútil no escopo do chroot(2), já que o root pode sair do chroot(2).
Não se esqueça que, se o processo de colocar sua aplicação em chroot é muito difícil, você não pode atualizar ou instalar uma nova versão do sistema na frequência que deveria. Isso pode acabar tornando seu sistema MENOS seguro que um sistema mais atualizado e com o chroot desativado.
O shell padrão para o usuário root no OpenBSD é o ksh.
Uma diretiva Unix tradicional é usar para o root somente shells compilados estaticamente, porque se seu sistema entra em modo usuário único, partições não-raiz não são montadas, e shells ligados dinamicamente não são capazes de acessar as bibliotecas situadas na partição /usr. Isso não é realmente um problema significante no OpenBSD, já que o sistema pergunta por um shell quando ele entra em modo usuário único, e o shell por padrão é o sh. Os três shells padrão do OpenBSD (csh, sh e ksh) são todos ligados estaticamente, e são utilizáveis no modo usuário único.
Usuários confortáveis com o shell bash, utilizado na maioria das vezes em sistemas Linux, provavelmente acharão o ksh muito familiar. O ksh(1) oferece a maioria das opções encontradas no shell bash, incluindo a completação de comandos através da tecla tab, edição de linha de comando e acesso ao histórico através das teclas direcionais, e CTRL-A/CTRL-E para pular para o começo ou fim da linha de comando. Se você deseja outras opções do shell bash, o próprio bash pode ser instalado através dos pacotes ou através dos portes.
O prompt de comando do ksh pode ser facilmente alterado para fornecer mais informações do que o prompt padrão "$ ", através da configuração da variável PS1. Por exemplo, ao inserir a seguinte linha:
no seu arquivo /etc/profile, produz-se o seguinte prompt de comando:export PS1='$PWD $ '
Veja o arquivo /etc/ksh.kshrc, que inclui muitas opções úteis e exemplos, e pode ser executado em seu arquivo .profile de usuário./home/nick $
O shell ksh(1) do OpenBSD foi melhorado. Vários "caracteres especiais" para a sequência primária de prompt, PS1, similares àqueles usados no shell bash, foram adicionados. Por exemplo:
\e - Insere um caractere de escape ASCII.(veja a página de manual ksh(1) para obter mais detalhes, e muito, muito mais caracteres especiais! Também note que o caractere "$" tem um significado especial dentro de aspas duplas, então manipule-o com cuidado)
\h - O nome da máquina, sem o nome de domínio.
\H - O nome completo da máquina, incluindo o nome de domínio.
\n - Insere um caractere de nova linha.
\t - O horário atual, no formato HH:MM:SS de 24 horas.
\u - O nome do usuário atual.
\w - O diretório de trabalho atual. $HOME é abreviado como `~'.
\W - O nome base do diretório de trabalho atual.
\$ - Mostra "#" para os usuários root, e "$" para os outros.
Você pode usar o seguinte comando:
para ter um prompt de comando excessivamente detalhado, mas de certa forma útil.export PS1="\n\u@\H\n\w \\$ "
O OpenBSD pode ser usado como servidor e cliente de banco de dados contendo credenciais de usuários, informações de grupos e outros dados relacionados à rede.
Naturalmente, você pode usar vários serviços de diretório no OpenBSD. Mas o YP é o único que pode ser acessado diretamente usando as funções da biblioteca padrão de C como getpwent(3), getgrent(3), gethostbyname(3) e outras. Assim, se você mantém seus dados em um banco de dados YP, você não precisa copiá-lo para arquivos de configuração locais como master.passwd(5) antes de você poder utilizá-lo, por exemplo, para autenticar usuários do sistema.
YP é um serviço de diretório compatível com o NIS ("Network Information System", ou Sistema de Informação da Rede) da Sun Microsystems. Veja yp(8) para uma visão geral sobre as páginas de manual disponíveis. Seja cuidadoso, alguns sistemas operacionais possuem serviços de diretório com nomes parecidos, mas todos são incompatíveis; por exemplo, NIS+.
Para usar outros serviços de diretório, exceto o YP, você precisa popular arquivos de configuração locais a partir do diretório, ou você precisa de um "frontend" YP para o diretório. Por exemplo, você pode usar o porte sysutils/login_ldap quando escolher o primeiro, enquanto o daemon ypldap(8) fornece o último.
Para algumas aplicações, a simples sincronização de um pequeno número de arquivos de configuração entre um grupo de máquinas usando ferramentas como cron(8), scp(1) ou rsync (disponível no portes) se torna uma alternativa fácil e robusta para um serviço de diretório completo.
Por razões de compatibilidade, todas as características de segurança embutidas na implementação de YP do OpenBSD estão desativadas, por padrão. Mesmo quando elas estão todas ativadas, o protocolo NIS ainda é de natureza insegura por duas razões: Todos os dados, incluindo dados sensíveis como dispersões de senhas, são transmitidos sem encriptação na rede, e nem o cliente nem o servidor podem verificar confiavelmente a identidade um do outro.
Dessa forma, antes de ativar qualquer servidor YP, você deve considerar se essas falhas de segurança são aceitáveis no seu contexto. Em particular, YP é inadequado se atacantes em potencial têm acesso físico à sua rede. Qualquer um com acesso root em qualquer computador conectado no seu segmento de rede com tráfego YP pode enganar o seu domínio YP e recuperar seus dados. Em alguns casos, passar o tráfego YP por túneis SSL ou IPSec pode ser uma opção, ou você pode considerar a combinação de YP com autenticação kerberos(8).
Um servidor YP serve um grupo de clientes chamado de um "domínio". Você primeiro deve selecionar um nome de domínio; ele pode ser uma string arbitrária e não precisa estar relacionado em nenhuma forma com nomes de domínio DNS. Escolher um nome aleatório, como "Eepoo5vi", pode melhorar marginalmente a segurança, embora o efeito seja de segurança por obscuridade. Caso você precise manter vários domínios YP diferentes, provavelmente é melhor escolher nomes descritivos como "vendas", "marketing" e "pesquisa" para evitar erros de administração do sistema causados pela obscuridade. Também note que algumas versões do SunOS requerem o uso do nome de domínio DNS da máquina, então sua escolha pode ser restrita em uma rede que inclui tais máquinas.
Use o utilitário domainname(1) para definir um nome de domínio, e coloque-o no arquivo defaultdomain(5) para defini-lo automaticamente durante a inicialização do sistema.
echo "puffynet" > /etc/defaultdomain domainname `cat /etc/defaultdomain`
Inicialize o servidor YP usando o comando interativo
Neste ponto ainda não é necessário especificar os servidores escravos. Para adicionar servidores escravos, você deve executar novamente o ypinit(8) usando a opção -u. Configurar ao menos um servidor escravo para cada domínio é útil para evitar as interrupções de serviço, pois o servidor mestre pode desligar-se ou perder a conectividade de rede; em particular, os processos clientes tentando acessar os mapas YP ficarão bloqueados indefinidamente até que eles recebam a informação requerida. Assim, interrupções de serviço YP tipicamente fazem com que as máquinas clientes fiquem inutilizáveis até que o serviço YP volte a funcionar.ypinit -m
Decida onde guardar os arquivos fonte usados para gerar seus mapas YP. Manter a configuração do servidor separada da configuração servida ajuda a controlar quais informações serão servidas e quais não serão, então o /etc padrão na maioria das vezes não é a melhor escolha.
A única inconveniência causada por mudar o diretório fonte é que você não será capaz de adicionar, remover e modificar usuários e grupos no domínio YP usando utilitários como user(8) e group(8). No lugar, você terá que editar os arquivos de configuração com um editor de texto.
Para definir o diretório fonte, edite o arquivo /var/yp/`domainname`/Makefile e mude a variável DIR; por exemplo
DIR=/etc/yp/src/puffynet
Considere a personalização de outras variáveis em /var/yp/`domainname`/Makefile. Veja Makefile.yp(8) para obter mais detalhes.
Por exemplo, mesmo no caso de você utilizar o diretório fonte padrão, /etc, você usualmente não precisa ter todas as contas e grupos existentes no servidor em todas as suas máquinas cliente. Em particular, não servir a conta do root e, assim, manter a dispersão da senha do root confidencial é, frequentemente, benéfico para a segurança. Revise os valores de MINUID, MAXUID, MINGID e MAXGID e ajuste-os de acordo com as suas necessidades.
Se todos os seus clientes YP usam OpenBSD ou FreeBSD, exclua as senhas encriptadas dos mapas passwd definindo UNSECURE="" em /var/yp/`domainname`/Makefile.
A prática anterior de editar o arquivo modelo /var/yp/Makefile.yp não é mais recomendada. Mudanças naquele arquivo afetam todos os domínios inicializados após a mudança, mas não afetam domínios inicializados antes da mudança, dessa forma essa prática é propensa a erros: você tem o risco de que as mudanças não tenham efeito, e o risco de esquecê-las e delas afetarem outros domínios mais tarde, para os quais essas mudanças nunca foram pretendidas.
Crie o diretório fonte e popule-o com os arquivos de configuração que você necessita. Veja Makefile.yp(8) para aprender sobre quais mapas YP requerem quais arquivos fonte. Para o formato de arquivos de configuração individuais, consulte passwd(5), group(5), hosts(5) e outros, e olhe nos exemplos em /etc.
Crie a versão inicial dos seus mapas YP utilizando os comandos
Não se preocupe com as mensagens de erro do yppush(8) por enquanto. O servidor YP não está em execução ainda.cd /var/yp make
YP utiliza o rpc(3) ("remote procedure calls", ou chamadas de procedimento remoto) para comunicar-se com os clientes, então é necessário ativar o portmap(8). Para fazer isso, edite o rc.conf.local(8) e defina portmap_flags="". Isso iniciará o portmapper na próxima inicialização. Você pode evitar a reinicialização iniciando-o manualmente:
echo 'portmap_flags=""' >> /etc/rc.conf.local portmap
Considere o uso do recurso de segurança securenet(5) ou o ypserv.acl(5) do daemon servidor YP. Mas esteja atento ao fato de que ambos somente fornecem controle de acesso baseado em IP. Dessa forma, eles somente ajudam enquanto atacantes em potencial não possuem acesso físico ao hardware do segmento de rede transmitindo seu tráfego YP nem acesso root em qualquer máquina conectada a esses segmentos de rede.
Finalmente, inicie o daemon servidor YP:
Ele será reiniciado automaticamente durante a inicialização contanto que o diretório /var/yp/`domainname` continue existindo.ypserv
Para testar o novo servidor, considere torná-lo o seu próprio cliente, seguindo as instruções na primeira parte da próxima seção. Caso você não queira usar seus próprios mapas, você pode desativar a parte do cliente após o teste, com os seguintes comandos:
pkill ypbind rm -rf /var/yp/binding
Se você deseja permitir que usuários mudem suas senhas a partir de máquinas clientes, então você precisa ativar yppasswdd(8):
Caso você deixe o diretório fonte no /etc padrão, use apenas yppasswdd_flags="".echo 'yppasswdd_flags="-d /etc/yp/src/puffynet"' >> /etc/rc.conf.local rpc.yppasswdd
Lembre-se que a cada vez que você muda um arquivo incluído por um mapa YP, você deve gerar novamente seus mapas YP.
Isso atualiza todos os arquivos de banco de dados em /var/yp/`domainname`, com uma exceção: o arquivo ypservers.db, que lista todos os servidores YP, mestres e escravos, associados ao domínio, é criado diretamente com ypinit -m e modificado exclusivamente por ypinit -u. No caso de você excluí-lo acidentalmente, execute ypinit -u para recriá-lo a partir do zero.cd /var/yp make
Igual no servidor, você precisa definir um nome de domínio e ativar o portmapper:
echo "puffynet" > /etc/defaultdomain domainname `cat /etc/defaultdomain` echo "portmap=YES" >> /etc/rc.conf.local portmap
É recomendado o fornecimento de uma lista de servidores YP no arquivo de configuração /etc/yp/`domainname`. Caso contrário, o daemon cliente YP usará emissões ("broadcasts") de rede para encontrar os servidores YP para seu domínio. Especifique de maneira explícita os servidores que são mais robustos e marginalmente menos abertos à ataques. Se você não configurou os servidores escravos, apenas coloque o nome de máquina do servidor mestre em /etc/yp/`domainname`.
O daemon cliente YP é chamado de ypbind(8). A inicialização manual criará o diretório /var/yp/binding, como ele será automaticamente reiniciado na inicialização.
ypbind
Se tudo ocorrer bem, você deve ser capaz de consultar o servidor YP usando o ypcat(1) e ver seu mapa de senha como resposta.
Outras ferramentas úteis para a depuração da sua configuração YP incluem ypmatch(1) e yptest(8).ypcat passwd bob:*:5001:5000:Bob Nuggets:/home/bob:/usr/local/bin/zsh ...
Para uma lista de mapas YP padrão e seus usos, veja Makefile.yp(8). Os casos mais comuns de uso incluem:
Se você quer incluir todas as contas de usuário do domínio YP, acrescente o marcador YP padrão no arquivo de senhas mestre e recompile o banco de dados de senhas:
Para detalhes sobre inclusão e exclusão seletiva de contas de usuário, veja passwd(5). Para testar se a inclusão funciona, use o utilitário id(1).echo '+:*::::::::' >> /etc/master.passwd pwd_mkdb -p /etc/master.passwd
Se você quer incluir todos os grupos de um domínio YP, acrescente o marcador YP padrão no arquivo de grupo:
Para detalhes sobre a inclusão seletiva de grupo, veja group(5).echo '+:*::' >> /etc/group
Se você está distribuindo nomes de máquina via YP, você agora deve revisar o resolv.conf(5) e verificar se a ordem de procura de nome de serviço está correta. A maioria dos usuários utilizarão uma linha como esta:
lookup file yp bind
Para usar um dos conjuntos de caracteres estendidos, a variável de ambiente LC_CTYPE deve ser definida para o nome de uma das localidade suportadas. A variável LC_CTYPE afetará somente o conjunto de caracteres disponíveis para aplicações. Ela não vai mudar o idioma usado para mensagens do aplicativo.
A lista de localidades pode ser listada com o seguinte comando:
A variável de ambiente LC_CTYPE pode ser definida das seguintes maneiras:ls /usr/share/locale
ao arquivo ~/.xsession antes de iniciar sua sessão (para mais detalhes, veja Customizando o Ambiente X Window). Este exemplo habilita o charset Unicode (UTF-8) e possibilita aplicações como o xterm(1) a usar o modo UTF-8 por padrão.export LC_CTYPE="en_US.UTF-8"
Se estiver efetuando login via linha de comando, adicione a linha
ao arquivo ~/.profile. Tenha em mente que o uso do console só dará suporte a caracteres ASCII e ISO8859-1. UTF-8 não é suportado.export LC_CTYPE="en_US.ISO8859-1"
Poucos utilitários do sistema base suportam UTF-8 até o momento. A maioria vai fazer uso de caracteres ASCII. Entretanto, muitos programas presentes na Coleção de Ports tem suporte a UTF-8.
UTF-8 can also be used with specific applications only by starting those applications in uxterm(1). This works even if the login session uses a non-UTF-8 locale.
Se estiver efetuando login remoto utilizando ssh(1), a variável de ambiente LC_CTYPE presente em seu sistema não será propagada e você terá de defini-la manualmente para que tenha o mesmo valor utilizado no terminal local.
O idioma utilizado em mensagens das aplicações pode ser alterado modificando o valor da variável de ambiente LC_MESSAGES para o nome de uma das localidades suportadas. Este procedimento pode ser realizado da mesma maneira como descrito acima, para alterar o valor da variável de ambiente LC_CTYPE. Ambas as variáveis, LC_MESSAGES e LC_CTYPE, devem ser configuradas com os mesmos valores.
Poucos utilitários presentes no sistema base suportam outro idioma, senão Inglês, até o momento. Entretanto, muitos programas presentes na Coleção de Ports já suportam diversos idiomas. Eles retornarão mensagens em Inglês, caso o idioma desejado não esteja disponível.
[Índice da FAQ] [Seção 9 - Migração para OpenBSD] [Seção 11 - O sistema X Window]
![[voltar]](../../images/back.gif){kind=small}
www@openbsd.org