Linux in Brazil tem o orgulho de apresentar mais um artigo do Elvis Pfützenreuter, que além de ser consultor de informática (com ênfase no uso do Linux), também já prestou muitos serviços à comunidade brasileira, com algumas traduções e também alguns ótimos artigos originais.
Desta vez o artigo é sobre o Samba, o pacote de software capaz de fazer o Linux emular um servidor Windows NT. Vamos ao texto do Elvis:
versão 1.0 - 09/10/1999
Elvis Pfützenreuter - info@rootshell.com.br
O objetivo deste documento é cobrir algumas lacunas da documentação "oficial" do Samba. v.g. SMB-HOWTO e manual on-line do arquivo /etc/smb.conf. O diretório de documentos do Samba contém diversos textos esparsos que lançam luz sobre os detalhes de funcionamento do protocolo NetBIOS, e este texto procura trazer as informações mais importantes ali contidas.
O Samba é um programa complexo e já bastante maduro. Em sua versão estável atual - 2.0 - a única coisa que o Samba não suporta de forma irrestrita é o conceito de domínios. Especificamente, ele não pode ser PDC ou BDC em redes Windows NT, nem suporta o conceito de servidores WINS redundantes. O suporte completo a domínios está previsto para a versão 2.1, que não tardará a ser liberada.
Parece que boa parte da documentação disponível para o Samba pressupõe conhecimento razoável sobre o protocolo NetBIOS. Infelizmente, não é bem essa a realidade. Depois de passar alguns apuros e ficar dependendo da sorte para que os servidores Linux aparecessem na janela "Ambiente de Rede", criei coragem e imprimi todos os textos da documentação esparsa do Samba (/usr/doc/samba*/docs/textdocs/*). Ali, finalmente encontrei aquele conhecimento de baixo nível que dava remédio a meus azares.
O protocolo NetBios foi concebido para ser simples de configurar e usar em redes pequenas. Porém, essa aparente simplicidade desaparece em qualquer instalação que contém duas ou mais redes Ethernet. É o que eu chamo de "curva de aprendizado exponencial", característica que o NetBIOS compartilha com o Windows, Visual Basic e assim por diante. Outros procolos (TCP/IP) e softwares (Linux) obrigam seus usuários a ter um conhecimento relativamente profundo por mais simples que seja a tarefa; porém não reservam "surpresas" para instalações de complexidade crescente. Portanto, desenham uma curva de aprendizado logarítmica, de que tanto gostam os Linuxers.
Não obstante, o NetBios - assim como o DHCP, para quem o conhece - tem o seu valor, e, uma vez dominados seus conceitos, pode ser útil e muito adequado até mesmo em redes sem máquinas Windows.
Este documento não substitui o SMB HOWTO, nem o manual on-line do arquivo /etc/smb.conf, nem mesmo a documentação esparsa. É um apanhado geral que deve servir como ponto de partida, para que a leitura de todos esses outros documentos seja mais confortável, pela prévia dominação dos conceitos de baixo nível.
NetBIOS é um protocolo de transporte e de sessão, de uso geral, mas primariamente destinado a serviços de arquivo e impressão. Nesse último aspecto, é semelhante ao protocolo NCP da Novell. Porém o NCP é um protocolo de sessão; o transporte é feito pelo protocolo subjacente IPX (embora será muito difícil encontrar uma instalação onde IPX e NCP não estejam "empilhados").
Para quem não sabe, protocolo de transporte é aquele que leva UM pacote de rede da origem até o destino. Protocolo de sessão encarrega-se de dividir seqüências arbitrariamente longas de dados em pacotes (então transportados pelo protocolo de transporte) e remontá-las no destino, possivelmente ordenando a retransmissão de pacotes perdidos etc. No protocolo TCP/IP, o IP é encarregado do transporte e o TCP, da sessão.
Como o protocolo NetBios é capaz de cuidar do transporte, não precisa ser "carregado" por nenhum outro protocolo; pode ser constituído como pacote de rede e transmitido. É isso que o protocolo NetBEUI da Microsoft faz - pega os pacotes NetBIOS in natura e transmite-os rede afora. Porém, o NetBIOS não é nativamente capaz de ser roteado; portanto, fica "preso" à rede local.
Uma possível solução é programar os roteadores para que retransmitam pacotes NetBIOS às outras redes; assim, o pacote NetBIOS/NetBEUI acabará atingindo o seu destino, pois é recebido e analisado por absolutamente todos os computadores da organização. Essa solução tem o inconveniente de gerar um tráfego de rede infernal, e ainda mais infernal de a comunicação inter-redes for feita através de links de baixa velocidade.
Outra solução é encapsular o NetBIOS em um protocolo de transporte que seja roteável, como o IPX ou o TCP/IP. De fato, a forma mais comum de se usar serviços NetBIOS hoje é através de TCP/IP - e é a única forma suportada pelo Samba. Como o NetBIOS não é nativamente roteável e não aceita o conceito de endereço IP ou IPX, várias extensões foram criadas para torná-lo mais adequado a uma instalação com diversas redes locais. Veremo-nas todas ao longo deste texto.
Como o Samba suporta apenas NetBIOS encapsulado em TCP/IP, daqui por diante não falaremos mais sobre outras encapsulaçòes. Apenas vale lembrar que, ao configurar suas máquinas Windows, procure não misturar encapsulamentos diferentes. i.e. usar NetBIOS encapsulado em IPX, TCP/IP e NetBEUI todos ao mesmo tempo. Isso pode ser fonte de inúmeros problemas intermitentes e dores de cabeça. Tire o NetBEUI da lista de protocolos suportados e, se precisar usar IPX, certifique-se de que não está habilitado o transporte de NetBIOS sobre IPX.
Como o NetBIOS se obriga a cuidar do transporte, e ao mesmo tempo não suporta números IP, ele trabalha com técnicas de broadcasting. Uma vez lançado um pacote na rede local, todas as máquinas receberão e analisarão esse pacote; apenas aquela que for a máquina-destino deverá assimilar o pacote. Obviamente existe uma identificação da máquina de destino, que é um NOME de até 15 caracteres (doravante chamado de "nome NetBIOS da máquina") e não um endereço númérico. Isso é muito diferente de uma comunicação TCP/IP "normal", onde as próprias placas de rede determinam se o pacote lhes pertence ou não, sem envolver processamento de software.
O TCP/IP permite fazer broadcasting de uma forma muito simples: supondo uma rede local 10.30.0.0/16, o endereço de broadcasting é 10.30.255.255. Um pacote IP emitido com esse endereço será analisado a nível de software por todas as máquinas daquela rede local. É exatamente esse expediente que o NetBIOS utiliza para forçar broadcasting mesmo quando encapsulado em TCP/IP.
O uso massivo de broadcasting torna o NetBIOS muito simples de usar em redes isoladas, pois não é necessário saber muito sobre endereços IP para que as máquinas enxerguem umas às outras. É claro que existe o custo (relativamente pequeno) de processamento, pois todas as máquinas tem de analisar todos os pacotes NetBIOS a nível de software.
Como já foi dito, o broadcasting não combina muito bem com instalações onde há várias redes locais interligadas por roteadores. Os pacotes de broadcast não conseguem ultrapassar a fronteira do roteador. O contorno dessa limitação está descrito no tópico 4.
Um dos aspectos mais interessantes e desconhecidos do NetBIOS está na "eleição" do navegador-mestre local, descrito na documentação do Samba como local master browser, e doravante aqui chamado de "mestre". Periodicamente, os computadores de uma rede local trocam pacotes para determinar quem tem o maior OS level. O OS level (doravante chamado de "nível") é nada mais que um número de 0 a 255. Se não me falha a memória, o nível do Windows 95 é 001 (decimal!), o do Windows NT é 032, e o nível padrão (porém alterável) do Samba é 033.
O computador com maior nível vencerá a eleição. Se houver mais de um computador com o mesmo nível, haverá um desempate por critérios aleatórios. Mesmo que a rede tenha apenas computadores Windows 95, todos com um número de nível muito baixo, um deles acabará sendo o escolhido.
O computador vencedor ficará responsável em compilar uma lista das máquinas presentes na rede local. Não surpreendentemente, ele usará técnicas de broadcasting para esse fim. Os demais computadores obterão essa lista junto ao mestre. É justamente essa lista que aparece na janela "Ambiente de Rede" do Windows.
É importante entender que, numa rede local, há apenas um computador tomando conta da lista. Pode até parecer, pela demora no surgimento da janela, que cada computador desbrava a rede por conta própria, mas NÃO é isso que acontece.
Agora a primeira "pedra" onde alguém pode tropeçar. O Windows NT não gosta de perder a eleição para o Samba se ambos tiverem o mesmo OS level. Portanto, nunca configure o Samba com o mesmo OS level que o Windows NT. Configurar o Samba para que ele nunca vença a eleição para mestre, ou então use o maior nível possível (255).
Note que todo esse processo ocorre dentro de uma rede local. O fato de um computador ser o mestre de uma rede (ainda) não lhe dá o poder de enxergar as demais redes da instalação. Isso é assunto para o tópico 4.
Um detalhe importantíssimo: mesmo dentro de uma única rede local, haverá um mestre para cada grupo de trabalho (workgroup). Portanto, se você quer que todas as máquinas se enxerguem, tome o cuidado de configurá-las todas com o mesmo grupo de trabalho. Ou, se deseja isolar grupos de máquinas dentro de uma rede isolada, configure deliberadamente com grupos diferentes.
O sintoma mais aparente de um computador com grupo de trabalho configurado incorretamente é o fato de ele não enxergar nenhum computador na janela Ambiente de Rede; quando muito, enxerga apenas o grupo de trabalho. Exemplo: o grupo de trabalho é VITARA e um computador está configurado para o grupo VITARE. Esse último computador está num grupo isolado e tornar-se-á o mestre daquele grupo. Obviamente, a lista que ele mesmo compilou só contém um computador, pois as demais máquinas da rede estão em outro grupo de trabalho e elegeram outro mestre.
Se o computador-mestre for desligado, alguma outra máquina procurará pelo mestre, e não o achará. Nesse caso, uma nova eleição é efetuada. Esse é um ponto interessante do NetBIOS: redundância automática.
Forçando um pouco os conceitos, pode-se dizer que um domínio é um grupo de trabalho onde haja pelo menos um computador "responsável" por ele - é o mestre do domínio. (Temos aqui um conceito recursivo, eu acho.)
No mundo Windows NT, o mestre do domínio é o próprio PDC - primary domain controller. Já o Samba, que ainda não suporta completamente todas as funções de um controlador de domínio NT (*), pode ser explicitamente configurado para ser apenas o navegador-mestre do domínio.
(*) A versão 2.1 do Samba deve trazer suporte quase completo a controle de domínio e BDCs.
O mestre do domínio compilará a lista de TODAS as máquinas do grupo de trabalho, mesmo que estejam em outras redes locais. Além disso, por ser uma máquina privilegiada, vencerá sempre as eleições para mestre da rede local, pois não faria sentido haver um mestre local e um mestre de domínio separados.
Deve haver APENAS UM mestre de domínio por domínio. Tenha em mente que o NT costuma ser configurado em tempo de instalação para ser o mestre do domínio. Tome cuidado com isso ao instalar outras máquinas NT, e principalmente, não configure o Samba para ser mestre de domínio sem antes verificar as configurações dos servidores NT. Como não existe eleição para mestre de domínio, a presença de mais de um mestre é fonte certa de problemas, principalmente se um dos pretensos mestres de domínio for NT.
Agora, resta saber como o mestre do domínio consegue descobrir os nomes das máquinas de fora da rede local. As bases estão nos tópicos 4 e 5, e o mecanismo prático está descrito no tópico 6.
Como o NetBIOS utiliza-se de broadcasting, fica restrito à rede local, pelo menos nas instalações "sérias". Para que o NetBIOS possa ultrapassar as fronteiras da rede local, três mecanismos são necessários:
- capacidade de comunicar-se diretamente com outros computadores pelo número IP, pois só assim os roteadores aceitarão transportar os pacotes;
- capacidade de traduzir nomes NetBIOS para números IP, para que o usuário não perca a comodidade de usar nomes NetBIOS;
- capacidade de compilar listas que contenham todos os computadores de todas as redes da instalação.
A implementação da Microsoft para o protocolo NetBIOS foi estendida de modo a cumprir o primeiro quesito, e uma extensão "externa" ao NetBIOS, denominada WINS, cumpre os demais quesitos.
Assim, modernamente o NetBIOS não depende mais exclusivamente do broadcasting para fazer o transporte. Se houver um mecanismo qualquer que identifique o número IP da máquina de destino, o pacote NetBIOS encapsulado em TCP/IP será mandado diretamente ao IP do computador-destino, mesmo que esse IP esteja fora da rede local, pois os roteadores serão capazes de transportá-lo. É possível inclusive trafegar NetBIOS pela Internet pública !
O mecanismo mais primitivo de tradução de nomes NetBIOS para endereços IP é o arquivo c:\windows\lmhosts ou /etc/lmhosts. É uma lista pura e simples dos nomes NetBIOS com os endereços IP ao lado. Logo descobre-se as desvantagens desse mecanismo: cada computador tem de ter a sua lista, as atualizações também precisam ser feitas em todas as máquinas, e os computadores desse arquivo não aparecem na janela Ambiente de Rede. O ideal seria que a tradução funcionasse de modo análogo ao DNS.
Entra o serviço WINS, que opera de modo análogo ao DNS. Note que eu disse análogo, e não semelhante, nem paralelo, nem igual. O WINS é contactado diretamente pelo número IP - nada de broadcasting para localizar o servidor WINS, até porque ele não faz parte do NetBIOS em si.
O WINS não tem um cadastro estático de computadores. Ele recebe informações de todos os computadores da instalação e, dinamicamente, vai formando uma lista de todos os computadores da rede: nomes NetBIOS, grupos de trabalho e os respectivos endereços IP. O servidor WINS mantém cadastros de todas as máquinas da instalação, independentemente do grupo de trabalho. Por isso mesmo, deve haver apenas um servidor WINS na instalação inteira, mesmo que haja vários grupos de trabalho e/ou mestres de domínio.
NÃO confunda o servidor WINS com o mestre do domínio. Embora é comum rodar o WINS na própria máquina que foi designada como mestre do domínio, é perfeitamente possível que os dois residam em computadores separados!
Também lembre-se que não existe nenhuma integração automática entre DNS e WINS, mesmo que ambos rodem no mesmo servidor. O fato de cadastrar o nome DNS de um computador não significa que o servidor WINS vá passar a conhecer o endereço IP do mesmo.
Existem alguns mecanismos de fallback onde o nome NetBIOS é consultado junto ao servidor DNS se o servidor WINS não responder à consulta, mas a própria documentação do Samba desaconselha seu uso. Em grandes instalações com muitas estações de trabalho, é muito comum (e aconselhável) o uso de DHCP, o que torna o DNS completamente inútil para acesso inter-estações.
O documento BROWSING-Config.txt contém uma excelente descrição de como o mestre de domínio consegue compilar a lista de todos os computadores de uma instalação. Considere a descrição a seguir uma cópia pálida e "mastigada".
Suponha que haja três redes locais interligadas por roteadores: A, B e C. Suponha também que em cada rede haja cinco computadores, e que todos, independentemente do sistema operacional, ofereçam serviços NetBIOS. Suponha também que:
- O nome do grupo de trabalho/domínio seja ACME;
- O computador A_2 seja o mestre de domínio;
- O computador A_3 seja o servidor WINS e seu IP é 10.30.14.56;
- Todos os computadores estejam configurados corretamente e "saibam" que o endereço IP do servidor WINS é 10.30.14.56;
- Os computadores A_1, B_1 e C_1 estejam rodando o Samba e, exceto por A_1, estejam programados para vencer as eleições para mestre local.
Tão logo os computadores sejam ligados, haverá eleições para mestre em cada uma das redes locais. Nas redes B e C, os computadores B_1 e C_1 vencerão. Na rede A, o computador A_2 vencerá a eleição pois é o mestre do domínio e isso lhe dá preponderância sobre todas as outras máquinas da rede.
O mestre do domínio (A_2) registrará o domínio junto ao servidor WINS (A_3). Da mesma forma, todas as outras máquinas registrarão seus nomes NetBIOS, grupos de trabalho e números IP junto ao servidor WINS.
Os computadores começarão a anunciar a si mesmos por pacotes de broadcast. Atentos, os mestres locais compilarão uma lista das máquinas de cada rede. Nesse instante, os mestres de cada rede local conterão as seguintes listas de computadores:
A_2: -> A_1, A_2, A_3, A_4, A_5
B_1: -> B_1, B_2, B_3, B_4, B_5
C_1: -> C_1, C_2, C_3, C_4, C_5
Até agora, nenhuma rede tem conhecimento da existência das demais redes.
Cada um dos computadores de todas as redes vai contactar o servidor WINS (A_3) e registrar-se junto a ele. Nesse ponto, o servidor WINS conhece os nomes NetBios, grupos de trabalho e endereços IP de todas as máquinas. Como o WINS funciona independente do mestre de domínio A_2, este último continua com sua lista incompleta.
Cada mestre local (B_1 e C_1) contacta o servidor WINS e descobre o endereço IP do mestre de domínio (A_2.). A seguir, o mestre local contacta o mestre do domínio e transmite a ele a lista de todas as máquinas do grupo de trabalho. Em troca, o mestre de domínio transmite ao mestre local a lista geral dos computadores do domínio.
Supondo que os mestres locais B_1 e C_1 contactem o mestre de domínio A_2 em ordem, as listas em cada servidor ficarão assim:
A_2: -> A_1, A_2, A_3, A_4, A_5, B_1, B_2, B_3, B_4, B_5, C_1, C_2, C_3, C_4, C_5
B_1: -> B_1, B_2, B_3, B_4, B_5, A_1, A_2, A_3, A_4, A_5
C_1: -> C_1, C_2, C_3, C_4, C_5, A_1, A_2, A_3, A_4, A_5, B_1, B_2, B_3, B_4, B_5
O servidor B_1 contactou A_2 antes de C_1. Naquele instante, A_2 ainda não sabia que a rede C existia. Por isso, a lista do servidor B_1 ficou prejudicada. Já o servidor C_1 contactou o mestre de domínio A_2 quando este último já tinha recebido a lista da rede B. (Está claro que a lista da rede "A" tinha sido compilada pelo próprio mestre do domínio A_2.)
Dentro de 15 minutos, os mestres locais contactarão novamente o mestre de domínio para retransmitir e atualizar as listas. Nesse momento, o mestre de domínio A_2 já conhece a rede inteira, e o mestre local B_1 poderá completar sua lista:
A_2: -> A_1, A_2, A_3, A_4, A_5, B_1, B_2, B_3, B_4, B_5, C_1, C_2, C_3, C_4, C_5
B_1: -> B_1, B_2, B_3, B_4, B_5, A_1, A_2, A_3, A_4, A_5, C_1, C_2, C_3, C_4, C_5
C_1: -> C_1, C_2, C_3, C_4, C_5, A_1, A_2, A_3, A_4, A_5, B_1, B_2, B_3, B_4, B_5
Agora, todos os computadores da rede aparecerão na janela "Ambiente de Rede" de qualquer das estações.
Lembre-se sempre disto: a lista de máquinas NÃO vai aparecer completa imediatamente. Pode levar até 30 minutos até que todos os mestres locais tenham a lista completa da rede. Da mesma forma, se um dos computadores for desligado ou uma rede for desconectada, haverá um lapso de tempo durante o qual a máquina continuará aparecendo nas listas (36 minutos), até que o mestre local da rede desligada finalmente retire-a da lista e informe o fato ao mestre do domínio.
Supondo agora que o computador C_4 quer comunicar-se com o computador A_5. Pela lista, ele sabe que o computador A_5 existe, mas não sabe qual é seu endereço IP. Então, C_4 consulta o servidor WINS, obtém o endereço IP e contacta A_5 diretamente, sem usar broadcast. Note bem aqui como o trabalho de compilação de listas é independente do servidor WINS.
O Samba suporta quatro formas de autenticação de usuários, reguladas pela linha security = ... do arquivo /etc/smb.conf. Assuma, até segunda ordem, que estamos falando de senhas não criptografadas.
SHARE: Sem segurança. Todo e qualquer usuário será aceito. As operações de arquivo e impressão serão executadas com as permissões do usuário UNIX associado ao hóspede (guest account = ...). Se você escolher essa modalidade, verifique se o usuário UNIX terá permissões suficientes para acessar arquivos e, se for o caso, imprimir.
USER: Segurança por usuário, local. A senha do usuário é reduzida a letras minúsculas e confrontada com a senha UNIX. Essa modalidade de segurança obriga que os usuários sejam cadastrados no Linux, e suas senhas sejam atribuídas corretamente. As operações sobre arquivos e de impressão serão feitas com a permissão do respectivo usuário UNIX. Todavia, pode-se abrir aos hóspedes o acesso a determinados volumes ou impressoras - para esses objetos, a segurança operará no estilo SHARE.
SERVER: Segurança por usuário, remota. O Samba pega o nome de usuário e a senha, e autentica junto a outro servidor, que poderá ser outro Linux rodando Samba, ou um Windows NT. Apesar da autenticação ser remota, ainda é necessário criar os usuários UNIX localmente em determinados casos. (Consulte a linha map to guest = Bad User do arquivo de configuração comentado.) DOMAIN: Segurança por usuário, remota. Praticamente idêntica à modalidade SERVER, porém convive com instalações mais complexas onde existem computadores NT operando como PDCs (primary domain controllers) e BDCs (backup domain controllers). Nesse modo, mais de um servidor de autenticação pode ser especificado na linha password server do arquivo de configuração. É necessário criar uma conta no servidor de domínio para que o Samba identifique a si mesmo junto ao NT. (O suporte do Samba a domínios do NT ainda é incompleto e deve estar pronto na versão 2.1; por ora, a modalidade DOMAIN não difere muito da modalidade SERVER.)
O Windows 98, bem como versões mais recentes do Windows NT Workstation, transmitem senhas criptografadas no processo de autenticação. Isso torna a configuração do Samba bem mais complicada, especialmente na modalidade USER, pois ele tem de armazenar as senhas num arquivo separado (/etc/smbpasswd), mantida por um utilitário não padrão do Unix (smbpasswd). O esquema de encriptação do NetBIOS é completamente diferente do Unix, portanto não há possibilidade de usar as senhas armazenadas em /etc/passwd.
A verdade é que as senhas criptografadas não adicionam quase nenhuma segurança ao NetBIOS, por razões diversas. (Portanto, NÃO pense que trafegar NetBIOS na Internet pública é seguro, mesmo usando senhas criptografadas !!!) Sendo assim, por amor à comodidade, o melhor a fazer é configurar o Windows 98/NT para usar senhas não criptografadas.
Para fazer isso, você deve adicionar um item no Registro do Windows. Consulte o diretório /usr/samba*/docs. Lá você encontrará uns arquivos *.reg que, em conjunção ao REGEDIT do Windows, criam esses itens automaticamente nos diversos "sabores" de Windows.
Você pode consultar aqui um arquivo-exemplo de configuração, totalmente comentado e coerente com as explicações dos demais tópicos.
[em construção]
Segue algumas opções avançadas do arquivo smb.conf. Sua descrição completa tornaria esse documento muito longo (bem, agora é tarde, ele JÁ ESTÁ longo demais!), mas elas mereciam pelo menos ser citadas.
Você pode consultar o manual on-line do arquivo smb.conf (com man smb.conf) para obter a explanação completa acerca destas e de todas as outras opções de configuração do Samba.
add user script - permite adicionar usuários automaticamente ao Linux, via script. Isso contradiz a informação de que "usuários NetBIOS tem de ser cadastrados manualmente no Linux para que tenham acesso aos recursos...". Pode ser MUITO interessante em instalações com grande número de usuários.
admin users - usuários administrativos, que terão acesso equivalente a root aos arquivos dos volumes. Pode ser útil para criar usuários de backup, sem ter de se preocupar com permissões de leitura etc. Esse parâmetro pode ser específico por volume i.e. especificado na descrição do volume e com validade restrita a ele.
auto services - Lista de serviços que serão automaticamentes adicionados às listas de navegação. Úteis para diretórios-base de usuários e impressoras, que de outra forma não seriam visíveis.
bind interfaces only - Fará com que o Samba atenda somente as requisições que tenham vindo através das interfaces especificadas no parâmetro 'interfaces'. Dependendo de sua necessidade, pode ser uma forma de segurança mais limpa que o 'hosts allow'.
guest only - Permite que apenas o hóspede tenha acesso ao volume ou impressora que contiver o parâmetro 'guest only = yes'
Até aqui, foi dado a entender que a única forma de configurar o Samba é editar manualmente o arquivo /etc/smb.conf. Isso pode ser suficiente (ou mesmo preferível) para muitos administradores de sistemas. Porém muitos prefeririam um meio mais "soft" de configurar o Samba, tal como uma interface GUI, ou mesmo uma interface de texto orientada a menus.
Há várias formas alternativas de configurar o Samba sem "sujar as mãos" no /etc/smb.conf:
- existe um módulo LinuxConf para esse fim. Por sua vez, o LinuxComf oferece concomitantemente as interfaces texto, gráfica e Web, portanto já são três opções de configuração amigável;
- ksamba, um programa GUI voltado ao ambiente gráfico KDE;
- programas interpretados em Tcl/Tk;
- programas que atuam como CGIs (interface Web).
O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação) notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter histórico, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.