Compartilhando impressoras com clientes Linux e Windows

O Cups, o servidor de impressão padrão no Linux, possui um recurso nativo de compartilhamento de impressoras. Ele permite não apenas compartilhar impressoras com outras máquinas Linux, mas também com máquinas Windows da rede, através de um servidor unificado. Para habilitar o compartilhamento, edite o arquivo "/etc/cups/cupsd.conf", deixando-o com o seguinte conteúdo:

AccessLog /var/log/cups/access_log
ErrorLog /var/log/cups/error_log
LogLevel info
PageLog /var/log/cups/page_log
Printcap /etc/printcap.cups
User lp
Group sys
Port 631
Browsing On
BrowseAllow All
BrowseInterval 30


Order Deny,Allow
Deny From None
Allow From All



Order Deny,Allow
Deny From All
Allow From 127.0.0.1



Order Deny,Allow
Deny From None
Allow From All


Veja que a seção "/printers", que contém as impressoras, fica com permissão de acesso para todo mundo, enquanto o utilitário de administração do Cups (seção /admin) continua acessível apenas localmente, através do endereçohttp://127.0.0.1:631.

Aqui não estamos impondo nenhum tipo de restrição, por isso contamos com o firewall para bloquear qualquer tentativa de impressão proveniente de micros da Internet. Você pode também fazer o compartilhamento de uma forma mais segura, especificando manualmente a faixa de endereços da rede local, ou mesmo especificando individualmente os endereços IP que poderão imprimir. Neste caso, as seções (onde vai a configuração que permite aos clientes verem as impressoras disponíveis) e ficaria:


Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From 192.168.0.*



Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From 192.168.0.*


Não se esqueça de incluir o endereço "127.0.0.1" na lista. Caso contrário, todo mundo vai imprimir na impressora, menos você mesmo :).

Compartilhar impressoras através do Cups é mais simples do que fazê-lo através do Samba e oferece a vantagem adicional de permitir o uso do recurso de autodiscover do Cups nos clientes Linux. O autodiscover permite que osclientes Linux da rede reconheçam automaticamente a impressora compartilhada e a configurem automaticamente durante o boot, sem necessidade de nenhuma intervenção manual. É um recurso bastante interessante: você dá boot com o CD do Kurumin, por exemplo, manda imprimir qualquer coisa e o trabalho é direcionado de forma automática para a impressora compartilhada no servidor.

Funciona mais ou menos assim: durante o boot, o cliente manda um broadcast para a rede, perguntando se alguém está compartilhando impressoras. O servidor responde que está compartilhando a "hp" e aproveita para transmitir detalhes, como o modelo e driver usado pela impressora, configuração de impressão, etc. Como ambos estão rodando o Cups, significa que o cliente usa o mesmo conjunto de drivers de impressão do servidor; isso permite que ele simplesmente configure a impressora usando as informações recebidas, sem precisar perguntar nada ao usuário. O pacote de broadcast é reenviado periodicamente pelo cliente, permitindo que impressoras recentemente compartilhadas sejam descobertas.

Caso existam mais impressoras na rede, você pode escolher qual usar nas preferências de impressão. É um recurso que funciona surpreendentemente bem.



Caso você precise adicionar a impressora manualmente, abra o kaddprinterwizard e selecione a opção Remote CUPS Server. Forneça o endereço IP do servidor na rede local (ex: 192.168.0.10) e a porta onde o Cups está escutando, que por padrão é a 631.

Isso mostrará uma lista das impressoras disponíveis no servidor. Basta escolher a que será usada, apontar o driver que será usado e configurar as opções da impressora (papel, qualidade de impressão, etc.).



Nos clientes Windows, a configuração é semelhante. Eles não suportam o autodiscover, por isso é preciso adicionar a impressora manualmente pelo Painel de Controle > Impressoras e fornecer o CD com os drivers.

Vamos por passos. Comece abrindo o navegador e tentando acessar a página de administração do Cups no servidor. Acesse o http://192.168.0.10:631 substituindo o "192.168.0.10" pelo endereço IP correto do servidor. Acesse a opção "Manage Printers" e clique no link da impressora que será usada. Você verá um endereço, como "http://192.168.0.10:631/printers/hp", na barra do navegador. Este é o endereço "completo" da sua impressora, que vamos usar na instalação.

De volta ao "Painel de Controle > Impressora", clique no "Adicionar Impressora" e marque a opção "Impressora de rede". Selecione a opção "Conectar-se a uma impressora na internet ou na intranet" e preencha o campo "URL" com o endereço completo da impressora (o "http://192.168.0.10:631/printers/hp" que anotamos no passo acima).

Se você estiver usando o Windows 2000 sem o Service Pack 2 ou o XP sem atualizações, ele vai dar um erro estúpido, dizendo que não é possível se conectar à impressora, mas isso é esperado. Dê ok e volte à tela inicial. Marque agora a opção "Impressora local" e deixe marcado o "Detectar e instalar automaticamente impressora Plug and Play". Ele dará outro erro, simplesmente confirme e diga que quer indicar a impressora manualmente. Você verá que, apesar dos erros, a impressora aparecerá disponível no final da lista. Basta selecioná-la e continuar com o processo normal de instalação da impressora, fornecendo o CD de drivers, etc.

Se você tem um servidor de impressão problemático na sua rede, que precisa ser reiniciado várias vezes ao dia, etc., recomendo que experimente substituí-lo por um servidor de impressão Linux. O Cups é um servidor de impressão muito sólido, ele raramente dá problemas. Uso na minha rede interna e até hoje não precisei reiniciar os micros por problemas na impressão uma única vez.

Se você estiver rodando o Windows em uma janela do VMware, o procedimento de instalação da impressora é o mesmo. Basta compartilhar a impressora no Linux e instalá-la no Windows do VMware seguindo os passos que mostrei acima, como se fosse uma impressora de rede.

Lembre-se de que qualquer tipo de compartilhamento de rede é sempre um risco potencial de segurança. Se você for ativá-lo em um micro simultaneamente conectado à internet e à rede local, não se esqueça de habilitar o firewall, abrindo apenas para os endereços da rede local.

O suporte a impressoras de rede compartilhadas no Cups foi incluído apenas a partir do Windows 2000. Para usar este recurso no Windows 95. 98 ou ME, você deve instalar o "Internet Printer Services", uma atualização disponibilizada pela Microsoft, que você pode baixar em:
http://www.microsoft.com/windows98/downloads/contents/WUPreviews/IPP/Default.asp

Depois de reiniciar, acesse o Painel de Controle > Impressora, clique no "Adicionar Impressora" e marque a opção "Impressora de rede". Coloque o endereço da impressora (http://192.168.0.10:631/printers/hp, por exemplo) no lugar do caminho para a impressora e forneça o driver.

Logando clientes Linux num domínio

Além de autenticar as máquinas Windows, o servidor Samba PDC pode ser usado para logar também os clientes Linux, centralizando a autenticação de toda a rede. Fazer uma máquina Linux se logar no PDC é mais complicado do que uma máquina Windows, pois temos que fazer várias alterações que alteram a forma como sistema autentica os usuários. Ao invés de verificar os arquivos "/etc/passwd" e "/etc/shadow", onde ficam armazenadas as contas locais, o cliente passa a utilizar o Samba e o Winbind (que permite que uma máquina Linux ingresse no domínio) para buscar os logins no servidor.

Esta configuração é indicada para distribuições derivadas do Debian que utilizam o KDM, com destaque para o Kurumin, ideal para situações em que você usa o Kurumin nos desktops da empresa e quer usar a lista de logins de um servidor Samba, ao invés de logins locais. Ela funciona em outras distribuições, mas eventualmente podem ser necessárias pequenas mudanças, de acordo com as peculiaridades de cada uma.

O primeiro passo é instalar os pacotes "samba" (ou samba-server), "winbind" (ou samba-winbind) e "libpam-modules" em cada cliente. Nas distribuições derivadas do Debian, instale diretamente os três pacotes:

# apt-get install samba winbind libpam-modules

No Fedora, o winbind está incluído no pacote principal do Samba e os módulos do PAM são instalados através do pacote "pam_smb":

# yum install samba pam_smb

A configuração no servidor não muda em relação ao que já vimos. Toda a configuração que vemos aqui é feita nos clientes. Abra agora o arquivo "/etc/samba/smb.conf" (no cliente Linux) e faça com que a seção Global fique como o exemplo. Você pode tanto adicionar compartilhamentos, quanto ficar apenas com esta configuração básica:

[global]
workgroup = Dominio
netbios name = cliente1
winbind use default domain = yes
obey pam restrictions = yes
security = domain
encrypt passwords = true
wins server = 192.168.1.1
winbind uid = 10000-20000
winbind gid = 10000-20000
template shell = /bin/bash
template homedir = /home/%U
winbind separator = +
printing = cups
invalid users = root

Não se esqueça de substituir o "Dominio" pelo nome do domínio usado na rede, o "cliente1" pelo nome do cliente e o 192.168.1.1" pelo endereço IP do servidor Samba PDC.

Abra agora o arquivo "/etc/nsswitch.conf" e substitua as linhas:

passwd: compat
group: compat
shadow: compat

... no início do arquivo, por:

passwd: compat winbind
group: compat winbind
shadow: compat winbind

Um exemplo do arquivo completo é:

passwd: compat winbind
group: compat winbind
shadow: compat winbind

hosts: files dns mdns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis

Depois de modificar os dois arquivos, reinicie o Samba e o Winbind e teste a configuração, ingressando no domínio. Para isso, use o comando "net rpc join":

# net rpc join member -U root

Password:
Joined domain DOMINIO.

A senha solicitada é a senha de root do servidor PDC, cadastrada no Samba, assim como fazemos ao cadastrar as máquinas Windows. Em caso de problemas, você pode usar também o comando abaixo, que especifica o nome do servidor (-S) e o nome do domínio (-w):

# net rpc join -S gdh -w dominio -U root

Se você receber uma mensagem de erro, como:

Creation of workstation account failed
Unable to join domain DOMINIO.

... provavelmente você esqueceu de cadastrar a máquina cliente no servidor. O nome da máquina (que você verifica através do comando "hostname") deve ser o mesmo que o incluído no arquivo smb.conf. Para criar a conta de máquina para o cliente, use (no servidor) os comandos que vimos anteriormente:

# useradd -d /dev/null -s /bin/false cliente1$
# passwd -l cliente1$
# smbpasswd -a -m cliente1

Neste ponto o cliente já está logado no domínio. Esta configuração é permanente, de forma que você não precisa se preocupar em refazer a configuração a cada boot.

Falta agora a parte mais problemática, que é configurar o PAM, o sistema de autenticação do sistema, para buscar os logins no servidor. Isso é feito modificando os arquivos "/etc/pam.d/login" e "/etc/pam.d/kdm".

Comece adicionando as linhas abaixo no início do arquivo "/etc/pam.d/login" (responsável pela autenticação dos usuários no sistema), sem apagar as demais:

session required pam_mkhomedir.so skel=/etc/skel umask=0022
session optional pam_mount.so
auth sufficient pam_winbind.so
account sufficient pam_winbind.so
session required pam_winbind.so

Abra agora o arquivo "/etc/pam.d/kdm", deixando o arquivo com o seguinte conteúdo (apague ou comente as demais linhas). A mesma configuração pode ser usada no arquivo "/etc/pam.d/gdm", usado por distribuições que trazem o Gnome por padrão:

auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_nologin.so
auth sufficient /lib/security/pam_winbind.so
auth required /lib/security/pam_pwdb.so use_first_pass shadow nullok
account required /lib/security/pam_winbind.so
session required /lib/security/pam_mkhomedir.so skel=/etc/skel umask=0022

Esta configuração faz com que o KDM exiba a lista de usuários cadastrados no servidor e permita que você faça login diretamente no domínio, sem passar pela autenticação local. É importante também desativar o autologin do KDE (ainda no cliente), no Centro de Controle do KDE > Administração do Sistema > Gerenciador de login.



Se você apenas adicionar as linhas acima no "/etc/pam.d/kdm", mas não apagar as linhas que já existem no arquivo (que permitem a autenticação local), a tela do KDM vai exibir a lista de logins do servidor, mas vai recusar o login, dizendo que a senha está incorreta. Este é um dos erros de configuração mais comuns :).

Se você deixar disponível a opção "Bloquear sessão" do KDE, vai precisar editar também o arquivo "/etc/pam.d/kscreensaver", para que ele também use as contas do servidor. Caso contrário, o usuário vai acabar tendo que reiniciar o X, cada vez que clicar por engano no ícone.



Adicione as duas linhas abaixo no início do arquivo (/etc/pam.d/kscreensaver), sem apagar as demais:

auth sufficient pam_winbind.so
auth required pam_unix.so shadow nullok

Para que esta configuração funcione, é importante que os usuários sejam cadastrados no servidor como usuários reais, usando o comando "adduser", e não o "adduser --disabled-login --no-create-home" ou similar. Basicamente, é preciso que o usuário possa se logar no servidor, caso contrário também não vai conseguir se logar nas estações.

No cliente, acesse a pasta "/etc/rc5.d" e verifique se os links responsáveis por inicializar os serviços samba, winbinde kdm foram criados corretamente. Eles precisam ser carregados nessa ordem. No caso de distribuições que inicializam o KDM primeiro (como no caso do Kurumin), renomeie o link, de forma que ele seja inicializado por último, como em:

# mv /etc/rc5.d/S02kdm /etc/rc5.d/S99kdm

Reinicie o cliente, para que os módulos do PAM sejam atualizados e os serviços inicializados na ordem correta. Você notará que a tela de login do KDM passará a exibir os usuários cadastrados no servidor, ao invés dos usuários locais, sintoma de que está tudo funcionando.



Configurando desta forma, os usuários locais que forem eventualmente criados no terminal chegam a aparecer na lista, mas não é possível fazer login neles através do KDM (essa é justamente a idéia). Apesar disso, você pode se logar nos terminais remotamente (usando o root e outros logins locais) via SSH, quando precisar alterar as configurações.

No arquivo "/etc/pam.d/login", incluímos a linha "session required pam_mkhomedir.so skel=/etc/skel umask=0022". Ela faz com que a pasta "/etc/skel" (da estação) seja usada como um template para a criação dos diretórios home dos usuários que só existem no servidor. A pasta "/home" (na estação) armazena apenas os arquivos que forem alterados em relação à pasta "/etc/skel", simplificando os backups. Você pode configurar o servidor Samba instalado em cada estação para compartilhar o diretório home, com permissões de acesso apenas para o administrador da rede, de forma que você possa acessar o home de cada estação a partir do servidor e fazer backup periodicamente.

O "/etc/skel" é justamente uma pasta modelo, cujo conteúdo é copiado para o diretório home, sempre que um novo usuário é criado. As configurações padrão mudam muito de distribuição para distribuição. Esta configuração privilegia o uso das configurações padrão de cada distribuição, permitindo que você use diversas distribuições diferentes nos clientes, independentemente de qual esteja usando no servidor. O Fedora continua com cara de Fedora, o Slackware de Slackware, e assim por diante.

Logando clientes Windows no PDC Linux

Neste ponto, a configuração do servidor Samba está pronta. Falta apenas configurar os clientes Windows para efetuarem logon no domínio. Nem todas as versões do Windows suportam este recurso. Como controladores de domínio são usados principalmente em redes de médio ou grande porte em empresas, a Microsoft não inclui suporte no Windows XP Home e no XP Starter (também chamado jocosamente de "Miserable Edition"), de forma a pressionar as empresas a comprarem o XP Professional, que é mais caro.

A configuração muda de acordo com a versão do Windows:

- No Windows 2000, acesse o "Meu Computador > Propriedades > Identificação de rede > Propriedades". Coloque aqui o nome do computador (que precisa ser um dos logins de máquinas adicionados na configuração do Samba) e o nome do Domínio, que é definido na opção "workgroup =" do smb.conf. Para ter acesso a esta opção você deve estar logado como administrador.



Na tela de identificação que será aberta a seguir, logue-se como "root", com a senha definida no Samba. É normal que a conexão inicial demore dois ou três minutos. Se tudo der certo, você é saudado com a mensagem "Bem-vindo ao domínio DOMINIO".



É necessário identificar-se como root ao fazer a configuração inicial, para que seja criada a relação de confiança entre o servidor e o cliente. A partir daí aparece a opção opção "Efetuar logon em: DOMINIO" na tela de login, permitindo que o usuário faça logon usando qualquer uma das contas cadastradas no servidor. Continua disponível também a opção de fazer um login local.

- No Windows 98 ou ME: Comece logando-se na rede (na tela de login aberta na inicialização) com o mesmo usuário e senha que será usado para fazer logon no domínio. Acesse agora o "Painel de Controle > Redes > Cliente para redes Microsoft > Propriedades". Marque a opção "Efetuar Logon num domínio NT", informe o nome do domínio e marque a opção "Efetuar logon e restaurar conexões". Ao terminar, é preciso fornecer o CD de instalação e reiniciar a máquina.

Note que as máquinas com o Windows 98/ME não são compatíveis com todos os recursos do domínio, elas acessam o domínio dentro de uma espécie de modo de compatibilidade, onde podem acessar os compartilhamentos, mas não têm acesso ao recurso de perfis móveis, por exemplo.

- No Windows XP Professional o procedimento varia de acordo com a versão do Samba usada. Se você está usando uma versão recente do Samba, da versão 3.0 em diante, a configuração é muito simples, basta seguir os mesmos passos da configuração no Windows 2000.

Se, por outro lado, você ainda está usando o Samba 2.x, a configuração é um pouco mais complicada. Comece copiando o arquivo "/usr/share/doc/samba-doc/registry/WinXP_SignOrSeal.reg" (do servidor), que fica disponível como parte da instalação do pacote "samba-doc". Esta é uma chave de registro que precisa ser instalada no cliente.

Acesse agora as propriedades do "Meu Computador" e na aba "Nome do Computador" clique no botão "ID de rede". Será aberto um Wizard que coleta o nome do domínio, nome da máquina e login de usuário. Lembre-se que é necessário efetuar o primeiro logon como root.

Se não der certo da primeira vez, acesse o "Painel de controle > Ferramentas administrativas > Diretiva de segurança local > Diretivas locais > Opções de segurança" e desative as seguintes opções:

* Membro do domínio: criptografar ou assinar digitalmente os dados de canal seguro (sempre)
* Membro do domínio: desativar alterações de senha de conta da máquina
* Membro do domínio: requer uma chave de sessão de alta segurança (Windows 2000 ou posterior)


Para confirmar se os clientes estão realmente efetuando logon no servidor, use o comando "smbstatus" (no servidor). Ele retorna uma lista dos usuários e máquina logadas, como em:

Samba version 3.0.14a-Debian

PID Username Group Machine
-----------------------------------------------------
4363 joao joao athenas (192.168.0.34)


Service pid machine Connected at
-----------------------------------------------------
joao 4363 athenas Sat Jul 9 10:37:09 2005

Usando o Samba como controlador de domínio (PDC)

Em uma pequena rede, manter as senhas dos usuários sincronizadas entre as estações Windows e o servidor Samba não chega a ser um grande problema. No entanto, em redes de maior porte, isso pode se tornar uma grande dor de cabeça e passar a consumir uma boa parte do seu tempo.

Para solucionar o problema, existe a opção de usar o servidor Samba como um controlador primário de domínio (PDC), onde ele passa a funcionar como um servidor de autenticação para os clientes Windows e (opcionalmente) armazena os perfis de cada usuário, permitindo que eles tenham acesso a seus arquivos e configurações a partir de qualquer máquina onde façam logon.

Nota: A Microsoft usa o termo "logon" (logar em) em toda documentação relacionada a redes Microsoft. Por isto adoto este termo dentro da configuração do PDC, substituindo o tempo "login" (logar no) que uso no restante do livro.

Ao cadastrar um novo usuário no servidor Samba, ele automaticamente pode fazer logon em qualquer uma das estações configuradas. Ao remover ou bloquear uma conta de acesso, o usuário é automaticamente bloqueado em todas as estações. Isso elimina o problema de sincronismo entre as senhas no servidor e nas estações e centraliza a administração de usuários e permissões de acesso no servidor, simplificando bastante seu trabalho de administração.

O primeiro passo é modificar o arquivo de configuração do Samba. Existem algumas regras adicionais para transformar o Samba em um controlador de domínio. A seção "global" deve conter as linhas "domain master = yes", "domain logons = yes" e "logon script = netlogon.bat" e (importante) não deve conter a linha "invalid users = root", pois precisaremos usar a conta de root no Samba ao configurar os clientes. É preciso ainda adicionar um compartilhamento chamado "netlogon", que conterá o script de logon que será executado pelas estações.

Este é um exemplo de arquivo de configuração do Samba para um controlador de domínio. Ele não contém as configurações para compartilhamento de impressoras, que você pode adicionar (juntamente com os compartilhamentos desejados) depois de testar a configuração básica:

[global]
workgroup = Dominio
netbios name = GDH
server string = Samba PDC

domain master = yes
preferred master = yes
local master = yes
domain logons = yes
logon script = netlogon.bat

security = user
encrypt passwords = yes
os level = 100

[netlogon]
comment = Servico de Logon
path = /var/samba/netlogon
guest ok = Yes
browseable = No

[homes]
comment = Diretorio Home
valid users = %S
guest ok = Yes
browseable = No

Acostume-se a sempre rodar o comando "testparm" depois de fazer alterações no arquivo, pois ele verifica a sintaxe e indica erros de configuração. Ao configurar o Samba como PDC, ele deve exibir a mensagem: "Server role: ROLE_DOMAIN_PDC".

Depois de configurar o arquivo, verifique se a conta root do sistema foi cadastrada no Samba e se as senhas estão iguais. Caso necessário, use o comando "smbpasswd -a root" para cadastrar o root. Aproveite para criar a pasta "/var/samba/netlogon" e configurar corretamente as permissões:

# mkdir -p /var/samba/netlogon
# chmod 775 /var/samba/netlogon

Com o "775" estamos permitindo que, além do root, outros usuários que você adicionar no grupo possam alterar o conteúdo da pasta. Isso pode ser útil caso existam outros administradores de rede além de você.

Cadastre agora os logins dos usuários, com as senhas que eles utilizarão para fazer logon a partir das máquinas Windows. Neste caso, não é preciso se preocupar em manter as senhas em sincronismo entre o servidor e as estações. Na verdade, as contas que criamos aqui não precisam sequer existir nas estações, pois o login será feito no servidor. Para adicionar um usuário de teste "joao", use os comandos:

# adduser joao
# smbpasswd -a joao

É importante criar também a pasta "profile.pds" dentro do diretório home do usuário, onde o cliente Windows armazena as informações da sessão cada vez que o usuário faz logon no domínio:

# mkdir /home/joao/profile.pds

Ao rodar este comando como root, não se esqueça de ajustar as permissões da pasta, de forma que o usuário seja o dono:

# chown -R joao.joao /home/joao/profile.pds

Além das contas para cada usuário, é preciso cadastrar também uma conta (bloqueada, e por isso sem senha), para cada máquina. Você deve usar aqui os mesmos nomes usados na configuração de rede em cada cliente. Se a máquina se chama "athenas" por exemplo, é preciso criar um login de máquina com o mesmo nome:

# useradd -d /dev/null -s /bin/false athenas$
# passwd -l athenas$
# smbpasswd -a -m athenas

Note que nos dois primeiros comandos é adicionado um "$" depois do nome, que indica que estamos criando uma conta de máquina, que não tem diretório home (-d /dev/null), não possui um shell válido (-s /bin/false) e está travada (passwd -l). Esta conta é válida apenas no Samba, onde é cadastrada com a opção "-m" (machine). Estas contas de máquina são chamadas de "trusted accounts" ou "trustee".

Lembre-se que para usar este comando o arquivo "/etc/shells" deve conter a linha "/bin/false". Se preferir, você pode adicionar as contas de máquina dentro de um grupo do sistema ("maquinas" ou "machines" por exemplo). Neste caso, crie o grupo usando o comando "groupadd" e use o comando abaixo para criar as contas de máquina já incluindo-as no grupo:

# useradd -g maquinas -d /dev/null -s /bin/false athenas$

Por último, é necessário criar o arquivo "/var/samba/netlogon/netlogon.bat", um script que é lido e executado pelos clientes ao fazer logon. Você pode fazer muitas coisas através dele, mas um exemplo de arquivo funcional é:

net use h: /HOME
net use x: \\gdh\arquivos /yes

Este script faz com que a pasta home de cada usuário (compartilhada pelo Samba através da seção "homes") seja automaticamente mapeada como a unidade "H:" no cliente, o que pode ser bastante útil para backups, por exemplo. Naturalmente, cada usuário tem acesso apenas a seu próprio home.

A segunda linha é um exemplo de como fazer com que determinados compartilhamentos do servidor sejam mapeados no cliente. O "net use x: \\gdh\arquivos /yes" faz com que o compartilhamento "arquivos" (que precisaria ser configurado no smb.conf) seja mapeado como o drive "X:" nos clientes. Lembre-se que o "gdh" dentro do netlogon.bat deve ser substituído pelo nome do seu servidor Samba, configurado na opção "netbios name =" do smb.conf.

Mais um detalhe importante é que o arquivo do script de logon deve usar quebras de linhas no padrão MS-DOS e não no padrão Unix (que é o padrão da maioria dos editores de texto do Linux). Você pode criá-lo usando um editor de texto do Windows ou usar algum editor do Linux que ofereça esta opção. No Kwrite por exemplo, a opção está em: "Configurar > Configurar Editor > Abrir/Salvar > Fim de linha > DOS/Windows".


Mais uma configuração útil (porém opcional) é fazer com que o servidor armazene os arquivos e configurações do usuário (recurso chamado Roaming Profiles, ou perfis móveis), fornecendo-os à estação no momento em que o usuário faz logon. Isso permite que o usuário possa trabalhar em outras máquinas da rede e faz com que seus arquivos de trabalho sejam armazenados no servidor, diminuindo a possibilidade de perda de dados.

Por outro lado, ativar os perfis móveis faz com que seja consumido mais espaço de armazenamento do servidor e aumenta o tráfego da rede, já que os arquivos precisam ser transferidos para a estação a cada logon. Isso pode tornar-se um problema caso os usuários da rede tenham o hábito de salvar muitos arquivos grandes na área de trabalho.

Note que o servidor não armazena todos os arquivos do usuário, apenas as configurações dos aplicativos, entradas do menu iniciar, cookies, bookmarks e arquivos temporários do IE e o conteúdo das pastas Desktop, Modelos e Meus Documentos.

Para ativar o suporte no Samba, adicione as duas linhas abaixo no final da seção "global" do smb.conf (abaixo da linha "logon script = netlogon.bat"):

logon home = \\%L\%U\.profiles
logon path = \\%L\profiles\%U

A variável "%L" neste caso indica o nome do servidor e o "%U" o nome do usuário que está fazendo logon. Quando, por exemplo, o "joao" faz logon é montado o compartilhamento "\\gdh\profiles\joao". Adicione também um novo compartilhamento, adicionando as linhas abaixo no final do arquivo:

[profiles]
path = /var/profiles
writeable = Yes
browseable = No
create mask = 0600
directory mask = 0700

Crie a pasta "/var/profiles", com permissão de escrita para todos os usuários:

# mkdir /var/profiles
# chmod 1777 /var/profiles

Cada usuário passa a ter uma pasta pessoal dentro da pasta ("/var/profiles/joao", por exemplo) onde as configurações são salvas. Apesar das permissões locais da pasta permitirem que qualquer usuário a acesse, o Samba se encarrega de permitir que cada usuário remoto tenha acesso apenas ao seu próprio profile.

As estações Windows 2000 e Windows XP utilizam os perfis móveis automaticamente, quando o recurso está disponível no servidor Samba. Você pode verificar a configuração e, caso desejado, desativar o uso do perfil móvel no cliente no "Meu Computador > Propriedades > Perfis de Usuário > Alterar tipo".

Configurando o Samba manualmente.

Configurando manualmente o /etc/samba/smb.conf

Toda a configuração do Samba, incluindo as configurações gerais do servidor, impressoras e todos os compartilhamentos, é feita em um único arquivo de configuração, o "/etc/samba/smb.conf". Programas de configuração, como o Swat, simplesmente lêem este arquivo, "absorvem" as configurações atuais e depois geram o arquivo novamente com as alterações feitas. Isso permite que o Swat coexista com a edição manual do arquivo. Como o formato é bastante simples e conciso, muitas vezes é mais rápido e até mais simples editar diretamente o arquivo do que através do Swat. O único porém é que o Swat remove todos os seus comentários e formatação, deixando apenas as opções.

O smb.conf possui as mesmas seções mostradas no swat: global, homes, printers, etc. Ao instalar o Samba através do ícone mágico, é instalado um smb.conf já pré-configurado com uma configuração de exemplo. A idéia é que o servidor já fique acessível imediatamente depois da instalação e você possa se concentrar em adicionar os usuários e compartilhamentos.

Para abri-lo, com privilégios de root, você pode digitar simplesmente "kdesu kedit /etc/samba/smb.conf" no terminal. Veja um exemplo do conteúdo do arquivo. Lembre-se de que as linhas iniciadas com # são comentários, não interferem na configuração:

# Arquivo de Configuração do Samba escrito para o Kurumin # Por Carlos E. Morimoto

# Seção Globals: # Aqui vão parâmetros gerais, como o nome da máquina e grupo de trabalho.

[global] workgroup = GRUPO netbios name = KURUMIN server string = %h server (Samba %v) name resolve order = lmhosts, host, wins, bcast printcap name = lpstat encrypt passwords = Yes wins support = yes preferred master = yes panic action = /usr/share/samba/panic-action %d invalid users = root preserve case = no short preserve case = no default case = lower os level = 100

[homes]

comment = Home Directories create mask = 0700 directory mask = 0700 browseable = No

[printers]

comment = Todas as Impressoras path = /var/spool/samba guest ok = yes public = yes printable = yes browseable = yes use client driver = yes

# Compartilhamentos: # Aqui vai a configuração das pastas compartilhadas. Você pode criar mais # compartilhamentos usando o Swat ou editando diretamente este arquivo. # Veja como funciona a configuração: # # [publico] : O nome do Compartilhamento, como aparecerá no ambiente de redes. # path = /home/samba_publico : A pasta local que está sendo compartilhada. # available = yes : O compartilhamento está disponível? # Mudando para "available = no" ele ficará "congelado" e ninguém poderá acessar. # browseable = yes : O compartilhamento aparecerá na rede? # Mudando para "browseable = no" ele virará um compartilhamento oculto # writable = yes : O compartilhamento fica disponível para leitura e escrita. # writable = no : o compartilhamento fica disponível para somente leitura.

# Agora é a sua vez:

#[compartilhamento] # path = /pasta/pasta # available = yes # browseable = yes # writable = yes

Se você quiser criar um novo compartilhamento, chamado "arquivos", que dá acesso à pasta "/home/arquivos" e pode ser acessado em modo somente-leitura por todos os usuários cadastrados no Samba, bastaria adicionar as linhas:

[arquivos] path = /home/arquivos available = yes writable = no

Se você quiser permitir que o compartilhamento fique com permissão de escrita e leitura, mas fique acessível apenas pelos usuários "maria" e "joao" (os outros usuários não acessam nem para leitura), adicione a linha: "valid users = joao maria". A entrada ficaria:

[arquivos] path = /home/arquivos available = yes writable = yes valid users = maria, joao

Se preferir, você pode continuar permitindo que os outros acessem o compartilhamento para leitura e criar uma lista de escrita, contendo a maria e o joao:

[arquivos] path = /home/arquivos available = yes writable = yes write list = maria, joao

Outra forma de limitar o acesso é usar a opção "hosts allow" para permitir que apenas alguns endereços IP possam acessar os compartilhamentos, como em:

[arquivos] path = /home/arquivos available = yes writable = yes hosts allow = 192.168.0.2, 192.168.0.5

É possível ainda combinar as duas coisas, permitindo que apenas a maria e o joao acessem o compartilhamento e, ainda assim, só se estiverem usando uma das duas máquinas permitidas, como em:

[arquivos] path = /home/arquivos available = yes writable = yes write list = maria, joao hosts allow = 192.168.0.2, 192.168.0.5

O Swat serve apenas como uma interface para a edição deste arquivo. Seja qual for o modo de configuração escolhido, basta fazer backups regulares deste arquivo para restaurar as configurações do servidor em caso de problemas. Além do arquivo smb.conf, salve também o arquivo "/etc/samba/smbpasswd", que contém os usuários e senhas.

Sempre que alterar manualmente smb.conf, ou mesmo alterar algumas opções pelo Swat e quiser verificar se as configurações estão corretas, rode o testparm (basta chamá-lo no terminal). Ele funciona como uma espécie de debug, indicando erros grosseiros no arquivo. Depois de fazer qualquer alteração, reinicie o Samba usando o comando "/etc/init.d/samba restart" ou "service smb restart". O comando smbstatus também é muito útil, pois permite verificar quais estações estão conectadas ao servidor e quais recursos estão sendo acessados no momento.