14.1. Conceitos sobre o servidor Samba?

ESTE FAQ REFERE-SE À VERSÃO 2.0.6 DO SAMBA.

Quais as limitações do Samba na integração com Windows NT?

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:
[root@localhost]# smbadduser epx:elvisp [root@localhost]# 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.):

    [root@localhost]# /etc/rc.d/init.d/smb restart

Como administrar as permissões dos usuários usando grupos?

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

    [root@localhost]# chown root:contabil /home/samba/hercules
    [root@localhost]# 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?

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.
nmblookup. Apenas lista as máquinas NetBIOS da rede.
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.
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).
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 !
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 é 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 erro".

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

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

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.

Erros reportados no samba

Quando aparece este erro:

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