Página seguinte
Página anterior
Índice
ESTE FAQ REFERE-SE À VERSÃO 2.0.6 DO SAMBA.
Versão: 0.2
Data de atualização: 16/02/1999 14:38
. Quais as limitações do Samba na integração com Windows NT ?
(versão 2.0.6 do Samba)
A grande limitação do Samba é não poder FILIAR-SE, como SERVIDOR, a um DOMÍNIO,
pois tal faculdade depende do protocolo SAM, cujo modus operandi não é
divulgado pela Microsoft. Especificamente, o Samba não pode:
- ser BDC de um domínio NT, pois para ser BDC o Samba teria de ter acesso ao
SAM do PDC;
- possuir BDCs.
- ser um servidor "agregado", cujos recursos e permissões são gerenciados
de forma centralizada no PDC (vide: O que são domínios ?).
- ser um servidor de backup do WINS.
- ter servidores de backup do WINS.
Por outro lado, o samba PODE, entre outras coisas:
- ser um PDC, seja de clientes Windows 9x ou NT.
- ser um servidor WINS, desde que não tenha de interagir com outros servidores
WINS.
- dar suporte a logons ao domínio (9x/NT).
- dar suporte a roaming profiles (9x/NT).
- autenticar a senha de um usuário junto a outro servidor Samba ou NT, seja
ou não um PDC.
. E quanto ao Windows 2000 ?
O Samba interage corretamente com o Windows 2000, desde que este último
esteja configurado em MODO DE COMPATIBILIDADE COM NT 4. Nativamente, o
Windows 2000 utiliza Kerberos e LDAP, e o Samba ainda não oferece
interoperabilidade com Windows nesses protocolos.
. Quando o Samba pretende melhorar o suporte a domínios ?
A próxima grande revisão do Samba, cognominada TNG (que corresponderá à versão
2.1.0 ou 3.0.0) deve trazer suporte mais ou menos completo ao DCE/RPC, e com
isso traz de roldão uma melhor integração com domínios NT.
Não obstante, a versão estável do Samba (2.0.x) tem incorporado algum suporte
a domínios a cada revisão, portanto é possível que algumas limitações citadas
caiam bem antes do lançamento da versão TNG.
-------------------------------------------------------------------------------
. O que significam essas siglas: NetBIOS, SMB, CIFS, DCE/RPC, SAM, PDC, BDC ?
NetBIOS: Um protocolo desenvolvido nos anos 80 para suporte a integração
de diversos computadores, numa rede não-hierárquica. Suas principais
características são:
- simplicidade de implementação;
- não precisa de servidor dedicado;
- acesso aos diversos nós por nomes ao invés de endereços numéricos;
- resolução de nomes para endereços de rede através de técnicas de broadcast;
- suporte muito fraco a inter-redes(*).
(*) inter-redes: diversas redes locais, agregadas por roteadores.
Note que muitas das características que tornam esse protocolo simples acabam
sendo limitantes na hora de implementá-lo em uma planta de grandes proporções.
Para isso é que existem as extensões :)
NetBEUI: Protocolo de transporte do NetBIOS. Nada mais é que um pacote NetBIOS
puro dentro de um pacote de rede em modo broadcast. O NetBEUI, por ser tão
simples, não é roteável, ou seja, não pode ser facilmente usado em inter-redes.
Esse protocolo de transporte caiu em desuso, em favor do TCP/IP, que é
roteável.
SMB: Novo nome dado ao protocolo NetBIOS, já bastante estendido. O SMB é
inversamente compatível com computadores NetBIOS, e esforça-se bastante
para manter essa compatibilidade.
CIFS: Novo nome dado ao protocolo SMB que foi novamente estendido pela Microsoft.
NMB: Subconjunto do protocolo SMB/CIFS que dedica-se a traduzir nomes de
máquinas para endereços IP.
WINS: protocolo de resolução de nomes para endereços IP. É a mais importante
extensão ao protocolo SMB, pois permite uma operação "limpa" em ambiente
de inter-redes. (Vide: O que é um servidor WINS ?)
DCE/RPC: Tipo de RPC (Remote Procedure Call), implementado pela Microsoft,
utilizado em praticamente tudo que se refira a administração de domínio,
inclusive gerenciamento remoto do servidor.
É transportado por um "pipe" do SMB. Portanto, não é exatamente uma extensão
do SMB, e sim um protocolo empilhado sobre ele. De qualquer forma, pelo uso
massivo do DCE/RPC em domínios NT, torna-se mandatório implementar esse
protocolo em conjunção ao SMB.
SAM: Banco de dados + protocolo de gerenciamento de domínios.
O banco de dados armazena as mais diversas informações sobre um domínio,
a maioria delas geralmente relacionada com permissões de usuários. Esse
banco de dados é mantido pelo PDC e pelos BDCs.
O protocolo é uma classe de RPC, portanto é "empilhado" sobre o DCE/RPC.
PDC: Primary domain controller - controlador primário de domínio. O banco de
dados SAM mantido por este computador é o "que vale" para todo o domínio.
Os BDCs consultam periodicamente este computador para obter dele o SAM e/ou
as últimas alterações.
BDC: Backup domain controller - controlador reserva. Como já foi dito, o BDC
duplica o SAM do PDC periodicamente. O BDC tem duas funções numa rede:
tomar provisoria ou definitivamente o lugar do PDC caso este último falhe
(o BDC tomar automaticamente o lugar do PDC, porém a promoção definitiva
para PDC tem de ser manual)
atender a usuários de uma rede local que esteja "distante" do PDC.
Exemplo: uma filial ligada à matriz por um link muito lento.
. O que são workgroups (grupos de trabalho) ?
Um grupo de trabalho é uma coleção de máquinas que implementam o protocolo
NetBIOS.
Não existe hierarquia de máquinas dentro de um grupo de trabalho. Cada
computador é dono e responsável por seus próprios recursos. Não existe
gerenciamento centralizado de usuários, senhas, ou permissões.
É claro que podemos exigir autenticação por usuário/senha no acesso a um
recurso. Mas não existe nada que impeça, por exemplo, um usuário de
liberar totalmente o acesso aos recursos de sua máquina.
Uma forma de melhorar um pouco a segurança é delegar toda a
autenticação de usuários/senhas a um único computador da rede - é o
'security = remote' do Samba. Também pode-se rotular alguns computadores
como "servidores" e garantir sua segurança física, de modo que ninguém
possa alterar seus esquemas de autenticação. Note que é você quem está
dizendo quais são os servidores - o protocolo continua não distinguindo essas
máquinas das demais.
Um aspecto interessante acerca dos workgroups são as listas de navegação,
aquelas que aparecem no smbclient e no Ambiente de Rede. A lista das máquinas
de CADA workgroup é mantida por apenas UM computador da rede. O computador
responsável pela lista é escolhido automaticamente (essa "eleição" faz parte
do protocolo NetBIOS). Como esse processo acontece por broadcast, não
funciona muito bem se houver duas ou mais redes - caso em que você precisará
dos DOMÍNIOS.
--------------------------------------------------------------------------------
. O que são domínios, no jargão do SMB ? No que um domínio é diferente de um
grupo de trabalho (workgroup) ?
Domínios são workgroups onde existe alguma hierarquia, ou separação entre
"clientes" e "servidores", sendo que essa hierarquia é garantida pelo protocolo.
A primeira adição ao paradigma dos workgroups é o NAVEGADOR-MESTRE DE DOMÍNIO.
Esse servidor, que TEM DE SER indicado explicitamente pelo administrador
do sistema, vai compilar as listas de computadores de todas as redes locais.
Compreensivelmente, essa função costuma ser acumulada com a de PDC, sendo que
no Windows NT essa acumulação é compulsória. (No Samba, é falcultativa.)
Quando o mestre de domínio é ligado, ele registra-se no servidor WINS,
informando explicitamente a ele que é um mestre de domínio. Cada navegador
local deve contactar o mestre de domínio e transmitir a ele a lista dos i
computadores da rede local. Para localizar o mestre, o navegador simplesmente
pergunta ao servidor WINS: "qual é o navegador-mestre do domínio XYZ ?" e o
WINS responde de acordo.
Portanto, o paradigma de domínio torna possível o funcionamento do protocolo
SMB em uma planta com inter-redes.
Outro aspecto dos domínios é o logon de domínio. Isso faz mais sentido quando
as máquinas-clientes são Windows. Para entrar no domínio, o usuário *precisa*
digitar um usuário/senha válido, do contrário não terá acesso a nenhum
servidor NetBIOS/SMB, e talvez nem à sua própria máquina (isso depende de
configuração).
Note como isso é diferente de um workgroup, onde basta digitar um par
usuário/senha aleatório no Windows, que o usuário terá acesso a todas as
outras máquinas (sujeito, é claro, às exigências particulares de autenticação
de cada uma delas).
Outro aspecto do logon de domínio é o profile (perfil), que pode ficar
armazenado no servidor de domínio. Seja qual for a máquina em que o usuário
esteja logado, receberá seu próprio ambiente de trabalho, com as letras e
cores do seu gosto e com as restrições impostas pelo administrador. (Isso
vale mesmo que o cidadão esteja logando-se de um laptop via Internet!)
O domínio permite a agregação de servidores com administração centralizada.
Ou seja, um computador pode ser definido como servidor pertencente ao domínio.
O acesso dos usuários aos recursos do mesmo é cadastrado no PDC, e não mais
no próprio servidor.
Esse último recurso, não suportado ainda pelo Samba, permite a segregação
dos recursos em duas classes principais:
a) recursos do domínio ("seguros", sob controle do administrador);
b) recursos dos computadores de usuários (inseguros, os usuários compartilham
como bem entendem).
--------------------------------------------------------------------------------
. O que é um servidor WINS ?
No protocolo NetBIOS/SMB padrão, a resolução de nomes é feita com pacotes de
broadcast. É uma solução simples e dispensa configuração, porém não se presta
a plantas com inter-redes.
No WINS, cada máquina, ao ser ligada, REGISTRA seu nome, função e endereço IP
junto ao servidor WINS. Se todas as máquinas fizerem isso, o servidor WINS
terá uma lista de nomes e endereços de todas as máquinas da rede.
Esse registro independe do workgroup ou domínio a que pertença a máquina.
Deve haver apenas um servidor WINS em toda a inter-rede (vide: Um servidor
WINS não é muito pouco ?).
Quando um computador precisa descobrir o endereço IP de outro, não precisa
ficar procurando com broadcasts; consulta diretamente o servidor WINS.
Note que o servidor WINS não trata de nenhum aspecto referente a grupos de
trabalho ou domínios. A única coisa que ele sabe fazer é traduzir nomes
SMB para endereços IP.
Note também que, embora seja comum o PDC ou BDC acumular a função de servidor
WINS, essa concentração de serviços não é obrigatória.
Quando for configurar o Samba e sua rede usar WINS, você deve especificar
exclusivamente uma ou outra das seguintes opções (nunca as duas ao mesmo
tempo):
wins support = yes
wins server = <endereço IP>
A segunda linha indica que o servidor WINS está no <endereço IP>. A primeira
linha diz que o próprio Samba é o servidor WINS da rede.
. Um servidor WINS para toda a rede não é muito pouco ?
Como fica a questão da alta disponibilidade ?
O Samba ainda não suporta o conceito de vários servidores WINS trabalhando
de forma redundante e cooperativa.
Existe uma opção. Se uma empresa tem diversas plantas interligadas, mas não
precisa que e.g. os usuários da planta A enxerguem os usuários da planta B,
atribui-se um domínio e um servidor WINS separado para cada planta.
(Obviamente, esta não é uma solução, e sim uma saída a la Leão da Montanha :)
--------------------------------------------------------------------------------
. Posso passar sem servidor WINS numa inter-rede ?
Em tese, pode. O problema básico é assegurar que os navegadores locais
(ou mestres locais, ou local master browsers, é tudo a mesma coisa)
consigam descobrir onde está o mestre de domínio.
Um esquema possível é:
a) assegurar que o Samba será o mestre local;
b) introduzir um remote announce para a rede do mestre de domínio.
c) introduzir, no Samba mestre de domínio, remote announce para
todas as redes onde possam haver navegadores locais.
d) fazer alguns outros pequenos ajustes para que essa "dança" funcione.
Essa solução aumentaria bastante o tráfego inter-redes, o que pode se
tornar um problema caso haja links de baixa velocidade no caminho.
Se não puder usar o WINS, tente essa solução, mas faça uma boa análise
de tráfego antes de dar o caso por encerrado :)
. Como especificar o modo de resolução de nomes NetBIOS ?
Através da diretiva "name resolve order", que pode conter qualquer um dos
seguintes modos de resolução especificados, em ordem de preferência:
wins consulta o servidor WINS
lmhosts consulta o arquivo /etc/lmhosts
host consulta o DNS
bcast faz broadcast para achar o nome
Exemplo: name resolve order = wins lmhosts bcast
Se os nomes DNS das máquinas não coincidem com seus nomes NetBIOS, é
interessante deixar a opção "host" de fora, pois ela pode causar uma
consulta ao DNS que costuma ser demorada...)
Ideal seria usar apenas o WINS, porém, se o servidor WINS falhar, a rede
NetBIOS pára por completo. Mantendo o broadcast como segunda opção, a
procura fica mais lenta mas pelo menos continua funcionando.
--------------------------------------------------------------------------------
. O que são as senhas encriptadas ?
RESPOSTA CURTA
Ao invés de transmitir as senhas exatamente como são, elas são encriptadas
primeiro. Isso evita "sniffing" de senhas.
Como não existe (AFAIK) forma de um cliente dizer ao servidor que "olhe, estou
transmitindo uma senha encriptada", é necessário que cliente e servidor estejam
corretamente configurados para usarem, ambos, o mesmo tipo de senha.
Por isso é que, no Samba, é necessário especificar "encrypt passwords = yes/no",
pois ele não tem como adivinhar que tipo de senha as demais máquinas da rede
estão usando.
Implementações mais antigas (Windows for Workgroups, primeiro Windows 95) ainda
usam senhas em texto puro. Todas as implementações mais novas (Windows 95 OSR2,
Windows 98/NT/2000) usam senhas encriptadas por padrão, embora isso possa ser
mudado pela edição de uma chave no Registro. O diretório /usr/doc/samba tem
arquivos .reg para conversão dos diversos sabores do Windows para modo texto.
RESPOSTA LONGA
No protocolo NetBIOS/SMB original, as senhas são transmitidas em texto puro,
ou seja, exatamente como são, através da rede. Com a difusão das ferramentas
de "sniffing", qualquer usuário pode captar os pacotes de rede, filtrar
aqueles destinados à autenticação e coletar as senhas dos usuários.
A simples encriptação da senha não resolve o problema, apenas eleva um pouco
a dificuldade de invasão, do ponto de vista de um usuário comum, pois basta
sniffar/armazenar/transmitir a versão encriptada.
O protocolo SMB evita esse problema usando simultaneamente a encriptação e
um esquema de desafio/resposta, como segue:
- o servidor armazena a senha do cliente em forma encriptada (c);
quando o cliente vai se conectar ao servidor, gera um número aleatório
de 64 bits. (n)
- o cliente gera um "hash" da senha com o número aleatório. Esse hash será
o "desafio". (c * n)
- o cliente transmite o número aleatório e o desafio ao servidor.
- o servidor, que também tem uma versão encriptada da senha (c'), gera
novamente o "hash" baseado na sua senha mais o número aleatório gerado
pelo cliente. (c' * n)
- Se os dois "hashes" coincidirem, significa que o cliente sabe a senha,
pois
se (c * n) == (c' * n), então c == c'.
Como a operação "*", nesse caso, é um hash (no estilo MD5) e não uma
multiplicação, a igualdade acima indica que MUITO PROVAVELMENTE c == c',
mas sempre existe a (pequeníssima) chance de o cliente estar num dia de
sorte e ter "chutado" a senha correta.
Note que usar senhas encriptadas envolve muito mais passos na autenticação.
O esquema acima evita a transmissão da senha em qualquer situação, seja
a versão pura ou encriptada. Infelizmente, o protocolo DCE/RPC abre algumas
brechas no esquema, que permitem uma dedução facilitada da senha encriptada,
e então da senha original. *** O protocolo DCE/RPC só é garantidamente
seguro se trafegar por um canal por si só encriptado como o SSL ***
Existem dois tipos de senha encriptada. (É por isso que no arquivo
/etc/smbpasswd há dois campos com 32 dígitos hexa para a senha.)
O esquema mais antigo utiliza o algoritmo DES, adaptado de modo a gerar
um hash de 128 bits. Já o Windows NT utiliza o algoritmo MD4, que gera
128 bits "de berço". Ambos são relativamente pouco resistentes à
inversão (i.e. achar a senha original a partir da encriptada.)
. Como devo cadastrar os usuários no servidor Samba ?
Em primeiro lugar, cada usuário NetBIOS deve corresponder a um usuário
UNIX, porque deste último é que dependem as permissões de acesso. Então,
o primeiro passo é cadastrar os usuários Unix, com adduser ou coisa
parecida.
Se sua rede usa senhas em texto puro (acho improvável :) e os nomes dos
usuários NetBIOS correspondem exatamente aos usuários Unix em nome e
número, basta cadastrar as senhas com passwd, e nada mais precisa ser
feito.
Se sua rede usa senhas encriptadas, você precisa executar os seguintes
passos adicionais:
Adicionar o usuário em /etc/smbpasswd, com
smbadduser <usuário UNIX>:<usuário NetBIOS>.
Exemplos: smbadduser epx:elvisp
smbadduser joao:joao
Note que aqui você tem uma oportunidade de cadastrar usuários cujo
nome NetBIOS seja diferente do nome UNIX.
Cadastrar a senha encriptada do usuário, com smbpasswd. Esse utilitário
funciona de forma semelhante ao passwd, mas preencherá apenas as senhas
encriptadas em /etc/smbpasswd.
Se você tem vários usuários NetBIOS que devem ser mapeados como um único
usuário UNIX, você deve editar o arquivo /etc/smbusers. Esse arquivo tem
diversas linhas no formato
<usuário UNIX> = <usuário NetBIOS> <usuário NetBIOS> ...
Exemplos:
root = administrator
epx = elvis elvisp epx
Crie a relação entre usuários UNIX e NetBIOS no mesmo padrão. Depois,
certifique-se de que o arquivo /etc/smb.conf esteja com a seguinte
diretiva implementada e descomentada:
username map = /etc/smbusers
AFAIK também será necessário reiniciar o servidor SAMBA após fazer esta
última alteração (a maioria das alterações em /etc/smb.conf é assumida
pelo servidor sem necessidade de reiniciá-lo.):
/etc/rc.d/init.d/smb restart
--------------------------------------------------------------------------------
. Eu gostaria de administrar as permissões dos usuários usando grupos UNIX,
e tenho usuários que estão em diversos grupos. Porém, quando um usuário
cria um novo arquivo via servidor Samba, o grupo desse arquivo é sempre o
grupo primário do usuário. Como fazer com que os arquivos criados sejam
possuídos pelo grupo que eu definir ?
É fácil. Se, por exemplo, todos os arquivos criados no diretório
/home/samba/hercules devem ser possuídos pelo grupo "contabil", basta
tornar o grupo dono desse diretório e ligar o bit SGID, v.g.:
chown root:contabil /home/samba/hercules
chmod 2775 /home/samba/hercules.
O arquivo /etc/smb.conf deverá ter, para esse volume, os seguintes
parâmetros de permissão:
force create mode = 775
force directory mode = 2775
Note que isso NÃO modificará as permissões dos arquivos e diretórios que
já existem - você terá de fazer isso usando chmod e chown. Uma fez feito
isso, o Samba e o SGID encarregar-se-ão de manter as permissões estáveis.
(ao invés de x775, você poderá querer usar x770 ou x740, dependendo da
necessidade.)
. Tenho apenas uma rede local. Como devo planejar a minha rede e
configurar as outras máquinas ?
(Muitas das recomendações a seguir não são mandatórias, porém vão resultar
em uma rede mais estável e mais facilmente escalável.)
Tenha um mestre de domínio. Se você já tiver um computador NT como PDC,
provavelmente vai continuar com ele. Do contrário, escolha um dos
servidores Samba para a tarefa. Esse computador deverá ser um "servidor",
ou seja, um computador não sujeito a ser desligado/religado a toda hora.
No Samba, o comando "domain master = yes" define o mesmo como mestre de
domínio, ou PDC.
Eleja o mestre de domínio como navegador-mestre local, de forma explícita,
de forma a que os diversos Samba e/ou Windows NT não fiquem brigando
pela função. Um Windows NT que seja PDC ganha automaticamente essa função.
No Samba que faça papel de PDC, use a diretiva "os level = 254" para garantir
que ele ganhe a eleição. (Talvez um número bem menor que esse já basta, mas
é melhor não facilitar :)
JAMAIS promova o Samba a mestre de domínio ou coloque um OS level muito alto
se o PDC for outro computador - em particular se for o Windows NT, do
contrário haverá "guerra" pela função. O servidor NT, que seja PDC, não aceita
perder a eleição para navegador, convoca nova eleição, perde de novo, convoca
nova eleição... gerando um grande e desnecessário tráfego de rede.
Procure usar senhas encriptadas. Alguns recursos mais novos como logons de
domínio exigem o uso de senhas encriptadas, então é melhor acostumar-se com
elas desde já.
Se você possuir computadores com a primeira versão do Windows 95 ou 3.1x,
atualize-os com os patches da Microsoft para senhas encriptadas. Todas as
versões mais recentes do Windows usam senhas encriptadas por padrão.
AFAWK clientes MS-DOS ou Lan Manager não entendem senhas encriptadas, caso
em que você terá de usar senhas em texto puro. Verifique os arquivos
/usr/doc/samba/*.reg para aprender como desabilitar encriptação de senhas
nas diversas versões do Windows.
Use WINS. Defina um dos servidores como servidor WINS. (Não precisa ser
o PDC. É importante apenas que seja um computador ligado o tempo todo, e
com endereço IP fixo.)
Se escolher um computador Samba como servidor WINS, habilite esse recurso
com a cláusula "wins support = yes".
Nos demais computadores, não esqueça de indicar-lhes qual o número IP do
servidor WINS. No Windows, isso se configura nos folders do TCP/IP. Nos
computadores Samba, use a cláusula "wins server = a.b.c.d", e indique a
ordem de resolução de nomes com "name resolve order = wins bcast".
Se você usa DHCP, configure-o com o número IP do servidor WINS; assim,
você poderá ter cliente 100% plug-and-play. Isso pode ser feito tanto
no NT quanto no Unix.
Se você tem mais de um domínio ou grupo de trabalho, naturalmente haverá
um PDC ou mestre de domínio, por domínio :) No entanto, o servidor WINS
deverá ser único na rede (*).
(*) A não ser que você deliberadamente queira que os usuários de um domínio
não enxerguem outro(s) domínio(s).
. Eu tenho várias redes interligadas. O que mais preciso observar ?
(Assumindo que você já observou os pontos da pergunta anterior)
Defina qual será o mestre de domínio, ou PDC, para toda a planta. (Se houver
mais de um domínio, defina quais serão os PDCs.) Provavelmente ele já existe,
mas é importante que esse servidor esteja "perto" (em termos de largura de
banda) de todas as redes onde houverem usuários do domínio.
Defina qual será o servidor WINS, para toda a planta. A não ser que você
queria mesmo segregar usuários, o servidor WINS será um só para todos os
domínios.
Nas redes em que houver um servidor samba, configure-o com um OS level alto
para que ele seja o navegador daquela rede. Não esqueça de configurá-lo, e
a todas as máquinas da planta, com o endereço IP do servidor WINS.
Tome especial cuidado para que não haja coincidência em nomes de máquinas.
Particularmente problemático é um computador com o mesmo nome do mestre de
domínio.
A troca de dados entre os navegadores locais e o mestre de domínio é automática.
Pois, quando o PDC é ativado, registra-se com essa função no WINS. Os navegadores
locais "acham" o PDC por uma simples consulta ao WINS.
Os navegadores locais varrem a rede e passam esses dados ao PDC a cada 12
minutos. Devido a esse fator, um usuário de uma rede perimetral pode demorar
até 36 minutos para enxergar outro usuário em outra rede perimetral. (Isso
pode ser provado através de um pequeno exercício de lógica - e de qualquer
forma lembre-se que "se aconteceu, tem de ser possível" :).
--------------------------------------------------------------------------------
. Tenho duas placas de rede no meu servidor, mas apenas os usuários ligados
a uma das redes enxerga o Samba. Qual é o problema ?
O Samba, por padrão, liga-se apenas a primeira interface de rede que
encontrar. Isso pode ser mudado inserindo-se uma linha nesse estilo:
interfaces = 192.168.12.2/24 192.168.13.2/24
Note que essa configuração abre uma possibilidade não muito óbvia. Poderíamos
rodar várias instâncias separadas do Samba em um mesmo computador, desde que
cada instância ligue-se a uma interface separada. (Nada que não pudesse ser
aproximado com a macro %L, mas ...)
. Como o Linux pode ser *cliente* do protocolo SMB ?
1 - smbclient. É uma espécie de "canivete suíço", em modo texto. Permite
a navegação em volumes no estilo FTP, impressão, remessa de mensagens,
consulta a recursos de servidores etc. Alguns utilitários (smbprint,
smbtar) são meros scripts que chamam alguma função do smbclient.
Sua principal vantagem é ser versátil. A principal desvantagem é não
ser uma ferramenta adequada para o usuário final, e às vezes nem
mesmo para o usuário experimentado.
2 - nmblookup. Apenas lista as máquinas NetBIOS da rede.
3 - smbmount. Aliado a um módulo do kernel, permite montar volumes SMB
como diretórios do UNIX.
Sua principal vantagem é a transparência. Uma vez montado, o volume
pode ser tratado como qualquer outra árvore de diretórios do sistema.
Desvantagens: compatível apenas com Linux e também não é palatável
ao usuário final.
4 - smbwrapper. Instancia um shell e captura quase todas as chamadas de
sistema que lidam com arquivos (open, close, read, write...).
Emula uma estrutura de diretórios (/smb/<servidor>/<volume>/...), de
modo que tanto o shell quanto os programas executados a partir dele
"pensam" que estão acessando arquivos comuns, mas na verdade essas
chamadas são interceptadas e satisfeitas via SMB.
Vantagens: compatível com diversos Unixes, não envolve processo de
montagem e, como mapeia a rede NetBIOS como diretórios comuns, torna-se
acessível ao usuário final através de outras ferramentas. A pricipal
desvantagem é não funcionar direito. Outra desvantagem é não suportar
todas as chamadas de sistema passíveis de lidar com arquivos (e.g.
mmap).
5 - navegadores no estilo "Ambiente de Rede". Existem alguns (kruiser,
gnomba, xsmbbrowser), nenhum suficientemente bom ou estável. De todos,
o kruiser é o que mais perto chega de ser útil.
Mas a principal desvantagem é de outra natureza: fraca integração com
o ambiente gráfico. Pouco adianta enxergar volumes/arquivos dentro de
um utilitário, se você não enxerga esses mesmos objetos em nenhum outro
programa !
6 - smbtree. É um conjunto de utilitários em estágio inicial de desenvolvimento
pela Conectiva. É uma espécie de integrador dos recursos existentes
(smbclient, nmblookup, smbmount) com objetivo semelhante ao smbwrapper:
manter uma árvore de diretórios análoga à estrutra da rede NetBIOS.
Suas principais vantagens serão: a transparência do smbmount (pois
realmente montará os volumes que o usuário quer acessar), a casualidade
do smbwrapper (pois a estrutura de diretórios será dinâmica) e a
transparência, pois qualquer programa que consiga ler uma árvore de
diretórios, enxergará a rede NetBIOS.
Apesar de usar como apoio os utilitários smbmount, smbclient e nmblookup,
tentar-se-á eliminar a necessidade da presença do arquivo /etc/smb.conf,
problema que afeta todos os demais utilitários. (Pelo menos numa
workstation, parece estranho ter de configurar o servidor para se ser
cliente, não é ?)
Terá como desvantagens a pouca ou nenhuma compatibilidade com sistemas
não-Linux, e (por enquanto) não suportar filas de impressão remotas,
obrigando ao uso do smbprint.
-------------------------------------------------------------------------------
. Como posso montar um drive do Windows como um subdiretório do Linux ?
No Samba 2.0.6:
smbmount //servidor/volume /diretorio -o username=usuario%senha
^^^^^^^^ ^^^^^^ ^^^^^^^^^ ^^^^^^^ ^^^^^
As setas apontam os parâmetros que você vai alterar conforme seu sistema.
Note que para o smbmount funcionar, o arquivo /etc/smb.conf deve existir
e estar minimamente configurado para seu computador e rede. Nesse caso,
os parâmetros mais importantes são:
encrypt passwords
wins server
wins support
name resolver order (vide "Como especificar a ordem de resolução de nomes
NetBIOS ?)
A forma de especificar usuário e senha nas versões anteriores do Samba
é um pouco diferente. Consulte o manual on-line.
A desmontagem pode ser feita com smbumount /diretorio ou umount /diretorio.
O smbmount tem capacidade de recuperação (i.e. se a conexão é fechada, ele
tenta abrí-la novamente, tal qual faria um cliente Windows). Porém, devido
a um bug no sistema de log, o smbmount aborta ao tentar reabrir a conexão.
A versão 2.0.6 do Samba, que será distribuída com o Conectiva Linux 5.0,
está devidadamente "patcheada", porém fique atento a versões mais antigas
e mais novas !
. Como devo proceder para mandar jobs de impressão para uma impressora
ligada a um servidor Windows ?
A opção fácil é usar o printtool, um utilitário gráfico que também pode
ser acessado a partir do control panel. A configuração é muito fácil, mas
observe que seu arquivo /etc/smb.conf deve estar minimamente configurado,
tal como no caso do smbmount.
(Tudo fica mais fácil se você for acessar a impressora como guest, ou
seja, sem usuário/senha.)
Se você editar manualmente o arquivo /etc/printcap, você terá de executar
os seguintes passos adicionais:
chamar smbprint como um filtro de entrada (if=);
Criar o arquivo /var/spool/lpd/<nome da fila>/.config que conterá os
nomes de máquina, usuário e senha. O smbprint é um script que varia
ligeiramente conforme a distribuição; verifique seu conteúdo para
determinar o nome exato das variáveis que você deverá preencher.
Se tiver dúvidas e o modo gráfico estiver funcionando em seu (ou em outro)
computador, crie uma impressora via printtool e verifique o conteúdo de
/etc/printcap e /var/spool/lpd/<fila>/.config, para "pegar o bizú".
--------------------------------------------------------------------------------
. Existe algum utilitário semelhante ao "Ambiente de Rede" do Windows ?
Vide "Como o Linux pode ser *cliente* do protocolo SMB ?".
--------------------------------------------------------------------------------
. Quais as macros existentes (%[letra]) e como devem ser usadas ?
O manual on-line do smb.conf traz as macros (lista parcial):
%S o nome do serviço corrente (se houver/fizer sentido)
%P o diretório-raiz do serviço corrente
%u usuário UNIX (efetivo)
%g grupo primário UNIX correspondente a %u
%U usuário NetBIOS (que pode ser diferente de %u)
%G grupo primário de %U
%H Diretório-base do usuário %u.
%v Versão do Samba.
%h Nome DNS da máquina em que o Samba está rodando.
%m Nome NetBIOS do cliente.
%L Nome NetBIOS do servidor. (*)
%M O nome DNS da máquina-cliente.
%I O número IP da máquina-cliente.
%R Nível de protocolo negociado. (CORE[PLUS]?, LANMAN{1,2}, NT1)
%d O número do processo (PID) do servidor corrente.
%a Arquitetura da máquina-cliente. (**)
%T Data e hora correntes.
(*) Como um servidor pode ter diversos apelidos NetBIOS além do nome
primário, a macro %L permite alterar o comportamento do Samba de
acordo com o nome pelo qual o cliente conhece o servidor. Isso
permite, com o auxílio da diretiva include, ter-se diversos
"servidores virtuais", "diferentes", num único computador e
rodando uma única instância do Samba.
(**) Não é 100% confiável e informa apenas Samba, WfWg, WinNT e Win95.
Qualquer outro tipo de cliente será UNKNOWN.
As macros são interpretadas da seguinte maneira. Quando um usuário
conecta-se a um servidor, uma nova cópia do processo smbd é iniciada.
Essa cópia reinterpreta o arquivo /etc/smb.conf, substituindo as
macros pelos seus valores.
Note que você pode usar essas macros até com a diretiva "include", de modo
que é possivel se ter praticamente um smb.conf ("patcheado" com um include
específico) para cada usuário !
A diretiva include não aceita as macros %u, %P e %S.
--------------------------------------------------------------------------------
. Ok, já consigo fazer domain logons, tendo o Samba como PDC. Agora, onde crio
o logon script ?
O arquivo de configuração do Samba deve conter uma diretiva semelhante a:
logon script = %U.bat
O diretório-base dos logon scripts é o volume [netlogon]. No exemplo, se o
diretório do volume netlogon for igual a "/home/samba/netlogon", o script
do usuário "roberto" seria procurado em /home/samba/netlogon/roberto.bat.
Nada impede que se introduza um subdiretório na diretiva logon script, como em
logon script = profiles/%U.bat
Dois detalhes muito importantes:
Verifique as permissões do usuário: as permissões do volume [netlogon]
em si, as permissões UNIX do usuário para com o(s) diretório(s) desse
volume, e finalmente permissão de leitura do usuário para o script.
O script DEVE ser criado como um arquivo-texto do DOS. Se for simplesmente
criado no UNIX com o "vi", e nada for feito para converter o arquivo-texto
para o padrão do DOS, o logon script NÃO funcionará.
--------------------------------------------------------------------------------
. O que são volumes "home" ?
O volume [homes] do Samba é na verdade um falso volume, que é mapeado para
o diretório-base do usuário UNIX ("home"), correspondente ao usuário que
logou-se no servidor.
Como cada usuário tem esse volume mapeado para seu próprio diretório-base,
é uma forma fácil e rápida de criar volumes "privativos" dos usuários.
Conforme veremos em seguida, esses volumes são *necessários* para armazenar
profiles.
. Como usar roaming profiles ?
WINDOWS 95/98
No folder Painel de Controle / Senhas / Perfis de Usuário, o Windows deve
estar configurado para usar profiles (perfis) separados por usuário. O
padrão é usar um único perfil para todos os usuários da máquina.
Nesse mesmo folder você pode configurar também se ícones do desktop e menus
fazem ou não parte do profile.
Se você não usava profiles antes, é interessante apagar os usuários já
cadastrados no folder Painel de Controle / Usuários, suas senhas em cache
(\WINDOWS\*.PWL) e seus profiles locais (\WINDOWS\PROFILES\*).
O Windows NÃO pergunta ao PDC onde estão os profiles - ele assume que estão
no diretório-base do usuário ("home"). Isso significa, para o Samba, que
a cláusula "logon path" deve existir mas será inócua; o falso volume "homes"
deve existir.
Opcionalmente, pode-se jogar um arquivo nomeado CONFIG.POL no volume netlogon.
O Windows sempre procura por esse arquivo. Ali, podem ser configuradas algumas
políticas de funcionamento (FIXME: Imagino que ali podemos dizer que o profile
está em outro lugar que não o "home" do usuário).
Infelizmente, o CONFIG.POL não é um arquivo-texto comum, e seu formato não é
amplamente conhecido. Se precisar dele, você terá de criá-lo no Windows NT,
e depois copiá-lo para o Samba.
Alguns recomendam ainda que os volumes [netlogon] e [homes] devam ser
"browsable = yes", e que o logon script do cliente tenha um comando
semelhante a
net use X: /home
do contrário o Windows 95 recusar-se-ia a gravar os profiles no "home" do
usuário. Não confirmamos a necessidade disso; porém, existem várias
sub-versões do Windows 95, e pode ser que alguma delas exija essas coisitas.
Parece que o comportamento de jogar os profiles no diretório home é
particular do Samba 2.0.6, enquanto os Sambas anteriores obedeciam ao
logon path. Vide este e-mail da lista do Samba:
<< EOF
I wouldn't call them broken -- they got changed from 2.0.5a. If you'd like
to restore the 2.0.5a behavior (I like that behavior better), change these
two source/smbd/ipc.c calls from:
pstrcpy(p2, lp_logon_home());
to
pstrcpy(p2, lp_logon_path());
This will revert to the 2.0.5a behavior that gets profile location right
but has been reported to get home directory wrong. Also, it's been reported
that the following workaround places both profiles and the home directory
where they belong (without the source code reversion)
logon home = \\%L\%U\profile
Steve Litt
At 07:27 AM 02/18/2000 +1100, eirvine wrote:
>Hi,
>
>Roaming profiles are *broken* in 2.06. They work just fine on 2.05a.
>
>Eddie.
>
>JF HUNEZ wrote:
>>
>> Hello,
>> I run Samba 2.06 as PDC and the clients are Win98 machines
>> only.
>> Roaming profiles don't work, there is no user.dat in the profiles
>> share, only the START folder.
>> I have read the doc in /usr/doc and the NTDOM faq too ; my
>> smb.conf meets the recommendations.
>> Roaming profiles need a NT server on the network ??
>>
EOF
WINDOWS NT
Também deve ser configurado para usar perfis;
Ao contrário do 95, ele lê/grava o profile na localização apontada pelo PDC;
portanto, a diretiva "logon path" deve ser corretamente configurada.
Costuma ser recomendada a criação de um volume apenas para os profiles.
A desvantagem desse método é que o diretório de cada usuário tem de ser
criado manualmente. Uma saída possível é fazer
logon path = \\%N\%U\profile (*)
e modificar o script "adduser" de modo que esse ~/profile seja criado
no momento da criação do usuário. (Um FAQ sugeriu que o Windows tenta
criar automaticamente quaisquer subdiretórios, o que tornaria
desnecessária a alteração em adduser. Sujeito a verificação !!!)
(*) %N é o nome do próprio servidor e %U é o nome do usuário NetBIOS.
\\%N\%U resulta no próprio volume "home" do usuário -- desde que o volume
[homes] exista !
O NT também lê o arquivo CONFIG.POL, se ele existir.
--------------------------------------------------------------------------------
. Como posso fazer o profile ser individual por MÁQUINA (não por usuário,
como é mais comum) e fixo (somente-leitura) ?
(by lclaudio@conectiva.com.br)
Use a seguinte linha:
logon path = %systemroot%\profiles\%u
onde %systemroot% simboliza um diretório LOCAL da máquina-cliente de logon,
e %u é o usuário.
A partir disso, pode-se configurar as políticas da máquina para obter
o profile padrão a partir de um "default user", eliminar profiles de novos
usuários assim que eles vão embora (útil num ambiente de laboratório, onde
muitíssimas pessoas usam as máquinas esporádica e aleatoriamente, e não
faz sentido manter profile de cada um).
<completar com os detalhes da configuração no Windows>
--------------------------------------------------------------------------------
. Quais são as soluções de HA (alta disponibilidade) para Samba ?
O protocolo SMB estabelece o conceito de "cliente bem-comportado". O aspecto
desse bom comportamento que interessa à questão HA é que, se o cliente estiver
ligado a um servidor e for desconectado, ele tentará reconectar-se
automaticamente, e insistirá nisso até desistir (e reportar erro ao usuário).
Portanto, um esquema simples de HA que envolva start/stop do Samba em
duas ou mais máquinas tende a funcionar bem.
Outro aspecto importante do SMB é que o acesso às máquinas é feito pelo nome,
e não pelo endereço IP. Assim, mesmo que o servidor substituto tenha IP
diferente, o cliente será capaz de procurar pelo nome do servidor "oficial",
achará o subtituto e fará a conexão.
(Essa última funcionalidade não funcionará tão bem caso a rede use um
servidor WINS. Como qualquer esquema decente de HA envolve takeover de IP,
não constitui empecilho real para a implementação de HA).
O serviços mais facilmente portados para HA são os "stateless". Stateless
significa que o servidor não retém informações sobre o cliente.
Infelizmente, o Samba não é stateless. Como o cliente refaz automaticamente
a conexão, isso não faz mossa... Mas, e se o cliente tiver locks sobre um
arquivo ? Bem, aí faz mossa.
Por esse último fator (locks mantidos na memória do processo-servidor), a
dificuldade de constituir um servidor Samba-HA varia enormemente DE ACORDO
COM O TIPO DE APLICAÇÃO QUE OS CLIENTES RODAM. O pior caso seria um programa
com banco de dados multiusuário não-SQL. O melhor caso seria o mero
armazenamento de textos e planilhas, com atualização esporádica.
==============================================================================
PERGUNTAS AVULSAS
==============================================================================
> >
> > nmbd/nmbd_name query.c: query_name response (95)
> > query_name_response: multiple (2) responses reiceived for a
> > query on subnet 192.168.0.117 for name DESENVOLV(1d).
> > this message was from 192.168.0.108
> >
> > Gostaria de saber o porque e como desabilitar isso...
>
> Isso significa que, provavelmente, na rede indicada pelo nmbd, existem
> duas máquinas com o mesmo nome NetBIOS, e talvez até com o mesmo IP.
>
> Essa mensagem me ajudou um dia a descobrir um problema de não-localização
> do PDC. Uma das máquinas Windows tinha o mesmo nome que o PDC, aí... :(
----------------------------------------------------------------------------
. Para que serve a cláusula "only user" ?
Para assegurar que apenas os usuários que estejam na lista definida pela
cláusula "user = ..." possam conectar-se ao volume.
O nome dessa diretiva é infeliz e, no caso do volume [homes], induz o
pensamento de que "only user" refere-se ao usuário dono do diretório home.
Habilitar essa diretiva terá como única conseqüência indisponibilizar o
volume a usuários perfeitamente legítimos.
Para outros volumes, seu uso é válido (em conjunção com user list = ...)
porém uma política de segurança baseada em usuários/grupos/permissões UNIX
seria mais indicada.
----------------------------------------------------------------------------
Página seguinte
Página anterior
Índice