Tutoriais diversos

Instalar o Webmin no Ubuntu Server 12.04 LTS

2014-02-10T17:59:00.005-08:00

O Webmin é uma aplicação que permite a administração de todo o sistema Unix / Linux, a qual é executada via Browser

1. Instalação

Pressionar Ctrl - Alt - T no teclado para abrir o terminal e introduzir o seguinte comando

sudo apt-get install perl libnet-ssleay-perl libauthen-pam-perl libpam-runtime openssl libio-pty-perl apt-show-versions python

1.1 via APT

Entrar como root

sudo -i

1.2 Adicionar o repositório Webmin ao Ubuntu Server

cat >> /etc/apt/sources.list <<-EOF
deb http://download.webmin.com/download/repository sarge contrib
deb http://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib
EOF

1.3 Sair de root

exit

1.4 Importar as chaves PGP e instalar

wget http://www.webmin.com/jcameron-key.asc && sudo apt-key add jcameron-key.asc

sudo apt-get update
sudo apt-get install webmin

2. Para aceder ao Webmin, executar o Browser e colocar http://host:10000/

Teste para pagamento no mercado pago "Cabo adaptador"

2013-07-25T07:02:00.001-07:00

Pagar

ou

Pagar

Guia sobre Linux: bash, comandos, permissões, rede, e outros.

2013-06-28T09:11:00.003-07:00

DIRETÓRIOS
Para os que estão se iniciando no Linux, conhecer os diretórios pode ser um pouco difícil, as vezes por causa da sua estrutura peculiar (eu diria, mais organizada) ou por estarem migrando do ''outro''.
/ : raiz do sistema, o diretório que ''guarda'' todos os outros diretórios. É um ''c: da vida''. Uma dica é que ele não possua nenhum arquivo além dos diretórios/arquivos (defalt) do sistema.
/bin : arquivos/comandos utilizados durante a inicialização di sistema e por usuários (após a inicialização)
/boot: arquivos utilizados durante a inicicialização do sistema
/dev : drivers de controle de dispositivos
/etc : arquivos de configurações do computador
/etc/sysconfig : arquivos de configuração do sistema para os dispositivos.
/etc/passwd : dados dos usuários, senhas criptografadas...
/etc/fstab : sistemas de arquivos montados no sistema
/etc/group : grupos
/etc/include : header para programação em C
/etc/inittab : arquivo de configuração do init.
/home : pasta pessoal dos usuários comuns. Um ''Meus Documentos da vida''
/lib : bibliotecas compatilhadas
/lib/modules : modulos externos do kernel usados para inicializar o sistema...
/misc : arquivos variados
/mnt : ponto de montagem de sistemas de arquivos (CD, floppy, partições...)
/proc : sistema de arquivos virtual com dados sobre o sistema.
/root : diretório pessoal do root
/sbin : arquivos/comandos especiais (geralmente não são utilizados por usuários comuns)
/tmp: arquivos temporários
/usr : Unix System Resources. Contém arquivos de todos os programas para o uso dos usuários de sistemas UNIX.
/usr/bin : executáveis para todos os usuários
/usr/sbin : executávies de administração do sistema
/usr/lib : bibliotecas dos executávies encontrados no /usr/bin
/usr/local : arquivos de programas instalados localmente
/usr/man : manuais
/usr/info : informações
/usr/X11R6 : Arquivos do X Window System e seus aplicativos.
/var : Contém arquivos que são modificados enquanto o sistema está rodando não é compartilhado em rede por ser específico de cada sistema, estando em constantes modificações.
/var/lib : bibliotecas
/var/local : arquivos variáveis de processos que estão rodando.
/var/log : arquivos de log do sistema
/var/run : arquivos úteis até o próximo boot (atualizações de softwares e kernel)
/var/tmp : arquivos temporários dos programas
O PATH
Para visualizar o path (caminho de procura de arquivos e comandos executáveis), usa-se o comando % echo $PATH. Todos os comandos executáveis serão executados ''se e somente se'' estiverem armazenados na variável path. O comando que está no PATH é executado apartir de qualquer diretório (não importa se o usuário está no home ou no mnt ou qualquer outro). Para inserir um arquivo no path usa-se ''./'' (Ex: ./arquivo ).
Para inserir o caminho para todos os usuários do sistema edite o earquivo /etc/profile ou /etc/bashrc.
Para alterar caminhos de um único usuário, edita-se o arquivo .bash_profile do diretório /home/ ou $HOME/.bashrc
Para adicionar caminhos novos ao ''caminho existente'' use e precione , vá até o fim da linha e adicione o novo caminho. Confira utilizando o comando % env.
Para adicionar novos comando com o alias faça:
% alias cdon = ''mount /dev/cdrom /mnt/cdrom'' o comando %cdon (recém criado) será adicionado ao path e utilizará o script de montagem do CD-ROM.
ATALHOS DO BASH
Ctrl + Alt + BackSpace : reinicia o X
Ctrl + Alt + Del : reinicia o sistema em modo texto
Ctrl + Alt + F''x'' : muda o shell (F1 – F6 (texto), F7 (gráfico))
Alt + F''x'' : alterna o shell (modo texto)
Alt + B : move o cursor do console para a palavra anterior
Alt + F : move o cursor do console para a palavra seguinte
Ctrl + A : vai para o início da linha
Ctrl + E : vai para o fim da linha
Ctrl + C : pára o comando
Ctrl + D : logout
Ctrl + W : apaga do cursor até o início da palavra
Ctrl + U : apaga do cursor até o início da linha
Ctrl + K : apaga do cursor até o fim da linha
Ctrl + L : clear
Ctrl + R : busca incremental no hitórico de comandos
Ctrl + T : inverte caractere sob o cursor com o anterior
Ctrl + Y : re-inserir o último texto apagado
Ctrl + Z: colocar processo em background
Shift + Page(UP/DOWN) : navega pelo shell
!''x'': repete o último comando (onde ''x'' é o comando a ser chamado – Exemplo: !mount)
TAB : autocompletar
COMANDOS DE INICIALIZAÇÃO
shutdown :Sintaxe: shutdown [atributo] [tempo]
Atributos: -r : reboot
-h : halt
-n : force (sem sincronizar)
-f : reboot rápido
-c : cancela shutdown corrente
-k : somente simula um shutdown
Tempo: now : executar no exato momento
Exemplo: Shutdown -r now
poweroff : halt
init 0 : halt
init 3: derruba o modo gráfico
init 5: iniciar o modo gráfico
init 6 : reboot
init q: examinar o arquivo /etc/inittab
init s: entrar em modo mono usuário (single mode)
exit: termina sessão atual
logout : termina sessão atual
COMANDOS DE SISTEMA
dmsg | less : mostrar lista de inicialização
arch : mostra a arquitetura do computador
uname : informações de sistema
Parâmetros: -m : hardware
-n : nome da máquina na rede
-r : versão do kernel
-s : nome do OS
-v : data de compilação do OS
-a : todas as acima...
uptime : mostra o tempo em que a máquina está no ar
free : mostra o uso da memória
vmstat : Mostra as estatísticas da memória virtual
ps -aux | grep tty : lista terminais em uso
tty : mostra em qual terminal o usuário atual está
stty : exibir ou escolher parâmetos do terminal
tset : escolher tipo de terminal
fgconsole : exibe o nº de terminais válidos
cu : chama outro sistema unix
type : informa o que faz um certo comando. Exemplo: type mount
time : mede o tempo gasto para executar um comando
cal : calendário
date: data e hora
who : mostra quem está na máqina no momento
whoami : mostra quem é você
last : informa a entrada e saída de usuários no sistema
lastlog : informa o último usuário que logou no sistema
at : agendar tarefas. Sintaxe : at [hora][data][comando]
crontab : programa tarefas.
Sintaxe: crontab [-parâmetros][usário][arquivo]
Parâmetros: -l : exibe crontab do usuário atual
-r : remove crontab do usuário atual
edita-se o arquivo /usr/spool/cron/crontab . São 6 campos separados por sendo que:
1º é o minuto
2º é o hora
3º é o dia do mês
4º é o mês
5º é o dia da semana (que começa com 0 = domingo)
6º é a tarefa ou script a ser executado
lspci : lista os dispositivos PCI
setserial : informações sobre as portas seriais
COMANDOS PARA REDES
ifconfig : configura a interface de rede
netconf : Interface gráfica do RedHat para confiurar a rede
netconfig : Outra interface gráfica para a configuração da rede
hostname : nome da máquina
netstat : Mostra informações sobre as conexões à rede
domainname: Mostra ou ajusta o nome de domínio do sistema
route : Mostra e manipula a tabela de roteamento
showmount : Mostra informações de sistemas NFS montados sobre a rede
nmap: capta informações em conexões remotas, como o sistema operacional usado, portas abertas...
Sintaxe: nmap -O 200.0.0.5
tracerout : mostra o caminho percorrido do pc até um ''tal'' servidor da internet
ping : informações de conexão
Parâmetros: -r : avisa se o pacote não chegar ao destino
-c''N'' : onde ''N'' é o nº de pings a serem executados
-s : determina o tamanho dos pacotes enviados, por defalt é 56bytes
rusers : mostra quem está usando as máquinas na rede
ruptime : informações sobre máquinas da rede local
Parâmetros : -a: usuários inativos a mais de uma hora
-l : ordena saída de informações de cada host
-r : inverte ordem de saída de informações
-t : (uptime)
-u: ordena saída por nº de usuários
rup: semalhante ao uptime, porém para outra máquina na rede. Sintaxe: rup
rwho : mostra o que está ''sendo feito'' nos computadores da rede local (semelhante ao ruptime)
mail : rebe ou envia e-mail
smbclient : Cliente para redes SAMBA.
smbmount : Monta um sistema de arquivos SAMBA (Windows)
COMANDOS DE AJUDA
man: manual de ajuda. Exemplo : man mount
xman : man em modo gráfico
info : como o man, porém com links nos textos
makewhatis : levanta banco de dados para o comando apropos
apropos:levanta respostas de comandos desconhecidos, antes deve-se executar makewhatis. Exemplo :
% apropos compiler (serão localizados arquivos que contenham a descrissão de compiler).
help: ajuda do shell atual
COMANDOS PARA MANIPULAÇÃO DE DIRETÓRIOS
cd : entra no diretório
Atributos: - : volta ao último diretório buscado
~ [nomedapastadousuario] : vai para a pasta do usuário
/ : diretório raiz
.. : diretório ''acima''
ls : lista arquivos e diretórios
Atributos : -C : exibe em colunas
-R : modo recursivo
-a : mostra ocultos
-l : mostra propriedades
mkdir : cria um diretório
rmdir : remove um diretório (atributo : -R para deletar diretórios não vazios)
pwd : mostra o diretório atual
cp : copia diretórios
Atributos: -f : não perguta para sobrescrever
-i : pergunta para sobrescrever
-r : cópia recursiva
mv : movimenta diretórios (mesmos atributos do cp)
du : mostra hierarquia
Atributos: -a : informações de todos os arquivos
-b : mostra em bytes
-k : mostra em kbytes
-s : lista o total de cada argumento
-x : ignora diretórios com sistemas de arquivos diferentes
-S : apresenta o tamanho de cada diretório separadamente
diff : exibe diferenças entre 2 arquivos ou diretórios
diff3 : exibe diferenças entre 3 arquivos ou diretórios
ln : link simbólico para arquivos e/ou pastas. Exemplo: ln linux-2.6 kernel-atual
COMANDOS PARA MANIPULAÇÃO DE ARQUIVOS
bash : executa o bash
basename :exclui o sulfixo do arquivo
fsbrowser : encontra arquivos ou diretórios no pc
head : lista a primeira parte dos arquivos
tail : o contrário do head
cat : exibe conteúdo do arquivo ou direciona-o para outro
Exemplos: cat /home/fulano/contato (exibe o conteúdo do arquivo contato)
cat contato1 > contato2 (faz uma cópia do arquivo contato)
cat contato1 >> contato2 (adiciona um arquivo ao outro)
cat musica.wav > /dev/dsp1 (direciona o som para o dispositivo de audio)
cat arquivo1 arquivo 2 | gzip > arquivo1e2.gz (compacta arquivo1 e arquivo2 num só arquivo)
tac : inverso do cat
file : identifica o tipo de arquivo
find : localiza arquivo ou diretório.
Sintaxe: find [opções] [dados] [opções]
Opções: -name: parâmetro seguido do arquivo a ser procurado
-print : mostrar resultado na tela
-exec ''comando'' : executa um comando
-ok : idem a exec, porém pergunta antes de executar o comando
awk : procura por um modelo apartir de um arquivo
bdiff : compara 2 arquivos grandes
bfs: procura um arquivo grande
diff : exibe diferenças entre 2 arquivos ou diretórios
uniq : compara 2 arquivos, exibe as linhas incomparáveis do arquivo
diff3: exibe diferenças entre 3 arquivos ou diretórios
cmp : compara 2 arquivos, mostra a localização da primeira diferença entre eles
comm: compara 2 arquivos para determina quais linhas são comuns entre eles
split : dividir um arquivo
more e less : filtros depaginação
Exemplos : more /etc/fstab
ps -aux | less
ls : lista arquivos do diretório
Atributos : -C : exibe em colunas
-R : modo recursivo-a : mostra ocultos
-l : mostra propriedades
cp : copia arquivos
Atributos: -f : não perguta para sobrescrever
-i : pergunta para sobrescrever
-r : cópia recursiva
mv : movimenta arquivos (mesmos atributos do cp)
rm : remove um arquivo
wc: (não cacete! não é banheiro não!) esse aí lista as propriedades dos arquivos
Atributos : -l : nº de linhas do arquivo
-c : n de cracteres
-w : nº de palavras
-b : nº de bytes
grep : uma espécie de busca. Exemplo: % grep tty
od : mostra o arquivo em formato octal
ln : link simbólico para arquivos e/ou pastas. Exemplo: ln linux-2.6 kernel-atual
COMANDOS PARA COMPACTAR
Sem descrissões... todos fazem a mesma coisa, só que em formatos diferentes, dependendo da ocasião um pode ser melhor que o outro... depende do ''gosto'' de cada um...
compress/ uncompress : compacta / descompacta em .z
Sintaxe : idem a bzip2
Atributos: -f : compacta em background
-c : desmpacta na tela
-V : informações sobre o arquivo
-v : informações sobre a compactação corrente
-d: junto dom o compress, descompacta o arquivo
tar : Atributos: -t : lista conteúdo do arquivo tar
-x : extrai arquivos
-c : cria um arquivo tar
-d : compara um arquivo tar com arquivos atuais
-r : anexa arquivos no fim do arquivo tar
-u : analiza arquivos
-A : anexa outros tar
-v : mostra informações de processamento
Exemplos: tar cvM -L 1350 -f /mnt/floopy/partes.tgz grande.tgz : quebra um arquivo grande em
partes menores.
tar pvfx arquivo.tar: extrai tar
tar zpvfx : extrai tar.gz ou tgz
tar jpvfx : extrai tar.bz2
gzip : compacta arquivos e nomes de arquivos com mais de 14 letrras
Atributos: -d : descompacta
-f : compacta
-l : informações sobre arquivo compactado
-r : recursivo
gunzip : descompacta
Exemplo: gzip -c arquivo1 > arquivo1e2.gz ; gzip -c arquivo2 > arquivo1e2.gz ou
cat arquivo1 arquivo 2 | gzip > arquivo1e2.gz
(compacta arquivo1 e arquivo2 num só arquivo)
bzip / bunzip: compacta / descompacta
bzcat : descompacta na tela do sistema
bzip2recover : recupera arquivos danificados quando for possível
Atributos : -1 : (1, 2,3...9) sendo que 9 é o maior fator de compactação
-v : informações de processamento
-c : descompacta na tela do sistema
-d : descompacta
-t : verifica integridade do arqivo
-f : sobrescreve
-s : reduz us da memória exigida
cpio: executa funções equivalentes a arquivos de dados em formato cpio ou tar, e contém informações sobre o arquivo. Seus modos de arquivamento são entrada, saída e passagem.
Modo de entrada: extrai arquivos de um arquivo maior, caso não for inserido um padrão, todos são extraídos.
Modo de saída: copia os arquivos em um arquivo maior
Modo de passagem : combina os modos de entrada e saída sem usar modo de arquivamento, copia
uma árvore de diretórios para outra
Parâmetros: -0 : (saída / passagem) lê arquivo terminado em caractere nulo; ao invéz de nova linha
-A : (saída) adiciona um arquivo existente; deve estar especificado -0 ou -F
-d : cria diretório (se for preciso)
-H : indica o formato do arquivo maior
-i : (entrada) extrai
-o : (saída) cria
-t : (entrada) lista tabela
-u :sobrescreve sem perguntar
-v : lista arquivos processados
USUÁRIOS E GRUPOS
useradd : adiciona usuário
userdel : exclui usuário
username : exibe nome do usuário logado no momento
users : exibe os usuários logados no momento
usermod : Modifica um usuário.
id : identificação do usuário e grupos a que pertence
passwd : adiciona senha em usuário já cadastrado. Exemplo: % passwd fulano
chpasswd : muda senha de usuário
groupadd : cria grupo
groupdel : exclui grupo
groups : lista grupos
groupmod : Modifica um grupo
newgrp : altera identificação do grupo
chgroup : altera propriedade do grupo
chown : altera usuário/propriedade do grupo de cada arquivo especificado. Ex: % chown -R root /home
sg : executa comando como se fosse de outro grupo
su : usado para ganhar permissão de root.
wall : Manda uma mensagem para todos no terminal.
PERMISSÕES
Primeiramente precio dar umas breves explicações sobre permissões, dono, grupo e coisarada de esquemas... Vou mostrar permissões no modo ''literal'' e no modo ''octal'', que são mais fáceis e mais usadas, porém pode ser feito com aplicativos, cliques no botão direito e coisarada, se a distro tiver tal recurso. Para todos os modos usa-se o comando:
% chmod [opções] [permissão] [diretório]
Atributos: -v : mostra arquivos processados
-f : não mostra mensagens de erro
-c : mostra somente arquivos com permissão
-R : recursivo
Dono: é o usuário que criou o arquivo
Grupo: é um recurso para que vários usuários tenham como ''usar'' um mesmo arquivo
Outros : não são donos e nem pertencem ao grupo do arquivo
ESQUEMA USADO NO % ls -l
r : permite leitura
w : permite edição/gravação
x : permite executar arquivos executáveis. Se for um dietório, pode ser acessado pelo comando % cd
Se houver 1 ''d'', indica que é um diretório; se houver um ''-'' indica um arquivo
Exemplo: -rw------- (somente o dono pode ler e gravar no arquivo)
MODO LITERAL :
Esse é o modo em que o sistemas nos mostra as permissões num % ls -l, mas esse é o mais ''chatinho'' pois é feito linha por linha.
[a]LL : todos
[g]roup : grupo
[o]thers : outros
[u]ser : dono
[+] : adiciona permissão
[-] : remove permissão
Com o comando % chmod ficaria assim:
% chmod a -rx /mnt (retira a permissão de leitura e execussão para todos no diretório /mnt)
% chmod o +r /mnt (da permissão para ''outros'', no caso os que não pertencem ao grupo do dono)
MODO OCTAL :
É o jeito mais fácil e rápido de ''adminitrar'' permissões, pois usa números de 0 a 7 para dar permissões para dono, grupo e outros numa única linha de comando. É uma verdadeira economia de tempo e paciência... :-)
Depois do % chmod usa-se 3 dígitos (que como já disse, variam de 0 a 7). O 1º indica a permissão do dono do arquivo, o 2º indica o grupo do dono e o 3º indica os outros usuários...
DÍGITO PERMISSÃO (UGOA)
0 Nenhuma ---
1 Executar --x
2 Escrever -w-
3 Escrever/Executar -wx
4 Ler r--
5 Ler/Executar r-x
6 Ler/Escrever rw-
7 Ler/Escrever/Executar rwx
Exemplo: % chmod -R 750 /mnt (Dono: pode Ler, Escrever e Executar; Grupo: pode Ler e Executar, e os outros não podem nada) para o diretório /mnt e todos os seus subdiretórios.
COMANDOS PARA MANIPULAR IMPRESSÃO
lpq : mostra trabalhos de impressão atual
lpr : copia um arquivo para a linha da impressora
lprm : remove trabalhos de impressora
lpstat: informações
Atributos: -a : lista relatórios enviados para a impressora
-p : lista o estado das impressoras
-s : sumário do estado das impressoras
-R : mostra o nº de cada jobna fila de impressão
COMANDOS PARA MANIPULAR PROCESSOS
ps -aux | less: mostra o PID dos processos
top : mostra todos os processos ativos no pc. (em modo grafico usa-se ktop (do kde) gtop (do gnome)...)
kill: mata um processo pelo PID. Sintaxe: kill [PID]
killall : mata processospelo nome. Sintaxe: killall -HUP [nome]
sleep : torna um processo inativo por determinado tempo
nice : prioridade de execussão (-19 é o máximo e 19 é o mínimo). Sinaxe: nice [opções][comando]
& : quando colocado no fim da linha, executa o processo em 2º plano (ou background se preferir)
jobs : exibe processos em 2º plano
bg : ao rodar um processo tecle Ctrl + Z para congelar o processo, depois digite bg para o programa voltara ''rodar'' em 2º plano.
fg: para fazer o processo voltar ao 1º plano. Sintaxe: fg [nº do processo]
nohup : logout sem matar processos no 2º plano. Exemplo: nohup cc program C & ; logout
COMANDOS DE MANIPULAÇÃO DE MÍDIAS
cfdisk : particionador
mke2fs : formata o hd. Exemplo: mke2fs -j /dev/hda1 (formata a primeira partição do hd primário em ext3)
dosfsck : Verifica e repara sistemas FAT do DOS
dumpe2fs : Faz o backup de blocos do HD e grupos.
e2fsck : Verifica um volume ext2 em busca de erros.
E2label : Muda o nome de uma partição ext2.
dump : Usado para fazer o backup de um sistema ext2. O complemento deste comando é o restore
restore : Usado para restaurar um sistema ext2.
badblock: busca por setores ruins
fsck: faz reparos na partição
df : mostra espaço usado, livre e a capacidade das partições do HD
mount : monta dispositivo. Exemplo: mount -vfat /dev/hda1
umount : desmonta dispositivo. Exemplo: unmount /mnt/cdrom
supermount : monta dispositivos automaticamente. Sintaxe: supermount [opções] [/local/do/dispositivo]
mformat : formatação de baixo níveis em disquetes no formato M$-DOS
fdformat : formatação de baixo níveis em disquetes. Exemplo: fdformat /dev/fd0 H1440
GRAVANDO CDs
Aqui eu vou falar de gravação pelo console mesmo... linhas de comando... as vezes até acaba sendo mais fácil... Ah! Essas aí foram inteiramente retiradas de um e-mail que recebi da Dicas-L :-)
Cds de Áudio:
% cdrecord dev=0,0,0 -pad -dao -v -eject -audio track01.wav...trackN.wav
-eject : ejeta no final
-dao : para não ficar com muito espaço entre as faixas
-pad : enche (se necessário) os arquivos com o número correto de espaços (para o aparelho de som ler em múltiplos de 2352 bytes)
Convertendo mp3 para cdr:
mpg123 –cdr – track1.mp3 > track1.cdr
grave usando -audio para indicar cada trilha
nice -19 cdrecord -eject -v speed=8 dev=1,1,0 -audio track1.cdr
track2.cdr...
Decodificar mp3 direto no CD:
for | in*.mp3
do
mpg123 –cdr - ''$|'' | cdrecord -dummy – audio -pad -nofix -
done
cdrecord -fix
Parâmetro: -dummy : Simulação
Criando ..iso:
mkhybrid -r -j -o imagem.iso diretório_dos_arqivos
Testando o .iso antes de gravar
mount -t iso9660 -o loop imagem.iso /mnt/iso
Fazendo uma cópia fiel de cd pra cd:
cdrecord -v speed=8 dev=1,1,0 -isosize /dev/cdrom
Fazendo CD de Boot:
Crie a imagem apartir de um disquete de boot
dd if=/dev/fd0 of=boot.img bs=18k
Apagando CD-RW
Para sobrescrever um CD-RW use o parâmetro blank=fast no cdrecord
CD-ROM de audio e dados:
cdrecord -v speed=8 dev=1,1,0 -data imagem.iso -audio track1.cdr
track2.cdr
EMULADORES*
* os ''comandos'' citados nesse tópico necessitam do aplicativo instalado (as vezes vem com a própria distro... dá uma ''baga no pc pra ve se tem... heheh)
* o Wine não se ''considera'' emulador como seu nome diz (Wine Is Not Emulator), mas... acho que aqui é melhor pra falar desse treco.
* Leia (!) os arquivos de ajuda de cada ferramenta asseguir citadas, isso impede que a ''pecinha'' (que tá olhando pro pc) cometa algum erro e venha com a mensagem : - ''Ai meu Deus, não funciona... Ahhhhhh''
WINE : esse daí emula o rWindows. Pode emular programas que ESTÃO numa partição com Windows ou num pc SÓ com linux (basta configurar... não vou dar muitos detalhes porque é meio que MUITA COISA). Depois de configurado certinho é só dá um % wine calc (pra abrir a calculadora do rWindows... Tá, foi um exemplo ''meio'' inútil, mas foi só exemplo). Dra pra rodar até jogos...
DOSEMU : emulador de programas para M$-DOS... Sintaxe: % dos (ou xdos no modo gráfico)
MTOOLS : emula comandos do M$-DOS (pra que diabos alguém ia querer isso? Sei lá) usa-se ''m'' antes do comando. Exemplo: mtools , mdir, mdel ...
USANDO O RPM
RPM é um pacote (normalmente pré-compilado para cada distro) de fácil instalação. Com uma só linha de comando ou cliques no rato são suficientes para instalar e não se incomodar com compilações e coisarada...
Sintaxe : rpm [parâmetros][opções][pacote.rpm]
Parâmetros : -i : instala
-e : desinstala
-q : consulta
-v : verbose
-h: exibe ''#'' como porcentagem a medida que o pacote se instala
showrc : exibe
checksig : verifica assinatura
setugids [especificações do pacote] : ajusta UID
etperms [especificações do pacote] : ajusta permissões
+ : após de um parâmetro, indica que pode haver repetição
Mas não é só isso minha gente!!! (aeeeeeeeeee!!!). Tá aí algumas receitas de bolo (mas não deixe dar usar um % man pra REALMETE aprender os segredos milenares – mas nem tanto – desse desse comando).
Obtendo instalações de pacotes instalados:
% rpm -qa | sort | less : lista em ordem alfabética os pacotes instalados
% rpm -qa | wc -1 : mostra a quantidade de pacotes instalados
% rpm -qf /usr/bin/nomedopacote.rpm : mostra os pacotes pertencentes ao arquivo
% rpm -qa | grep gimp: lista todos os arquivos que correspondem ao gimp
Para pacotes não instalados:
% rpm -qip /.../.../pacote.rpm : informações do pacote
% rpm -qdp /.../.../pacote.rpm : encontra documentação
% rpm -qp /.../.../pacote.rpm : mostra como será o nome do pacote
% rpm -qlp /.../.../pacote.rpm : lista os arquivos do pacote
% rpm -qcp /.../.../pacote.rpm : lista arquivos de configuração dos pacotes
% rpm -q –whatrequires /.../.../pacote.rpm : mostra o requerimentos
Desinstalação depacotes:
% rpm – e [opções] pacote.rpm
Opções: --allmatches : remove todas as versões do pacote
--noscripts : não executa scripts de pré/pós instalação
--nodeps : verifica se as dependências serão quebradas
--test : somente simula a desinstalação
Instalação/Atualização de pacotes:
% rpm -ivh [opções] pacote.rpm : instala
% rpm -Uvh [opções] pacote.rpm : atualiza
Opções: --force : sobrescreve
--noscripts : não executa scripts de pré/pós instalação
--nodeps : verifica se as dependências serão quebradas
--excludedocs : não instala arquivos de texto
--test : somente simula a desinstalação
--percent : exibe porcentagem
--oldpkage : atualiza para versão anterior
--replacepkgs : substitui arquivos instalados
--allfiles : instala atualiza pacotes faltantes
% whereis : mostra a localização dos binários do pacote instalado
% rpm -ivh /.../.../gimp-* : instala todos os pacotes do gimp simultaneamente
Instalação por FTP:
% ftp://:@host /.../.../arquivo.rpm
Opções: --ftpproxy : a ''máquina'' do host citado será o servidor proxy para tranferências
--ftpport: Especifica uma porta TCP ao invéz de FTP (porta 21). É cara, troca o xxx pelo número da porta.

Fonte: http://www.linuxbsd.com.br

A história do Linux

2013-05-23T12:12:00.001-07:00

Introdução

Quando Linus Torvalds criou o Linux, certamente não sabia da importância que este projeto teria para os mais variados aspectos da computação. Graças à sua iniciativa, o Linux está presente em centenas de milhares de servidores, computadores pessoais e dispositivos portáteis em todo o mundo. Mas, como isso aconteceu? Por que Torvalds criou o Linux? Por qual motivo este projeto teve uma aceitação tão grande? Efetivamente, o que é Linux? Para obter as respostas para estas e outras questões relacionadas, nada melhor do que conhecer a história do Linux. É isso que o InfoWester apresenta a seguir.

O que é Linux?

Para muita gente, o Linux é meramente um sistema operacional. Esta definição não está errada, mas também não está completa. Na verdade, o Linux é parte de um todo, mais precisamente, é um kernel de código-fonte* aberto, que foi - e é desenvolvido - ao longo do tempo graças à colaboração voluntária de desenvolvedores de várias partes do mundo.

* Em poucas palavras, código-fonte é um conjunto de instruções baseado em uma linguagem de programação que, depois de compilado ou interpretado, forma um software. Tendo acesso ao código-fonte, é possível saber como determinado programa ou recurso de software foi desenvolvido.

O que é kernel?

Kernel pode ser entendido como o núcleo do sistema operacional, isto é, como a parte essencial deste. Cabe ao kernel fazer o intermédio entre o hardware e os programas executados pelo computador. Isso significa que a junção do kernel mais os softwares que tornam o computador usável (drivers, protocolos de comunicação, entre outros), de acordo com a sua aplicação, é que formam o sistema operacional em si.

Para compreender melhor, você pode imaginar o kernel como sendo o chassi de um veículo. De acordo com a aplicação em questão, uma montadora pode adquirir um chassi e utilizá-lo para montar um carro para transportar cargas ou, se a necessidade for esta, para construir um automóvel de passeio para uma família.

Perceba que o kernel não é, necessariamente, um software manipulável pelo usuário. Ou seja, não se trata de algo tão simples a ponto de poder ser instalado e, logo em seguida, estar pronto para uso, como um programa de edição de textos, por exemplo. O kernel é uma base complexa, que serve de estrutura para o sistema, atuando nos "bastidores". Assim, o usuário sequer precisa saber de sua existência para poder utilizar o computador.

Então, o Linux é um kernel?

Exatamente! Quando procuramos um programa que possui versões para vários sistemas operacionais - como o navegador Mozilla Firefox -, nos deparamos com vários links: um que aponta para a versão Windows, outra que direciona para a versão Mac OS X, outra para Linux e assim por diante. Perceba que, em situações como esta, o nome Linux não é empregado incorretamente. Por outro lado, achar que o Linux é todo o conjunto de software, incluindo aplicativos, interfaces gráficas e outros, é uma visão bastante limitada.

Mas, para entender melhor o que é Linux e o que ele representa, é conveniente conhecer a sua história.

A história do Linux

A história do Linux começa no ano de 1991, pelas mãos de um estudante universitário finlandês chamado Linus Torvalds. O Linux foi criado por ele, não totalmente do "zero", mas sim como uma variação do MINIX.

Linus Torvalds - Imagem por Wikipedia

O MINIX é um sistema operacional simples, criado por Andrew S. Tanenbaum, um renomado professor de computação que é conhecido pelos diversos livros que escreveu para a área.

Tanenbaum disponibilizou o MINIX principalmente para servir de auxílio no ensino de computação. Trata-se de um sistema operacional simples, que exige poucos recursos de hardware e cuja primeira versão foi lançada em 1987.

Dadas as suas finalidades acadêmicas, não só o MINIX foi disponibilizado de maneira gratuita e livre, como também o seu código-fonte completo. Assim, os estudantes de computação podiam - e podem - estudá-lo inteiramente para desenvolver suas habilidades ou mesmo para criar projetos derivados. Foi assim que Linus Torvalds entrou nesta história.

A relação do Linux - e do MINIX - com o UNIX

O MINIX também não foi escrito do "zero". Trata-se, na verdade, de um projeto baseado em um sistema operacional que tem grande participação na história da computação: o UNIX.

O surgimento do UNIX se deu em 1969, como um projeto da Bell Labs, laboratório pertencente à AT&T. Mas somente em meados da década seguinte tornou-se um sistema efetivamente disponível no meio acadêmico, o que permitiu a sua evolução e o surgimento de variações.

O UNIX, na verdade, começou em meados dos anos 1960 como um projeto a ser desenvolvido por um grupo de habilidosos programadores, entre eles, Ken Thompson e Dennis Ritchie: um sistema operacional de nome Multics.

O Multics era um projeto ambicioso, mas enfrentou vários problemas, entre eles, falta de recursos computacionais. Assim, no mesmo ano, Ken Thompson decidiu criar algo mais "realista", chamando o novo projeto de Unics. Tempos depois, o nome foi mudado para UNIX, denominação que permanece até hoje.

Apesar de haver outros programadores envolvidos com a criação do UNIX, Ken Thompson e Dennis Ritchie são os nomes mais lembrados porque ambos, em 1973, praticamente reescreveram o UNIX a partir da linguagem C.

C é uma criação de Dennis Ritchie, daí o seu comprometimento com o trabalho envolvendo a linguagem e o UNIX. Por causa de seus recursos, a linguagem passou a ser utilizada em vários outros projetos mais complexos, inclusive no desenvolvimento de outros sistemas operacionais, fazendo com que o seu criador fosse reconhecido mundialmente como um dos grandes nomes da computação (infelizmente, Dennis Ritchie faleceu eum outubro de 2011).

O UNIX teve grande aceitação não somente em universidades, mas também em ambientes corporativos, resultando no surgimento de variações diversas do sistema, como as versões BSD e o Solaris. O MINIX, assim como o Linux, é uma delas, o que não quer dizer que ambos sejam iguais ao UNIX, mas notoriamente parecidos.

O surgimento do Linux

Linus Torvalds, então com quase 20 anos, começou a estudar ciência da computação na Universidade de Helsinki, na Finlândia, em 1988. Cerca de dois anos depois, aproveitando o conhecimento que tinha e estava adquirindo sobre a linguagem C, decidiu criar a sua própria implementação de um terminal em seu recém obtido computador 80386, principalmente para acessar o servidor UNIX da instituição de ensino. Isso porque ele já havia testado o MINIX para esta finalidade, mas não estava satisfeito com os seus recursos.

A intenção de Torvalds era a de fazer com que o projeto rodasse especificamente em sua máquina 80386, com o desenvolvimento sendo feito a partir do MINIX. O trabalho avançou de tal forma que chegou um ponto onde Torvalds já tinha um kernel funcional em mãos.

Em 1991, Linus Torvalds decidiu divulgar abertamente o seu projeto. Para isso, publicou mensagens na Usenet (uma espécie de antecessora da internet, baseada em troca de mensagens) pedindo sugestões e colaborações para a sua iniciativa.

Eis a íntegra da primeira mensagem, em inglês, postada em 25 de agosto de 1991. Logo em seguida, sua tradução para português:

From: torvalds@klaava.Helsinki.Fi (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: What would you like to see most in minix?
Summary: small poll for my new operating system
Keywords: 386, preferences
Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI>
Date: 25 Aug 91 20:57:08 GMT
Organization: University of Helsinki
Lines: 20

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).

I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want. Any suggestions
are welcome, but I won't promise I'll implement them :-)

Linus (torvalds@klaava.Helsinki.Fi)

PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
It is NOT protable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks, as that's all I have :-(.

Tradução para português:

Assunto: O que você gostaria de ver no minix?
Summary: Pequena pesquisa para o meu novo sistema operacional

Olá a todos que usam o minix -

Estou fazendo um sistema operacional (livre - apenas como um hobby,
não será algo grande e profissional como o GNU) para
máquinas AT 386 (486). Ele tem sido trabalhado desde abril, e
está começando a ficar pronto. Eu gostaria de
opiniões sobre coisas que as pessoas gostam/não gostam no
minix, já que o meu SO lembra um pouco ele (mesmo layout
físico do sistema de arquivos (por motivos práticos),
entre outros).

Eu já portei o bash (1.08) e o gcc (1.40) e as coisas parecem
funcionar. Isso indica que conseguirei alguma coisa prática
dentro de alguns meses, e gostaria de saber quais recursos as pessoas
mais gostaria de ter. Todas as sugestões serão
bem-vindas, mas não prometo implementá-las :-)

Linus (torvalds@kruuna.helsinki.fi)

PS. Sim - ele está livre de qualquer código do minix, e
tem sistema de arquivos com multi-threading. Ele NÂO é
portável (usa 386, chaveamento de tarefas, etc) e provavelmente
nunca suportará qualquer coisa além de discos
rígidos AT, pois é tudo o que eu tenho :-(.

Por esta mensagem, é possível perceber que Linus Torvalds não esperava que seu projeto fosse crescer tanto e se tornar tão importante para o advento da computação e da Tecnologia da Informação.

O início da trajetória do Linux não foi isenta de problemas. Uma dos obstáculos que Torvalds teve que enfrentar foram as críticas do professor Andrew S. Tanenbaum, que em suas declarações afirmou que o "Linux é obsoleto", especialmente por este ter "design monolítico".

Tanenbaum não estava contente com o fato de o Linux ter sido preparado especificamente para rodar com o processador 80386 que, além de caro, teria sua arquitetura substituída futuramente, o que, na verdade, não aconteceu.

Linus respondeu às críticas e continuou seu trabalho, contando com o apoio de cada vez mais pessoas. Com o passar do tempo, o Linux acabou inclusive sendo portado para várias outras plataformas, o que certamente contribuiu para o seu sucesso.

Linux rodando no console Nintendo DS

O nome Linux

O projeto já era realidade, mas não tinha um nome. Inicialmente, Torvalds atribuiu ao kernel a denominação Freax, uma mistura de free (livre) com freak (monstruoso, esquisito) e a letra 'x', para lembrar o UNIX.

O símbolo do Linux é o Pinguim Tux

O programador Ari Lemmke, depois de sugerir a Torvalds que colocasse o projeto em uma rede para torná-lo mais acessível, decidiu criar no servidor de FTP que hospedaria o software uma pasta de nome "linux" (muito provavelmente, uma mistura de Linus com UNIX), já que não havia gostado de Freak. A denominação "Linux" acabou "pegando" e é, tal como você vê, utilizada até hoje.

GNU/Linux

Você já deve ter visto em vários lugares - inclusive aqui no InfoWester - a expressãoGNU/Linux. O que isso significa?

Tal como você já sabe, o Linux, por si só, é um kernel. Sozinho, um kernel não tem muita utilidade. É necessário "juntá-lo" a um conjunto de softwares para que tenhamos, efetivamente, um sistema operacional em condições de uso. É aí que o projeto GNU entra.

GNU é a sigla para um nome curioso: "GNU is Not UNIX (GNU Não é UNIX)". Trata-se de um projeto que teve início em 1984, pelas mãos de Richard Stallman, que queria criar um sistema compatível com UNIX, mas sem utilizar código deste.

Com o passar dos anos, o projeto foi ganhando recursos, como compiladores e editores de texto. Mas, faltava um elemento importantíssimo: um kernel. Stallman e seus colaboradores estavam trabalhando em um kernel de nome Hurd, mas dada a demora em concluí-lo, muitos daqueles que precisavam ou queriam usar software GNU decidiram recorrer a algo que souberam ser capaz de atender à necessidade que tinham: o Linux.

Então, basicamente, o Linux que temos hoje é conhecido por trabalhar em conjunto com software GNU. Por isso, muitos integrantes e simpatizantes de movimentos ligados ao software livre defendem a ideia de que, quando houver referência ao sistema operacional como um todo, o nome GNU/Linux seja utilizado. Acontece que, por comodidade ou simplesmente desconhecimento, muitas pessoas criaram o hábito de chamar todo o conjunto de Linux e não somente o kernel.

Distribuições Linux

Você já sabe que o Linux, ao contrário de outros sistemas baseados no UNIX ou mesmo deste, não é um sistema operacional como um todo. Mas, sendo um kernel disponível de maneira gratuita e com código-fonte aberto, qualquer pessoa ou organização pode juntá-lo a um conjunto de softwares para criar um sistema operacional customizado.

Ao longo dos últimos anos, foi justamente isso que aconteceu. Vários grupos ou mesmo empresas se organizaram e criaram seu próprio sistema operacional baseado em Linux. Cada uma delas recebe o nome de "distribuição Linux" (ou "distribuição GNU/Linux").

Há várias distribuições Linux por aí, para os mais diversos fins. Muitas inclusive fazem parte de negócios rentáveis, onde a empresa fornece, por exemplo, o sistema operacional de graça, mas obtém receita a partir de serviços de suporte técnico. Naturalmente, aquelas distribuições que se destinam ao segmento de usuários domésticos são mais populares.

Captura de tela do Ubuntu

Para o público em geral, a distribuição mais famosa é o Ubuntu, da empresa Canonical. Por padrão, são lançadas novas versões do Ubuntu em todos os meses de abril e outubro de cada ano. Há um esquema de numeração que ajuda a identificar a época de lançamento: a versão 11.10 do Ubuntu, por exemplo, foi lançada em 2011, no mês de outubro. É possível saber disso porque a indicação de ano aparece primeiro (11) e, depois do ponto, vem a indicação do número do mês (10).

É claro que há outras distribuições renomadas, entre elas:

Fedora (ligada à Red Hat);
Debian;
Mandriva;
Linux Mint;
CentOS (com foco em servidores);
Slackware.

É possível obter informações sobre estas e outras distribuições Linux no site DistroWatch.com(em inglês).

Versões do kernel

Periodicamente, novas versões do kernel Linux são lançadas. Atualizações são naturais para qualquer software e ocorrem para atribuir melhorias a determinadas funcionalidades, para corrigir falhas (bugs) e, no caso de sistemas operacionais, para adicionar recursos importantes ao kernel, principalmente compatibilidade com novos hardwares.

Normalmente, cada versão do kernel é representada por três números distintos separados por pontos, por exemplo: 2.6.24. O primeiro número indica a versão do kernel. O segundo número indica a última revisão feita até o momento naquela versão. O terceiro número, por sua vez, indica uma revisão menor, como se fosse uma "revisão da última revisão" do kernel. Um quarto número pode ser utilizado para indicar uma atualização importante naquela versão.

É válido frisar que antes da série 2.6.x, a numeração do kernel tinha o seguinte esquema: se o segundo número da representação fosse ímpar, significava que aquela série ainda estava em desenvolvimento, ou seja, era uma versão instável e em fase de testes ou aperfeiçoamentos. Se o número fosse par, significava que aquela série já tinha estabilidade para ser disponibilizada para uso.

A numeração sofreu outra mudança em julho de 2011, quando foi lançada a versão 3.0 do Linux. Das versões 1.x para 2.x houve significativas alterações no kernel. No entanto, da 2.x para a 3.x não houve nada tão importante assim, tanto que, pelo esquema, esta versão deveria ser 2.6.40.

Tudo indica que a mudança aconteceu por uma questão de comodidade e "estética". Há também quem afirma que a numeração 3.0 foi dada como forma de comemorar o aniversário do Linux, que completou 20 anos de existência em 2011.

A licença do Linux

Uma licença é, em poucas palavras, um documento que explica como determinado software pode ser utilizado. No que se refere a programas de código-fonte aberto, há vários tipos de licenças disponíveis. O Linux utiliza a GPL (GNU Public Licence).

Vale frisar que, inicialmente, Linus Torvalds aplicou ao Linux uma licença própria, que tinha restrições para uso comercial. A GPL só foi adotada somente em 1992, mesmo porque o Linux já era utilizado com software GNU.

A GPL é uma licença criada pela Free Software Foundation (organização fundada por Richard Stallman) baseada nas liberdades que a entidade defende:

liberdade de executar o programa, para qualquer propósito (liberdade zero);
liberdade de estudar como o programa funciona e adaptá-lo às suas necessidades (liberdade 1), sendo o acesso ao código-fonte um pré-requisito para esta aspecto;
liberdade de distribuir cópias de forma que você possa ajudar ao seu próximo (liberdade 2);
liberdade de melhorar o programa e liberar os seus aperfeiçoamentos, de modo que toda a comunidade se beneficie (liberdade três). Novamente, aqui o acesso ao código-fonte é um pré-requisito.

Um software não pode utilizar a GPL se não corresponder a todos estes requisitos.

A GPL surgiu em 1989, mas foi revisada em 1991 para atender a determinadas necessidades, resultando na GPLv2 (GPL versão dois). Em 2007, surgiu a GPLv3 (GPL versão três). É possível consultar a GPL no seguinte link (em inglês): www.gnu.org/licenses/gpl.html.

Finalizando

Você pode até não ter Linux em seu computador, mas já o utilizou de alguma forma. Por se tratar de um software gratuito, de código-fonte aberto e amplamente disponível, é comum encontrá-lo nas mais diversas aplicações. O servidor que hospeda o InfoWester, por exemplo, roda uma distribuição Linux. Também é possível encontrar este kernel em sistemas embarcados, caixas eletrônicos, dispositivos portáteis, entre outros.

Para saber mais sobre o assunto, você pode consultar os sites que serviram de referência para este texto:

en.wikipedia.org/wiki/Linus_Torvalds;
www.gnu.org/gnu/linux-and-gnu.pt-br.html;
en.wikipedia.org/wiki/MINIX;
www.unix.org;
www.bell-labs.com/history/unix;
netfiles.uiuc.edu/rhasan/linux.
en.wikipedia.org/wiki/Tanenbaum_Torvalds_debate.
http://www.infowester.com/historia_linux.php

A história dos sistemas operacionais

2013-05-22T12:44:00.002-07:00

Atualmente, os sistemas operacionais (SO) estão cada vez mais fáceis de usar, possuindo interfaces muito simples e bonitas. Contudo, todas estas funcionalidades não surgiram do nada, foram evoluindo com o tempo. Por exemplo, a bela interface gráfica do Windows Vista é resultado de mais de 20 anos de desenvolvimento, desde as primeiras versões deste SO. Por isso, criamos este artigo que conta a história dos sistemas operacionais, incluindo os principais representantes de cada época.

Sistema operacional não é a maquina

Atualmente, ainda são comuns alguns equívocos em relação ao sistema operacional. Por exemplo, todos alguma vez já ouviram um diálogo como este:

- Que computador você irá comprar?
- Vou comprar o Windows.
O diálogo acima demonstra um erro muito comum no mundo da informática: pensar que o sistema operacional é a máquina em si. Basicamente, o computador é composto por duas grandes categorias: hardware e software. A primeira delas se refere à parte física da máquina, ou seja, o que pode ser tocado fisicamente. Já a segunda abrange a parte lógica responsável por realizar tarefas, utilizando-se do hardware para a realização de suas tarefas.

Por isso, sistemas operacionais como o Windows, Linux ou o MAC OS, são apenas softwares que gerenciam toda a atividade do hardware, mas não o computador em si. Consequentemente, em um PC que contenha um dos SOs citados acima, quase sempre é possível instalar outro.

Sistemas operacionais primitivos

Primeiramente, vamos tratar sobre a gênese dos sistema operacionais, abordando a forma como eram desenvolvidos nas décadas de cinquenta, sessenta e setenta.

Máquinas que não usavam SO

A primeira geração da computação moderna (1945-1955) não trabalhava com o conceito de sistema operacional propriamente dito, visto que as operações eram setadas através de hardware. Por exemplo, chaves, quilômetros de fios e luzes de aviso, como na foto abaixo do Eniac. Nesse período, era muito comum que a mesma pessoa projetasse, programasse e utilizasse os computadores. A principal implicação desta abordagem é o fato de que era muito difícil criar rotinas programáveis, exigindo trabalho intenso dos operadores de máquinas.

Programação em Batch

O conceito de sistema operacional apareceu durante a segunda geração da computação moderna (1955 - 1965), através da programação em Batch. Assim, vários comandos já poderiam ser executados em sequência através de cartões perfurados, eliminando parte do trabalho do operador de terminal. Normalmente, um programa era composto por um conjunto de cartões inseridos pelo usuário do sistema, na ordem correta.

Sistemas específicos

Em meados da década de 60, os primeiros sistemas operacionais foram desenvolvidos conforme a evolução da tecnologia da época. Contudo, cada máquina possuía seu próprio SO específico, o que implicava na incompatibilidade de mainframes distintos. Um dos maiores representantes foi o CTSS, criado pela MIT, sendo lançado em 1961 para o computador IBM 7090.

Unix, o primeiro sistema operacional moderno

Visando ao problema da incompatibilidade de SOs de máquinas distintas, um grupo de desenvolvedores da AT&T ciaram o Unix em 1969, sendo o primeiro sistema operacional moderno da computação. É possível afirmar que mais de 90 porcento dos SOs atuais foram influenciados de alguma maneira pelo Unix.

Sua primeira versão foi escrita em linguagem assembly, sendo posteriormente reescrito em C no ano de 1973, linguagem utilizada até os dias de hoje. Este sistema introduziu conceitos muito importantes para a computação: portabilidade, multi-usuário, multi-tarefas e compartilhamento de tarefas.

Durante a década de 70, o Unix foi distribuído gratuitamente (incluindo seu código fonte) para universidades e órgãos governamentais norte-americanos, o que conferiu muita popularidade a este sistema. Sua interface era totalmente em modo texto sem interface gráfica

Em 1977 foi lançado o BSD, sistema operacional fortemente baseado no Unix, focado principalmente para a execução em máquinas específicas de alto desempenho, como o famoso computador VAX, o qual foi uma referência de hardware na época.

Sistemas Operacionais para computadores pessoais

Tanto o Unix quanto o BSD, em suas primeiras versões, foram desenvolvidos para o uso de computadores de grande porte, normalmente em universidades. Contudo, alguns jovens programadores possuíam uma ideia absurda para época: criar sistemas operacionais para o uso de pessoas comuns.

Steve Jobs e a Apple

Um dos primeiros a pensar desta forma foi Steve Jobs, fundador da Apple. Desde a criação de sua empresa, seu principal foco foi a criação de computadores para o dia-a-dia, incluindo sistemas operacionais fáceis de serem operados. O lançamento do Apple I em 1976, um dos primeiros computadores pessoais, foi um marco na história da computação.

Pela primeira vez, um PC continha um teclado fácil de ser utilizado, com uma mini-televisão adaptada como monitor. Assim, conhecimentos avançados de computação já não eram mais requisitos para se operar um PC. Jobs fez questão de criar o seu sistema operacional do zero, sem se basear inicialmente no Unix. Nos anos seguintes, os modelos Apple II e Apple III foram lançados no mercado, um sucesso de vendas. Suas interfaces gráficas eram muito primitivas comparadas com o padrão usado atualmente, mas avançadíssimas para a época.

Em meados de 1979, Steve Jobs tomou conhecimento sobre o desenvolvimento de um computador totalmente inovador pela Xerox Parc. Em uma vista a esta empresa, ele ficou deslumbrado com Xerox Alto, um PC que possuía uma interface gráfica (GUI) totalmente revolucionária. Pouco tempo depois, a Apple lançou o Lisa, aproveitando todas as ideias gráficas do computador. Não é nem preciso dizer que o sucesso foi estrondoso. Cada versão do Apple possuía um sistema operacional distinto.

Como se não bastasse, o Apple Machintosh foi lançado em 1984, introduzindo o conceito de desktop, utilizando ícones e pastas para representar programas e arquivos do modo como conhecemos hoje. Esta máquina acompanhava o revolucionário e inovador sistema chamado MAC OS. Seu sucesso foi estrondoso em todo EUA, principalmente pela vinculação de seu comercial durante a final do Superbowl do mesmo ano.

Com o passar dos anos, as novas versões do Macintosh e o do MAC OS já não eram mais populares como antes, o que fez com que a Apple perdesse bastante mercado para a Microsoft. No final dos anos 90, o código do Macintosh apresentava muitos problemas, o que obrigou que um novo plano fosse traçado. Em 2001, a Apple surpreendeu o mundo da informática, abandonando o seu próprio código e reescrevendo todo o seu sistema operacional usando o Unix como base. A partir daí, ele passou a se chamar MAC OSX, sistema que continua forte até os dias de hoje.

Bill Gates e a Microsoft

Voltando ao final da década de 70, outro jovem programador, chamado Bill Gates, também possuía o desejo de revolucionar o mundo da informática. Em 1975, ele fundou a Microsoft, empresa que possuía como objetivo primário o desenvolvimento de software em linguagem BASIC para o computador Altair da IBM. Com o sucesso dos programas desenvolvidos pela Microsoft, a empresa afirmou que possuía um sistema operacional completo. A IBM se interessou pelo projeto e ambas as organizações afirmaram um contrato, em 1979.

Entretanto, a Microsoft estava com sérios problemas, pois não possuía um sistema operacional de verdade. A solução encontrada foi a compra do SO da Seattle Computer Products pelo valor de $50.000. Muitos o chamam de negócio do século, pois a partir de 50 mil dólares, a Microsoft possui o patrimônio atual avaliado em dezenas de bilhões de dólares.

Após várias melhorias sobre o sistema comprado, a Microsoft lançou MS-DOS em 1982 cuja interface era baseada em modo texto, bastante parecida com a utilizada pelo Unix. Na época, esse SO não chamou tanta atenção, pois o Apple Lisa de Steve Jobs já trabalhava com uma interface gráfica. Tomando conhecimento deste problema, Bill Gates fez uma vista a Apple, com o objetivo básico de conhecer a empresa. Ao final da visita, Gates convenceu Jobs a ser incluído no desenvolvimento do Macintosh.

O objetivo de Gates era maior que isso: copiar a interface gráfica do Machintosh, e foi exatamente isso que aconteceu. No lançamento do novo PC da Apple, Steve Jobs descobriu que a Microsoft estava lançando máquinas no Japão, cujas interfaces eram muito parecida com a do seu computador. Após a quebra da parceria entre os dois, Gates lançou o Sistema Operacional Windows 1.0 em 1985, batendo de frente com o MAC OS.

Após problemas de administração, Jobs foi demitido da Apple, o que desestabilizou a empresa, retornando somente em 1997. Assim, a Microsoft foi ganhando cada vez mais mercado no mercado, lançando o Windows 2.0 em 1987, trazendo melhorias consideráveis na parte visual e no gerenciamento de memória.

Windows 3.0 e 3.11

No início dos anos 90, o mercado de sistemas operacionais sofreu novo boom com o lançamento do Windows 3.0 (1990) e Windows 3.1(1992). Na sua versão 3.0, a memória passou a ser gerenciada de maneira muito mais eficiente, incluindo a melhora substancial na interface gráfica. Foi criado um painel de controle e um gerenciador de arquivos organizado, facilitando todo o trabalho do usuário.
Um dos principais motivos que contribuíram para seu sucesso foi o fato do sistema já vir instalado de fábrica em um grande número de máquinas.

O Windows 3.1, incluindo seu service pack 3.11, trouxe melhorias à versão 3.0, como uma interface de rede melhor desenvolvida. Em 2 meses de lançamento, o 3.1 vendeu 3 milhões de cópias.

Windows 95, 98 e ME

No ano de 1995, foi lançada no mercado a nova versão deste sistema operacional, o Windows 95. Esta versão foi tão importante para informática que acabou definindo o padrão com que o desktop é organizado, o qual ainda é utilizado no Vista. Por exemplo, podemos citar o botão Start, o menu Iniciar, a barra de tarefas e o gerenciador de arquivos Windows Explorer. Após alguns services packs, esta versão passou a suportar a leitura de dispositivos USB, o navegador internet explorer, entre outras funcionalidades.

Dando continuidade a seu antecessor, a nova versão deste sistema foi lançada no ano de 1998, chamada de Windows 98. Apesar de apresentar melhorias em relação ao 95, o SO era um pouco lento e instável. Tais problemas só foram arrumados com o Windows 98 SE (Second Edition), lançado em 1999, que incluía funções avançadas para compartilhamento de rede, suporte integrado a drivers de DVD-ROM, entre outras tarefas

O sucessor, Windows Me, lançado em 2000, foi um dos maiores fracassos na questão de sistema operacional, pois era muita instável. Possuía somente poucas melhoras em relação ao Windows 98 SE. Por isso, logo foi deixado de lado.

Todas as versões apresentadas até aqui usavam o MS-DOS como núcleo do sistema, ou seja, o Windows funcionava como uma espécie de ambiente gráfico. Com o passar do tempo, o uso desta arquitetura tornou-se insuportável, visto que o MS-DOS não conseguia dar conta de processar tantas informações, o que ficou evidente no Windows Me.

Windows XP e Vista

Lançado em 2001, o Windows XP tornou-se um marco na história dos sistemas operacionais, principalmente por trazer muitos recursos totalmente novos. Entre eles é possível citar que o sistema tornou-se muito mais seguro, através da diferenciação de permissões entre administradores e usuários comuns. A estabilidade também é uma de suas fortes características, pois o número de telas azuis diminuíram consideravelmente.

O principal motivo para todo esse avanço é uso do núcleo (kernel) NT como base, que exclui totalmente a necessidade do MS-DOS. Na verdade, o núcleo NT já vem sido usado desde outras versões do Windows lançadas para uso de servidores, como o Windows NT (1993) e Windows 2000 (2000). Contudo, foi somente no XP que esta arquitetura foi lançada para o usuário comum. Para saber mais sobre a definição de núcleo, clique aqui.

Depois de seis anos de espera, a Microsoft lança o Windows Vista, em 2007, que foi muito aguardado pelos usuários. Ao contrário do XP, esta nova versão desapontou o público de uma maneira geral, principalmente por exigir uma máquina muito potente. Somente em computadores top de linha é possível observar vantagens no desempenho do Vista, principalmente pela suporte a multi-core. Seu grande destaque foram os efeitos gráficos de última geração provido pelo pelo Aero e o Flip 3D.

A nova versão deste SO, Windows Seven, já está em desenvolvimento.

Sistemas Operacionais Livres

Até o exato momento, apresentamos a evolução dos principais sistemas proprietários do mercado: Mac OS X e Windows. Agora, vamos focar nos sistemas livres. Apesar de fazer bastante sucesso nos anos 70, o Unix continuou a ser desenvolvido durante toda esta década e a seguinte também. No ano de 1983, um revolucionário programador chamado Richard Stallman criou o projeto GNU, ele afirmava que os softwares deveriam ser desenvolvidos de maneira livre, sem restrições na leitura ou modificação de seus códigos fontes.

Em 1984, o MIT desenvolveu o X Window System, que como o seu nome diz, é um sistema gráfico de Janelas para o Unix. Ele permaneceu proprietário até 1987, quando uma versão opensource foi lançada, sendo incorporada no desenvolvimento deste sistema operacional. Um dos principais objetivos da GNU sempre foi desenvolver a sua própria versão do Unix, através de um Kernel próprio, chamado de GNU Hurd. Contudo, este núcleo possuía muitas falhas de sistema, comprometeu muito o seu desenvolvimento.

O kernel Linux

Visando estas falhas, um programador chamado Linus Torvalds estava desenvolvendo outro kernel para o GNU, chamado de Linux, em. Em seu primeiro lançamento oficial (1991), na versão 0.2, o Linux já possuía mais funcionalidades que o GNU, o que atraiu bastantes desenvolvedores. Pouco tempo depois, o núcleo criado por Torvalds já era o sistema GNU mais usado do mundo.

Além disso, os programadores eram e ainda são livres para utilizar o kernel Linux em seus próprios sistemas, o que acabou gerando as famosas distribuições como conhecemos hoje . As primeiras ficaram conhecidas como Debian e Slackware, ambas lançadas no Ano de 1993. No início, eram difíceis de serem utilizadas, comparadas com os Windows 3.11 e 95, pois exigiam um conhecimento profundo de computação por parte dos usuários.

Com o tempo, as distribuições Linux foram se tornando cada vez mais fáceis de serem utilizadas, principalmente para atrair o usuário comum do computador. Atualmente, utilizar este sistema é tão fácil quanto o Windows, principalmente em distribuições como o Ubuntu.

Fonte: www.tecmundo.com.br

Instalação e configuração do Samba usando o Swat

2013-05-22T10:04:00.002-07:00

A necessidade de compartilhar arquivos e impressoras motivou o aparecimento das primeiras redes de computadores (ainda na década de 70) e continua sendo uma necessidade comum. Mesmo para fazer um simples backup armazenado remotamente, é necessário configurar algum tipo de compartilhamento de arquivos. Existem diversas formas de disponibilizar arquivos através da rede, incluindo o NFS, o FTP, o SFTP e até mesmo um servidor web, que pode ser usado para compartilhar a pasta contendo os arquivos e aceitar uploads através de um script em PHP, por exemplo. Entretanto, quando falamos em redes locais, o protocolo mais usado é o CIFS (Common Internet File System), que é o protocolo usado para compartilhar arquivos e impressoras em redes Microsoft. O nome "CIFS" pode soar estranho à primeira vista, mas ele nada mais é do que a mais nova versão do protocolo SMB, usada a partir do Windows 2000. A história do SMB e do CIFS começa em 1984, quando a IBM criou o protocolo NetBIOS (Network Basic Input Output), um protocolo para troca de mensagens entre micros PC ligados em rede, originalmente desenvolvido para servir como uma extensão do BIOS da placa-mãe, oferecendo recursos de rede. Em 1985, o protocolo foi expandido, dando origem ao protocolo NetBEUI, que foi durante muito tempo o principal protocolo usado em redes locais, antes da popularização do TCP/IP. O SMB (Server Message Block) veio mais tarde, junto com o Windows 3.11. O protocolo SMB governa o compartilhamento de arquivos e impressoras em redes Microsoft, incluindo a navegação na rede, o estabelecimento de conexões e a transferência de dados. Ele utiliza o NetBIOS para a troca de mensagens entre os hosts e inclui uma versão atualizada do protocolo, que roda sobre o TCP/IP.Acessando as propriedades do protocolo TCP/IP dentro das configurações de rede de uma máquina com o Windows XP, você pode ver que ele (NetBIOS) continua presente, com o objetivo de manter compatibilidade com as versões anteriores do Windows:

O problema com o NetBIOS é que ele depende do uso intensivo de pacotes de broadcast e de pacotes UDP. O CIFS é a evolução natural do SMB, que inclui diversos novos recursos, abandona o uso do NetBIOS e passa a utilizar uma única porta TCP (445) no lugar das três portas (137 UDP, 138 UDP e 139 TCP) utilizadas pelo SMB. O Samba é justamente uma implementação das mesmas funções para sistemas Unix, incluindo não apenas o Linux, mas também o BSD, Solaris, OS X e outros primos. Ele começou como uma implementação do protocolo SMB e foi então sucessivamente expandido e atualizado, de forma a incorporar suporte ao CIFS e a se manter atualizado em relação aos recursos oferecidos pelas versões mais recentes do Windows.

Um Pouco de História

O projeto nasceu no final de 1991, de forma acidental. Andrew Tridgell, um australiano que na época era estudante do curso de PhD em ciências da computação da Universidade Nacional da Austrália. Ele precisava rodar um software da DEC (que na época era uma das gigantes no ramo de tecnologia) chamado "eXcursion", que trabalhava em conjunto com o Patchworks, um software de compartilhamento de arquivos. O Patchworks era um software proprietário, que utilizava um protocolo obscuro, sobre o qual não existiam muitas informações disponíveis. Como todo bom hacker, ele decidiu estudar o protocolo e assim desenvolver um servidor que pudesse rodar em seu PC. Ele desenvolveu então um pequeno programa, chamado clockspy, que era capaz de examinar o tráfego da rede, capturando as mensagens enviadas pelo cliente e as respostas do servidor. Com isso, ele foi rapidamente capaz de implementar o suporte às principais chamadas e a desenvolver um programa servidor, que era capaz de conversar com os clientes rodando o Patchworks. O objetivo desta primeira versão era apenas resolver um problema doméstico: interligar um micro PC rodando o MS-DOS ao servidor rodando o Solaris. Depois de algum tempo, Andrew recebeu um e-mail contando que o programa também funcionava em conjunto com o LanManager da Microsoft, permitindo compartilhar arquivos de um servidor Unix com máquinas rodando o MS-DOS. O protocolo obscuro usado pelo Patchworks se revelou uma implementação do protocolo SMB, que havia sido desenvolvida internamente pela DEC. Nasceu assim, acidentalmente, o um dos aplicativos open-source mais importantes da atualidade. Pouco depois, em janeiro de 1992, ele disponibilizou o "Server 0.1" no servidor da Universidade, que foi rapidamente seguido por uma versão aprimorada, o "Server 0.5". Este arquivo ainda pode ser encontrado em alguns dos FTPs do http://samba.org, com o nome "server-0.5". Esta versão inicial rodava sobre o MS-DOS. Depois de um longo período de hibernação, o software foi portado para o Linux, dando origem à versão seguinte (1.5), que foi lançada apenas em dezembro de 1993 e passou a se chamar "smbserver". O nome continuou sendo usado até abril de 1994, quando foi finalmente adotado o nome definitivo. O nome "Samba" surgiu a partir de uma simples busca dentro do dicionário Ispell por palavras que possuíssem as letras S, M e B, de "Server Message Blocks", posicionadas nessa ordem. A busca retornou apenas as palavras "salmonberry", "samba", "sawtimber" e "scramble", de forma que a escolha do nome acabou sendo óbvia. Uma curiosidade é que não existiu um "Samba 1.0", pois a primeira versão a utilizar o nome "Samba" foi a 1.6.05, que foi a sucessora imediata do "smbserver 1.6.4". O projeto começou a se tornar popular a partir da versão 1.6.09 (lançada pouco depois), que foi a primeira a trazer suporte ao controle de acesso com base nos logins de usuário (assim como o Windows NT), enquanto as versões anteriores suportavam apenas o controle de acesso com base no compartilhamento (assim como no Windows 3.11 e 95), onde a única opção de segurança era usar uma senha de acesso para os compartilhamentos. A partir daí, o projeto não parou de crescer, atraindo um número crescente de usuários e desenvolvedores, até se transformar no monstro sagrado que é hoje. Estes dois links contam um pouco mais sobre a história do Samba, desde as primeiras versões:

http://www.samba.org/samba/docs/10years.html
http://www.rxn.com/services/faq/smb/samba.history.txt

Em 1994 a Microsoft liberou as especificações do SMB e do NetBIOS, o que permitiu que o desenvolvimento do Samba desse um grande salto, tanto em recursos quanto em compatibilidade, passando a acompanhar os novos recursos adicionados ao protocolo da Microsoft, que mais tarde novamente deixou de ser aberto. Hoje, além de ser quase 100% compatível com os recursos de rede do Windows 98, NT, 2000 e XP, o Samba é reconhecido por ser mais rápido que o próprio Windows na tarefa de servidor de arquivos. Um dos pontos fortes do Samba é que o projeto foi todo desenvolvido sem precisar incorrer em qualquer violação de patentes. Todas as chamadas (com exceção das que a Microsoft tornou públicas em 1994) foram implementadas monitorando as transmissões de dados através da rede, processo que os desenvolvedores chamam de "French Cafe technique". Dentro da analogia, seria como aprender francês sentando-se em um café e passando a prestar atenção nas conversas, aprendendo a partir daí novas palavras, expressões e situações onde elas podem ou não serem usadas. É um trabalho bastante detalhista e tedioso, que demanda um grande esforço e resulta em avanços graduais, mas, se executado por anos a fio, como no caso do Samba (que começou a ser desenvolvido em 1991), resulta em conquistas surpreendentes. Isso torna o Samba virtualmente invulnerável a ações legais relacionadas a quebras de patentes ou problemas similares, já que o software é inteiramente baseado em observação e no uso de especificações públicas. Uma curiosidade é que a existência do Samba permitiu que a Microsoft conseguisse colocar PCs rodando Windows em muitos nichos onde só entravam Workstations Unix, já que com o Samba os servidores Unix existentes passaram a ser compatíveis com as máquinas Windows. Ou seja: até certo ponto, o desenvolvimento do Samba foi vantajoso até mesmo para a Microsoft. Quase tudo que você pode fazer usando um servidor Windows, pode ser feito também através do Samba, com uma excelente segurança, confiabilidade e com um desempenho em muitas situações bastante superior ao de um servidor Windows com a mesma configuração. O Samba é uma solução bastante completa e flexível para uso em redes locais, pois oferece um grande volume de opções de configuração e é compatível com todas as versões do Windows; do 3.11 ao Vista. Além de compartilhar arquivos, ele permite também compartilhar impressoras e centralizar a autenticação dos usuários, atendendo tanto a clientes Windows, quanto a clientes Linux. Para os clientes Windows, o servidor Samba aparece no ambiente de redes exibindo os compartilhamentos disponíveis, exatamente da mesma forma que um servidor Windows:

Os compartilhamentos podem ser acessados da forma tradicional e inclusive mapeados. No caso dos compartilhamentos de impressoras, é possível inclusive utilizar o Point-and-Print, onde os clientes obtém os drivers de impressão diretamente a partir do servidor e a impressora fica disponível com apenas dois cliques. Além de compartilhar arquivos e impressoras, o servidor Samba pode atuar como um PDC, autenticando os usuários da rede. Existem também diversas opções de segurança, que permitem restringir o acesso aos compartilhamentos. Naturalmente, o servidor pode ser acessado de forma simples também nos clientes Linux da rede. As versões recentes do Konqueror e do Nautilus incorporam plugins que permitem acessar os compartilhamentos de forma bastante prática (experimente digitar smb://endereço_do_servidor na barra de endereços do Konqueror) e existem também clientes especializados, como o Smb4k:

O Samba é dividido em dois módulos, o servidor Samba propriamente dito e o "smbclient", o cliente que permite acessar compartilhamentos em outras máquinas. Os dois são independentes, de forma que você pode instalar apenas o servidor, apenas o cliente ou ambos, de acordo com a função da máquina.

Instalando o Samba

Como comentei a pouco, o Samba é dividido em dois módulos. O servidor propriamente dito e o cliente, que permite acessar compartilhamentos em outras máquinas (tanto Linux quanto Windows). Os dois são independentes, permitindo que você mantenha apenas o cliente instalado num desktop e instale o servidor apenas nas máquinas que realmente forem compartilhar arquivos. Isso permite melhorar a segurança da rede de uma forma geral. Os pacotes do Samba recebem nomes um pouco diferentes nas distribuições derivadas do Debian (incluindo o Ubuntu, Kubuntu e outras) e no Fedora (e outras distribuições derivadas do Red Hat, como o CentOS). Veja:

Pacote	Debian	Fedora
Servidor	samba	samba
Cliente	smbclient	samba-client
Documentação	samba-doc	samba-doc
Swat	swat	samba-swat

Para instalá-lo no Debian ou Ubuntu, por exemplo, você usaria:

# apt-get install samba smbclient swat samba-doc

O script de instalação faz duas perguntas. A primeira é se o servidor deve rodar em modo daemon ou sob o inetd. Responda "daemons" para que o servidor rode diretamente. Isso garante um melhor desempenho, melhor segurança e evita problemas diversos de configuração relacionados ao uso do inetd, serviço que está entrando em desuso. Em seguida ele pergunta: "Gerar a base de dados para senhas /var/lib/samba/passdb.tdb?". É importante responder que "Sim", para que ele crie o arquivo onde serão armazenadas as senhas de acesso. Como explica o script, "Caso você não o crie, você terá que reconfigurar o samba (e provavelmente suas máquinas clientes) para utilização de senhas em texto puro", o que é um procedimento trabalhoso, que consiste em modificar chaves de registro em todas as máquinas Windows da rede e modificar a configuração de outros servidores Linux. Muito mais fácil responder "Sim" e deixar que ele utilize senhas encriptadas, que é o padrão. :) Lembre-se de que você deve instalar todos os pacotes apenas no servidor e em outras máquinas que forem compartilhar arquivos. O Swat pode ajudar bastante na etapa de configuração, mas ele é opcional, pois você pode tanto editar manualmente o arquivo smb.conf, quanto usar um arquivo pronto, gerado em outra instalação. Nos clientes que forem apenas acessar compartilhamentos de outras máquinas, instale apenas o cliente. No Fedora e no CentOS a instalação é feita usando o yum:

# yum install samba samba-client samba-doc samba-swat

O Fedora inclui mais um pacote, o "system-config-samba", um utilitário de configuração rápida, que permite criar e desativar compartilhamentos de forma bem prática. Outro configurador rápido é o módulo "Internet & Rede > Samba", disponível no Painel de Controle do KDE. Aqui abordo apenas a configuração manual e o uso do Swat, que é o configurador mais completo, mas você pode lançar mão destes dois utilitários para realizar configurações rápidas. Com os pacotes instalados, use os comandos:

# /etc/init.d/samba start
# /etc/init.d/samba stop
... para iniciar e parar o serviço.

Por padrão, ao instalar o pacote é criado um link na pasta "/etc/rc5.d", que ativa o servidor automaticamente durante o boot. Para desativar a inicialização automática, use o comando:

# update-rc.d -f samba remove

Pata reativá-lo mais tarde, use:

# update-rc.d -f samba defaults

No Fedora, CentOS e no Mandriva, os comandos para iniciar e parar o serviço são:

# service smb start
# service smb stop

Para desabilitar o carregamento durante o boot, use o "chkconfig smb off" e, para reativar, use o "chkconfig smb on". Note que, em ambos, o pacote de instalação se chama "samba", mas o serviço de sistema chama-se apenas "smb". É sempre recomendável utilizar os pacotes que fazem parte da distribuição, que são compilados e otimizados para o sistema e recebem atualizações de segurança regularmente. De qualquer forma, você pode encontrar também alguns pacotes compilados por colaboradores nohttp://samba.org/samba/ftp/Binary_Packages/, além do código fonte, disponível nohttp://samba.org/samba/ftp/stable/. Ao instalar a partir do código fonte, o Samba é instalado por default na pasta "/usr/local/samba", com os arquivos de configuração na pasta "/usr/local/samba/lib". Este texto é baseado no Samba 3 que, enquanto escrevo, é a versão estável, recomendada para ambientes de produção. O Samba 3 trouxe suporte ao Active Directory, passou a ser capaz de atuar como PDC, trouxe muitas melhorias no suporte a impressão e inúmeras outras melhorias em relação à série 2.x. O Samba 3.0.0 foi lançado em setembro de 2003, ou seja, há mais de 4 anos. Comparado com os ciclos de desenvolvimento das distribuições Linux, que são em sua maioria atualizadas a cada 6 ou 12 meses, 4 anos podem parecer muita coisa, mas se compararmos com os ciclos de desenvolvimento de novas versões do Windows, por exemplo, os ciclos parecem até curtos :). Para efeito de comparação, o Samba 2 (o major release anterior) foi lançado em 1999 e o Samba 4 está (em junho de 2008) em estágio de desenvolvimento, ainda sem previsão de conclusão. Por ser um software utilizado em ambientes de produção, novas versões do Samba são exaustivamente testadas antes de serem consideradas estáveis e serem oficialmente lançadas. Graças a isso, é muito raro o aparecimento de bugs graves e, quando acontecem, eles costumam ser corrigidos muito rapidamente. Naturalmente, as versões de produção continuam sendo atualizadas e recebendo novos recursos. Entre o Samba 3.0.0 lançado em 2003 e o Samba 3.0.24 incluído no Debian Etch, por exemplo, foram lançadas nada menos do que 28 minor releases intermediários. Se tiver curiosidade em ler sobre as alterações em cada versão, pode ler o change-log de cada versão no: http://samba.org/samba/history/. Você pode verificar qual é a versão do Samba instalada usando o comando:

# "smbd -V"

como em:

# smbd -V Version 3.0.24

Ao usar qualquer distribuição atual, muito provavelmente você encontrará o Samba 3.0.23 ou superior. Se por acaso você estiver usando alguma distribuição muito antiga, que ainda utilize uma versão do Samba anterior à 3.0.0, recomendo que atualize o sistema, já que muitos dos recursos que cito ao longo do texto, sobretudo o uso do Samba como PDC, não funcionam nas versões da série 2.x. Para usar o Samba em conjunto com estações rodando o Windows Vista, você deve utilizar o Samba versão 3.0.22, ou superior, que oferece suporte ao protocolo NTLMv2, que é o protocolo de autenticação utilizado por padrão pelo Windows Vista. Se não for possível atualizar o Samba, a segunda opção é configurar as estações com o Vista para permitirem o uso do sistema NTLM, o que é feito através do utilitário "secpol.msc" em "Diretivas locais > Opções de segurança > Segurança de rede: nível de autenticação Lan Manager", alterando o valor da opção de "Enviar somente resposta NTLMv2" para "Enviar LM e NTLM - use a segurança da sessão NTLMv2, se negociado".

Cadastrando Usuários

Depois de instalar o Samba, o próximo passo é cadastrar os logins e senhas dos usuários que terão acesso ao servidor. Esta é uma peculiaridade do Samba: ele roda como um programa sobre o sistema e está subordinado às permissões de acesso deste. Por isso, ele só pode dar acesso para usuários que, além de estarem cadastrados no Samba, também estão cadastrados no sistema. Existem duas abordagens possíveis. A primeira é criar usuários "reais", usando o comando adduser ou um utilitário como o "user-admin" (disponível no Fedora e no Debian, através do pacote gnome-system-tools). Ao usar o adduser, o comando fica:

# adduser maria

Uma segunda opção é criar usuários "castrados", que terão acesso apenas ao Samba. Essa abordagem é mais segura, pois os usuários não poderão acessar o servidor via SSH ou Telnet, por exemplo, o que abriria brecha para vários tipos de ataques. Nesse caso, você cria os usuários adicionando os parâmetros que orientam o adduser a não criar o diretório home e a manter a conta desativada até segunda ordem:

# adduser --disabled-login --no-create-home maria

Isso cria uma espécie de usuário fantasma que, para todos os fins, existe e pode acessar arquivos do sistema (de acordo com as permissões de acesso), mas que, por outro lado, não pode fazer login (nem localmente, nem remotamente via SSH), nem possui diretório home. Uma dica é que no Fedora e no CentOS (e outras distribuições derivadas do Red Hat), você só consegue usar o comando caso logue-se como root usando o comando "su -" ao invés de simplesmente "su". A diferença entre os dois é que o "su -" ajusta as variáveis de ambiente, incluindo o PATH, ou seja, as pastas onde o sistema procura pelos executáveis usados nos comandos. Sem isso, o sistema não encontra o executável do adduser, que vai na pasta "/usr/sbin". Os parâmetros suportados pelo adduser também são um pouco diferentes. O padrão já é criar um login desabilitado (você usa o comando "passwd usuário" para ativar) e, ao invés do "--no-create-home", usa a opção "-M". O comando (no Fedora) fica, então:

# adduser -M maria

De qualquer uma das duas formas, depois de criar os usuários no sistema você deve cadastrá-los no Samba, usando o comando: "smbpasswd -a", como em:

# smbpasswd -a maria

Se você mantiver os logins e senhas sincronizados com os usados pelos usuários nos clientes Windows, o acesso aos compartilhamentos é automático. Caso os logins ou senhas no servidor sejam diferentes, o usuário precisará fazer login ao acessar:

Um detalhe importante é que, ao usar clientes Windows 95/98/ME, você deve marcar a opção de login como "Login do Windows" e não como "Cliente para redes Microsoft" (que é o default) na configuração de rede (Painel de controle > Redes). Para desativar temporariamente um usuário, sem removê-lo do sistema (como em situações onde um funcionário sai de férias, ou um aluno é suspenso), você pode usar o parâmetro "-d" (disable) do smbpasswd, como em: # smbpasswd -d maria Se o servidor Samba for configurado como PDC da rede, autenticando os clientes Windows (como veremos em detalhes a seguir), os usuários com contas desativadas sequer conseguem fazer logon no sistema:

Para reativar a conta posteriormente, use o parâmetro "-e" (enable), como em:

# smbpasswd -e maria

Se, por outro lado, você precisar remover o usuário definitivamente, use o parâmetro "-x" (exclude), seguido pelo comando "deluser", que remove o usuário do sistema, como em:

# smbpasswd -x maria
# deluser maria

Depois de criados os logins de acesso, falta agora apenas configurar o Samba para se integrar à rede e compartilhar as pastas desejadas, trabalho facilitado pelo Swat. A segunda opção é editar manualmente o arquivo de configuração do Samba, o "/etc/samba/smb.conf", como veremos mais adiante. As opções que podem ser usadas no arquivo são as mesmas que aparecem nas páginas do Swat, de forma que você pode até mesmo combinar as duas coisas, configurando através do Swat e fazendo pequenos ajustes manualmente, ou vice-versa.

Usando o Swat

O Swat é um utilitário de configuração via web, similar ao encontrado nos modems ADSL. Isso permite que ele seja acessado remotamente e facilita a instalação em servidores sem o ambiente gráfico instalado. Esta mesma abordagem é utilizada por muitos outros utilitários, como o Webmin. Manter o ambiente gráfico instalado e ativo em um servidor dedicado é considerado um desperdício de recursos, por isso os desenvolvedores de utilitários de configuração evitam depender de bibliotecas gráficas. Desse modo, mesmo distribuições minimalistas podem incluí-los. No caso de redes de pequeno ou médio porte, você pode até mesmo usar uma máquina antiga como servidor de arquivos, fazendo uma instalação minimalista do Debian, Ubuntu ou outra distribuição e instalando o Samba e o Swat em modo texto. Como facilitador, o Swat acaba sendo uma faca de dois gumes, pois ao mesmo tempo em que facilita a configuração, por ser uma ferramenta visual e dispensar a edição manual do arquivo, ele complica, por oferecer um grande número de opções específicas ou obsoletas. Vamos então aprender como fazer uma configuração básica usando o Swat e depois nos aprofundar na configuração do Samba editando o smb.conf manualmente. Se preferir, você pode ir diretamente para o tópico seguinte.

Ativando o Swat

No Debian, Slackware e também no Gentoo, o Swat é inicializado através do inetd. O inetd tem a função de monitorar determinadas portas TCP e carregam serviços sob demanda. Isto evita que serviços e utilitários que são acessados esporadicamente (como o Swat) precisem ficar ativos o tempo todo, consumindo recursos do sistema. No caso do Ubuntu, o inetd não vem instalado por padrão. A documentação recomenda usar o xinetd no lugar dele, o que é uma boa deixa para falar um pouco sobre as diferenças de configuração entre os dois serviços. O xinetd tem a mesma função do inetd ou seja, carregar serviços sob demanda, mas ele é mais recente e um pouco mais seguro, de forma que acabou se tornando o mais usado. Apesar disso, a configuração dos dois é diferente: no caso das distribuições que usam o inetd, você precisa adicionar (ou descomentar) a linha abaixo no arquivo de configuração do inetd, o "/etc/inetd.conf":

swat stream tcp nowait.400 root /usr/sbin/tcpd /usr/sbin/swat

O arquivo "/etc/inetd.conf" é composto por um grande número de linhas similares a essa, cada uma referente a um dos serviços suportados por ele (incluindo os serviços que não estão instalados). Ao descomentar a linha, você ativa o serviço. Para que a alteração entre em vigor, reinicie o inetd com o comando:

# /etc/init.d/inetd restart

Para o xinetd, a configuração é um pouco diferente. Em vez em um único arquivo de configuração, com uma linha para cada serviço, é utilizado um conjunto de arquivos de configuração (um para cada serviço) que são armazenados na pasta "/etc/xinetd.d". O primeiro passo para instalar o Swat no Ubuntu seria instalar os pacotes "swat" e "xinetd" usando o apt-get:

# apt-get install swat xinetd

Para ativar o Swat, é necessário criar o arquivo "/etc/xinetd.d/swat", com o seguinte conteúdo:

service swat {
port = 901
socket_type = stream
wait = no
user = root
server = /usr/sbin/swat log_on_failure += USERID
disable = no }

Depois de criado o arquivo, reinicie o serviço e o Swat ficará disponível.

# /etc/init.d/xinetd restart

Nas distribuições derivadas do Red Hat, o Swat também é inicializado através do xinetd, mas nelas a configuração pode ser feita de forma automática utilizando o chkconfig. Para ativá-lo, use os comandos:

# chkconfig swat on
# service xinetd restart

Em caso de problemas, abra o arquivo "/etc/xinetd.d/swat" e substitua a linha "disable = yes" (caso presente) por "disable = no" e reinicie novamente o serviço xinetd. No Fedora, você pode também reiniciar os serviços usando o utilitário "systemconfig-services", que funciona como uma interface gráfica para o comando "service". Como pode ver, devido às diferenças de configuração entre as distribuições e o uso do xinetd/inetd, ativar o Swat pode ser um pouco mais complicado do que ativar outros serviços, embora o Samba propriamente dito não dependa dele para fazer seu trabalho. Para acessar o Swat localmente, basta abrir o Firefox ou outro Browser disponível e acessar o endereço http://localhost:901. No prompt de login, forneça a senha de root (do sistema) para acessar. As credenciais do root são necessárias para que o Swat possa alterar os arquivos de configuração, reiniciar os serviços e outras operações que ficam disponíveis apenas para o root. No caso do Ubuntu, você pode definir a senha de root usando o comando "sudo passwd". Ao configurar um servidor remotamente, ou ao instalar o Samba/Swat em um servidor sem o ambiente gráfico instalado, você pode acessar o Swat remotamente, a partir de qualquer máquina da rede. Abra o navegador e acesse o endereço "http://ip-do-servidor:901", como em: http://192.168.1.1:901. Uma observação é que o Swat não utiliza encriptação, o que é uma temeridade do ponto de vista da segurança, já que alguém poderia capturar a senha sniffando a rede. Você pode evitar isso criando um túnel seguro usando o SSH e acessando o Swat através dele. Para isso, é preciso apenas que o SSH esteja ativo no servidor. Para criar o túnel, use o comando:

# ssh -f -N -L901:192.168.1.1:901 -l login 192.168.1.1

Onde o "192.168.1.1" é o endereço IP do servidor, o "901" é a porta do Swat e o "login" é a sua conta de usuário no servidor. Este comando cria um túnel encriptado entre a porta 901 do seu micro e a porta 901 do servidor, que permite acessar o Swat de forma segura. Com o túnel ativo, você acessa o Swat usando o endereço http://localhost:901, como se estivesse sentado na frente do servidor. O SSH se encarrega de transportar as informações de forma transparente entre os dois pontos, encriptando os dados e garantindo a segurança.

Opções Gerais do Swat

Ao abrir o Swat, você verá um menu como o do screenshot abaixo, com vários links para a documentação disponível sobre o Samba, que você pode consultar para se aprofundar no sistema. Na parte de cima, estão os links para as seções da configuração, que é o que nos interessa:

Na seção Password, você pode cadastrar usuários, substituindo o uso manual do comando "smbpasswd -a". Neste caso, você precisará primeiro cadastrar os usuários no sistema, utilizando o comando adduser. O Swat apenas cadastra os usuários no Samba:

Em seguida, acesse a seção "Globals", que engloba todas as configurações de rede e de acesso. A opção "netbios name" indica o nome do servidor, através do qual ele será identificado na rede Windows. Normalmente se utiliza o nome da máquina, mas isso não é obrigatório, já que o nome de máquina utilizado pelo Samba não está relacionado ao nome definido no arquivo "/etc/hosts" ou à configuração do DNS. O nome pode ter até 15 caracteres e ser composto por letras e números, além de espaços e dos caracteres a seguir: ! @ # $ % ^ & ( ) - ' { } ~. Ao usar mais do que 15 caracteres, os caracteres excedentes serão ignorados. É também permitido o uso de pontos, mas usá-los não é uma boa idéia, pois torna os nomes NetBIOS difíceis de diferenciar de nomes de domínio, o que pode confundir os usuários. A opção "workgroup" indica o grupo de trabalho ao qual o servidor pertence. Você pode tanto utilizar o mesmo grupo de trabalho em todas as máquinas da rede quanto agrupar suas máquinas em grupos distintos como "diretoria", "vendas", etc.

A seguir, temos a opção "interfaces", que permite limitar os acessos ao servidor caso ele possua mais de uma placa de rede. É o caso, por exemplo, de quem acessa via ADSL ou cabo e possui uma segunda placa de rede para compartilhar a conexão com os micros da rede local. Nesses casos, a placa da web será reconhecida como eth0, enquanto a placa da rede local será reconhecida como eth1, por exemplo. Você pode, então, preencher o campo com o endereço da placa de rede local (eth1). Assim, o Samba só aceitará conexões vindas dos micros da rede local, descartando automaticamente todas as tentativas de acesso vindas da Internet. Caso o campo permaneça vazio, o Samba permite acessos vindos de todas as placas de rede e passa a ser necessário bloquear os acessos provenientes da internet usando o firewall. Na seçãoSecurity Options temos a opção "security", uma opção capciosa que aceita os valores "user", "share", "server" e "domain". Com nomes tão descritivos a configuração fica fácil, já que "server" é para quando estamos configurando o Samba como servidor e "domain" é para quando ele está sendo configurado como controlador de domínio, certo? Errado! :) As opções share e server são opções obsoletas (como veremos em detalhes mais a seguir) e a opção "domain" é usada quando você deseja que o servidor Samba seja configurado como membro (cliente) de um domínio sob responsabilidade de outro servidor. Se você está configurando um servidor Samba, seja como um servidor de grupo de trabalho, seja como controlador de domínio, a opção correta para a opção security é a "user". Utilizando o modo user, as permissões de acesso aos compartilhamentos do samba ficam condicionadas às permissões de acesso de cada usuário. Por exemplo, se você compartilhar a pasta "/home/maria/arquivos", por default apenas a usuária "maria" terá permissão para gravar novos arquivos e alterar o conteúdo da pasta. Para que outros usuários tenham acesso à pasta, você deve dar permissão a eles, criando um novo grupo e dando permissão de escrita para os integrantes do mesmo. Outra opção é adicionar os demais usuários no grupo "maria" (cada usuário possui um grupo com o mesmo nome do login, criado no momento em que é cadastrado) e configurar as permissões de acesso de forma que o grupo possa escrever na pasta. Você pode fazer a administração de grupos usando o "users-admin", que facilita bastante as coisas ao trabalhar com um grande número de usuários. Lembre-se de que no Debian ele é instalado através do pacote "gnome-system-tools". No Fedora e no CentOS ele se chama "system-config-users":

Para criar um novo grupo, mude para a aba "Grupos" e use a opção "Adicionar Grupo", especificando o nome do novo grupo e os usuários que farão parte dele na janela seguinte:

O próximo passo é alterar as permissões de acesso da pasta, colocando o grupo cadastrado como dono da pasta e fazendo com que o grupo tenha permissão para ler e alterar os arquivos. A alteração dá poderes sobre a pasta a todos os usuários que foram cadastrados no grupo:

Se você não está tão preocupado com a segurança, pode fazer do jeito "fácil", alterando a opção "outros" nas permissões de acesso da pasta, que dá acesso a todo mundo. Isso faz com que qualquer usuário local do sistema (ou logado via SSH) tenha acesso aos arquivos da pasta, mas não permite necessariamente que outros usuários do Samba possam acessar, pois neste caso ainda são usadas as permissões de acesso no Samba. A alteração das permissões da pasta é feita usando o Konqueror ou outro gerenciador de arquivos e não através do Samba:

Ou seja, é necessário fazer com que os usuários do grupo, ou todos os usuários do sistema, possam escrever na pasta, evitando que as permissões do sistema conflitem com as permissões configuradas no Samba. Se configuro o Samba para permitir que o usuário "joao" possa escrever no compartilhamento, mas a configuração das permissões da pasta compartilhada não permitem isso, o joao vai continuar sem conseguir escrever. Ao criar compartilhamentos no Samba, é preciso se preocupar com as duas coisas. Mais abaixo, temos a opção Encrypt Password. Ela também é importe, e deve ficar sempre ativa (Encrypt Password = yes). Todas as versões do Windows, incluindo o 3.11 suportam o uso de senhas encriptadas, mas até o Windows 95 original os clientes deixavam de usar a encriptação e passavam a enviar as senhas em texto puro quando percebiam que o interlocutor não suportava encriptação. Entretanto, isso abria margem para todo tipo de ataques, de forma que a partir do Windows 95 OSR/2 e do Windows NT 4 SP3, senhas em texto puro deixaram de ser suportadas, de forma que ao desativar o uso de senhas encriptadas no Samba, o servidor simplesmente não conseguirá conversar com as máquinas Windows e você vai ficar quebrando a cabeça até se lembrar deste parágrafo. :) A partir do Samba 3, existe a opção de fazer com que o próprio Samba mantenha as senhas dos usuários sincronizadas em relação às senhas dos mesmos no sistema. Antigamente, sempre que você alterava a senha de um usuário no Samba, usando o "smbpasswd", precisava alterar também a senha do sistema, usando o comando "passwd". As duas senhas precisam ficar em sincronismo, do contrário caímos no problema das permissões, onde o Samba permite que o usuário acesse o compartilhamento, mas o sistema não permite que o Samba acesse os arquivos no disco. Para ativar este recurso, ative a opção "unix password sync" no Swat. Originalmente, esta opção fica desativada e aparece apenas dentro das opções avançadas. Para chegar até ela você deve clicar no botão "Change View To: Advanced" no topo da tela. Depois de alterar, clique no Commit Changes". Para que tudo funcione, é necessário que as opções "passwd program" e "passwd chat" estejam configuradas com (respectivamente) os valores: "/usr/bin/passwd %u" e "*EntersnewsUNIXspassword:* %nn *RetypesnewsUNIXspassword:* %nn .". Estes já são os valores padrão no Swat, mas não custa verificar:

A opção "Hosts Allow" deve incluir os endereços IP de todos os computadores que terão permissão para acessar o servidor. Se quiser que todos os micros da rede tenham acesso, basta escrever apenas a primeira parte do endereço IP, como em "192.168.0.", o que faz com que todos os endereços dentro do escopo sejam permitidos. Se for incluir mais de um endereço ou mais de um escopo de endereços, separe-os usando vírgula e espaço, como em: "192.168.0., 10.0.0., 123.73.45.167". Caso o campo permaneça vazio, a opção fica desativada e todos os micros que estiverem ligados em rede com servidor Samba poderão acessá-lo. A opção "Hosts Deny", por sua vez, permite especificar máquinas que não terão permissão para acessar o servidor. É importante notar que as opções "Hosts Allow" e "Hosts Deny" possuem algumas peculiaridades, sobretudo quando usadas em conjunto. Veremos mais detalhes sobre o uso das duas mais adiante. Continuando, em uma rede Windows, uma das máquinas fica sempre responsável por montar e atualizar uma lista dos compartilhamentos disponíveis e enviá-la aos demais, conforme solicitado. O host que executa esta função é chamado de "Master Browser". De uma forma geral, todas as versões do Windows são capazes de atuar como Master Browser da rede e o cargo pode mudar de dono conforme as máquinas vão sendo ligadas e desligadas, mas o Samba executa o trabalho de forma muito eficiente, de forma que, a menos que você tenha outro servidor em posição hierarquicamente superior, é sempre interessante delegar esta tarefa ao servidor Samba. O cargo de Master Browser é disputado através de uma eleição, onde os micros da rede enviam pacotes de broadcast contendo informações sobre o sistema operacional usado, o tempo de uptime e outras informações. Ao receber o pacote de broadcast de um "oponente", cada máquina compara suas credenciais com as do pacote recebido. Se suas credenciais forem inferiores, ela desiste da eleição, caso contrário responde enviando o pacote com suas próprias credencias. Este processo de eliminação continua até que sobre apenas uma máquina, que passa então a ser o Master Browser da rede (até que seja desconectada da rede, ou perca o cargo para outra máquina com credenciais superiores). A principal credencial é o "OS Level", que nas máquinas Windows varia de acordo com a versão do sistema. As máquinas com o Windows NT Server, 2000 Server, 2003 Server ou 2008 Server possuem um Os Level de 32, as com o Windows NT Workstation, 2000 Professional ou qualquer versão doméstica do XP ou Vista possuem OS Level de 16 e as versões antigas do Windows (3.11, 95, 98 e ME) possuem OS Level de apenas 1. Nos servidores Samba o valor é ajustado através da opção "OS Level", na seção Browse Options. Isso permite que você "trapaceie", fazendo com que o servidor Samba sempre ganhe as eleições. Para isso, configure esta opção com um valor alto, 100 por exemplo, para que ele sempre ganhe as eleições (você pode usar qualquer valor entre 0 e 255). O default dessa opção é 20, o que faz com que o servidor Samba ganhe de todas as máquinas Windows, com exceção das versões Server. Para completar, deixe a opção "Local Master" e "Preferred Master" como "Yes". A opção "Local Master" faz com que o servidor Samba convoque uma nova eleição sempre que necessário (de forma a defender o cargo caso outra máquina tente assumir a posição) e a "Preferred Master" dá a ele uma leve vantagem quando confrontado com outra máquina com o mesmo OS Level:

É importante enfatizar que você nunca deve colocar dois servidores Samba na rede com o mesmo OS Level e com a opção "Preferred Master" ativada, caso contrário eles iniciarão uma disputa interminável pelo cargo, o que fará com que a navegação na rede se torne intermitente. Ao usar vários servidores Samba na rede, crie uma hierarquia, usando valores diferentes para a opção OS Level. Se, por outro lado, você não desejar que o servidor Samba participe das eleições (caso já tenha outro servidor desempenhando este papel), basta definir a opção "Local Master" com o valor "no". Logo abaixo, deixe a opção WINS Support ativada (Yes) para que o servidor Samba atue como um servidor WINS para os demais micros da rede. A opção WINS Serverdeve ser deixada em branco, a menos que exista na rede algum servidor Wins (rodando uma das versões Server do Windows) ao qual o servidor Linux esteja subordinado. Caso o único servidor seja a máquina Linux, você pode configurar as máquinas Windows para utilizá-la como servidor Wins. Para isto basta colocar o seu endereço IP no campo "Servidor Wins" na configuração de rede das estações (veja mais detalhes a seguir). Terminado, pressione o botão "Commit Changes" no topo da tela para que as alterações sejam salvas no arquivo "/etc/samba/smb.conf". Uma observação importante é que o Swat lê o arquivo smb.conf ao ser aberto, lendo as opções configuradas e mostrando-as na interface, mas gera um novo arquivo sempre que você clica no "Commit Changes". Ao ler o arquivo, ele procura por trechos específicos de texto, ignorando tudo que for diferente. Isso faz com que ele remova qualquer tipo de comentário incluído manualmente no arquivo. Em geral, quem tem o hábito de editar manualmente o smb.conf, acaba nunca usando o Swat e vive-versa.

Criando Compartilhamentos

Depois de cadastrar os usuários no sistema e no Samba e configurar a seção Globals, falta apenas configurar as pastas que serão compartilhadas com as estações, através da seção "Shares". Cada usuário válido (ou seja, os usuários "reais", que podem fazer login, e não os usuários limitados, criados usando o "adduser -M") cadastrado no sistema possui automaticamente um diretório home. Estas pastas ficam dentro do diretório /home e podem ser usadas para guardar arquivos pessoais, já que, a menos que seja estabelecido o contrário, um usuário não terá acesso à pasta pessoal do outro. Além dos diretórios home, você pode compartilhar mais pastas de uso geral. Para criar um compartilhamento, basta escrever seu nome no campo no topo da tela e clicar no botão "Create Share".

Depois de criado um compartilhamento, escolha-o na lista e clique no botão "Choose Share" para configurá-lo. Você verá uma lista de opções, contendo campos para especificar usuários válidos e inválidos, usuários que podem ou não escrever no compartilhamento, nomes ou endereços de máquinas, entre outras opções.

O campo "path" é o mais importante, pois indica justamente qual pasta do sistema será compartilhada. O nome do compartilhamento diz apenas com que nome ele aparecerá no ambiente de rede, que não precisa necessariamente ser o mesmo nome da pasta. A opção "comment" permite que você escreva um breve comentário sobre a pasta que também poderá ser visualizado pelos usuários no ambiente de rede. Este comentário é apenas para orientação, não tem efeito algum sobre o compartilhamento. A opção "read only" determina se a pasta ficará disponível apenas para leitura (opção Yes) ou se os usuários poderão também gravar arquivos (opção No). Você pode também determinar quais máquinas terão acesso ao compartilhamento através das opções "Hosts Allow" e "Hosts Deny". Note que as configurações das opções "Hosts Allow" e "Hosts Deny" incluídas na seção global possuem precedência sobre as colocadas dentro da configuração dos compartilhamentos, por isso (salvo poucas exceções), elas não são usadas em conjunto. Ao bloquear um host através da seção Global, ele perde o acesso a todos os compartilhamentos do servidor, mesmo que a configuração de um compartilhamento específico diga o contrário. Continuando, a opção "browseable" permite configurar se o compartilhamento aparecerá entre os outros compartilhamentos do servidor no ambiente de rede, ou se será um compartilhamento oculto, que poderá ser acessado apenas por quem souber que ele existe. Isso tem uma função semelhante a colocar um "$" em uma pasta compartilhada no Windows. Ela fica compartilhada, mas não aparece no ambiente de rede. Apenas usuários que saibam que o compartilhamento existe conseguirão acessá-lo. Esta opção tem efeito apenas sobre os clientes Windows, pois no Linux a maior parte dos programas clientes (como o Smb4k) mostram os compartilhamentos ocultos por padrão. Finalmente, a opção "available" especifica se o compartilhamento está ativo ou não. Você pode desativar temporariamente um compartilhamento configurando esta opção como "No". Fazendo isso, ele continuará no sistema e você poderá torná-lo disponível quando quiser, alterando a opção para "Yes". Terminadas as configurações, reinicie o serviço do Samba e o servidor irá aparecer imediatamente no ambiente de rede, como se fosse um servidor Windows. Os compartilhamentos podem ser acessados de acordo com as permissões que tiverem sido configuradas, mapeados como unidades de rede, entre outros recursos. Para compartilhar uma impressora já instalada na máquina Linux, o procedimento é o mesmo. Dentro do Swat, acesse a seção printers, escolha a impressora a ser compartilhada (a lista mostrará todas as instaladas no sistema), configure a opção available como "yes" e ajuste as permissões de acesso, como vimos anteriormente. No Mandriva, você pode instalar impressoras através do Control Center. No Fedora está disponível o "system-config-printer", que contém basicamente as mesmas funções. Em outras distribuições, você pode usar o kaddprinterwizard ou a própria interface de administração do Cups, que você acessa (via navegador) através da URL:

http://127.0.01:631

Dicas e configurações adicionais do Samba

2013-05-22T09:57:00.003-07:00

A configuração do Samba que vimos até aqui é voltada para a configuração de servidores de arquivos. Como você viu, é possível gerar rapidamente tanto configurações básicas, que fazem com que o Samba simplesmente compartilhe algumas pastas, sem muita segurança, quanto configurações muito mais complexas, com o uso de um PDC, perfis móveis e tudo mais. Entretanto, imagine que você precisa permitir que os usuários também criem compartilhamentos em suas estações de trabalho Linux, assim como no Windows. Não seria muito prático ter que ensiná-los a usar o Swat ou a editarem manualmente o arquivo smb.conf. Precisaríamos de algum sistema mais simples para a criação dos compartilhamentos. O KDE possui um módulo que resolve este último problema, permitindo que os usuários compartilhem arquivos dentro dos seus respectivos diretórios de usuário de uma forma bastante simples, algo parecido com o que temos no Windows. Para que este recurso funcione, você deve instalar o módulo de compartilhamento de arquivos do Konqueror. No Debian, ele é fornecido pelo pacote "kdenetwork-filesharing", que pode ser instalado pelo apt-get, juntamente com o servidor Samba: # apt-get install kdenetwork-filesharing samba Em outras distribuições, ele é incluído diretamente no pacote "kdenetwork", que faz parte da instalação básica do KDE. Nesses casos, o módulo já vem ativado e você precisa instalar apenas o pacote do servidor Samba. Como os usuários podem apenas compartilhar seus próprios arquivos, a possibilidade de danos ao sistema é pequena. Se você tiver um firewall isolando a sua rede local da internet, você poderá conviver com isso sem muitos sustos. :) Dentro do "Centro de Controle do KDE" (em cada estação), acesse a seção "Internet & Rede > Compartilhamento de arquivos". Clique no "Modo administrador", forneça a senha de root e marque a opção "Compartilhamento simples (habilite o compartilhamento simples, para permitir que os usuários compartilhem pastas de sua pasta pessoal (home), sem saberem a senha de root.)". No botão "Usuários permitidos" você tem a opção de autorizar todos os usuários (permitir a todos os usuários compartilhar pastas) ou autorizar apenas os usuários de um determinado grupo. Neste caso, use o "users-admin" ou outro programa de configuração de usuários e grupos para criar um novo grupo e adicionar os usuários desejados a ele:

A partir daí os usuários poderão compartilhar pastas simplesmente acessando a aba "Compartilhar" dentro das propriedades de cada uma e ativando a opção "Compartilhado":

Este compartilhamento do KDE faz, na verdade, um duplo compartilhamento. Além do Samba, os compartilhamentos ficam disponíveis na rede através do NFS, permitindo que você possa escolher qual protocolo prefere usar em cada caso. Lembre-se de que, se você não quiser o compartilhamento via NFS, basta desativar (ou desinstalar) o serviço "nfs-kernel-server" (ou "nfs", nas distribuições derivadas do Red Hat). Naturalmente, para que o compartilhamento funcione, você deverá ter o servidor e o cliente Samba instalados no sistema e manter o serviço SMB ativo.

Montagem permanente dos compartilhamentos

A forma mais prática de acessar os compartilhamentos do Samba em clientes Linux é utilizar clientes gráficos como o Smb4K (do KDE) e o módulo de acesso a compartilhamentos do Nautilus (disponível no menu "Locais > Rede"):

Apesar disso, o Samba possui também um cliente de modo texto, o smbclient, usado via terminal. É possível também montar os compartilhamentos diretamente, funcionalidade que equivale à opção "mapear unidade de rede" disponível nos clientes Windows. Para que os compartilhamentos sejam montados durante o boot, é necessário adicionar as entradas apropriadas no arquivo "/etc/fstab". Dessa forma, os compartilhamentos são montados automaticamente durante o boot e ficam acessíveis de forma permanente nas pastas especificadas por você. Esta é uma opção interessante em muitos ambientes, já que é mais fácil para os usuários simplesmente acessarem os arquivos através de uma pasta, do que terem que montar o compartilhamento usando o Smb4K ou o Nautilus. O primeiro passo é aprender a sintaxe da montagem dos compartilhamentos via linha de comando, já que as entradas do fstab utilizam os mesmos argumentos. Começando do básico, você pode listar os compartilhamentos disponíveis em um servidor da rede usando o comando:

$ smbclient -L 192.168.1.254 -U gdh

Veja que o comando especifica o endereço do servidor (você pode usar também o nome na rede Windows) e a conta de usuário que será usado para abrir a conexão. Depois de fornecer a senha, você obtém uma lista dos compartilhamentos disponíveis, como em:

E230 Printer print$
Disk Drivers de impressao para os clientes Windows
arquivos Disk
projetos Disk
backup Disk IPC$ IPC IPC Service (Samba PDC)

O exemplo mais simples para montar um dos compartilhamentos via linha de comando seria:

# mount -t smbfs //servidor/arquivos /mnt/smb

Aqui, estou montando o compartilhamento "arquivos" na pasta "/mnt/smb" (que deve ser previamente criada usando o comando mkdir). O "servidor" pode tanto ser o nome da máquina, dentro da rede Windows, quanto seu endereço IP. Como em outros comandos de montagem, você precisa executar o comando como root. O comando mount é um dos comandos mais tradicionais do Linux, que permite "mapear" um diretório qualquer dentro de outro diretório do sistema. A opção "-t" serve para especificar o sistema de arquivos, neste caso o "smbfs", usado para acessar compartilhamentos Windows. Note que a localização do compartilhamento é fornecida numa sintaxe muito similar à que usaríamos para mapear um compartilhamento no Windows, com a sintaxe "barra barra servidor barra compartilhamento". A única diferença é que aqui usamos barras "normais" ao invés de barras invertidas. Só para efeito de comparação, ao mapear o mesmo compartilhamento em uma máquina Windows, teríamos:

O problema com o comando anterior é que ele só funciona realmente ao montar compartilhamentos do Windows 95, 98 e ME, que não possuem senhas. No Windows 2000, XP e Vista (com exceção das estações com o simple sharing ativado), sem falar dos próprios servidores Linux rodando o Samba, você vai receber uma mensagem de acesso negado, já que neles você precisa se autenticar para obter acesso aos compartilhamentos. Para isso, é necessário incluir a opção "-o username=usuario" (tudo junto, sem espaços), especificando o login que será usado, como em:

# mount -t smbfs //servidor/arquivos /mnt/smb -o username=gdh

É possível também especificar a senha diretamente no comando, o que permite usá-lo em scripts:

# mount -t smbfs //servidor/arquivos /mnt/smb -o username=gdh,password=1234

Se, ao executar o comando, você receber um erro similar a: mount: tipo de sistema de arquivos incorreto, opção inválida, superbloco inválido em //servidor/arquivos, faltando página de código ou outro erro Em alguns casos informações úteis são encontradas no syslog - tente "dmesg | tail" ou algo do tipo Significa que o cliente Samba e/ou o suporte ao sistema de arquivos smbfs não está instalado na estação. Nesse caso, instale o pacote "smbfs" usando o gerenciador de pacotes, como em:

# apt-get install smbfs

Este problema é muito reportado por usuários do Ubuntu, já que o pacote não vinha instalado por padrão no Edgy, no Feisty e no Gutsy. Continuando, depois de montado o compartilhamento, os arquivos podem ser acessados normalmente, usando o Konqueror, Nautilus ou outro gerenciador de arquivos. É muito similar ao acessar um compartilhamento mapeado no Windows, a principal diferença é que você define uma pasta onde ele será montado, ao invés de acessá-lo através de uma letra, como "E:" ou "Z:". Uma peculiaridade do mount é que os arquivos dentro da pasta montada passarão por padrão a ser propriedade do root. Isso não altera as permissões de acesso dos arquivos no servidor (a mudança é apenas local), mas impede que seu login de usuário consiga alterar os arquivos, mesmo que as permissões de acesso do Samba digam o contrário. Para evitar isso é necessário adicionar a opção "uid=", especificando o login de usuário (na máquina local) correto, como em:

# mount -t smbfs //servidor/arquivos /mnt/smb -o username=gdh,password=1234,uid=gdh

A opção "uid=" é interpretada localmente. O login especificado não é repassado ao servidor Samba, de forma que você pode usar qualquer conta de usuário local. Ele serve apenas para corrigir as permissões de acesso, de forma que você possa alterar os arquivos normalmente usando seu login de usuário. O passo seguinte é tornar a montagem permanente, já que usando o comando mount ela é perdida ao reiniciar o micro. Para isso, inserimos uma nova linha no final do arquivo "/etc/fstab". A ordem dos parâmetros fica um pouco diferente, mas você notará que os argumentos continuam os mesmos que usamos no comando anterior:

//servidor/arquivos /mnt/smb smbfs username=gdh,password=1234,uid=gdh 0 0

Caso necessário, você pode também indicar o grupo, junto com o usuário local, usando a opção "gid=", como em:

//servidor/arquivos /mnt/smb smbfs username=gdh,password=1234,uid=gdh,gid=users 0 0

O fstab é um dos principais arquivos de configuração do sistema, por isso é sempre importante ter cuidado ao editá-lo. Apenas adicione a nova linha, sem alterar as anteriores e lembre-se sempre de deixar uma linha em branco no final do arquivo. Um parâmetro útil que pode ser incluído é a opção "users", que permite que você consiga montar e desmontar o compartilhamento usando seu login de usuário, sem precisar usar a conta de root. Para isso, adicione o parâmetro "user", antes do "username=" (sem espaços), como em:

//servidor/arquivos /mnt/smb smbfs users,username=gdh,password=1234,uid=gdh 0 0

A montagem e desmontagem neste caso é feita indicando apenas o diretório, como em "umount /mnt/smb" e "mount /mnt/smb". A principal observação é que o smbmnt (o comando responsável pela montagem) só aceita fazer a montagem em uma pasta de propriedade do usuário, por isso é necessário ajustar as permissões da pasta usando o comando chown, como em:

# chown gdh:gdh /mnt/smb

O "0 0" incluído sempre no final da linha é um parâmetro passado ao sistema, que diz que ele não deve verificar o sistema de arquivos usando o fsck durante a inicialização, já que aqui estamos montando um compartilhamento de rede e não uma partição. Embora não seja muito recomendável do ponto de vista da segurança, também é possível escancarar as permissões, fazendo com que qualquer usuário logado no cliente Linux tenha acesso completo a todos os arquivos. Para isso, você usaria o parâmetro "smbpasswd,fmask=777,dmask=777", como em:

//servidor/arquivos /mnt/smb smbfs users,username=gdh,password=1234
smbpasswd,fmask=777,dmask=777 0 0
(tudo em uma única linha)

Como estamos adicionando as senhas dos compartilhamentos dentro do arquivo, também é fortemente recomendável manter as permissões de leitura do arquivo em "600", de forma que apenas o root tenha permissão para ver seu conteúdo. Para isso, use o comando:

# chmod 600 /etc/fstab

É possível montar diversos compartilhamentos, adicionando uma linha para cada um. Não existe limitação para o número máximo de compartilhamentos que podem ser adicionados, mas você deve ter cuidado de adicionar apenas compartilhamentos de servidores que ficam ligados continuamente. Se o servidor estiver desligado durante o boot da estação, o boot do cliente vai demorar muito mais que o normal e o usuário verá o erro relacionado à montagem do compartilhamento, o que não é muito elegante, nem muito bom para sua reputação como administrador. :) Nos exemplos anteriores, especificamos as senhas de montagem dos compartilhamentos diretamente no arquivo "/etc/fstab". Mesmo protegendo o arquivo com o "chmod 600", muita gente afirma que isso é um problema grave de segurança, já que alguém que conseguisse obter acesso ao arquivo, obteria automaticamente as senhas dos compartilhamentos. Uma opção é usar um arquivo externo para armazenar as senhas. Ele pode ser armazenado tanto dentro do diretório /home/root, quanto dentro do home do usuário do sistema que tem acesso ao compartilhamento. Você pode também usar diversos arquivos de senha, um para cada compartilhamento que precisa ser montado. Para criar os arquivos de senha, use os três comandos abaixo, ainda como root:

# echo "username=gdh" > /home/gdh/.smbpasswd
# echo "password=1234" >> /home/gdh/.smbpasswd
# chmod 600 /home/gdh/.smbpasswd

Usado desta forma, o comando echo permite criar arquivos de texto e adicionar novas linhas. O primeiro comando cria o arquivo, adicionando a linha com o nome do usuário, enquanto o segundo adiciona a linha com a senha. Se por acaso o arquivo já existir, ele é subescrito. Como o arquivo foi criado pelo root, o comando "chmod 600" usado no final faz com que, mesmo colocado dentro do home do usuário "joao", apenas o root tenha acesso ao arquivo, evitando acidentes. Você pode também criar o arquivo usando um editor de textos qualquer e ajustar as permissões manualmente. Neste caso, bastaria adicionar as duas linhas:

username=gdh
password=1234

Com o arquivo criado, você pode modificar a(s) linha(s) no fstab, especificando a localização do arquivo, ao invés de colocar o usuário e senha diretamente, como em:

//servidor/arquivos /mnt/smb smbfs users,credentials=/home/gdh/.smbpasswd 0 0

ou:

//servidor/arquivos /mnt/smb smbfs users,credentials=/home/gdh/.smbpasswd smbpasswd,uid=gdh,gid=gdh 0 0
(tudo em uma única linha)

Ao montar vários compartilhamentos, que são acessados usando o mesmo login e senha, você pode especificar o mesmo arquivo em todas as linhas, mas, no caso de diversos compartilhamentos, montados usando credenciais diferentes, você deve criar arquivos separados para cada um e especificar o arquivo correto dentro da linha de montagem de cada compartilhamento. Você pode criar quantos arquivos de senha diferentes quiser, mas cada arquivo deve conter um único usuário e senha. Concluindo, uma limitação importante do smbfs é que ele suporta, por default, transferências de arquivos de no máximo 2 GB. O sintoma do problema é que as transferências começam normalmente, mas param ao chegar aos 2 GB, com um erro "file size limit exceeded" ou outra mensagem de erro qualquer, gerada quando o gerenciador de arquivos não consegue concluir a transferência:

Esta na verdade não é uma limitação do Samba, mas sim do protocolo SMB, que é usado por default pelo smbfs. A solução para o problema é adicionar a opção "lfs" (a sigla é abreviação de "large file support" e, como o nome sugere, ativa o suporte a arquivos de mais de 2 GB, que está disponível no protocolo CIFS) no comando de montagem, ou entre as opções especificadas na linha do fstab. como em:

# mount -t smbfs //servidor/arquivos /mnt/smb -o lfs,username=gdh,password=1234,uid=gdh

ou:

//servidor/arquivos /mnt/smb smbfs lfs,users,username=gdh,password=1234 smbpasswd,fmask=777,dmask=777 0 0
(tudo em uma única linha)

É importante notar que a opção lfs elimina qualquer limitação com relação ao tamanho dos arquivos por parte do Samba, mas você ainda poderá ter problemas ao copiar arquivos grandes para máquinas com HDs formatados em FAT32, sistema que suporta arquivos de no máximo 4 GB. A solução nesses casos é (no caso das máquinas Windows) converter as partições para NTFS. No caso das máquinas Linux, não existem restrições, já que o EXT3 suporta arquivos de até 2 TB.

Portas e firewall

O Samba é um servidor destinado a ser usado dentro da rede local, ou da intranet. É muito difícil imaginar uma situação em que você gostaria de disponibilizar um servidor Samba na internet. É relativamente comum encontrarmos máquinas ou mesmo servidores Windows onde o compartilhamento de arquivos e impressoras está disponível para o mundo devido a algum descuido do dono, mas é quase impossível encontrar alguém que o faça intencionalmente. Existem muitas formas de impedir que o servidor Samba fique disponível na internet. Em um servidor com duas placas de rede, a mais simples é configurar o firewall para bloquear todas as conexões provenientes da placa ligada à internet e/ou adicionar a linha "interfaces = eth1" (onde a "eth1" é a placa da rede local) na seção [global] do smb.conf, o que faz com que o Samba passe a escutar apenas na interface especificada. Mais uma opção que pode ser usada é a "hosts allow", que permite que você especifique uma faixa de endereços a partir da qual o servidor vai aceitar requisições. Limitando o acesso à faixa de endereços da rede local, você garante que ele não vai ser acessado por hosts da internet. Nesse caso, você adicionaria a linha "hosts allow = 192.168.0." (onde o 192.168.0. é a faixa de endereços da rede local) na seção [global]. Você pode inclusive combinar as três coisas (o firewall e as duas regras restritivas), afinal, segurança nunca é demais. No caso da rede local, o firewall nem sempre é necessário, já que em pequenas redes você normalmente conhece os usuários. Em redes maiores, entretanto, o cenário é mais "cada um por sí" e uma configuração mais cuidadosa torna-se necessária. O ideal é ativar o firewall e manter abertas apenas as portas dos serviços intencionalmente disponibilizados, minimizando a chance de alguém obter acesso ao servidor através de algum serviço que você não sabia que estava ativo. As portas usadas pelo Samba, que precisam ficar abertas na configuração do Firewall são:

137/udp: Usada pelo Daemon nmbd, responsável pela navegação nos compartilhamentos de rede.
138/udp: Também usada pelo nmbd, dessa vez para a resolução dos nomes das máquinas da rede.
139/tcp: Usada pelo daemon smbd, o componente principal do Samba, responsável pelo compartilhamento de arquivos e impressoras.
445/tcp: Esta porta é usada pelos clientes Windows 2000, XP e Vista para navegação na rede. Eles utilizam o protocolo CIFS, no lugar do antigo protocolo NetBIOS.

Um exemplo de regras do Iptables que você poderia incluir no seu script de firewall para mantê-las abertas é:

iptables -A INPUT -p udp --dport 137 -j ACCEPT
iptables -A INPUT -p udp --dport 138 -j ACCEPT
iptables -A INPUT -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -p tcp --dport 445 -j ACCEPT

Mantendo o horário sincronizado

Ao compartilhar arquivos na rede, manter os relógios das máquinas sincronizados passa a ser uma necessidade, afinal, se cada máquina está usando um horário diferente, fica impossível acompanhar as datas de modificações dos arquivos. Achar a versão mais recente de um determinado arquivo torna-se uma tarefa impossível e o trabalho de ferramentas diversas de backup fica prejudicado, sem falar nos logs do sistema e outros recursos que dependem do horário. Felizmente, é muito simples manter os horários das máquinas sincronizados, graças a vários servidores NTP públicos, disponíveis pelo mundo. Os servidores principais, chamados de stratum 1, sincronizam seus relógios a partir de relógios atômicos ou um sistema de GPS e, por isso, são extremamente precisos. A seguir, temos os servidores stratum 2, servidores menores sincronizados a partir dos primeiros. Você pode sincronizar o relógio da sua máquina rapidamente usando o comando "ntpdate -u", seguido pelo servidor desejado. O comando faz parte do pacote "ntp" ou "ntpd", instalado por padrão na maioria das distribuições. A opção "-u" faz com que seja usada uma porta alta, necessário se você acessa usando uma conexão compartilhada ou tem um firewall ativo. Para facilitar as coisas, existe o servidor "pool.ntp.org", que serve como um load balancer, encaminhando as requisições para um servidor geograficamente próximo de você. Ao invés de ficar caçando servidores públicos no Google, você pode sincronizar diretamente a partir dele:

# ntpdate -u pool.ntp.org

Sep 14:12:29 ntpdate[20592]: step time server 128.208.109.7 offset -9.091791 sec

O Linux utiliza um sistema relativamente complexo para manter o horário do sistema. Em vez de simplesmente confiar no horário informado pelo relógio da placa mãe, ele utiliza um sistema mais elaborado, baseado no clock da placa mãe para calcular a passagem do tempo. Sempre que o sistema é desligado corretamente, diferenças no horário do sistema e no horário informado pelo relógio da placa mãe são salvas em um arquivo, de forma que possam ser recuperadas na hora do boot. Em geral, este sistema é bem mais preciso e permite que o horário mantenha-se correto (desde que o micro não seja desligado) mesmo nos casos em que a bateria do setup está fraca e o relógio da placa-mãe está atrasando. No entanto, existem casos onde o sistema calcula o clock de forma incorreta, fazendo com que o relógio comece a adiantar ou atrasar, mesmo que o relógio da placa-mãe esteja indicando o horário corretamente. A solução, nestes casos, é rodar o comando ntpdate periodicamente, de forma que o horário seja sempre corrigido antes que as diferenças se acumulem. Neste caso, a melhor solução é fazer com que o cron execute o comando de hora em hora. O jeito mais simples de fazer isso é criar um pequeno script dentro da pasta "/etc/cron.hourly/", cujo conteúdo é executado de hora em hora pelo cron. Crie o arquivo "/etc/cron.hourly/ntpdate", contendo as duas linhas a seguir:

#!/bin/sh
ntpdate -u pool.ntp.org

Em seguida, transforme-o em executável:

# chmod +x /etc/cron.hourly/ntpdate

O cron detecta mudanças nos arquivos automaticamente, mas, se preferir, você pode forçar a atualização usando o comando:

# /etc/init.d/cron restart

Um número cada vez maior de distribuições oferecem a opção de manter o horário sincronizado automaticamente em relação a um servidor NTP durante a instalação, o que torna desnecessário usar o ntpdate manualmente. Os servidores NTP atendem clientes de todo o mundo, independentemente do fuso horário, pois são configurados para utilizar um horário comum, o UTC (Universal Time Zone). Os clientes ajustam o horário de acordo com o fuso horário local, adicionando ou subtraindo algumas horas do horário UTC. Naturalmente, para que isso funcione, é necessário que o fuso horário esteja configurado corretamente. A maioria das distribuições ajusta isso logo durante a instalação, mas você pode configurar o fuso horário do sistema através de vários utilitários, como o "tzconfig" ou o configurador do KDE (kcmshell clock), que aparece ao clicar com o botão direito sobre o relógio e acessar a opção "Mudar data e hora". O NTP é suportado também pelos clientes Windows. No Windows XP, a opção de usar o NTP está disponível no "Painel de Controle > Data e hora > Horário da Internet". Por padrão, é usado um servidor da Microsoft, mas você pode alterar a configuração usando o pool.ntp.org, ou qualquer outro servidor de sua preferência, incluindo um servidor disponível na sua rede local (veja a seguir).

A coisa fica um pouco mais complicada no caso do Windows 2000, Windows 98 e outras versões antigas do Windows, que não suportam o NTP nativamente. No caso deles, você precisa utilizar um cliente NTP avulso. Você pode baixar as versões oficiais no: http://ntp.isc.org/bin/view/Main/ExternalTimeRelatedLinks O protocolo NTP leva em conta o ping entre as máquinas e outros fatores para fazer as atualizações de forma extremamente precisa. Diferenças de sincronismo entre os servidores são sempre da ordem de poucos milésimos de segundo. Apesar disso, muitos administradores preferem configurar servidores NTP locais. A principal vantagem é que configurando as estações para sincronizarem o horário em relação a um servidor local, você garante que todas manterão exatamente o mesmo horário e que a sincronização continuará funcionando mesmo que o link com a Internet caia. Um servidor local também é a melhor opção em casos onde os demais micros da rede não possuem acesso à internet. O primeiro passo é instalar o pacote com o servidor NTP que, de acordo com a distribuição usada, pode se chamar "ntp", "ntpd" ou "ntp-server". Nas distribuições derivadas do Debian, você instalaria diretamente pelo apt-get:

# apt-get install ntp

A configuração vai no arquivo "/etc/ntp.conf". Normalmente, o arquivo padrão é funcional, mas permite apenas conexões a partir do localhost. Para permitir que os demais micros da rede local sincronizem o horário a partir do servidor, você deve adicionar a linha abaixo no final do arquivo:

restrict 192.168.1.0 mask 255.255.255.0 nomodify

O "nomodify" faz com que os micros da rede local tenham acesso apenas de leitura ao horário do servidor, sem poder alterá-lo (o que é o comportamento desejável). Não se esqueça de alterar a faixa de endereços e a máscara de acordo com a usada na sua rede local. Um exemplo de arquivo de configuração simplificado (mas funcional) é:

driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
server 0.pool.ntp.org iburst
server pool.ntp.org iburst
restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0 nomodify

As duas linhas "server" indicam os endereços a partir dos quais o servidor irá sincronizar seu horário e as duas linhas "restrict" fazem com que o servidor NTP fique acessível apenas a partir do localhost e dos micros da rede local. Ao alterar o arquivo, você deve reiniciar o servidor NTP, usando o comando:

# /etc/init.d/ntp restart
(ou /etc/init.d/ntpd restart)

Se quiser ter certeza de que o serviço está funcionando, você pode usar o comando "ntpdc -p", que mostra o status atual do servidor NTP e a lista dos servidores em relação aos quais ele está sincronizando. É normal que o servidor demore alguns minutos para começar a responder depois de reiniciado o serviço. A partir daí, você pode configurar os micros da rede local para sincronizarem o horário em relação ao endereço IP do seu servidor NTP local, como no screenshot do cliente Windows que vimos a pouco. O servidor passa, então, a sincronizar o horário em relação aos servidores da Internet especificados no arquivo e os clientes da rede local passam a sincronizar o horário em relação a ele. Ao usar um firewall no servidor, certifique-se de que a porta 123/UDP usada pelo NTP está aberta (o NTP usa apenas UDP). É necessário que ela fique aberta tanto para a rede local, quanto para a internet, já que o servidor precisa sincronizar o horário em relação aos servidores externos. Caso necessário, você pode acrescentar uma regra como esta no seu script de firewall, de forma a manter a porta aberta:

iptables -A INPUT -p udp --dport 123 -j ACCEPT

Fonte: http://www.mktecnologia.net.br

Compartilhando impressoras no Samba

2013-05-22T08:59:00.002-07:00

O Samba oferece suporte aos mais diferentes sistemas de impressão, incluindo o BSD, SYSV, AIX, HPUX, QNX, PLP e LPRNG. Antigamente, criar um simples compartilhamento de impressora no Samba era uma tarefa espinhosa, já que você precisava verificar qual era o sistema de impressão usado na instalação do sistema e especificar os comandos de impressão manualmente na configuração do Samba, adicionado opções como estas na seção [global], ou na seção referente a cada compartilhamento:

printing = bsd
print command = /usr/bin/lpr -P%p %s; /bin/rm %s
lpq command = /usr/bin/lpq -P%p
lprm command = /usr/bin/lprm -P%p %j
queue pause command = /usr/sbin/lpc stop %p
queue resume command = /usr/sbin/lpc start %p

Com a popularização do Cups, tudo se tornou muito mais simples, pois você precisa apenas adicionar as opções "printing = cups" e "load printers = yes" na seção [global] do smb.conf e nada mais:

printing = cups
load printers = yes

Na verdade, nas versões recentes do Samba estas linhas nem mesmo são obrigatórias, pois o Cups já é o sistema de impressão usado por padrão e as impressoras disponíveis são carregadas por padrão quando o Samba encontra uma configuração válida no arquivo smb.conf.

De qualquer forma, se você está usando alguma distribuição antiga, pode checar se a versão do Samba instalada inclui suporte ao Cups usando o comando "smbd -b", como em:

# smbd -b | grep CUPS

Ele deve responder: HAVE_CUPS Continuando, o primeiro passo para compartilhar a impressora é instalá-la no servidor, o que pode ser feito da forma tradicional, utilizando utilitários como o kaddprinterwizard (usado nas distribuições com o KDE) o gnome-cups-add (o utilitário equivalente no Gnome) ou o system-config-printer (usado no Fedora e no CentOS) o que, desde que a impressora seja bem suportada pelo sistema, é bastante simples nas distribuições atuais:

Configurando a impressora pelo gnome-cups-add Estas ferramentas de configuração estão fortemente atreladas às bibliotecas do KDE e do Gnome, de forma que elas não estarão disponíveis se você fizer uma instalação enxuta do sistema no servidor, sem instalar os ambientes gráficos. Naturalmente, os desenvolvedores do Cups pensaram nessa possibilidade e adicionaram uma interface de administração via web, similar ao Swat, que pode ser usada até mesmo no caso de servidores sem interface gráfica, que você acessa remotamente:

A interface de administração do Cups

A interface de administração fica acessível através da porta 631 (TCP) do servidor e pode ser acessada através do navegador, tanto localmente (através do endereço http://127.0.0.1:631) quanto remotamente (através do http://servidor:631). O grande problema é que você só tem acesso às opções administrativas (como adicionar ou remover impressoras) ao acessar a interface usando um navegador rodando no servidor, o que é um problema quando você está configurando o servidor remotamente. É possível alterar as permissões de acesso, de forma a liberar o acesso para o endereço IP do seu micro de forma simples editando o arquivo de configuração do Cups, o "/etc/cups/cupsd.conf". Procure a seção referente à pasta "/admin" (onde estão concentradas as opções administrativas) e adicione uma linha autorizando o endereço IP da sua máquina logo depois do "Allow localhost", como em:

<Location /admin>
Order allow,deny
Allow localhost Allow 192.168.1.10
</Location>

Depois da alteração, reinicie o serviço e você poderá acessar a interface sem limitações e assim fazer toda a configuração da impressora:

# /etc/init.d/cupsys restart

Compartilhando a impressora no Samba

Depois de instalar e testar a impressora no servidor, o próximo passo é compartilhá-la através do Samba. A forma mais simples de fazer isso é adicionar o compartilhamento "[printers]" no arquivo de configuração. Ele é um serviço interno do Samba, similar ao "[homes]", que permite compartilhar de uma vez todas as impressoras disponíveis no servidor e replica as mudanças na configuração do Cups de forma automática. O serviço "[printers]" pode ser inclusive usado em conjunto com o "[homes]", basta adicionar as duas seções no arquivo de configuração. A única observação ao usar os dois em conjunto é que você não pode ter um usuário e uma impressora com o mesmo nome, caso contrário o servidor não conseguirá compartilhar a impressora. A principal vantagem de usar o "[printers]" é que você não precisa especificar manualmente quais impressoras deseja compartilhar, basta configurar as impressoras no Cups e incluir a seção referente ao compartilhamento no smb.conf:

[printers]
comment = Todas as Impressoras
print ok = yes
guest ok = yes
path = /var/spool/samba

Aqui, temos um exemplo de arquivo completo, incluindo o compartilhamento:

[global]
netbios name = Hades
workgroup = Grupo
server string = Servidor
encrypt passwords = true
preferred master = yes
os level = 100
preferred master = yes
wins support = yesprinting = cups
load printers = yes<

[homes]
valid users = %S
create mask = 0700
directory mask = 0700
browseable = no

[arquivos]
path = /mnt/hda6
writable = no
write list = +arquivos

[printers]
comment = Todas as Impressoras
path = /var/spool/samba
print ok = yes
guest ok = yes
browseable = yes

A opção "print ok" é similar à opção "available" que usamos nos compartilhamentos de pastas. Ao usar o "print ok = yes" a impressora fica disponível e, ao usar "print ok = no" o compartilhamento é desativado temporariamente. É obrigatório incluir esta opção no compartilhamento, pois é justamente ela que indica que trata-se de um compartilhamento de impressora. A opção "guest ok = yes" indica que a impressora deve ficar disponível para o uso de qualquer um. Se preferir que ela fique disponível apenas para os usuários cadastrados no Samba, mude para "guest ok = no". A opção "path" indica o diretório do sistema onde serão armazenados os trabalhos de impressão. A pasta "/var/spool/samba" é usada por padrão e deve ter sido criada automaticamente durante a instalação do Samba. De qualquer forma, se mais para a frente você não conseguir imprimir, recebendo mensagens de "disco cheio" ou "acesso negado" a partir dos clientes, verifique se a pasta realmente existe e se as permissões estão corretas:

# ls -l /var/spool/ | grep samba

Ele deve responder algo como:

drwxrwxrwt 2 root root 4096 2008-01-24 15:37 samba

O drwxrwxrwt indica as permissões da pasta, no caso uma pasta pública onde todos os usuários podem ler e gravar arquivos. O último "t" indica o uso do sticky bit, uma precaução de segurança, que faz com que cada usuário possa alterar apenas seus próprios arquivos. Isso evita que algum engraçadinho consiga corromper trabalhos de impressão enviados por outros usuários. Se você precisar criar manualmente a pasta, o comando para setar as permissões corretamente é:

# chmod 1777 /var/spool/samba/
(note o uso do "1", que ativa o stick bit)

Continuando, depois de reiniciar o Samba, ou aguardar o tempo de atualização, as impressoras passarão a aparecer no ambiente de redes, com os mesmos nomes que foram definidos ao instalar as impressoras no servidor. O Samba pode inclusive ser usado para centralizar as impressoras da rede, recompartilhando impressoras disponibilizadas por outros micros, desde que você as configure corretamente no Cups. Nesse screenshot, por exemplo, temos duas impressoras. A "E230" está instalada diretamente no servidor, enquanto a "Optra-E+" é uma impressora disponibilizada por outro micro. Como pode ver, o cliente pode visualizar e imprimir em ambas:

É possível, também, especificar individualmente o compartilhamento de cada impressora, o que é útil quando o servidor compartilha várias impressoras diferentes e você precisa especificar as permissões individualmente. A configuração a adicionar no arquivo de configuração é praticamente a mesma. A principal diferença é que agora você deve especificar o nome da impressora no nome do compartilhamento, ao invés de usar a string "printers", como em:

[E230]
print ok = yes
guest ok = yes
path = /var/spool/samba

Assim como no caso dos compartilhamentos de arquivos, você pode limitar o acesso à impressora com base nos endereços IP ou nos nomes das máquinas, com base nos logins de usuário, ou através de uma combinação de ambos, através das opções "hosts allow", "hosts deny", "valid users" e "invalid users". Estas opções podem ser usadas tanto ao ativar o serviço [printers] quanto ao compartilhar as impressoras individualmente. Para permitir que a impressora seja usada por apenas alguns endereços específicos, você usaria:

[E230]
print ok = yes
guest ok = yes
path = /var/spool/samba
hosts allow = 192.168.1.3, 192.168.1.4, 192.168.1.65

Você pode, também, usar os nomes das máquinas dentro da rede Windows no lugar dos endereços IP, como em:

[E230]
print ok = yes
guest ok = yes
path = /var/spool/samba
hosts allow = micro1, micro2, micro3

Para bloquear o acesso à impressora para os usuários "joao" e "maria", utilizaríamos a opção "invalid users", assim como em um compartilhamento de arquivos:

[E230]
print ok = yes
guest ok = no
path = /var/spool/samba
invalid users = joao, maria

Similarmente, para inverter a lógica, permitindo que apenas os dois usem a impressora, usaríamos a opção "valid users":

[E230]
print ok = yes
guest ok = no
path = /var/spool/samba
valid users = joao, maria

Para combinar as duas coisas, permitindo que a impressora seja usada apenas pelos dois usuários e, além disso, apenas a partir de dois endereços específicos, você usaria:

[E230]
print ok = yes
guest ok = no
path = /var/spool/samba
valid users = joao, maria
hosts allow = 192.168.1.3, 192.168.1.4

Configuração nos clientes

Continuando, a impressora pode ser instalada nos clientes Windows através do "Painel de Controle > Impressora > Adicionar Impressora > Impressora de rede" ou simplesmente clicando sobre ela no ambiente de rede. O Samba não se preocupa com o driver de impressão, apenas disponibiliza um spool remoto no qual os clientes podem colocar os trabalhos de impressão. Devido a isso, é necessário instalar os drivers de impressão nos clientes, da mesma forma que você faria ao instalar uma impressora local. Inicialmente, você receberá uma mensagem de erro ao instalar a impressora nos clientes, avisando que o servidor não possui o driver instalado:

Esta mensagem se refere a outro recurso suportado por servidores Windows, onde você pode fazer o upload dos drivers de impressão para o servidor, de forma que os clientes possam obtê-los automaticamente ao se conectarem à impressora. Por enquanto ainda não configuramos isso, de forma que é preciso instalar a impressora da forma tradicional, fornecendo os drivers manualmente no cliente:

Naturalmente, as impressoras compartilhadas através do Samba podem também ser usadas a partir dos clientes Linux, que precisam apenas ter instalado o Cups e o cliente Samba. Ao instalar a impressora nos clientes, procure pela opção de instalar uma impressora Windows ou SMB, que é suportada pela maioria das ferramentas de configuração. No caso do kaddprinterwizard você usaria a opção "Impressora SMB compartilhada (Windows)" e no gnome-cups-add a opção "Impressora Windows (SMB)":

É possível também instalar as impressoras nos clientes Linux diretamente via linha de comando usando o comando "lpadmin", como em:

# lpadmin -p E230 -E -v smb://192.168.1.254/E230

O parâmetro "-p" especifica o nome da impressora, conforme será instalada no cliente (não precisa necessariamente ser o mesmo nome usado pelo servidor), enquanto o "-v" indica a localização da impressora (endereço IP ou nome do servidor, seguido pelo nome do compartilhamento). Nesse exemplo, estamos instalando a impressora "E230" compartilhada pelo servidor disponível no endereço 192.168.1.254. Se o compartilhamento no servidor incluir a opção "guest ok = yes" você conseguirá acessar a impressora diretamente, caso contrário você precisará especificar o login e senha ao instalá-la. Nesse caso, o comando ficaria:

# lpadmin -p E230 -E -v smb://gdh: 12345@192.168.1.254 /E230

Veja que o login e a senha são especificados diretamente no comando, entre o "smb://" e o endereço do servidor, que é agora separado por um "@".

Disponibilizando drivers de impressão para os clientes

Em uma pequena rede, instalar os drivers manualmente ao configurar a impressora nos clientes não seria um grande problema, já que você poderia simplesmente carregar o CD de instalação, ou mesmo criar um compartilhamento de rede contendo os arquivos e fazer a instalação manualmente em cada um. Entretanto, em uma grande rede isso pode ser bastante tedioso. Chegamos então ao recurso de upload de drivers de impressão que, naturalmente, também é suportado pelo Samba. Ele consiste em um compartilhamento oculto, chamado "print$", que contém os drivers que serão fornecidos aos clientes. Depois de configurar o recurso, o uso das impressoras nos clientes torna-se muito mais simples, pois você precisa apenas clicar sobre o ícone da impressora no "Meus locais de rede" para instalá-la, recurso chamado de "point and print" ou "p-n-p" (diferente do PnP, de "plug-and-play"). O Windows exibe um aviso, confirmando a instalação do driver e em seguida, a impressora é instalada automaticamente:

Configurar este recurso é um pouco trabalhoso, mas não chega a ser difícil. Vamos lá :).

O primeiro passo é criar um usuário administrativo, que você usará para acessar o servidor a partir dos clientes Windows e assim poder dar o upload dos drivers. Comece criando o usuário no servidor e cadastrando-o no Samba da forma tradicional:

# adduser gdh
# smbpasswd -a gdh

O próximo passo é ativar o uso de privilégios (que vamos usar mais adiante) no Samba e criar um compartilhamento chamado "print$", o compartilhamento oculto onde irão os drivers de impressão. Para isso, precisaremos fazer duas alterações no arquivo "/etc/samba/smb.conf". A primeira é adicionar a linha "enable privileges = yes" no final da seção "[global]", sem alterar as demais, como em:

[global]
workgroup = GRUPO
netbios name = Asus server
string = Servidor
encrypt passwords = true
wins support = yes
preferred master = yes
# invalid users = root
os level = 100enable privileges = yes

Se você usou o Swat para configurar o arquivo, muito provavelmente ele conterá a linha "invalid users = root". É importante que esta linha seja removida ou comentada (como no meu exemplo), caso contrário você não conseguirá atribuir os privilégios para o usuário, como faremos em seguida. O próximo passo é incluir as linhas referentes ao compartilhamento "[printer$]", que é um pouco diferente de um compartilhamento normal:

[print$]
comment = Drivers de impressão para os clientes Windows
path = /var/smb/printers
read only = yes
write list = gdh
inherit permissions = yes

A opção "path" diz qual a pasta do servidor onde serão colocados os drivers. Aqui estou usando a pasta "/var/smb/printers", mas você pode usar outra pasta se quiser. Em seguida, usamos a opção "read only = yes" para que o compartilhamento seja somente-leitura e usamos a opção "write list" para criar uma exceção, permitindo que o usuário administrativo que criamos na etapa anterior possa gravar no compartilhamento. A segurança é importante, pois os drivers são baixados automaticamente para os clientes Windows, de forma que alguém mal intencionado que pudesse alterar o conteúdo da pasta poderia muito bem usar o serviço como um vetor para transmitir vírus e spywares para os clientes Windows da rede. Você pode também usar um grupo, como em "write list = +ntadmin" ou uma lista de usuários, como em "write list = gdh, admin"; o importante é limitar o acesso apenas às pessoas autorizadas. Não se esqueça de reiniciar o Samba ou aguardar alguns minutos para que as alterações entrem em vigor. O próximo passo é criar a pasta onde ficarão os drivers de impressão, criar as subpastas WIN40 (drivers para estações 95/98/ME) e W32X86 (estações com o NT/2000/XP) dentro dela e ajustar as permissões, de forma que o usuário criado tenha permissão para alterar o conteúdo da pasta e os demais possam apenas ler:

# mkdir -p /var/smb/printers
# cd /var/smb/printers
# mkdir WIN40 W32X86
# chown gdh WIN40 W32X86
# chmod 2775 WIN40 W32X86

Falta agora uma etapa importante, que é transformar o usuário em um administrador de impressão no Samba, pois, sem isso, ele terá acesso ao compartilhamento mas não conseguirá dar upload dos drivers a partir dos clientes, usando o procedimento que veremos a seguir. Isso é feito usando o comando "net", usado para ajustar os privilégios dos usuários do Samba, que deve ser executado no servidor, como root. Se o servidor se chama "asus" e o usuário se chama "gdh", o comando seria:

# net -S localhost -U root -W ASUS rpc rights grant 'ASUSgdh' SePrintOperatorPrivilege

A opção "-S localhost -U root" diz que o comando net deve se conectar ao servidor Samba rodando na máquina local, usando a conta de root. A opção "-W ASUS" especifica o nome do servidor (como definido na configuração do Samba) e o "grant 'ASUSgdh' SePrintOperatorPrivilege" adiciona os privilégios para o usuário "gdh" do servidor "asus". Ele vai pedir a senha de root e, em seguida, exibir uma mensagem de confirmação:

Password:
Successfully granted rights.

Se nesse ponto você receber uma mensagem de erro, dizendo que não é possível se logar no servidor, muito provavelmente você esqueceu de comentar a linha "invalid users = root", esqueceu de adicionar a linha "enable privileges = yes" ou as alterações no arquivo ainda não entraram em vigor (nesse caso, experimente reiniciar o Samba manualmente, usando o "/etc/init.d/samba restart" ou o "service smb restart"). Com isso, concluímos a configuração no servidor. Os passos seguintes são feitos a partir de um cliente Windows da rede. O primeiro passo é se logar no cliente usando o mesmo login (gdh no exemplo) que foi criado no servidor, já que apenas ele possui as permissões necessárias para atualizar os drivers. Caso necessário, adicione o usuário na estação usando o "Painel de Controle > Contas de usuário". Acesse o servidor através do "Meus locais de rede", acesse a pasta "Impressoras e aparelhos de fax" e clique na opção "Arquivo > Propriedades do servidor" na janela principal do Explorer:

Na janela de propriedades, acesse a aba "drivers", que mostra os drivers disponíveis no servidor. Originalmente ela estará vazia; use o botão "Adicionar" para instalar os drivers de impressão desejados:

Se nesse ponto as opções não estiverem disponíveis, provavelmente você não adicionou o privilégio "SePrintOperatorPrivilege" para o usuário administrativo, ou não se logou usando o login correto na estação Windows. Clicando no "adicionar" é aberta a tela padrão de seleção do driver, onde você pode usar um dos drivers do Windows ou especificar a localização de um driver. Entretanto, diferente do que teríamos normalmente, os drivers não são propriamente instalados, mas apenas copiados para o compartilhamento "print$" do servidor. A idéia da ferramenta é justamente permitir que você adicione vários drivers diferentes, que atendam clientes rodando diferentes versões do Windows, por isso, a cada driver, é aberta uma nova janela de seleção, que pergunta a que versões do Windows o driver é destinado. Na lista, "Intel" corresponde a máquinas rodando as versões de 32 bits do Windows, enquanto "x64" corresponde a máquinas rodando as versões de 64 bits do sistema:

Dessa forma, você pode cadastrar um driver para máquinas com o Windows XP ou 2000, outra para os clientes com o 98/ME, outro para os com o XP de 64 bits e assim por diante. Se o servidor tiver mais de uma impressora instalada, você pode aproveitar para carregar os drivers das outras impressoras:

Nesse ponto, você verá que foram criadas subpastas dentro das pastas "/var/smb/printers/W32X86" e "/var/smb/printers/WIN40" do servidor, referentes aos drivers carregados. Por enquanto, os drivers foram apenas copiados para o servidor. É preciso ainda associar a impressora com o driver correspondente, para que o servidor passe a fornecê-lo para os clientes. Ainda logado com o usuário administrativo, clique com o botão direito sobre a impressora e acesse as propriedades:

Você receberá a mesma mensagem exibida ao instalar a impressora nos clientes, dizendo que o servidor não possui o driver de impressão (é justamente isso que estamos corrigindo, afinal :).

Nesse ponto, a resposta natural seria clicar no "OK", mas, se você fizer isso, vai abrir a tela de seleção do driver e acabar fazendo uma instalação local dos drivers da impressora que não é o que queremos. Por estranho que possa parecer, a resposta correta aqui é o botão "Cancelar", o que o levará às propriedades da impressora:

Dentro do menu de propriedades, acesse aba "Avançado" e especifique o driver que será usado na opção "Driver", que originalmente estará em branco. Com isso, o driver é associado com a impressora, fazendo com que o servidor passe a fornecê-lo para os clientes que se conectarem a ela, concluindo a configuração. Se o servidor tiver outras impressoras compartilhadas, faça o mesmo para as demais. Estes passos parecem estranhos e pouco intuitivos, mas são os mesmos passos que você usaria para instalar os drivers em um servidor de impressão Windows. O Samba simplesmente implementa as mesmas funções. Uma observação é que ativar o upload de drivers faz com que as impressoras compartilhadas, disponíveis na pasta "Impressoras e aparelhos de fax" sejam renomeadas para o nome "oficial" fornecido pelo driver. É por isso que a minha "E230" foi renomeada para "Lexmark Optra E+ (MS)". Se você não quiser que isso aconteça, adicione a opção "force printername = yes" na seção referente à impressora (ou na seção [printers]) do smb.conf, como em:

[E230]
print ok = yes
guest ok = yes
path = /var/spool/sambaforce printername = yes

Depois que a alteração é aplicada, a impressora volta a ser compartilhada com o nome definido por você. Vamos então a mais um exemplo de configuração, desta vez bem mais incrementado, incluindo o compartilhamento de impressoras, o compartilhamento para os drivers Windows, lixeira e outros recursos que vimos até aqui:

[global]
netbios name = Cartago
server string = Servidor
workgroup = Grupo
local master = yes
os level = 100
preferred master = yes
wins support = yes
map to guest = bad user
guest account = guest
vfs objects = recycle
recycle:keeptree = yes
recycle:versions = yes
recycle:repository = /mnt/sda2/trash/%U
recycle:exclude = *.tmp, *.log, *.obj, ~*.*, *.bak, *.iso recycle:exclude_dir = tmp, cache
printing = cups
load printers = yes
enable privileges = yes

[lixeira]
path = /mnt/sda2/trash/%U
writable = yes

[printers]
path = /var/spool/samba
print ok = yes
guest ok = yes
browseable = yes

[print$]
path = /var/smb/printers
read only = yes
write list = gdh
inherit permissions = yes

[arquivos]
path = /mnt/hda2
writable = no
write list = +arquivos

[engenharia]
path = /mnt/sda1/engenharia
writable = yes
valid users = +engenheiros
browseable = no

[gerencia]
path = /mnt/sda1/gerencia
writable = yes
valid users = joao, maria
hosts allow = 192.168.1.2, 192.168.1.32
browseable = no

[publico]
path = /mnt/sda2/publico
writable = yes
guest ok = yes

[backup]
path = /mnt/sda2/backup/%U
writable = yes
valid users = %U
writable = yes
guest ok = no

Este exemplo de configuração exige alguns passos adicionais para ser usado, incluindo a configuração das impressoras e a instalação dos drivers de impressão a partir dos clientes Windows, como vimos até aqui; ele não poderia ser usado diretamente em um servidor que você acabou de instalar. Ele inclui também o uso da lixeira para todos os compartilhamentos e o uso de 5 compartilhamentos de arquivos. Um deles é o compartilhamento "arquivos", que já utilizei em exemplos anteriores, onde os arquivos ficam disponíveis para todos os usuários, mas apenas os usuários cadastrados no grupo "arquivos" podem fazer alterações. Continuando, temos os compartilhamentos "engenharia" e "gerencia", que são um pouco mais seguros, acessíveis apenas para alguns usuários. Eles são também protegidos pela opção "browseable = no", que, como vimos, faz com que eles não sejam listados no ambiente de redes. Os três são complementados pelo compartilhamento "publico", que fica acessível para todos os usuários através do uso da conta "guest". Este exemplo não inclui o [homes], que substituí por um compartilhamento para armazenamento de backups. Ele utiliza a variável "%U" (nome do usuário) para criar pastas particulares, onde cada usuário pode armazenar seus backups. Para usá-lo, seria necessário criar diversas subpastas dentro da pasta "/mnt/sda2/backup", uma com o nome de cada usuário, e ajustar as permissões para que o usuário tenha acesso apenas à sua própria pasta, como em:

# mkdir /mnt/sda2/backup/joao
# chown joao:joao /mnt/sda2/backup/joao

Todos os usuários verão o compartilhamento "backup" ao acessarem o servidor, mas devido ao uso da variável, cada um verá apenas sua própria pasta ao acessá-lo.

Compartilhando impressoras através do Cups

Ao compartilhar impressoras, o Samba atua mais como um spool de impressão do que como um servidor propriamente dito, já que o trabalho pesado é na verdade feito pelo servidor Cups rodando abaixo dele. O Samba se limita a receber os trabalhos de impressão enviados pelos clientes e repassá-los ao servidor de impressão. Se você está configurando um servidor Samba, é natural usá-lo para compartilhar também as impressoras, já que o Samba oferece diversas opções de controle de acesso e outras opções avançadas. Entretanto, o próprio Cups possui um recurso nativo de compartilhamento de impressoras, que além de atender outras máquinas Linux (como seria de se esperar) permite que as impressoras sejam usadas também pelos clientes Windows, de uma forma bastante simples. Para habilitar o compartilhamento, edite o arquivo "/etc/cups/cupsd.conf" (no servidor), deixando-o com o seguinte conteúdo:

Port 631
Listen 631
Browsing On
BrowseAllow All
BrowseInterval 30
BrowseAddress @LOCAL
BrowseInterval 30

<Location />
Order allow,deny
Allow all
</Location>

<Location /printers>
Order allow,deny
Allow all
</Location>

<Location /admin>

Encryption Required
Order allow,deny
Allow localhost
</Location>

<Location /admin/conf>
AuthType Basic
Require user @SYSTEM
Order allow,deny
Allow localhost
</Location>

Veja que a seção "<Location /printers>" dentro do arquivo (que define as permissões de acesso às impressoras) fica com permissão de acesso para todo mundo, enquanto o utilitário de administração do Cups (<Location /admin>) continua acessível apenas localmente, através do endereço http://127.0.0.1:631. No caso do Ubuntu e do Kubuntu é necessário um passo adicional. Os desenvolvedores optaram por mudar a configuração padrão, mantendo a porta utilizada pelo servidor Cups aberta apenas para o localhost, de forma que precisamos abrí-la para que os demais hosts da rede possam imprimir. A configuração de portas vai num arquivo separado, o "/etc/cups/cups.d/ports.conf". Edite-o, substituindo a linha:

Listen localhost:631

Por:

Listen 631

Até 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 <Location /> (onde vai a configuração que permite aos clientes verem as impressoras disponíveis) e <Location /printers> ficaria:

<Location />
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From 192.168.1.*
</Location>

<Location /printers>
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From 192.168.1.*
</Location>

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

Configuração das impressoras nos clientes

Além da configuração mais simples, outra vantagem de compartilhar através do Cups é que as impressoras podem ser configuradas automaticamente nos clientes Linux, sem necessidade de qualquer configuração manual. Basta manter a opção "browsing" ativa na configuração do Cups (/etc/cups/cupsd.conf) nos clientes, como em:

LogLevel warning
SystemGroup lpadmin
Listen localhost:631
Listen /var/run/cups/cups.sock Browsing On
BrowseOrder allow,deny
BrowseAllow @LOCAL
BrowseAddress @LOCAL

A opção "browsing" faz com que os clientes 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 usando uma distribuição Live-CD no cliente, manda imprimir qualquer coisa e o trabalho é direcionado de forma automática para a impressora compartilhada no servidor, sem que você precise fazer nada para configurá-la. 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 "e230" 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 do cliente. É um recurso que funciona surpreendentemente bem.

Caso você precise adicionar a impressora manualmente, abra o kaddprinterwizard (ou outro utilitário de configuração disponível no cliente) e selecione a opção "Remote Cups Server". Forneça o endereço IP do servidor na rede local (ex: 192.168.1.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 recurso de configuração automática, por isso é preciso adicionar a impressora manualmente através do "Painel de Controle > Impressoras" e fornecer o CD com os drivers. Vamos por passos. Comece abrindo o navegador e acessando a página de administração do Cups no servidor. Ela fica disponível através do http://ip-do-servidor:631. Dentro da interface, acesse a opção "Manage Printers" e clique no link da impressora que será usada. Você verá um endereço, como "http://192.168.1.1:631/printers/e230", 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.1.1:631/printers/e230" 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 mostrar 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 bastante sólido e que utiliza poucos recursos da máquina. Isso permite que você utilize até mesmo uma máquina antiga como servidor de impressão. 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.1.1:631/printers/e230, por exemplo) no lugar do caminho para a impressora e forneça o driver.

Fonte: www.guiadohardware.net/tutoriais/impressoras-samba/
Autor: Carlos E. Morimoto

Usando o Samba como PDC

2013-05-22T08:57:00.001-07:00

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, armazenar os perfis dos usuários, permitindo que eles tenham acesso a seus arquivos e configurações a partir de qualquer máquina onde façam logon. 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, além de centralizar 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", "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. Continuando a lista de "exigências", é necessário também que o modo de segurança esteja configurado em nível de usuário (security = user) e que o uso de senhas encriptadas esteja ativado (encrypt passwords = yes). Na verdade, não é obrigatório incluir estas duas linhas no smb.conf, já que estes valores são usados por default pelo Samba 3, mas é sempre interessante usá-los em exemplos e modelos de configuração para fins didáticos e para deixar claro que o arquivo não deve ter opções que conflitem com elas. Embora não seja obrigatório, é fortemente recomendável ativar o uso do tdbsam como backend, adicionando a linha "passdb backend = tdbsam", como vimos a pouco. Usar o smbpasswd em um PDC oferece várias desvantagens. A principal delas é que o smbpasswd armazena um conjunto bastante incompleto de atributos referentes aos usuários, de forma que atributos como o SID (um código de identificação único a cada usuário, usado como verificação de segurança) ficam em branco ou são gerados dinamicamente durante os acessos, o que pode quebrar o suporte aos roaming profiles em algumas situações. O uso do tdbsam soluciona estes problemas. 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, lixeira e outras opções 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
domain logons = yes
logon script = netlogon.bat
security = user
encrypt passwords = yes
enable privileges = yes
passdb backend = tdbsam
preferred master = yes
local master = yes
os level = 100
wins support = yes

[netlogon]
comment = Servico de Logon
path = /var/samba/netlogon
read only = yes
browseable = no

[homes]
valid users = %S
create mask = 0700
directory mask = 0700
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", como em:

$ testparm

Load smb config files from /etc/samba/smb.conf
Processing section "[netlogon]"
Processing section "[homes]"
Loaded services file OK.
Server role: ROLE_DOMAIN_PDC

As linhas "preferred master = yes", "local master = yes" e "os level = 100" fazem com que o servidor assuma também a função de master browser da rede. É comum que o PDC acumule também a função de master browser, mas, na verdade, uma coisa não tem relação com a outra. Você pode remover as três linhas e configurar outra máquina para assumir a função de master browser se preferir. 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 a conta de root no Samba. 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. Nesse 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

Aproveite e crie a pasta "profile.pds" dentro do diretório /etc/skel, de forma que ela seja criada automaticamente dentro do home dos usuários que criar daqui em diante:

# mkdir /etc/skel/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 "alesia" por exemplo, é preciso criar um login de máquina com o mesmo nome:

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

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); a conta é válida apenas no Samba, onde é cadastrada com a opção "-m" (machine). Essas contas de máquina são chamadas de "trusted accounts" ou "trustees". Lembre-se de que para usar este comando o arquivo "/etc/shells" (no servidor) deve conter a linha "/bin/false". Em caso de erro ao adicionar a máquina, use o comando abaixo para adicionar a linha e tente novamente:

# echo "/bin/false" >> /etc/shells
(este comando só funciona se executado diretamente usando o root, não funciona se executado usando o sudo)

Se preferir, você pode adicionar as contas de máquina dentro de um grupo do sistema ("maquinas" ou "machines" por exemplo). Nesse 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 alesia$

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: gdharquivos /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: gdharquivos /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 na 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: "Configurações > 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, reduzindo a possibilidade de perda de dados. Por outro lado, ativar os perfis móveis faz com que seja consumido mais espaço de armazenamento no 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, 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 = %Lprofiles%U

A variável "%L" indica, neste caso, o nome do servidor, enquanto o "%U" indica o nome do usuário que está fazendo logon. Dessa forma, quando o usuário "joao" faz logon é montado o compartilhamento "gdhprofilesjoao", por exemplo. 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

Concluindo, 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 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". No Windows XP, o default foi alterado e o sistema tenta usar o perfil móvel por padrão, exibindo uma mensagem de erro (repetida a cada logon) caso o recurso não esteja disponível no servidor. Para eliminar as mensagens de erro é necessário desativar o uso dos perfis móveis, o que é feito através do utilitário "gpedit.msc", que pode ser chamado através do "Iniciar > Executar" (é necessário estar logado localmente, usando uma conta com privilégios administrativos). Dentro dele, acesse a opção "Configuração do computador > Modelos administrativos > Sistema > Perfis de usuário > Só permitir perfis de usuário locais" e mude a opção de "Não configurado" para "Ativado" (esta alteração precisa ser repetida em todas as máquinas):

Aqui vai mais um exemplo de configuração para o servidor Samba, incluindo a configuração para uso como PDC, o compartilhamento netlogon, suporte a perfis móveis e compartilhamento de impressoras:

[global]
netbios name = Byzantium
workgroup = Dominio
server string = Servidor PDC
domain master = yes
domain logons = yes
logon script = netlogon.bat
logon home = %L%U.profiles
logon path = %Lprofiles%U
security = user
encrypt passwords = yes
enable privileges = yes
passdb backend = tdbsam
preferred master = yes
local master = yes
os level = 100
wins support = yes
printing = cups
load printers = yes
enable privileges = yes

[printers]
path = /var/spool/samba
print ok = yes
guest ok = yes
browseable = yes

[print$]
path = /var/smb/printers
read only = yes
write list = gdh
inherit permissions = yes

[netlogon]
comment = Servico de Logon
path = /var/samba/netlogon
read only = yes
browseable = no<

[profiles]
path = /var/profiles
writeable = yes
browseable = no
create mask = 0600
directory mask = 0700

[homes]
valid users = %S
create mask = 0700
directory mask = 0700
browseable = no

[arquivos]
path = /mnt/hda2
writable = no
write list = +arquivos

Com o servidor Samba configurado, falta o mais importante, que é configurar os clientes para fazerem logon no domínio. Ao usar um PDC, surge a necessidade de cadastrar as máquinas no domínio, para só então os usuários cadastrados poderem utilizar as máquinas. É possível cadastrar tanto máquinas Windows quanto máquinas Linux no domínio, vamos agora às peculiaridades de cada sistema.

Logando Clientes Windows

Nem todas as versões do Windows suportam o uso de um domínio. 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, assim como no Vista Starter, Vista Home Basic e Vista Home Premium, de forma a pressionar as empresas a comprarem as versões mais caras do sistema. É possível burlar a limitação através da alteração de chaves do registro, mas isso viola o contrato de uso do sistema, o que de qualquer forma não é aceitável em um ambiente de produção. Tendo isso em mente, vamos aos passos relacionados à configuração, que muda de acordo com a versão do Windows: No Windows XP Professional, acesse o "Painel de Controle > Sistema > Nome do Computador" e use a opção "Alterar...". No menu seguinte, defina o nome da máquina (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:

Nunca é demais lembrar que o "Nome do computador" fornecido na opção deve corresponder a uma das contas de máquinas cadastradas no servidor Samba, usando os três comandos que citei anteriormente. Para cadastrar a máquina "hp", por exemplo, você usaria (no servidor, como root) os comandos abaixo:

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

Na tela de identificação que será aberta a seguir, logue-se como "root", com a senha definida no servidor Samba. É normal que a conexão inicial demore um ou dois minutos. Se tudo der certo, você é saudado com a mensagem "Bem-vindo ao domínio Dominio" (onde o "Dominio" é o nome definido na opção "workgroup" do smb.conf):

Fornecer a senha de root do servidor ao cadastrar o cliente no domínio, prova que quem está fazendo a operação é o administrador, ou alguém autorizado por ele. Se qualquer um pudesse adicionar e remover máquinas do domínio, ele não seria muito diferente de um grupo de trabalho e a configuração perderia todo o sentido. Se você não gostou da idéia de usar a senha de root para cadastrar as máquinas, é possível também outorgar o privilégio a uma outra conta através do comando "net", como veremos a seguir. Quando a máquina passa a fazer parte do domínio, é criada uma "relação de confiança" entre ela e o servidor. Uma senha (chamada de "machine trust account password") é usada pela máquina para comprovar sua identidade ao contatar o servidor de domínio. Esta é uma senha interna, gerada automaticamente pelo sistema durante a conexão inicial. Depois de reiniciar a estação, aparecerá a 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, mas, nesse caso, perde-se o acesso aos recursos relacionados ao domínio e é usado o perfil do usuário local:

Para remover a máquina do domínio, é preciso acessar a mesma opção e mudar a opção de "Membro de Domínio:" para "Membro de Grupo de trabalho:". O sistema solicita novamente a senha do servidor, como uma forma de comprovar que o usuário está autorizado a realizar a operação. Isso evita que os usuários da rede desfaçam a configuração, removendo as máquinas do domínio sem permissão do administrador. 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 das 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

No Windows Vista, a opção de adicionar a máquina ao domínio está no "Painel de Controle > Sistema > Configurações avançadas do sistema (na lista à esquerda) > Nome do Computador > Alterar":

A forma como você escolhe se quer se logar ao domínio ou fazer um login na máquina local na tela de login do Vista segue uma lógica um pouco curiosa. Depois que a máquina é adicionada ao domínio, a tela de login mostra a opção de fazer logon no domínio, onde o último login utilizado fica pré-selecionado. Para usar outro login, é necessário clicar no botão "Trocar Usuário" e fornecê-lo na tela seguinte. Entretanto, não existe uma opção para fazer logon na máquina local. Para isso, é necessário especificar o nome da máquina seguido pelo nome do usuário no campo de login, como em: Vistagdh. Outra opção é usar um "." antes do nome do usuário, como em ".gdh". No Windows 2000, o procedimento é basicamente o mesmo do Windows XP, muda apenas a localização da opção, que está disponível no "Meu Computador > Propriedades > Identificação de rede > Propriedades". Ao contrário do XP Home, XP Starter, Vista Starter e Vista Home, as máquinas com o Windows 98 ou o Windows ME podem ser adicionadas ao domínio. Entretanto, elas participam dentro de um modo de compatibilidade, onde podem acessar os compartilhamentos, mas não têm acesso ao recurso de perfis móveis, por exemplo. Para cadastrar a máquina, comece logando-se na rede (na tela de login aberta na inicialização do sistema) 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 do Windows (para a instalação dos componentes necessários) e reiniciar a máquina.

Corrigindo problemas

Naturalmente, com tantos passos a seguir, nem sempre as coisas dão certo na primeira tentativa. Vamos então a uma rápida seção de troubleshoot, com mensagens de erro comuns ao tentar cadastrar a máquina no domínio:

Esta primeira mensagem aparece quando o nome da máquina não foi cadastrado no servidor Samba como uma conta de máquina. O "nome de usuário" se refere, na verdade, à conta da máquina, adicionada usando os três comandos que vimos a pouco. Outro erro comum é:

Esta segunda mensagem indica que a conta de root não foi cadastrada no Samba (smbpasswd -a root), que a senha informada no cliente está incorreta ou que o Samba não está sendo capaz de utilizar a conta de root devido à presença da linha "invalid users = root" no smb.conf. Em resumo, ela é exibida quando, por qualquer motivo, o servidor Samba não consegue autenticar a conta de root e recusa o login da máquina Windows no domínio. O Samba é inteiramente compatível com as estações rodando o Windows XP a partir da versão 3. As últimas versões da série 2.x também podiam ser configuradas como servidores de domínio, mas, ao usá-las, era necessário fazer um conjunto de alterações nos clientes, desativando recursos que não eram suportados pelo Samba. Naturalmente, é muito mais fácil simplesmente atualizar o servidor Samba do que fazer alterações em cada cliente, mas de qualquer forma, caso isso não seja possível, você pode ajustar os clientes de duas formas:

Copie 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" para cada cliente e execute o arquivo, para que ele faça as alterações necessárias no registro.
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).

Cadastrando as máquinas sem usar a conta de root

Normalmente, você deve fornecer a senha de root ao inserir cada máquina no domínio. Fornecer a senha de root é justamente uma prova de que você é realmente o administrador do servidor e está autorizado a cadastrar as máquinas. Esta é a forma mais simples de trabalhar, mas muitos torcem o nariz para a idéia, temendo abrir uma brecha para ataques. É possível evitar a necessidade de usar a conta de root ao cadastrar as máquinas criando uma conta especial, com privilégios para adicionar máquinas ao domínio, de forma similar ao que fizemos ao configurar o fornecimento automático de drivers de impressão. Para isso, usamos novamente o comando "net", adicionando agora o privilégio "SeMachineAccountPrivilege" ao usuário que terá permissão para adicionar as máquinas no domínio. Se o servidor se chama "athenas" e o usuário se chama "gdh", o comando seria:

# net -S localhost -U root -W ATHENAS rpc rights grant 'ATHENASgdh' SeMachineAccountPrivilege(todo o comando forma uma única linha)

Este comando deve ser executado em um prompt do próprio servidor, e não localmente, nos clientes. Se você não tem acesso físico ao servidor, pode se logar nele via SSH. Ao executar o comando, o sistema solicita a senha de root (do servidor) e exibe uma mensagem de confirmação. Com isso, a conta de usuário especificada no comando (gdh no exemplo) ganha permissão para adicionar máquinas no domínio e pode ser usada para cadastrar os clientes, no lugar da conta root. Lembre-se de que, para adicionar os privilégios, você deve comentar ou remover a linha "invalid users = root" e adicionar a linha "enable privileges = yes" na seção [global] do smb.conf, como vimos no tópico sobre impressão.

Ajustando as permissões locais

Ao adicionar uma máquina Windows ao domínio, é criada uma distinção entre as contas locais e as contas de domínio. Quando o usuário se loga na estação Windows usando uma das contas cadastradas no servidor, ele é na verdade logado (na estação local) usando uma conta limitada, onde ele não tem permissão para compartilhar arquivos, para alterar as configurações da rede, nem para alterar a maior parte das configurações do sistema. Em muitas situações, é exatamente isso que você quer, mas em outras isso pode ser um grande problema, já que o usuário não conseguirá compartilhar pastas com outros usuários da rede, por exemplo. Veja que a aba de compartilhamento sequer fica disponível nas propriedades da pasta:

Para mudar isso, é necessário ajustar as permissões da máquina local, de forma que a conta do domínio tenha permissão para alterar as configurações. Para isso, logue-se localmente na estação Windows, usando uma conta com privilégios administrativos e acesse o "Painel de controle > Contas de usuário". Clique no "Adicionar" e especifique o login do usuário e o nome do domínio e, na tela seguinte, especifique o nível de permissão na máquina local (Administrador, Usuário avançado, etc.). Você pode adicionar outros usuários se desejar:

Faça logoff e logue-se novamente no domínio com a conta que foi cadastrada. Se você a cadastrou com privilégios administrativos, você notará que a aba de compartilhamento voltou a aparecer e o acesso às demais configurações foi destravado. Com isso o usuário assume o controle de sua máquina local e pode criar compartilhamentos e alterar as demais configurações:

Inicialmente, os compartilhamentos aparecerão no ambiente de rede, mas usuários de outras máquinas (também cadastradas no domínio) não conseguirão acessá-los, recebendo uma mensagem de permissão negada. Para solucionar este último problema, acesse as permissões da pasta (ainda na máquina local) e adicione os usuários do domínio que terão permissão para acessá-la, definindo as permissões de acesso de cada um:

Note que essa configuração é necessária apenas se você quiser que os usuários das estações possam criar compartilhamentos locais. Outra opção é simplesmente adicionar compartilhamentos no servidor e orientar os usuários a usarem os compartilhamentos criados para compartilharem os arquivos desejados. Centralizar todos os compartilhamentos no servidor Samba é mais seguro e facilita bastante os backups, já que você precisará se preocupar apenas em fazer backup dos arquivos do servidor. Continuando, é possível também criar usuários administrativos, com permissão para alterar o dono e as permissões dos arquivos colocados nos compartilhamentos do próprio servidor. Isso é feito usando o comando "net", o mesmo que utilizamos para permitir que o usuário possa dar upload dos drivers de impressão e possa adicionar máquinas ao domínio. Os três privilégios relacionados são:

SeDiskOperatorPrivilege: Permite que o usuário altere as permissões de acesso dos compartilhamentos e arquivos dentro deles.
SeRestorePrivilege: Permite que o usuário altere o dono dos arquivos e pastas, transferindo a posse para outro usuário (exceto ele mesmo)
SeTakeOwnershipPrivilege: Permite que o usuário assuma para si a posse de arquivos e pastas, complementando o SeRestorePrivilege.

Se o servidor se chama "athenas" e o usuário que receberá os privilégios se chama "gdh", os comandos para fornecer os três privilégios (a serem executados em um terminal do servidor) seriam:

# net -S localhost -U root -W ATHENAS rpc rights grant 'ATHENASgdh' SeDiskOperatorPrivilege
# net -S localhost -U root -W ATHENAS rpc rights grant 'ATHENASgdh' SeRestorePrivilege
# net -S localhost -U root -W ATHENAS rpc rights grant 'ATHENASgdh' SeTakeOwnershipPrivilege

Não é preciso dizer que, em uma grande rede, estes privilégios devem ser atribuídos apenas a outros administradores ou a usuários de sua inteira confiança, já que eles permitem acesso quase que irrestrito aos arquivos no servidor. Para listar os privilégios atribuídos a cada usuário, use o comando:

# net -S localhost -U% rpc rights list accounts

Isso lista todos os usuários com privilégios especiais, incluindo as contas do sistema. Depois de executar os três comandos que vimos a pouco, teríamos o usuário "gdh" aparecendo no final da lista, com os três privilégios:

ATHENASgdh
SeDiskOperatorPrivilege
SeRestorePrivilege
SeTakeOwnershipPrivilege

Para remover um determinado privilégio, é usado o mesmo comando que usamos para adicionar, apenas substituindo o "grant" por "revoke", como em:

# net -S localhost -U root -W ATHENAS rpc rights revoke
'ATHENASgdh' SeTakeOwnershipPrivilege

Logando clientes Linux no domínio

Embora a configuração seja um pouco mais complexa, é possível também logar clientes Linux no domínio, já que o Samba pode ser usado como cliente de um PDC Samba (ou de um PDC Windows). Isso permite que a estação Linux acesse os recursos do domínio normalmente e utilize o PDC como um servidor de autenticação na hora de compartilhar arquivos com a rede, da mesma forma que as máquinas Windows. Com isso, você elimina a necessidade de cadastrar os logins de usuários em todas as máquinas Linux que precisarem compartilhar arquivos, já que todo o processo de autenticação é centralizado no servidor. O primeiro passo é cadastrar o nome da máquina no servidor PDC, usando os três comandos que já vimos:

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

No caso dos clientes Linux, vale o nome definido durante a instalação do sistema, que fica armazenado dentro do arquivo "/etc/hostname". Esta é a única configuração que precisa ser feita no servidor. Os passos seguintes são feitos no próprio cliente. Comece fazendo uma instalação normal do Samba, instalando os pacotes "samba" e "samba-client" (ou smbclient) através do gerenciador de pacotes, da mesma forma que faria ao instalar um servidor Samba para a rede. É necessário cadastrar pelo menos uma conta de usuário no Samba (da estação), com a mesma senha definida no sistema, usando o comando smbpasswd, como em:

# smbpasswd -a joao

Com o Samba instalado, edite o arquivo smb.conf, deixando-o como este modelo:

[global]
netbios name = M5
workgroup = Dominio
security = domain
encrypt passwords = yes
password server = 192.168.1.254
username map = /etc/samba/smbusermap

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

A seção global deve conter as linhas "security = domain" (como citei anteriormente, este é o nível de segurança que permite que o Samba atue como cliente de um PDC), "encrypt passwords = yes" e a linha "password server =" que indica o endereço IP (ou o nome netbios) do servidor PDC. É importante também que a linha "workgroup" inclua o nome correto do domínio e a linha "netbios name" contenha o nome da máquina (cliente), como cadastrado no servidor e salvo no arquivo "/etc/hostname". Você pode incluir também os compartilhamentos de arquivos e impressoras desejados, como no caso do compartilhamento [arquivos] que incluí no exemplo. Depois de salvar o arquivo e reiniciar o serviço, é hora de adicionar a máquina ao domínio, o que é feito usando o comando abaixo (executado na estação):

# net join -U root

Password:
Joined domain DOMINIO.

A senha de root solicitada é a senha de root cadastrada no servidor, que é checada ao cadastrar a estação como uma forma de provar que você é o administrador da rede. Você pode também criar um usuário administrativo com poderes para adicionar as máquinas ao domínio (evitando assim o uso da conta de root), dando a ela o privilégio "SeMachineAccountPrivilege", como vimos no tópico anterior. Se o comando exibir a mensagem "Joined domain DOMINIO." sem solicitar a senha, rode-o novamente, pois isso acontece quando (por qualquer motivo) ele não conseguiu contactar o servidor. Se ele reclamar que a senha está incorreta, ou exibir um erro de permissão, verifique a configuração do servidor. Isso acontece, por exemplo, quando a linha "invalid users = root" está presente na configuração. Uma vez inserida no domínio, a instância do Samba rodando na estação passará a encaminhar todos os pedidos de autenticação para o servidor. Se o servidor autoriza o acesso, então o servidor Samba local permite o acesso ao compartilhamento. Com isso, um novo usuário cadastrado no servidor PDC, ganha acesso também aos compartilhamentos do estação, sem que você precise cadastrá-lo duas vezes. Para que isso funcione, é necessário duas coisas. Em primeiro lugar, é necessário especificar o endereço IP ou nome do servidor, para que a estação consiga contactá-lo, o que e feito através da opção "password server", como já vimos. O segundo passo é criar um arquivo com um mapa dos usuários na estação. O arquivo pode ser armazenado em qualquer pasta, mas você precisa especificar sua localização corretamente na opção "username map" do smb.conf, como em:

username map = /etc/samba/smbusermap

Este arquivo relaciona os logins cadastrados no servidor PDC com a conta cadastrada no servidor Samba local, explicando a ele como acessar os arquivos no sistema depois que o acesso é autorizado pelo PDC. Sem isso, o sistema bloqueia o acesso, já que as contas cadastradas no PDC não existem localmente. O arquivo com o username map segue uma estrutura muito simples, onde você especifica uma conta por linha, sempre seguindo a sintaxe "conta_local = nome_do_dominioconta_no_dominio", como em:

joao = DOMINIOgdh
joao = DOMINIOmaria
joao = DOMINIOjose
joao = DOMINIOisac

Basta criar um arquivo de texto usando qualquer editor e salvá-lo, prestando atenção no uso de barras invertidas. Quando qualquer usuário especificado no arquivo é autorizado pelo PDC, o servidor Samba local realiza a leitura no sistema de arquivos utilizando a conta "joao", que é a única cadastrada localmente. Com isso, você precisa apenas manter o arquivo atualizado, sem se preocupar com com senhas. Ao administrar uma rede com várias estações, é interessante manter o SSH ativo em todas as máquinas, de forma que você possa atualizar o arquivo remotamente, quando necessário. Ao serem acessados através do ambiente de rede, os compartilhamentos das estações de trabalho Linux ficam disponíveis para as demais máquinas do domínio sem necessidade de autenticação adicional, já que a autenticação é centralizada no PDC. Aqui temos um exemplo de máquina Linux, configurada como cliente do PDC, que está compartilhando uma pasta com a rede:

Concluindo, caso você deseje mais tarde remover a máquina Linux do domínio, basta alterar novamente o smb.conf (na estação), mudando a linha "workgroup = ", para que ela passe a indicar o nome do grupo de trabalho (e não mais do domínio) e alterar a linha "security = domain" para "security = user", como em:

[global]
workgroup = grupo
netbios name = M5
security = user
encrypt passwords = yes

Depois de reiniciar o Samba (ou aguardar o tempo de atualização após a mudança no arquivo), a estação deixa o domínio e volta a fazer parte do grupo de trabalho. A principal limitação dessa configuração é que ela permite centralizar apenas a autenticação dos compartilhamentos de rede, mas não resolve o problema da autenticação local nas estações Linux, que continua sendo feita da forma tradicional. Isso nos leva ao tópico seguinte...

Usando o PDC para autenticação local no Linux

É possível configurar os clientes Linux para fazerem a autenticação dos usuários locais no PDC e armazenarem as configurações no próprio servidor (assim como no caso das máquinas Windows), mas, nesse caso, a configuração é bem mais complicada, 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 para buscar os logins no servidor e assim autenticar o usuário. Se você procura uma solução simples e limpa, recomendo que se limite à configuração que mostrei até aqui. Se não se importa de sujar as mãos, continue por sua conta e risco. :) Esta configuração é indicada para distribuições derivadas do Debian que utilizam o KDM. 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]
netbios name = cliente1
workgroup = Dominio
winbind use
default domain = yes
obey pam restrictions = yes
security = domain
encrypt passwords = true
wins server = 192.168.1.254
winbind uid = 10000-20000
winbind gid = 10000-20000
template shell = /bin/bash
template homedir = /home/%U
winbind separator = +
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.254" 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

Nesse ponto o cliente já estará 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 noiní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 ele também não vai conseguir se logar nas estações. Ainda no cliente, acesse a pasta "/etc/rc5.d" e verifique se os links responsáveis por inicializar os serviços samba, winbind e kdm foram criados corretamente. Eles precisam ser carregados nessa ordem. No caso de distribuições que inicializam o KDM primeiro, 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 PDC. 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 Debian com cara de Debian e assim por diante.

Fonte: www.mktecnologia.net.br

Configuração Avançada do Samba

2013-05-22T08:54:00.004-07:00

A maior parte da 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 dentro da interface. Isso permite que o Swat coexista com a edição manual do arquivo. Como comentei a pouco, o Swat remove todos os seus comentários e formatação (deixando apenas as opções), por isso muitos evitam usá-lo. Apesar disso, o formato do arquivo de configuração do Samba é bastante simples e por isso muitas vezes é mais rápido e até mais simples editar diretamente o arquivo do que fazê-lo através do Swat. Ao instalar o Samba, é criado um arquivo de configuração de exemplo, com vários comentários. Assim como no caso do Squid, ele é longo e difícil de entender, por isso acaba sendo mais fácil renomeá-lo e começar com um arquivo em branco, ou usar como base a configuração gerada através do Swat. Vamos então a uma segunda rodada de explicações sobre a configuração do Samba, agora editando diretamente o arquivo smb.conf e explorando com maior profundidade as opções disponíveis. Vamos começar com um exemplo simplista, onde temos um único compartilhamento de teste:

[global]
netbios name = Sparta
workgroup = Grupo

[arquivos]
path = /mnt/arquivos
comment = Teste

Como você pode ver, o arquivo é dividido em seções. A primeira é sempre a seção "[global]", que contém as opções gerais do servidor. Por enquanto, definimos apenas o nome do servidor (netbios name) e o nome do grupo de trabalho (workgroup), que seria o mínimo necessário para colocar o servidor na rede. As demais opções (não especificadas no arquivo) são configuradas usando os valores default. Se você omitir a opção "workgroup", por exemplo, o Samba vai reverter para o grupo "WORKGROUP", que é o padrão. Se quiser, você pode também adicionar uma descrição para o servidor, o que é feito através da opção "server string" (adicionada dentro da seção [global]), como em:

server string = Servidor Samba

Duas dicas são que:

O default do Samba é usar a string "Samba 3.0.24" (onde o "3.0.24" é a versão usada) como descrição quando a opção "server string" não está presente no arquivo.
Nas máquinas com o Windows XP, a descrição do servidor aparece antes do nome propriamente dito, como em "Servidor Samba (Sparta)". É importante levar isso em consideração, já que, no final das contas, o que importa é o que os usuários irão ver ao navegar pelo ambiente de redes:

Abaixo da seção [global], incluímos seções adicionais para cada compartilhamento, que é o caso da seção "[arquivos]" que cria o compartilhamento de teste. O "[arquivos]" indica o nome do compartilhamento, da forma como ele aparecerá na rede. Logo a seguir temos a linha "path", que diz qual pasta do servidor será compartilhada e a linha "comment" (opcional), que permite que você inclua um comentário. Sempre que alterar manualmente o smb.conf, ou mesmo alterar algumas opções pelo Swat e quiser verificar se as configurações estão corretas, rode o comando testparm. Ele funciona como uma espécie de debug, indicando erros grosseiros no arquivo e informando o papel do servidor na rede:

# testparm
Load smb config files from /etc/samba/smb.conf
Processing section "[arquivos]"
Loaded services file OK.
Server role: ROLE_STANDALONE

O "ROLE_STANDALONE" significa que o servidor foi configurado como um membro normal do grupo de trabalho. É possível também fazer com que o servidor Samba atue como um controlador de domínio, como veremos em detalhes mais adiante. Em caso de erros no arquivo, o testparm ajuda a localizar o problema, indicando a linha ou opção inválida, de forma que você possa corrigí-la. Veja o que acontece ao adicionar um erro simples, usando a linha "wrritable = yes" no lugar de "writable = yes":

Unknown parameter encountered: "wrritable"
Ignoring unknown parameter "wrritable"

O Samba não diferencia o uso de maiúsculas e minúsculas nas opções, de forma que tanto faz escrever "writable = yes", "writable = Yes" ou "writable = YES". Entretanto, muitos dos parâmetros não são diretamente usados pelo Samba, mas sim repassados ao sistema que, diferentemente do Samba, diferencia os caracteres. Um exemplo são as localizações de pastas a compartilhar. Se você escrever "path = /mnt/Arquivos" (em vez de "path = /mnt/arquivos"), o compartilhamento não vai funcionar, pois o sistema reportará que a pasta não existe. Além do caractere "#", é possível usar também o ";" para comentar linhas. A principal observação é que você não pode inserir comentários em linhas válidas (mesmo que no final da linha), pois, ao fazer isso, toda a linha passa a ser ignorada pelo Samba. Neste exemplo, o comentário foi incluído na linha "path", o que acaba por desativar o compartilhamento completamente:

[teste] path = /mnt/arquivos
# Pasta compartilhada
comment = Compartilhamento que não funciona

O testparm também não indica o erro diretamente, já que ele também considera a linha como um comentário, o que pode levá-lo a perder um bom tempo tentando descobrir onde está o problema. Ao incluir comentários no arquivo, use sempre linhas separadas:

[teste]
# Pasta compartilhada
path = /mnt/arquivos
comment = Agora sim

As alterações no arquivo são lidas periodicamente pelo Samba (o default são 3 minutos) e aplicadas automaticamente. Isso permite que as mudanças de configuração sejam aplicadas de forma suave, sem prejudicar o acesso dos usuários, o que é importante em um ambiente de produção. Para fazer com que as alterações entrem em vigor imediatamente, reinicie o serviço do Samba, como em:

# /etc/init.d/samba restart

ou:

# service smb restart

A partir daí, o compartilhamento estará disponível. Ao tentar acessar o servidor através do "Meus locais de rede" nos clientes Windows, você receberá um prompt de senha, onde você precisa fornecer um dos logins cadastrados no servidor usando o comando "smbpasswd -a":

É importante enfatizar que todos os usuários cadastrados no Samba precisam também existir no sistema, por isso, antes de usar o comando "smbpasswd -a", você deve usar o adduser para criar o usuário. Como citei anteriormente, a solução para casos em que você não deseja criar contas válidas para todos os usuários é criar usuários limitados usando o comando "adduser --disabled-login --no-create-home usuario" ou "adduser -M usuario". Depois de logado, o cliente pode visualizar os compartilhamentos do servidor. Por enquanto temos apenas o compartilhamento "arquivos", que mostra o conteúdo da pasta "/mnt/arquivos" do servidor, mas ao longo do tutorial adicionaremos muitos outros recursos ao servidor:

Ajustando as permissões de acesso

Com esta configuração, os clientes conseguem visualizar os arquivos da pasta normalmente, mas ainda não conseguem gravar nos arquivos. Ao tentar salvar alguma coisa na pasta, você recebe uma mensagem de acesso negado:

Isso acontece por dois motivos. O primeiro é que o default do Samba é compartilhar com permissão apenas para leitura. Como não dissemos nada sobre as permissões de acesso do compartilhamento no arquivo de configuração, ele foi compartilhado usando o default. Para que o compartilhamento fique disponível com permissão de leitura e escrita, precisamos adicionar a opção "writable = yes" dentro da configuração do compartilhamento, que ficará:

[arquivos]
path = /mnt/arquivoswritable = yes
comment = Teste

Muito provavelmente, mesmo depois de reiniciar o Samba você continuará recebendo o mesmo erro ao tentar gravar os arquivos. Dessa vez, o Samba autoriza a gravação, mas ela ainda pode ser abortada se as permissões da pasta não permitirem que o usuário grave arquivos. Se você criou a pasta "/mnt/arquivos" como root, então o default é que apenas ele possa gravar arquivos na pasta. Para permitir que outros usuários possam gravar, é necessário abrir as permissões da pasta. A esta altura, a lei do mínimo esforço diria para você usar um:

# chmod 777 /mnt/arquivos

Obviamente, isso permitiria que os usuários gravassem na pasta. O problema é que as permissões ficariam escancaradas, a ponto de qualquer um, que tenha acesso ao servidor (por qualquer meio) possa alterar os arquivos dentro da pasta, o que não é nada bom do ponto de vista da segurança. No tópico sobre o Swat, vimos como criar um grupo usando o users-admin (system-config-users) e abrir as permissões da pasta apenas para os usuários que fazem parte dele. Vamos ver agora como fazer isso via linha de comando. O primeiro passo é criar um grupo para os usuários que poderão fazer alterações na pasta, usando o comando "groupadd". Eu prefiro criar grupos com o mesmo nome do compartilhamento, para ficar mais fácil de lembrar, mas isso fica a seu critério.

# groupadd arquivos

A partir daí, você pode adicionar usuários ao grupo usando o comando "adduser", nesse caso especificando o usuário já criado e o grupo ao qual ele será adicionado, como em:

# adduser joao arquivos
# adduser maria

arquivos Para remover usuários do grupo, você usa o comando "deluser", como em:

# deluser joao arquivos
# deluser maria arquivos

Depois de criar o grupo e adicionar os usuários a ele, falta apenas ajustar as permissões de acesso da pasta, de forma que o grupo tenha acesso completo, como em:

# chgrp arquivos /mnt/arquivos
# chmod 775 /mnt/arquivos

Com isso, trocamos o grupo dono da pasta e dizemos que tanto o dono quanto o grupo possuem acesso completo. A partir desse ponto, o Samba autoriza o acesso para todos os usuários cadastrados através do smbpasswd e o sistema autoriza a gravação para todos os usuários que fazem parte do grupo. Se você precisar que a alteração seja aplicada de forma recursiva, alterando as permissões de todas as subpastas e arquivos, adicione a opção "-R" nos dois comandos, como em:

# chgrp -R arquivos /mnt/arquivos
# chmod -R 775 /mnt/arquivos

Além de servirem para controlar as permissões de acesso dos usuários às pastas do sistema, os grupos podem ser usados para ajustar as permissões de acesso do Samba, de forma bastante simples. Se você quer que o compartilhamento fique disponível apenas para os usuários que cadastrou no grupo "arquivos", adicione a opção "valid users = +arquivos" na seção referente ao compartilhamento. O "+" indica que se trata de um grupo e não de um usuário isolado. O Samba verifica então quais usuários fazem parte do grupo e autoriza o acesso. A partir daí, quando você quiser liberar o acesso para um novo usuário, basta adicioná-lo ao grupo:

[arquivos]
path = /mnt/arquivos
writable = yesvalid users = +arquivos

Você pode também especificar uma lista de usuários isolados, separando-os por vírgula, por espaço, ou pelos dois combinados (o que preferir), como em:

[arquivos]
path = /mnt/arquivos
writable = yes
valid users = joao, maria, jose

É possível também combinar as duas coisas, indicando um ou mais grupos e também alguns usuários avulsos, como em:

[arquivos]
path = /mnt/arquivos
writable = yesvalid users = +arquivos, jose, joaquim, +admin

Assim como na maioria das opções do Samba, a opção "valid users" é exclusiva, ou seja, ao dizer que os usuários do grupo arquivos devem ter acesso, você automaticamente exclui todos os outros. Você pode também fazer o oposto, criando uma lista de usuários que não devem ter acesso e mantendo o acesso para os demais. Nesse caso, você usaria a opção "invalid users", como em:

[arquivos]
path = /mnt/arquivos
writable = yesinvalid users = jose, joaquim

Nesse caso, todos os usuários cadastrados no Samba podem acessar, com exceção dos usuários jose e joaquim. É possível ainda usar a opção "invalid users" para especificar exceções ao especificar grupos usando a opção "valid users", como em:

[arquivos]
path = /mnt/arquivos
writable = yesvalid users = +arquivos
invalid users = joao

Nesse caso, todos os usuários dentro do grupo arquivos terão acesso, com exceção do joao. Esta combinação pode ser usada em casos onde o grupo é especificado também em outros compartilhamentos e você precisa bloquear o acesso do usuário a um compartilhamento específico, sem removê-lo do grupo. É possível também criar uma lista de escrita, usando a opção "write list". Ela cria uma camada adicional de proteção, permitindo que, dentro do grupo de usuários com acesso ao compartilhamento, apenas alguns tenham permissão para alterar os arquivos, como em:

[arquivos]
path = /mnt/arquivoswritable = no
valid users = +arquivoswrite list = maria

Nesse caso, usamos a opção "writable = no", que faz com que o compartilhamento passe a ser somente-leitura. A seguir, especificamos que os usuários do grupo "arquivos" devem ter acesso (somente-leitura) e usamos a opção "write list = maria" para criar uma exceção, dizendo que a maria pode escrever na pasta. É importante notar que, neste exemplo, a maria deve fazer parte do grupo "arquivos", caso contrário teríamos uma situação interessante, onde ela não consegue alterar os arquivos no compartilhamento, pois não tem acesso a ele em primeiro lugar. :) Caso a maria não estivesse cadastrada no grupo, você deveria incluir o login na opção "valid users", como em:

[arquivos]
path = /mnt/arquivos
writable = no
valid users = +arquivos, maria
write list = maria

Podemos também fazer o oposto, restringindo a escrita para alguns usuários, mas mantendo o acesso para todos os demais. Nesse caso, usamos a opção "read list" para criar uma lista de exceções, como em:

[arquivos]
path = /mnt/arquivoswritable = yes
valid users = +arquivos, +adminread list = maria, jose

Nesse exemplo, usamos a opção "writable = yes" e especificamos que os usuários dentro dos grupos "arquivos" e "admin" tem acesso ao compartilhamento. Em seguida, usamos a opção "read list" para limitar o acesso dos usuários maria e jose, de forma que eles possam apenas ler, sem alterar os arquivos dentro da pasta. Outra opção relacionada é a "read only", que também aceita os valores "yes" e no". Na verdade, ela tem a mesma função da opção "writable", apenas usa uma lógica invertida. Dizer "writable = yes" ou dizer "read only = no" tem exatamente o mesmo efeito, como seis e meia-dúzia. Em geral, você usa uma ou outra de acordo com o contexto, como uma forma de tornar o arquivo mais legível, como em:

[modelos]
path = /mnt/modelosread only = yes

Continuando, é possível restringir o acesso também com base no endereço IP ou no nome da máquina a partir da qual o usuário está tentando acessar o compartilhamento. Isso permite adicionar uma camada extra de segurança no acesso a arquivos importantes, já que além do login e senha, é verificado a partir de qual máquina o acesso é proveniente. Isso é feito através das opções "hosts allow" e "hosts deny" que permitem, respectivamente, criar uma lista de máquinas que podem e que não podem acessar o compartilhamento. As listas podem incluir tanto os endereços IP quanto os nomes das máquinas. Para restringir o acesso ao compartilhamento a apenas duas máquinas específicas, você usaria:

[arquivos]
path = /mnt/arquivos
writable = yeshosts allow = 192.168.1.23, 192.168.1.24

[arquivos]
path = /mnt/arquivos
writable = yeshosts allow = sparta, athenas

É possível também fazer o inverso, bloqueando o compartilhamento para acessos provenientes das duas máquinas. Nesse caso, mesmo que o usuário tente acessar usando um login válido, vai receber a mensagem de acesso negado, como se o login tivesse sido bloqueado ou a senha tenha sido alterada. A lista não possui um tamanho máximo, você pode incluir quantas máquinas precisar, separando os endereços ou nomes por vírgula e espaço. Você pode inclusive misturar endereços IP com nomes de máquinas, como nesse exemplo:

[arquivos]
path = /mnt/arquivos
writable = yeshosts deny = 192.168.1.23, athenas

É possível ainda combinar a restrição com base nos nomes e endereços com a restrição com base nos logins de acesso, de forma que o acesso seja autorizado apenas quando as duas condições forem satisfeitas. Para permitir que apenas a maria e o joao acessem o compartilhamento e ainda assim apenas se estiverem usando uma das duas máquinas permitidas, você usaria:

[arquivos]
path = /home/arquivos
writable = yesvalid users = maria, joao
hosts allow = 192.168.1.23, 192.168.1.24

Você pode autorizar ou restringir o acesso para uma faixa inteira de endereços omitindo o último octeto do endereço. Por exemplo, para que apenas clientes dentro da rede "192.168.1.x" tenham acesso, você inclui apenas a parte do endereço referente à rede, omitindo o octeto referente ao host, como em:

[arquivos]
path = /mnt/arquivos
writable = yeshosts allow = 192.168.1.

Se precisar criar exceções, limitando o acesso a algumas máquinas dentro da faixa de endereços especificada, você pode usar a opção "EXCEPT" para especificar as exceções, como em:

[arquivos]
path = /mnt/arquivos
writable = yeshosts allow = 192.168.1. EXCEPT 192.168.1.23, 192.168.1.24

Com isso, todos os endereços dentro da faixa teriam acesso, com exceção do .23 e do .24. O mesmo pode ser feito ao usar a opção "hosts deny", como em:

[restrito]
path = /mnt/sda2/restrito
writable = yes
valid users = isachosts deny = 192.168.1. EXCEPT 192.168.1.23

Aqui a lógica é invertida e todos os hosts dentro da faixa de endereços são bloqueados, com exceção do .23, que passa a ser o único aceito pelo servidor. Outro parâmetro que pode ser usado ao criar exceções é o "ALL", que inclui todos os endereços possíveis. Se a idéia é que apenas um determinado endereço possa acessar o compartilhamento, uma opção é usar "hosts deny = ALL EXCEPT 192.168.1.34". O default do Samba é permitir o acesso a partir de qualquer máquina, de forma que se você não usar nem a opção "hosts allow", nem a "hosts deny", qualquer máquina poderá acessar o compartilhamento. Ao usar apenas a opção "hosts allow", apenas as máquinas listadas terão acesso ao compartilhamento, as demais serão recusadas. Ao usar apenas a opção "hosts deny", apenas as máquinas listadas não terão acesso ao compartilhamento (as demais continuam acessando). Ao combinar o uso das opções "hosts allow" e "hosts deny", a opção "hosts allow" tem precedência (não importa a ordem em que elas sejam colocadas), de forma que as máquinas listadas terão acesso, mesmo que ele seja negado pela opção "hosts deny". Por exemplo, ao usar:

[isos]
path = /mnt/isos
hosts allow = 192.168.1.
hosts deny = 192.168.1.43
comment = Algo está errado

O host "192.168.1.43" continuará tendo acesso ao compartilhamento, pois faz parte da faixa de endereços cujo acesso é autorizado pela opção "hosts allow". Neste caso, o Samba não considera a opção "hosts deny = 192.168.1.43" como uma exceção, mas sim como um erro de configuração. Para bloquear a máquina, você deveria usar:

[isos]
path = /mnt/isos
hosts allow = 192.168.1. EXCEPT 192.168.1.43
comment = Agora sim

Em situações onde você precisa restringir temporariamente o acesso a um determinado compartilhamento (para alguma tarefa de manutenção, por exemplo) você pode usar a opção "available = no", como em:

[arquivos]
path = /home/arquivos
writable = yes
valid users = maria, joaoavailable = no

Ela faz com que o compartilhamento "desapareça", da mesma forma que se você apagasse ou comentasse a configuração. A principal vantagem é que ao apagar você precisaria escrever tudo de novo para reativar o compartilhamento, enquanto ao usar o "available = no" você precisa apenas remover a opção ou mudar para "available = yes". Outra opção interessante que pode ser incluída é a "browseable = no", que transforma o compartilhamento em um compartilhamento oculto:

[arquivos]
path = /home/arquivos
writable = yesbrowseable = no

Com isso, ele não aparece mais no ambiente de redes, mas pode ser acessado normalmente se você especificar o nome manualmente ao mapear o compartilhamento:

Essa não é propriamente uma opção de segurança, mas pode ser usada para afastar os curiosos dos compartilhamentos com acesso restrito. Concluindo, muitas opções que ficam disponíveis no Swat podem ser omitidas ao configurar manualmente, simplesmente porque são o default no Samba. O próprio Swat evita incluir opções redundantes ao gerar o arquivo, incluindo apenas as configurações que são diferentes dos valores default. Não é necessário incluir opções como "writable =no", "available = yes" ou "browseable = yes" no arquivo, pois estes já são os valores usados por padrão no Samba. Apesar disso, usá-los também não atrapalha em nada, de forma que nada impede que você os inclua no arquivo para se lembrar mais facilmente das opções. Outra dica é que você pode verificar a qualquer momento quais usuários e quais máquinas estão acessando compartilhamentos no servidor usando o comando "smbstatus, como em:"

# smbstatus

Samba version 3.0.24
PID Username Group Machine
-------------------------------------------------------------------
17107 gdh gdh hp (192.168.1.2)
11588 gdh gdh semprao (192.168.1.10)
Service pid machine Connected at
-------------------------------------------------------------------
IPC$ 17107 hp Sun Oct 28 15:54:04 2007
arquivos 11588 semprao Sun Oct 28 15:23:59 2007
No locked files

Neste exemplo, podemos ver que o usuário "gdh" está logado no servidor a partir de duas máquinas diferentes, um indício de que duas pessoas estão utilizando a mesma conta.

A Seção [Global]

Todas as opções colocadas dentro da seção referente ao compartilhamento valem apenas para ele, o que permite que você crie diversos compartilhamentos diferentes e use um conjunto próprio de permissões para cada um. Estas mesmas opções, junto com um conjunto adicional podem ser especificadas de forma geral dentro da seção [global] do smb.conf. Nos exemplos anteriores, especificamos apenas o nome do servidor e o grupo de trabalho na seção [global]. Isto é suficiente para o servidor participar da rede e compartilhar arquivos, mas, naturalmente, existem muitas outras opções que podem ser usadas. Em primeiro lugar, temos o nível de segurança do servidor, definido através da opção "security". O default no Samba 3 é usar o controle de acesso baseado em usuário, que é o mesmo modo de acesso usado pelas versões domésticas do Windows 2000, XP e Vista. Neste modo, você cadastra os logins e senhas no servidor, define as permissões de acesso e o servidor checa as credenciais dos clientes antes de autorizar o acesso, a configuração que vimos até aqui. Este modo é ativado adicionando a opção "security = user" na seção [global], mas não é necessário usá-la no Samba 3, pois, como disse, ela é usada por padrão:

security = user

Em seguida, temos o modo "security = domain". Ao contrário do que o nome pode sugerir à primeira vista, este modo não é destinado a fazer com que o Samba atue como um controlador de domínio. Pelo contrário, ao configurar um servidor Samba como PDC, você continua usando a opção "security = user", da mesma forma que faria ao usar um servidor em modo stand alone. A opção "security = domain" é usada quando você quer que um servidor Samba participe do domínio como cliente, autenticando-se em um servidor PDC já existente (que pode tanto ser outro servidor Samba, quanto ser um servidor Windows). Existem ainda os modos "security = share" e "security = server", que imitam o sistema de acesso utilizado por estações Windows 95/98. Estes dois modos são obsoletos e devem ser removidos em futuras versões do Samba. Antigamente, o modo "security = share" era usado em casos onde você queria disponibilizar compartilhamentos públicos na rede, sem muita segurança, mas hoje em dia isso pode ser feito usando a conta guest (como veremos em detalhes mais adiante). O modo "security = server" descende da época em que o Samba ainda não era capaz de atuar como PDC; este modo permitia que ele atuasse como um proxy de autenticação, repassando as requisições para o servidor de autenticação principal. Atualmente este modo não é mais usado. Outra opção usada por padrão no Samba 3 é a "encrypt passwords = yes", de forma que também não é necessário especificá-la manualmente no arquivo. Entretanto, é saudável incluí-la em modelos e exemplos de configuração pois pode acontecer de alguém tentar usar o modelo no Samba 2, onde o default era que ela ficasse desativada.

encrypt passwords = yes

É muito comum que seja incluída também a opção "invalid users = root", uma medida de segurança para evitar que a conta de root seja usada ao acessar o servidor. A lógica é que a conta de root é a única conta presente em qualquer sistema Linux, de forma que alguém que decidisse usar um ataque de força bruta para tentar obter acesso ao servidor, testando todas as senhas possíveis, começaria justamente pela conta de root. Entretanto, a conta de root é necessária para dar upload de drivers de impressão e para logar os clientes ao usar o servidor Samba como PDC, situações onde a linha "invalid users = root" deve ser comentada ou removida. Continuando, as opções definidas dentro da seção [global] valem para todos os compartilhamentos do servidor, diferente das opções colocadas dentro da seção referente a cada um. Por exemplo, ao usar:

[global]
netbios name = Servidor
workgroup = Grupo
hosts allow = 192.168.1.

Apenas as máquinas dentro da faixa de endereços especificadas terão acesso ao servidor, o que seria interessante do ponto de vista da segurança, já que de qualquer forma o servidor deve ser acessado apenas por clientes da rede local. O maior problema é que a opção "hosts allow" usada na seção [global] tem precedência sobre qualquer opção "hosts deny" usada dentro dos compartilhamentos, o que pode criar problemas caso você queira restringir o acesso de alguma máquina da rede local a um determinado compartilhamento. Por exemplo, ao usar:

[global]
netbios name = Servidor
workgroup = Grupohosts allow = 192.168.1.

[share]
path = /mnt/sda2/sharedhosts deny = 192.168.1.2

A máquina "192.168.1.2" continuaria tendo acesso ao compartilhamento [share], pois o acesso é autorizado pela opção "hosts allow = 192.168.1." usada na seção [global]. Nesse caso, o melhor seria remover a linha "hosts allow = 192.168.1." da seção [global] e deixar apenas a opção "hosts deny = 192.168.1.2" na seção [share]:

[global]
netbios name = Servidor
workgroup = Grupo

[share]
path = /mnt/sda2/sharedhosts deny = 192.168.1.2

Em caso de conflito direto entre uma regra definida na seção [global] e outra definida em um dos compartilhamentos, a regra definida na seção [global] tem precedência. Por exemplo, ao usar:

[global]
netbios name = Servidor
workgroup = Grupohosts deny = 192.168.1.3

[share]
path = /mnt/sda2/sharedhosts allow = 192.168.1.3

A máquina "192.168.1.3" continuará sem acesso ao compartilhamento "share" (ou a qualquer outro recurso do servidor), já que vale a regra definida na seção [global]. Enquanto a linha "hosts deny = 192.168.1.3" não for removida, a máquina não terá acesso a nenhum dos compartilhamentos, não importa o que digam as demais linhas do arquivo. Continuando, um problema comum enfrentado ao administrar uma rede mista são os usuários escreverem a primeira letra do login em maiúsculo, como em "Joao" no lugar de "joao". No Windows isso não é um problema, já que o sistema é case insensitive, mas no Linux faz com que o sistema recuse o login. Uma forma de evitar isso no Samba é usar a opção "username level", como em:

username level = 2

Esta opção faz com que o Samba verifique várias combinações de maiúsculas e minúsculas caso o login seja recusado pelo sistema. O número indica o volume de variações, que pode ser qualquer número inteiro. Ao usar o valor "2", o Samba verifica até dois níveis, incluindo variações como JOao, jOAo, Joao, jOaO e assim por diante. Usar um número maior pode retardar a autenticação, já que o Samba precisará testar muitas combinações, por isso são geralmente usados os valores "1" ou "2". Outra peculiaridade digna de nota é a questão dos nomes de arquivos. No Windows, os nomes de arquivos são salvos da forma como digitados pelo usuário, preservando os caracteres maiúsculos e minúsculos. Entretanto, o sistema é case insensitive, de forma que o sistema não diferencia um arquivo chamado "Trabalho.txt" de outro chamado "trabalho.txt". Embora o Linux seja case sensitive, o Samba tenta emular o comportamento de uma máquina Windows ao localizar arquivos. Se o cliente pede o arquivo "Trabalho.txt", quando na verdade o arquivo armazenado na pasta se chama "trabaLho.txt" o Samba vai acabar fornecendo o arquivo correto para o cliente, pois o encontrará depois de testar diversas combinações de maiúsculas e minúsculas. No Samba 3 este recurso funciona muito bem, mas tem a desvantagem de consumir uma certa quantidade de memória do servidor. Em um pequeno servidor de rede local, isso não faz diferença, mas em um servidor que atende um grande número de requisições, a diferença pode se tornar considerável. Você pode simplificar as coisas orientando o Samba a salvar todos os arquivos em minúsculas. Para isso, adicione as linhas:

preserve case = no
default case = lower

No caso de servidores com duas ou mais interfaces de rede, sobretudo no caso de servidores conectados simultaneamente à internet e à rede local, você pode especificar qual interface será usada pelo Samba através da opção "interfaces", que deve ser combinada com a opção "bind interfaces only = yes". Para que o servidor escute apenas a interface eth0, ignorando tentativas de conexão em outras interfaces, você usaria:

interfaces = eth0
bind interfaces only = yes

Por default, o Samba escuta em todas as interfaces, o que (se não houver nenhum firewall ativo) pode expor seus compartilhamentos para a Internet caso você ative o Samba em uma máquina conectada diretamente à internet, como no caso de um servidor que compartilha a conexão. É recomendável usar sempre estas duas opções, como uma forma de garantir que o Samba ficará disponível apenas na interface desejada. Outra opção interessante é a "netbios aliases", que permite criar "apelidos" para o servidor, de modo de que ele possa ser acessado por mais de um nome. Usando um alias, o servidor realmente aparece duas ou mais vezes no ambiente de rede, como se existissem várias máquinas. Geralmente, isso acaba confundindo mais do que ajudando, mas pode ser útil em algumas situações, quando, por exemplo, um servidor é desativado e os compartilhamentos são movidos para outro. O novo servidor pode responder pelo nome do servidor antigo, permitindo que os desavisados continuem acessando os compartilhamentos através do endereço anterior. Para usá-la, basta adicionar a opção, seguida pelos apelidos desejados, como em:

[global]
netbios name = Servidor
netbios aliases = athenas, sparta
workgroup = Grupo

No tópico sobre o Swat falei sobre as opções "Local Master", "OS Level" e "Preferred Master", que definem se o servidor Samba deve participar das eleições para Master Browser e com qual nível de credencial. Para que o servidor participe com OS Level 100, você adicionaria as linhas:

local master = yes
os level = 100
preferred master = yes

Um segundo servidor Samba na rede poderia participar com uma credencial mais baixa, de forma a assumir o cargo apenas caso o servidor principal esteja desconectado da rede. Para isso, basta usar um valor mais baixo na opção OS Level, como em:

local master = yes
os level = 90
preferred master = no

O valor da opção OS Level é absoluto, não se trata de um sorteio. Um servidor configurado com o valor "100" ganha sempre de um com o valor "99", por exemplo. Se você omitir as três linhas, o servidor simplesmente utiliza os valores default (local master = yes, os level = 20), que fazem com que ele participe das eleições, mas utilize credenciais baixas. A opção "wins support = yes" faz com que o servidor Samba passe a trabalhar como um servidor WINS (Windows Internetworking Name Server) na rede. O WINS é um protocolo auxiliar dentro das redes Microsoft, responsável pela navegação na rede e listagem dos compartilhamentos e outros recursos disponíveis, de forma similar a um servidor DNS. O uso do WINS não é obrigatório; sua rede vai muito provavelmente funcionar muito bem sem ele. Entretanto, sem um servidor WINS os clientes passam a usar pacotes de broadcast para a navegação (a menos que você utilize um domínio), o que aumenta o tráfego da rede e torna todo o processo mais passível de falhas. Outra limitação importante é que os pacotes de broadcast são descartados pelos roteadores, o que faz com que eles (os pacotes de broadcast) não sejam transmitidos de um segmento a outro da rede caso ela esteja dividida em vários segmentos, interligados através de roteadores. O mesmo acontece caso você tenha duas redes ligadas através de uma VPN, onde o tráfego seja roteado. Em ambos os casos, os pacotes de broadcast são descartados pelos roteadores, fazendo com que os micros em um segmento não enxerguem os micros do outro e vice-versa. A solução em ambos os casos é implantar um servidor WINS na rede. Com isso, os clientes passam a consultar o servidor ao invés de mandar pacotes de broadcast, fazendo com que a navegação funcione mesmo ao utilizar vários segmentos de rede. Para isso, basta incluir a opção dentro da seção [global] do smb.conf:

wins support = yes

O próximo passo é configurar os clientes da rede para utilizarem o servidor. A opção fica escondida nas propriedades da conexão de rede, no Protocolo TCP/IP > Propriedades > Avançado > WINS, onde você deve adicionar o endereço IP do servidor:

A configuração do servidor WINS pode ser também enviada automaticamente para os clientes. Para isso, é necessário incluir a opção "netbios-name-servers" na configuração do servidor DHCP (no arquivo "/etc/dhcp3/dhcpd.conf", ou "/etc/dhcpd.conf"), especificando o nome do servidor, como em:

option netbios-name-servers 192.168.1.254;

Esta linha é colocada dentro da seção com a configuração da rede, como nesse exemplo: subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.100 192.168.1.199; option routers 192.168.1.1; option domain-name-servers 192.168.1.1; option netbios-name-servers 192.168.1.254; option broadcast-address 192.168.1.255; } No caso de outros micros Linux rodando o Samba que forem ser configurados como clientes do servidor principal, a configuração é feita adicionando a opção "wins server = servidor" (também na seção [global] do smb.conf), onde você especifica o endereço IP do servidor principal, como em: wins server = 192.168.1.254 Uma observação importante é que as opções "wins support" e "wins server" são mutuamente exclusivas. Ou a máquina atua como servidor WINS, ou como cliente (nunca as duas coisas ao mesmo tempo), de forma que você não deve jamais combinar as duas opções dentro da configuração. Em versões antigas do Samba, combinar as duas opções na configuração simplesmente fazia com que o servidor deixasse de funcionar. Nas atuais o resultado não chega a ser dramático (o servidor vai simplesmente ignorar a opção que for colocada depois), mas mesmo assim este é um erro grave de configuração que deve ser evitado. Um exemplo de seção [global] usando as opções que vimos até aqui seria:

[global]
netbios name = Athenas server
string = Servidor Samba
workgroup = Grupo
username level = 1
preserve case = no
default case = lower
interfaces = eth0
bind interfaces only = yes
local master = yes
os level = 100
preferred master = yes
wins support = yes

Esta configuração ativa o teste de variações de maiúsculas e minúsculas para os logins recusados (apenas um nível), faz com que todos os arquivos salvos nos compartilhamentos sejam renomeados para caracteres minúsculos, faz com que o servidor escute apenas a interface eth0, que seja master browser da rede e que atue como servidor WINS. Este é um arquivo de configuração perfeitamente utilizável, faltaria apenas adicionar as seções referentes aos compartilhamentos.

A Seção [Homes]

Uma vantagem de utilizar usuários "reais" no servidor Samba, em vez de usuários castrados, é que você tem a opção de compartilhar os diretórios home através da seção [homes] no smb.conf. Este é um serviço interno do Samba, que permite compartilhar automaticamente o diretório home de cada usuário, sem precisar criar um compartilhamento separado para cada um. A configuração mais comum é compartilhar os diretórios home com permissão de acesso apenas para o respectivo usuário. Dessa forma, cada usuário tem acesso apenas ao seu próprio diretório home (que aparece no ambiente de redes como um compartilhamento com o mesmo nome), sem poder acessar, nem muito menos alterar o conteúdo dos diretórios home dos demais usuários. Nesse caso, a configuração fica:

[homes]
valid users = %S
read only = no
create mask = 0700
directory mask = 0700
browseable = no

Não é necessário especificar a pasta a compartilhar, pois ao omitir a linha "path" o Samba sabe que deve compartilhar o home de cada usuário. As opções "create mask = 0700" e "directory mask = 0700" fazem com que todos os arquivos e pastas criados pelo usuário dentro do home sejam acessíveis apenas por ele mesmo. A opção "browseable = no" faz com que cada usuário possa ver apenas seu próprio diretório, o que é reforçado pela opção "valid users = %S", que diz explicitamente que apenas o próprio usuário deve ter acesso à sua pasta home. Uma queixa comum é que ao acessar o diretório home através do Samba, os usuários verão todos os arquivos e pastas de configuração de programas que são salvos dentro do diretório home, o que pode ser confuso. Uma forma de evitar isso é alterar a configuração, de forma que o Samba compartilhe uma pasta vazia dentro do home, e não o diretório home em si. Com isso é mantido o propósito de oferecer uma pasta particular para o usuário, onde ele possa salvar seus arquivos particulares e seus backups, sem a poluição gerada pela presença dos arquivos de configuração. A configuração nesse caso ficaria:

[homes]
path = /home/%u/share
valid users = %S
read only = no
create mask = 0700
directory mask = 0700
browseable = no

A linha "path = /home/%u/share" especifica que o Samba deve agora compartilhar a pasta "share" dentro do home e não mais o diretório home em si (você pode especificar outra pasta qualquer) e a linha "valid users = %S" garante que a pasta ficará acessível apenas para o próprio usuário. Naturalmente, a pasta "share" precisa ser criada dentro do home de cada usuário manualmente. Você pode fazer isso de forma automática para todos os usuários usando este mini shell script:

cd /home
for i in *; do
mkdir $i/share
chown $i:$i $i/share
done

Aproveite para criar também a pasta "share" dentro do diretório "/etc/skel", que é usado como um modelo para a criação do home de novos usuários. Isso faz com que o diretório seja adicionado ao home de todos os usuários criados daí em diante, de forma automática:

# mkdir /etc/skel/share

Concluindo, aqui vai uma lista de outras variáveis do Samba para referência:

%a : A versão do Windows usada, onde o "%a" é substituído pelas strings "Win95" (Windows 95/98), "WinNT" (Windows NT 3.x ou 4.x), "Win2K" (Windows 2000 ou XP) ou "Samba" (máquinas Linux rodando o Samba)
%I : Endereço IP da máquina cliente (ex: 192.168.1.2)
%m : Nome da máquina cliente (ex: cliente1)
%L : Nome do servidor (ex: athenas)
%u : Nome do usuário, como cadastrado no servidor Linux (ex: joao)
%U : Nome do usuário, como enviado pelo cliente Windows (pode ser diferente do login cadastrado no servidor em algumas situações)
%H : Diretório home do usuário (ex: /home/maria)
%g : Grupo primário do usuário (ex: users)
%S : Nome do compartilhamento atual (o valor informado entre colchetes, ex: arquivos)
%P : Pasta compartilhada (o valor informado na opção "path", ex: /mnt/arquivos)
%v : Versão do Samba (ex: 3.2.24)
%T : Data e horário atual

Ao longo do texto, veremos alguns outros exemplos de uso destas variáveis, mas você pode usá-las em outras situações para criar compartilhamentos "inteligentes", que mostram pastas diferentes de acordo com as propriedades do cliente. Por exemplo, a variável "%a" (que indica a versão do Windows no cliente), poderia ser usada para criar um compartilhamento com drivers, que mostrasse diretamente a pasta com os drivers corretos para a versão do Windows usada. Nesse caso, você poderia usar algo como:

[drivers]
path = /mnt/sda2/drivers/%a
read only = yes

A pasta "/mnt/sda2/drivers/" incluiria uma série de sub-pastas, com os valores possíveis para a variável, incluindo "Win95", "WinNT", "Win2K" e "Samba". Ao acessar o compartilhamento, o cliente vê apenas o conteúdo da pasta correspondente ao sistema operacional usado.

A Conta Guest

No Windows XP é usado por padrão um modo simplificado de compartilhamento de arquivos, o "simple sharing", que visa imitar o modo de acesso do Windows 95/98, onde os compartilhamentos são públicos e você apenas define se eles são apenas leitura ou leitura e escrita. Na verdade, o Windows XP usa o controle de acesso com base no usuário, assim como o Samba 3, mas, por baixo dos panos, todos os acessos passam a ser mapeados para a conta "guest" (ativa por padrão), o que permite que usuários remotos sem login válido acessem os compartilhamentos diretamente. Este recurso é também chamado de "force guest". Naturalmente, podemos fazer o mesmo no Samba. Para isso, adicione as linhas abaixo dentro da seção [global] do smb.conf:

map to guest = bad
user guest account = guest

A primeira opção faz com que sempre que um cliente especificar um usuário inválido ao tentar acessar o servidor, o servidor mapeie a requisição para o login especificado na opção "guest account", que é usada para acessar o compartilhamento. Neste exemplo, qualquer usuário não autenticado passaria a usar a conta "guest", que deve ter sido previamente cadastrada no servidor. Você pode também usar qualquer outra conta válida, como em "guest account = maria". Uma opção menos usada é a "map to guest = bad password". Ela se diferencia da "map to guest = bad user" pois permite o acesso apenas caso o usuário especifique um login válido, mas erre apenas a senha. O principal motivo dela não ser muito usada é que ela confunde o usuário, já que ele ou vai achar que está realmente logado no servidor (quando na verdade está apenas acessando de forma limitada através da conta guest) ou vai passar a achar que o servidor aceita qualquer senha. Para que os usuários não-autenticados possam acessar os compartilhamentos, você deve explicitamente autorizar o acesso, adicionando a opção "guest ok = yes" na configuração, como em:

[global]
netbios name = Sparta
workgroup = Grupo
map to guest = bad
user guest account = guest

[publico]
path = /mnt/sda2/publico
writable = yesguest ok = yes

Note que no exemplo usei a opção "writable = yes". Entretanto, para que os usuários não-autenticados possam efetivamente escrever na pasta, é necessário verificar se as permissões de acesso da pasta permitem que a conta especificada ("guest" no exemplo) altere os arquivos. Como disse anteriormente, o Samba está subordinado às permissões de acesso do sistema. Outra opção comum em compartilhamentos públicos é a "guest only = yes" (usada no lugar da "guest ok = yes", na seção [global]). Ela simula o "simple sharing" do Windows XP, mapeando qualquer acesso para a conta guest, sem sequer abrir o prompt de login para o cliente. Vamos então a mais um exemplo de configuração do smb.conf, desta vez usando a conta guest para criar um servidor de arquivos público. Ele possui duas partições de arquivos (montadas nas pastas "/mnt/hda2 e "/mnt/sda1") que ficam disponíveis a todos os usuários da rede:

[global]
netbios name = Plutus
server string = Servidor público
workgroup = Grupo
local master = yes
os level = 100
preferred master = yes
wins support = yesmap to guest = bad user
guest account = gdh

[arquivos]
path = /mnt/hda2
writable = yesguest ok = yes

[backups]
path = /mnt/sda1
writable = yes guest ok = yes

Esta configuração é bastante simples e a prova de falhas. O servidor vai assumir a função de master browser, se responsabilizando pela navegação dos clientes e vai mapear qualquer acesso para a conta "gdh" usada na opção "guest account", permitindo que qualquer um possa ler e gravar arquivos nos dois compartilhamentos. As duas principais observações são que o usuário "gdh" deve ser um usuário real do sistema, cadastrado no servidor Samba, e que ele deve ser o dono das duas pastas compartilhadas, de forma que não tenha problemas para acessar seu conteúdo. Isso pode ser feito usando os 4 comandos a seguir:

# adduser gdh <senha>
# smbpasswd -a gdh <mesma senha># chown -R gdh:gdh /mnt/hda2
# chown -R gdh:gdh /mnt/sda1

Essa configuração é ideal para pequenos servidores de rede local, que devem apenas disponibilizar arquivos na rede, sem muita segurança. Ela é similar ao exemplo de configuração para um servidor de arquivos público que incluí no livro Redes, Guia Prático.

Lixeira no Samba

Em qualquer servidor de arquivos, a principal prioridade é assegurar a integridade e a segurança dos dados. Entretanto, por mais estável que seja a rede e por mais robusto que seja o servidor, o elo mais fraco da cadeia acaba sendo sempre o usuário. De nada adianta um servidor perfeitamente estável se ele deleta um arquivo importante sem querer. Pensando nisso, o Samba oferece a opção de usar uma lixeira, que pode lhe poupar muita dor de cabeça em diversas situações. Isso é feito através da opção "vfs object = recycle", que cria uma lixeira dentro de cada pasta compartilhada, que passa a armazenar todos os arquivos deletados. Isso previne a remoção acidental de arquivos, já que o usuário passa a precisar deletar o arquivo e em seguida limpar o conteúdo da lixeira para realmente removê-lo, o que é o comportamento esperado por muitos. Por padrão, os arquivos deletados vão para a pasta ".recycle" (dentro do compartilhamento), mas o nome pode ser alterado através da opção "recycle:repository = lixeira" (onde o "lixeira" é o nome desejado, que pode ser qualquer um). Quando uma pasta é deletada, o padrão é simplesmente misturar todos os arquivos no diretório raiz da lixeira, mas isso pode ser evitado adicionando a opção "recycle:keeptree = yes". Aqui temos mais um exemplo de compartilhamento, incluindo as três opções:

[projetos]
path = /mnt/sda2/projetos
writable = yes
valid users = +apolo, isacvfs object = recycle
recycle:repository = lixeira
recycle:keeptree = yes

Outra opção útil é a "recycle:versions", que faz com que a lixeira mantenha diferentes versões do mesmo arquivo, em vez de manter apenas a última versão. Os arquivos repetidos passam então a ser renomeados para "Copy #1 of Samba.sxw", "Copy #2 of Samba.sxw" e assim por diante.

recycle:versions = yes

Com isso, você passa a dormir um pouco mais tranquilo a noite e se salva (na maior parte dos casos) de precisar recuperar arquivos acidentalmente deletados a partir de backups. É preciso apenas se lembrar de verificar o conteúdo das lixeiras de vez em quando e limpar as pastas quando elas começarem a consumir muito espaço em disco. Você pode inclusive deletar a pasta da lixeira inteira, pois ela é recriada automaticamente quando o próximo arquivo for deletado.

Uma opção para reduzir o problema do espaço desperdiçado é centralizar todas as lixeiras em uma única pasta. Isso permite inclusive que você utilize uma partição ou um HD separado para armazenar os arquivos da lixeira, sem correr o risco de ela crescer até ocupar todo o espaço disponível na partição principal. Para isso, usamos a opção "recycle:repository", seguida da pasta a ser utilizada (que deve ser criada previamente), como em:

recycle:repository = /var/samba/trash/

Como adicionamos o caminho completo (em vez de usar "recycle:repository = lixeira", como no exemplo anterior), a opção pode tanto ser adicionada individualmente em cada compartilhamento quanto ser especificada apenas uma vez na seção [global], o que faz com que a lixeira passe a ser automaticamente usada para arquivos deletados em todos os compartilhamentos do servidor. Centralizar todos os arquivos em uma única pasta criaria uma grande confusão, já que ela misturaria arquivos deletados por todos os usuários. Uma solução é adicionar a variável "%U", que faz com que os arquivos sejam organizados em várias subpastas, separados por usuário (as subpastas usadas por cada usuário são criadas automaticamente conforme necessário). Nesse caso a opção fica:

recycle:repository = /var/samba/trash/%U

O problema em usar essa opção é que os usuários deixam de ver a lixeira, já que ela passa a ficar em uma pasta separada. Uma solução para o problema é criar um novo compartilhamento, que permite que cada usuário veja sua lixeira particular. Para isso, iremos novamente usar a variável "%U":

[lixeira]
path = /var/samba/trash/%U
writable = yes

Usei a opção "writable = yes" para permitir que o próprio usuário possa limpar a lixeira quando quiser, mas isso é opcional. Vale lembrar que para que o usuário consiga limpar os arquivos da lixeira, é necessário que ele tenha permissão de escrita para a pasta "/var/samba/trash/". Nesse caso, você tem a opção de simplesmente abrir as permissões da pasta (chmod 777), ou ajustar manualmente as permissões da sub-pasta de cada usuário, como em:

# chown -R joao:joao /var/samba/trash/joao

Mais uma medida útil para evitar desperdício de espaço é bloquear a gravação de arquivos de backup e de arquivos temporários na lixeira, já que eles costumam ser numerosos e raramente são importantes. É saudável bloquear também arquivos .iso (que são tipicamente muito grandes), de forma que eles sejam também deletados diretamente. As extensões de arquivos são especificadas através da opção "recycle:exclude" e nomes de pasta através da opção "recycle:exclude_dir", como em:

recycle:exclude = *.tmp, *.log, *.obj, ~*.*, *.bak, *.iso
recycle:exclude_dir = tmp, cache

Assim como a "recycle:repository", as demais opções da lixeira podem tanto serem especificadas individualmente dentro de cada compartilhamento quanto diretamente dentro da seção [global], o que é naturalmente o mais simples caso você deseje ativá-la para todos os compartilhamentos. O default do Samba 3 é manter todas as opções desativadas, de forma que a lixeira só é usada quando as opções são especificadas. Um exemplo de configuração, com a lixeira ativa dentro da seção [global], dois compartilhamentos de arquivos e mais o compartilhamento que dá acesso à pasta central da lixeira por parte dos usuários seria:

[global]
netbios name = Phanteon
server string = Servidor com lixeira
workgroup = Grupo
local master = yes
os level = 100
preferred master = yes
wins support = yesvfs objects = recycle
recycle:keeptree = yes
recycle:versions = yes
recycle:repository = /var/samba/trash/%U
recycle:exclude = *.tmp, *.log, *.obj, ~*.*, *.bak, *.iso
recycle:exclude_dir = tmp, cache

[engenharia]
path = /mnt/sda2/engenharia
writable = yes
valid users = +engenheiros

[gerencia]
path = /mnt/gerencia
writable = yes
valid users = paulo, rebeca
hosts allow = micro3, micro4
browseable = no

[lixeira]
path = /var/samba/trash/%U
writable = yes

Auditando Acessos

O Samba oferece também um recurso de geração de log. Ele pode ser ativado adicionando as opções abaixo na seção [global] do smb.conf:

log level = 1
log file = /var/log/samba.log
max log size = 1000

A opção "log level" indica o nível das mensagens (de 0 a 10), sendo que o nível 0 mostra apenas mensagens críticas, o nível 1 mostra alguns detalhes sobre os acessos e os demais mostram diversos níveis de informações de debug, úteis a desenvolvedores. A opção "log file" indica o arquivo onde ele será gerado e a "max log size" indica o tamanho máximo, em kbytes. A partir do Samba 3.04 foi incluído um módulo de auditoria, que permite logar os acessos e as modificações feitas de uma forma muito mais completa que o log tradicional. Isso é feito através do módulo "full_audit", que (do ponto de vista técnico) funciona de forma similar ao módulo "recycle" usado pela lixeira. O primeiro passo é ativar o módulo, o que é feito através da linha abaixo:

vfs objects = full_audit

O próximo passo é definir quais operações devem ser logadas através da opção "full_audit:success", como em:

full_audit:success = open, opendir, write, unlink, rename, mkdir, rmdir, chmod, chown(as opções formam uma única linha)

As opções que incluí no exemplo são open (ler um arquivo), opendir (ver os arquivos dentro de uma pasta), write (alterar um arquivo), unlink (deletar um arquivo), rename (renomear um arquivo), mkdir (criar um diretório), rmdir (remover um diretório), chmod (alterar as permissões de acesso de um arquivo) e chown (mudar o dono de um arquivo). Você pode remover algumas destas opções, deixando apenas as opções desejadas, ou ver uma lista completa das opções que podem ser incluídas no manual do vfs_full_audit, disponível no: http://samba.org/samba/docs/man/manpages-3/vfs_full_audit.8.html Continuando a configuração, especificamos as informações que desejamos que sejam incluídas no log, usando a opção "full_audit:prefix". Aqui podemos utilizar as variáveis que mostrei no tópico sobre o compartilhamento [homes], como a "%u" (o nome do usuário), "%I" (o IP da máquina) e "%S" (o nome do compartilhamento onde foi feito o acesso ou a alteração). Não é necessário incluir a variável referente ao nome da máquina, pois o nome é incluído automaticamente:

full_audit:prefix = %u|%I|%S

Por padrão, o módulo loga não apenas os acessos e modificações, mas também um grande volume de mensagens de alerta e erros gerados durante a operação. A opção "full_audit:failure = none" evita que estas mensagens sejam logadas, fazendo com que o log fique muito mais limpo e seja mais fácil encontrar as opções que realmente interessam:

full_audit:failure = none

Concluindo, especificamos o nível dos alertas, entre os suportados pelo syslog, como em:

full_audit:facility = local5
full_audit:priority = notice

Juntando tudo, temos:

vfs objects = full_audit
full_audit:success = open, opendir, write, unlink, rename, mkdir, rmdir, chmod, chown
full_audit:prefix = %u|%I|%S
full_audit:failure = none
full_audit:facility = local5
full_audit:priority = notice

Esta configuração pode ser tanto incluída dentro da seção [global] (de forma que o log inclua os acessos e as alterações feitas em todos os compartilhamentos) quanto ser incluída apenas na configuração de um compartilhamento específico. Com isso, o Samba vai passar a gerar os eventos referentes aos acessos. Falta agora configurar o sysklogd (o serviço responsável pela geração dos logs do sistema), para logar os eventos, gerando o arquivo de log que poderá ser consultado. Para isso, abra o arquivo "/etc/syslog.conf" e adicione a linha abaixo:

local5.notice /var/log/samba-full_audit.log

Note que o "local5.notice" corresponde aos valores informados nas opções "full_audit:facility" e "full_audit:priority", enquanto o "/var/log/samba-full_audit.log" é o arquivo de log que será gerado. Depois de concluída a configuração, reinicie os serviços e o log passará a ser gerado imediatamente:

# /etc/init.d/samba restart
# /etc/init.d/sysklogd restart

Dentro do arquivo, você verá entradas contendo a data e hora, o nome da máquina, o usuário, o IP da máquina, o nome do compartilhamento, a operação realizada e o nome do arquivo ou pasta onde ela foi realizada, como em:

Nov 18 15:21:15 m5 smbd_audit: joao|192.168.1.23|arquivos|opendir|ok|.
Nov 18 15:21:29 m5 smbd_audit: joao|192.168.1.23|arquivos|open|ok|r|addr.txt
Nov 18 15:21:34 m5 smbd_audit: joao|192.168.1.23|arquivos|mkdir|ok|trabalho
Nov 18 15:21:36 m5 smbd_audit: joao|192.168.1.23|arquivos|opendir|ok|trabalho
Nov 18 15:21:43 m5 smbd_audit: joao|192.168.1.23|arquivos|open|ok|w|trabalho/Samba.sxw
Nov 18 15:21:44 m5 smbd_audit: joao|192.168.1.23|arquivos|open|ok|w|trabalho/foto.jpg

O log conterá entradas referentes a todos os usuários e máquinas, mas é fácil ver apenas as entradas referentes a um determinado usuário, compartilhamento, endereço IP ou outro parâmetro qualquer ao listar o arquivo pelo terminal usando o grep, que permite mostrar apenas as linhas contendo determinados trechos de texto, como em:

# cat /var/log/samba-full_audit.log | grep "joao|192.168.1.23"
(mostra os acessos provenientes do usuário joao, feitos a partir do endereço 192.168.1.23)
# cat /var/log/samba-full_audit.log | grep "|arquivos|"
(acessos feitos ao compartilhamento "arquivos", por parte de qualquer usuário)

E assim por diante. Você pode também direcionar a saída para um novo arquivo (ao invés de tentar lê-la pelo próprio terminal), como em:

# cat /var/log/samba-full_audit.log | grep "|arquivos|" > arquivos.log

Backends: smbpasswd ou tdbsam

As primeiras versões do Samba suportavam apenas o uso de senhas de texto puro, que eram transmitidas de forma não encriptada através da rede. Ainda é possível reverter a este sistema primitivo nas versões recentes do Samba usando a opção "encrypt passwords = no" no smb.conf, mas, além de não trazer nenhuma vantagem, isso quebra a compatibilidade com todas as versões recentes do Windows, que não aceitam o envio de senhas em texto puro. Durante a evolução do Samba, foram criados diversos backends, que permitem armazenar senhas encriptadas e outras informações referentes aos usuários. Você pode escolher qual backend usar através da opção "passdb backend" do smb.conf. Vamos entender como eles funcionam. O smbpasswd é o backend mais simples. Nele, as senhas são salvas no arquivo "/etc/samba/smbpasswd" e são transmitidas de forma encriptada através da rede, com suporte ao sistema NTLM, usado pelas versões contemporâneas do Windows. A vantagem do smbpasswd é que ele é um sistema bastante simples. Embora encriptadas, as senhas são armazenadas em um arquivo de texto, com uma conta por linha. Se você quer apenas configurar um servidor Samba para compartilhar arquivos e impressoras com a rede local, sem usá-lo como PDC, então o smbpasswd funciona bem. Ele é usado por padrão no Samba 3, de forma que se o arquivo smb.conf do seu servidor não contém a linha "passdb backend =" (como nos exemplos que vimos até aqui), você está usando justamente o smbpasswd. Em seguida temos o tdbsam, que usa uma base de dados muito mais robusta, armazenada no arquivo "/var/lib/samba/passdb.tdb" (é justamente este arquivo que o script executado durante a instalação do pacote "samba" no Debian pergunta se deve ser criado). O tdbsam oferece duas vantagens sobre o smbpasswd: oferece um melhor desempenho em servidores com um grande número de usuários cadastrados e oferece suporte ao armazenamento dos controles SAM estendidos usados pelas versões server do Windows. O uso do tdbsam é fortemente recomendável caso seu servidor tenha mais do que algumas dezenas de usuários cadastrados ou caso você pretenda usar seu servidor Samba como PDC da rede (veja mais detalhes a seguir). Ele é também um pré-requisito caso você precise migrar um domínio NT já existente para o servidor Samba. Ao usar uma versão recente do Samba, ativar o uso do tbdsam é bastante simples, basta incluir a linha "passdb backend = tdbsam" na seção [global] do smb.conf, como em:

[global]
netbios name = Sparta
workgroup = Grupo
server string = Servidor
encrypt passwords = true
wins support = yes
preferred master = yes
os level = 100
enable privileges = yespassdb backend = tdbsam

Embora o arquivo de senhas seja diferente, o comando para cadastrar os usuários no Samba ao usar o tdbsam continua sendo o mesmo:

# smbpasswd -a usuario

Isso acontece porque, ao ser executado, o smbpasswd verifica a configuração presente no smb.conf e assim realiza as operações necessárias para cadastrar os usuários no backend utilizado. A principal dica é que, ao utilizar o tdbsam, você deve adicionar a linha "passdb backend = tdbsam" no smb.conf logo no início da configuração, antes de começar a cadastrar os usuários no servidor, caso contrário, o smbpasswd cadastrará os usuários no smbpasswd e você precisará cadastrá-los novamente para atualizar a base do tdbsam mais tarde. Em muitos casos, um script incluído na distribuição pode se encarregar de fazer a conversão automaticamente, mas é melhor não contar com isso. Para verificar se os usuários estão cadastrados na base de dados do tdbsam, use o comando "pdbedit -Lw" (como root). Ele deve retornar uma lista contendo todos os usuários cadastrados, como em:

# pdbedit -Lw

gdh:1006:5567A38FC604AC6B90213960766D16B5:15350B7F4983CB5EAC073A892B423E8E:[U ]:LCT-471F5AF2:
root:0:E412294BCF24C19D433AC183134CC0F3:121797EEFB127E62222B23F77ED087BE:[U ]:LCT-464460FF:
manuel:1005:5567A38FC604AC63902139606B6D16B5:15350B7F4983CB5EAC073A892C687E8E:[U ]:LCT-4710F13C:
hp$:1007:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:0D80C51183ED74320799B5BEDDCBE388:[W ]:LCT-47421493:
m5$:1009:B233C3E987D08D924405A9EF76E52792:65DD4A9908A35667D79B599F94691E34:[W ]:LCT-4742D747:

Em seguida temos o mysqlsam e o ldapsam, onde as contas e senhas são armazenadas em, respectivamente, um servidor MySQL e um servidor LDAP. O uso do MySQL em conjunto com o Samba não é muito comum, mas o LDAP vem crescendo bastante em grandes redes. A grande vantagem é que o banco de dados pode ser acessado por vários servidores, sem necessidade de replicar o arquivo de senhas manualmente (usando o rsync, por exemplo). Isso é muito útil no caso de redes muito grandes onde a autenticação dos usuários é dividida entre vários servidores. Nesta configuração, o PDC divide a carga de trabalho com um conjunto de BDCs (backup domain controllers), que podem ser tanto outros servidores Samba quanto servidores Windows. Os BDCs são subordinados ao servidor PDC, mas todos tem acesso à mesma base de dados com os usuários, armazenada no servidor LDAP, o que evita problemas de sincronismo entre eles. De uma forma geral, um único PDC usando o tdbsam como backend atende bem a até 250 clientes. Este limite não é relacionado ao uso do tdbsam, mas sim a questões práticas relacionadas ao desempenho da rede. Ele pode ser maior ou menor na prática, de acordo com a velocidade da rede (100 ou 1000 megabits), o hardware do servidor e a carga sobre a rede. A partir daí, passa a fazer sentido migrar para um banco de dados LDAP e passar a adicionar servidores BDC secundários.

Fonte: http://www.mktecnologia.net.br

Ativando o TouchPad no Linux Fedora

2013-04-17T20:27:00.004-07:00

O Fedora é um ambiente de trabalho leve e flexível que eu tenho usado. Infelizmente, tive um pequeno problema com o touchpad Synaptics, não posso habilitar a função de tocar. Após algumas pesquisas eis a solução encontrada:

Passo 1. Como o usuário root, realizar o backup do arquivo "50 synaptics.conf" no diretório "/ usr/share/X11/xorg.conf.d /":

# Cp -v /usr/share/X11/xorg.conf.d/50-synaptics.conf /usr/share/X11/xorg.conf.d/50-synaptics.conf.bak

Passo 2. Como o usuário root, vá para o terminal e digite:

# Vi /usr/share/X11/xorg.conf.d/50-synaptics.conf

em seguida, substitua-o por:

Section “InputClass”

Identifier “touchpad catchall”

Driver “synaptics”

MatchIsTouchpad “on”

Option “TapButton1″ “1″

Option “VertEdgeScroll” “1″

MatchDevicePath “/dev/input/event*”

EndSection

Em seguida, salve o arquivo e saia.

# Pressione Esc após insira : "dois pontos" e por fim digite "x" para sair e salvar.

Passo 3. Reinicie o seu sistema. Então efetue o login e agora é só testar o touchpad tocando nele para abrir arquivos.

Boa sorte a todos!

Lista de Compiladores de C e C++

2013-04-17T10:03:00.003-07:00

Para baixar os compiladores ou para mais informações, clique no nome do compilador.

Nome	Gratuito	Descrição
Dev-C++	sim	Criado pela Bloodshed, o melhor para quem é iniciante tanto na linguagem quanto na programação. Tem suporte a projeto e boa interface com o usuário. A desvantagem é a impossibilidade de se criar projetos muito extensos. Apesar de compilar a linguagem C, seu código é escrito em um código totalmente diferente - o Delphi!
GCC	sim	Compilador utilizado pelo projeto GNU. É padrão ANSI C e nativo do sistema Linux, facilitando muito a vida de usuários Linux, pois não é preciso instalar compiladores de terceiros. Seu único problema é a falta de uma interface, que prejudica quem é principiante na linguaguem.
C++ Builder	não	O C++ Builder é um dos melhores compiladores que tem, com possibilidade de criação de projetos extensos. A Borland mantém no site da Code Gear duas versões: uma demo e outra paga. Ele segue o padrão ISO ou ANSI C, mas também tem muitas bibliotecas não padrão, fazendo muitas vezes com que o programa perca a portabilidade e o código escrito no C++ Builder não rode em outros compiladores, mesmo que a linguagem C seja a mesma.
Visual C++	não	O visual C++ é um compilador profissional da Microsoft que compõe o pacote Visual Studio, com vários recursos, como incremento de código, depurador de erros avançado e outras ferramentas que aumentam a produtividade do programador. O problema é que por ser da Microsoft tem o preço elevado e só compensará se você for usar esta linguagem para desenvolvimento profissional em aplicações Windows. Tem uma versão trial no site oficial.

Fonte: http://www.tiexpert.net/programacao/algoritmo/lista-compiladores-c.php

Clix Sense PTC

2013-04-17T08:38:00.002-07:00

Muitos já devem conhecer até mesmo por que ele existe desde 2008, eu mesmo ja usava este ptc mas como na época ele tinha os cliks de 0,001 não o quiz usar mais, mas como o neobux aderiu ao mesmo preço por cliks voltei a usar então volto a indicalo.

Hoje em dia ele representa esta melhor que o neo bux!

Vamos comprarar:

NeoBux cliks: 0,001 até 0,015 sendo stander ( tempo maior de espera por anuncio
ClixSense cliks: 0,001 até 0,015 sendo stander

NeoBux PREMIUM members: 90 dollars sem nivel de referidosClixSense PREMIUM members: 14.95 dollars até 8 nivel de referidos

NeoBux : Neopoints trocas por referidos
ClixSense: ClixGrid Ganhe até 5 dollars em sua conta se acerta o quadro onde esta a figura sem nenhum custo adicional!

NeoBux: Toolbar sim
ClixSense: Toolbar sim

NeoBux: Pagamento minimo 10,00
ClixSense: Pagamento minimo 10,00

Bom galera pra quem usa o neo indico agora tambem o clixSense pois os dois são compativeis e pode ser clicados ao mesmo tempo!!!

Ai fica o link pra quem querer aderir a este ptc http://www.clixsense.com/?5019894

Lista AntiSpam

2013-03-13T09:50:00.001-07:00

O fluxo de spam vem aumentando a cada dia, isso ocasiona muitos impactos para as empresas, vamos aos principais:

- Aumento no trafego no link de internet e rede interna.

- Risco de segurança (vírus, trojan, spyware).

- Improdutividade.

- Perda de espaço em disco.

- Maior tempo necessário para realizar backup do servidor de e-mail.

Com intuito de ajudar a prevenir esses impactos, disponibilizamos a lista de e-mails que enviam spam para que vocês bloqueiem nos servidores AntiSpam utilizados por vocês. A lista abaixo é para ser preferencialmente utilizada em empresas, mas pode ser utilizada para e-mail pessoal.

envio@promosender.com.br
flasp3@brwmkt.com
contato@gestoreselideres.com.br
mkt@mkttreinamentos.com.br
oliveira@rfscripts.com
envio@dedicadosturbo.info
envio@relayexpresso.net
envio@celebrareinfo.com.br
mail@midiamail.com.br
mailmarketing@desata.com.br
novidades1@superserver06.com.br
site@haverjeans.com.br
novidades@lojabest.com.br
team@cams.com
email@city-best.cccampaigns.com
newsletter@mardey.com.br
mercadolivre@ofertasmercadolivre.com.br
apontaofertas@ofertas.apontador.com.br
k2shop.2011@bol.com.br
news@extra.com.br
armazem@correionaweb101.com
renatobv@brturbo.com
noreply-br@m.mequedouno.com
newsletter@comunicado.imperdivel.com.br
info@news.groupon.com.br
noreply@diretomail.net
mkt@invistanocerto.com.br
envio@emktbr.com
sac@mouser.com.br
noreply@badoo.com
naoresponda@club89.com.br
contato@ofertaunica.com
contato@plantaosexy.com
mkt@ofertasbmc.com.br
noreply@majon.net
news@guiadaspromocoes.com.br
spn-h2@sitepronews.com
noreply@www.autosurfvisitas.ganhedinheiroaqui.com
news@trainningnews.com.br
wagner@eucoleciono.com.br
mkt@1001vantagens.com.br
webpronews@ientrynetwork.net
contato@cielofidelidade.com.br
info@canalmail.com
trabalhe@ymail.com
ofertafacil@atendimentosite.com.br
mkt@treinamentonobrasil.com.br
ofertas@directofertaunica.com.br
@downloads.net
correiomail@correiomail.com.br
vitrineabril@vitrineabril.alphainteractive.com.br
unyk@unyk.com
viajeaqui@abrildirect.com.br
cursosinfo@abrildirect.com.br
emm@divulgaoferta.com.br
marcelo.vitorino@pergunteaourso.com.br
boletins@pass.com.br
contato@reinourbano.com.br
owna@samd.net
newsletter@comunicado.superexclusivomkt.com.br
hotel@villarial.com.br
newsletter@entireweb.com
itc.educacao@intercambioglobal.com.br
mensagem@mercadolivre.com
promocoes@cielo.com.br
mkt@videosdetreinamento.com
mkt1@t63.com.br
tmail@mail.internetseer.com
mkt@workshopmkt4.com.br
hcd@hoteiscomdesconto.tur.br
contabil@contnarcontabil.com.br
contato@santander.com.bz
ofertadodia@ofertasclube.com.br
contato@mkttreinamentos.com.br
send@optinmb3.info
sender@linkvideos.com.br
@zyngamail.com
marina@lstreinamentos.com.br
premier1@superserver02.com.br
noreply@lucianonegocios.com
super@chshost.com.br
mktr@correionaweb103.com
atendimento@updmnews.com.br
mkt@werneckimports4.info
dende@dendedigital.com.br
naoresponda@paixeurbano.com.br
mkt@emktdifferential.com.br
respostas-cealvs@superserver04.com.br
smtour2011@gmail.com
informacoes@dvwcomunicacao.com.br
clickbamboo@correionaweb101.com
shoppingcenteronline@corpmail.net.br
mail44123@brwmkt.com
decorecenter@decorecenter.com.br
deixar.roncar@gmail.com
mkt@abcemkt.com.br
novidades@ofertacelulares.info
lquality@yourserver.com.br
emails@superofertasonline.net
ofertas@vipimportadora.com
mkt@currentwindow.com.br
naoresponda@peixeurbano.com.br
mkt@ideiasdemkt.com.br
qualicorp@chshost.com.br
mkt@ideiartes.com.br
tamfidelidade@post.com
vendas@acervocorinthiano.com.br
no-reply@pronaex.com.br
super@correiomkt.com
news@kzabacana.com.br
noreply@iqelite.com
noreply@espionagemdigital.com.br
santander@unificacao.com
assurecorretora@sistem01.com.br
comunicado@multiplus.com.br
walmart@servergreenline.com.br
contato@emarkenvios.com.br
bradescosaude@chshost.com.br
carrofino2@ig.com.br
bounce@fmz.fmzmidia.com.br
artstones@superserver03.com.br
send@brasilmkt.info
mktsdp@uol.com.br
c24@correionaweb.com
b2tag@b2tag.com
marconi@oralim.com.br
publicidade@conveniosdesaude.com.br
naoresponda@propagandabrasil.net
news@icsconsulting.com.br
climadigital1@gmail.com
mkt@guiasalao.ipmarketing.com.br
treinamentos.csb@gmail.com
planosdeconsorcios@r7.com
lista@leepubli.com
csbeventos@csbeventos.com.br
comercial@agenciak.com.br
info@trainningnews.com.br
centauro@thundermail.com.br
comercial@emark.com.br
mkt@globallmail.com.br
horacerta@papercolor.com.br
mkt@i9suavida.com.br
casal2829@yahoo.com.br
saudesampa2012@superserver04.com.br
mkt@neoservidor3.info
shows@portaldorock.com.br
regina@rfscript.com
mkt@duplomarketing.com.br
emagreca_dietas@gmail.com
atendimento@1.emailclaro.com.br
noreply@sonico.com
info@viagenspromo.net
mkt@workshopmkt3.com.br
envio@ondamkt.info
envio@painelondamkt.com
mkt@webemkt.com.br
mail@resultmarketing3.com.br
uol@noticiasdacidade.net
sender@resultmarketing3.com.br
publicidadedigital2012@gmail.com
BITHE02@GMAIL.COM
contato@cartavip.com.br
bounce@sendlead.com
dma_7693@virid.whservidor.com
contato@projetest.com.br
assinaturas@paulinas.com.br
parceiro@hbrbr.com.br
novidades@revendacelulares.info
valijur@uol.com.br
mkt@1001emktonline.com.br
comunicado@newsletter.digitravel.com.br
@cyberdetectives.net

serasa2012@gmail.com

contato@lotenet.info
b4net@b4net.net
vcsites@hotmail.com
emkt@acupunturasp.com
bounces@vomedia.co.uk
loja@host-lojaobaretiro.info
sac@achador.net
novidades@email.hoteishu.com.br
cliente@sky.com.br

@groundbreaking.net
daviconcurseiro@gmail.com
email@psafe-acq.ccemails.net
email@psafe-acq2.ccemails.net
vendas@spvideos.net
mkt@newsfolhas.com.br
marketing@publicidadeonline.info
info@ugabuga.com.br
guiareps1@yahoo.com.br
mkt@ideiasdevisao.com.br
cameras@makarara.com.br
contato@webe-marketing.com
mkt@mailactivity.com.br
send@portalfox.com.br
contato@inewsum.com.br
noreply@wakexpress.com.br
admin@server.shopespiao.com
contato@visitasgarantidas.com
contato@jogandoonline.net
noreply@tribalwars.com.br
naorespondaligue-11-24959364@uol.com.br
vivendadossantos2012@gmail.com
contato@sac.com
newslleter@ciadoaprendizado.com
contato@email-morpheus.com.br
sac@newesportes.com.br
daguia.meg@gmail.com
divulgacao@concurseirourbano.com.br
admin@surftguaxuma.com
envio@emailemmassa.com.br
interativotam@gmail.com
enviando@s1.divulguebrasil.in
cursos@planilhas.com.br
financeiro@portalvender.com.br
melhordamoda@correionaweb.com
skol@skol.com.br
bea@aprimoramentocontinuo.com.br
hidrolightshop@infomail.net.br
valsdp@uol.com.br
riscosemossas@riscosemossas.com.br
saudesampa001@superserver04.com.br
news@galeriegp.com
martaconcurseira@gmail.com
empresarial@token.com.br
crismanaia@hotmail.com
tam.com.br@cpro7090.publiccloud.com.br
contato@memoriaforense.com.br
financeiro.vidanova@gmail.com
sistema@neoserver1.com.br
superr2@correionaweb105.com
@megajogos.com.br
tinaventura@live.com
reservas@pontadolobo.com.br
informativo@radarnoticia.com.br
marketing@starwindsoftware.com
dell@lojadigitall.net
pousada@pedradailha.com.br
envio@e-hadnetserver.com
pqcthuy@web-article.net
keniacristiane@gmail.com
news@tibahia.com
contatos@vzserver.com.br
atendimento@newsletterup.com.br
dinheiro.online@hotmail.com
mkt@digiemkt.com.br
envio@supercorreio.com.br
emails@bemailer.com
envio@smtpbellaforma.com
mkt@connectionemkt.com.br
b4c@b4c.com.br
mail@agilemailing.com.br
mail4344@brwmktmail.com
elly14@hotmail.com
carolina@negociounico.co.cc
barrmikephilip2@yahoo.co.id
mrsamoh.odum@yahoo.com
lojadoprazer01@hotmail.com
noreply@sonicomail.com
kitpilotoautomatico@msn.com
accounts.net@snuck.arvixevps.com
mkt@emktshow.com.br
rainer.lesani@ashampoo.com
noreply@innogames.com
anja_angelagongom@hotmail.com
vivi.maria2012@bol.com.br
psicoped@teletalk.com.br
mensagem.real.2012@gmail.com
melhordamodapz@correionaweb108.com
souza-lu2012@bol.com.br
socoletivas@bol.com.br
dell@correiomkt103.com
emagnet@omegaofertas.com
comercial@opentreinamentos.com.br
naoresponda@servidoralpha.info
envio@enviarnewsletter.com.br
mkt@bgsurf.com.br
atendimento@housedog.com.br
envio@googleemail.com.br
web2mail@web2mail.com.br
renatoconsultorj@gmail.com
cms.liclourenco@hotmail.com.br
contatovip@dsa-bra.com.br
milardconsultoria@ig.com.br
tim@lojadigitall.net
@australianhardwoods.com
contato@server-emailsdobrasil.com
contato@lojadigitall.net
maladireta@plastipack.com.br
news@menteurbana.com.br
wma4559@brwmktmail.com
walmart@servergreen-mail.com.br
vjhx@clinicauniderm.com.br
applechinabrasil@gmail.com
sulamerica@pmesaudevida.com.br
j1kt8q@clinicauniderm.com.br
news@emailling-br.com.br
email@cielo.com.br
bounces-87-sem@geeklemail26.com.br
oreidaoferta@oreidaoferta.com.br
ttncosta@gmail.com
dst4339@brwmktmail.com
mkt@imercato1.com.br
evandro.gesteira@gmail.com
marketing@menshop.com.br
upsecure123@gmail.com
newsletter@claudialeitte.com.br
bali@ilhadebali.com.br
afiare@afiare.com.br
Noreply-service@miniinthebox.chtah.com
jrg4367@brwmktmail.com
marketing@tiqueimoveis.com.br
emailmarketing@divulgabrasil.info
wwwesternunion@ymail.com
wls4239@brwmktmail.com
izamontes@bol.com.br
gabriely.c.araujo@hotmail.com
davigato4@uol.com.br
sac.cromos@gmail.com
contato@veiculocommotorista.com
folegonews@gmail.com
marketing@intercambioglobal.com.br
cursocerimonialgiovanabarbosa@correionaweb.com
sistema@host-lojaobaretiro.info
kel125@hotmail.com
itau@bankline.com.br
enviando@sitesprontos.in
wsg3227@brwmktmail.com
carolina@sapatosdefranca.com.br
rodrigo.mattia@gmail.com
rccomercionorte1@gmail.com
email@serverwebhosting001.com
perfumakqs@correionaweb1.com
divulgacao@comprarrapido.com.br
euqueroumqs@correionaweb107.com
team@amigos.com
rogerioag@brwmkt.com
polishopqs@correionaweb.com
7@7marketing.com.br
retorno@lojadigitall.net
dobradoresdobrefacil@gmail.com
monica_escola@hotmail.com
fmn4285@brwmktmail.com
contato@correionaweb1.com
mp.sales@gmail.com
mkt@abalowvirtual.com.br
csbcursosetreinamentos.eventos@gmail.com
wilink.nr@senderwilinkpdbr.com.br
sodepe@uol.com.br
brazilnetwork@r7.com
envio@divulgandobrasil.info
brasil@midiaponto.com.br
pyjoi8jk@cmactacna.com.pe
link.nacionalp@senderstartmediapdbr.com.br
walmart@lexsusemail.com.br
lifh@cmactacna.com.pe
djmaurinho@djmaurinho.com
mkt@impactatmkt.com.br
hagana@serverwebhosting003.com
tam.com.br@ds3068.dreamservers.com
eicbrasil@brwmktmail.com
nacionalp@senderstartmediapdbr.com.br
noreply@www.autosurfbr.com
contato@autosurfbr.com

andrewmorre@infospeed.ro
vzat@cmactacna.com.pe
gimba.nacionalp@senderstartmediapdbr.com.br
supertourviagens@gmail.com
supertour@grupos.com.br
easymkt@live.com
atendimento@docesaude.com.br
gisele@indiquesaude.com
karol.bela69@hotmail.com
tim.nacionalo@senderstartmediapdbr.com.br
ksp1077@brwmktmail.com
lojaskd.nacionaln@senderstartmediapdbr.com.br
mailing@stellamidia.com.br
jamesh@infospeed.ro
ascom.sema@sema.ba.gov.br
dividaativa@spc.com.br
marcelo@rosselybolsas.com.br
informe.com.br@ps87524.dreamhostps.com
dell@olhaquebarato.com.br
emails@emktid.com
recepcao@intercambioglobal.com.br
bellinatiperez@sistemapro.com.br
caed@institutocaed.com.br
cdp@trackingmail.com.br
mkt@duplomkt.com.br
smtp@ff.souinformado.in
dicarreis@dicarreis.com.br
noreplay@cielo.com.br
oferta@mptudo.com
info@premios-e-descontos.com
falecom@fastclima.com.br
tododia@ssuperdesscontoss.com
sulamerica@leadsdemarketing.com.br
fidelidade@cielo.com.br
walmart@trackingmail.com.br
denisetimeline@lavabit.com
contato@server-emailsdobrasil.net
contato@roraimatem.cz.cc
contato@servemail.com.br
promocao@redecielo.com.br
monica@amigosligados.com
atendimentohs1@hotmail.com
efacil@sendergeopdbr.com.br
comercial@arrumei.com.br
bitleilao@superserver06.com.br
fbi@gov.net
vendas@prospin.com.br
marvelavengersalliance@playdom.com
envio@talento.omkt.com.br
vip-br@vipmailclub.com
megamamao2@gmail.com
travelace@serverwebhosting005.com
admin@goautosurf.com
gerencia@arrumei.com.br
noreply+351220498@badoo.com
produtos@uolboletim.com.br
atv_pass_afins@hotmail.com
mail4149@zomaxy.com
ll@cdptrack.com.br
catia@materiadosfamosos.com.br
invite+zj4os_oafsc9@facebookmail.com
spn-m@sitepronews.com
revistaveja@abrilinterativo.com.br
parceria@cartaexpressa.com.br
felipemafiaazul1@hotmail.com
revistanationalgeographic@abrildirect.com.br
parceiro@cartaexpressa.com.br
boletins@mail.grandebr.com.br
Novidades@mail.grandebr.com.br
ibopemedia@datalistasparceiros.com.br
qetqshk@yahoo.com
revistagestaoescolar@abrildirect.com.br
moahmcc@hotmail.com
meudesejo@thundermail.com.br
adriane.ga2@bol.com.br
atendimento@biglista.com.br
ofertas@updm15.com.br
contato@painel2-adworks.info
campanhas@olhaquebarato.com.br
suporte@hostcloudbr.net
Santander@santander.com
accounts-noreply@email.com
news@buscapromocao.com.br
envio@hostmarketing.com.br
envio@mktlion5.servermailbr.info
infonews@magazineinfomail.com.br
mail5078@ioffiz.com
no-reply@cielo.com.br
mkt.noreply@live.com
lhimoveis2011@bol.com.br
monit@vagas.com.br
linecursos@linecursos.com.br
mail3797@zomaxy.com
super@argonauticos.com
mkt@contatoph.com.br
envio@envioseguro102.com
marceladindin@bol.com.br
webmaster@tibiaspace.com
promocao.vale@pontosepremios.com
bruno@grupojmurbano.com.br
riazormkt@terra.com.br
demmyjemmy@yahoo.com
adilsonrobert@goobynet.com
i-aon@i-aon.com.br
relacionamento@loucasporcosmeticos.com.br
exerciciopeniano@gmail.com
rodrigo.perezNYN7@antiquejewelryauction.com
fernando@radcamp.com.br
rodrigo.perez7TSZ@fordomainsale.com
naoresponder@tam.com.br
comunicacao@abema.org.br
moda@brasaki.com
news@geolistaswebmarketing.com.br
email@ribeiraomarketing.com
smtp@loucosporsitenews.com.br
contato@greenshoppbrasil.com
contato@hotelurbanoinforma.com.br
mkt@enviodigital2.info
mkt-net-empresas@spedroso.info
adm@atmrepresentacoes.info
propagandas@sendergeopdbr.com.br
sobrecachorro@gmail.com
comercial@compazy.com.br
contato@enviohostcloudbr.com.br
news@newsmu.com.br
member@messaging.zoosk.com
super@superlocalweb.com.br
mets@fmzmidia.net.br
contato@supercorreio.com.br
ilha-do-sol@bol.com.br
tecmax@mktpublikmail.com.br
nandoimports@bol.com.br
loja@emailbarateiro1.com
atendimento@pescadoria.com.br
info@hojecomdescontos.com.br
mkt@ofertadoparceiro.com.br
retorno@brseguro.net
atendimento@trainingstore.info
carteiro2@planosnanet.com.br
resposta@cursos10.com.br
envio@crehar.com
emailmkt@saudeja.com.br
marketing@monsterbike.com.br
marketing@longisland.com.br
comunicado@noticiasemcasa.com.br
suzi@novidadesaude.com.br
contatovip@dsa-br.com.br
doris.pinheiro@uol.com.br
info@incentivo-imediato.com
info@multimediadelayed.com.br
info@dominadoosprecos.com.br
Gabriela@menos15quilos.com.br
info@ofertasbmc.co
emkt@mktturbomail.com.br
ofertamail@serverwebhosting004.com
mkt-nextel-fisica@marbas.info
info@braclick.com.br
atende.jcs@catho.com.br
nqeh@mp.ms.gov.br
mkt@bestoportunidade.com.br
ofertas@nossoferta.com.br
messages-noreply@bounce.linkedin.com
propagandas@americanaeventos.net
leads@qualityleads.com.br
dorisveiga@bol.com.br
contato@servidor4-003.info
mkt@newslettergratis.com
ofertas@1001descontos.com
super@pequihost.com
newsletter@tv5email.com
contato@webelearningtv.org
doris.pinheiro@bol.com.br
retorno@centralbr.net
tim@neomkt1.com.br

Onde está o NET SEND no Windows 7 e no Windows Vista?

2013-03-11T16:17:00.000-07:00

Inicialmente quero dar o crédito desse excelente post ao Idevar, pois foi do blog dele que consegui esse material para postar em meu blog.Hoje vou falar de algo que muitos andam questionando nos fóruns que eu participo. O famoso serviço “mensageiro”, do Windows XP, ficou tão famoso, a ponto de diversos usuários leigos utilizarem ele por linha de comando. Quem nunca viu alguém clicar no “Iniciar”, “Executar” e digitar “NET SEND fulano vamos almoçar onde hoje???” rs rs… O comando NET SEND faz parte do mensageiro do Windows XP, e só funciona se esse serviço estiver ativado. Muitas empresas aboliram o uso do NET SEND justamente por isso. Certa vez, vi um cidadão digitar NET SEND Olá!*. O asterisco, quando liberado, simplesmente envia mensagens instantâneas a todos os usuários que estão conectados ao mesmo servidor. Imagine… cerca de 500 pessoas receberam a mensagem. Sorte dele não ter sido mandado embora rs… depois disso, o administrador da rede desativou o uso do NET SEND.

O NET SEND não é usado só para brincadeira. Aliás, usá-lo como brincadeira é apenas uma de suas utilidades. Vários softwares o utilizam como maneira de trocar mensagens, até mesmo com servidores de banco de dados.

A novidade, no Windows Vista e, consequentemente no Windows 7, é: onde está nosso amigo NET SEND? Experimente digitar o comando e terá uma surpresa: o serviço “NET” ainda existe, porém foi retirada a função SEND, certamente por alguns problemas de segurança. E agora??? Não fique triste: muitos não perceberam, mas o Microsoft implementou um novo substituto ao NET
SEND: o MSG. Isso mesmo: MSG. Basta digitar esse comando no prompt de comando e verá que existem várias formas de utilizá-lo, inclusive a mais simples sendo semelhante ao seu avô NET SEND.

Veja só o exemplo, digitado no prompt de comando do Windows 7:

Sintaxe:
MSG /server:maquina123 Idevar Hello World(onde “maquina123″ é o nome da máquina de destino e ”Idevar” é o nome do
usuário de destino)

Resultado do uso do comando “MSG”

Tão simples assim? É isso aí… lembra o nosso velho NET SEND. É possível ainda, como no NET SEND, usar o nome do servidor. como na sintaxe abaixo:

MSG /server:<servidor> <usuário> <mensagem>

Digite apenas “MSG” e veja todas as opções disponíveis:

Enfim… teste na sua casa ou no trabalho. Tente usar o famoso “msg fulano Vamos almoçar?” enquanto ainda estiver habilitado na sua rede… rs…

Obs: o MSG não precisa do serviço mensageiro ativo.

Erros possíveis no envio das mensagens:

Após alguns comentários de problemas de funcionamento, realizei novos testes e cheguei à solução de alguns erros comuns.

“Erro 5 ao obter nomes de sessão”

Possível motivo: caso você esteja em uma rede de domínio e o envio da mensagem
não ocorrer, talvez se faça necessário alterar a chave de registro “AllowRemoteRPC” para “1″ em cada máquina local, no seguinte
caminho do REGEDIT: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server

<usuário> não existe ou está desconectado

A máquina que receberia a mensagem precisa ter o usuário de origem como
administrador da máquina de destino. Exemplo: usuário “pedro” quer enviar uma
mensagem para o usuário “joao”. A máquina utilizada pelo usuário “joao” precisa
ter o usuário “pedro” como administrador. Sobre essa necessidade, estou
tentando localizar mais informações a respeito, caso o usuário não possa ser o
administrador.

Problema no envio entre máquinas Windows XP e Windows Vista/7 ou vice-versa

Não localizei formas de integração para o envio pelo comando “MSG” de máquinas Vista/7 para máquinas Windows XP, assim como o NET SEND de máquinas Windows XP para máquinas Vista/7.

Outros erros: sempre verifique o Firewall. Em algumas situações, notei que o Firewall ligado era o problema que bloqueava as trocas de mensagens. Algumas políticas de segurança na rede também podem bloquear o envio. Neste caso, é necessário verificar com o administrador da rede.

************************
Atualização em 12/08/2011:
************************

Software PAGO (ou Trial) para troca de mensagens entre Windows 7, Vista e XP

Como muitas pessoas estão relacionando problemas abaixo com o uso direto do MSG, devido à alguma configuração de rede, sugiro testarem o uso do software WinSent Messenger, que é Trial (30 dias de uso gratuito). Para o download da última versão do WinSent Messenger, entre no site oficial clicando aqui. Por favor, relatem o uso do software, caso funcione com sucesso. Ele utiliza os mesmos recursos do Windows XP (net send), Windows Vista e Windows 7 para trocar as mensagens. Até onde verifiquei, a versão é com interface gráfica. Caso queira mais informações, entre no site oficial (Winsent Lab). que possui inclusive outros produtos semelhantes.

************************ Atualização em 19/02/2012: ************************

Software FREE para troca de mensagens entre Windows 7, Vista e XP

O Software WinSent Messenger notificado acima, é pago. A versão trial funciona somente 30 dias. Seguindo a dica de um dos nossos leitores, Marcus Mjm, que colocou um comentário abaixo, segue link do LANcet Chat, que é totalmente free e funciona entre as versões do Windows 7, Vista e XP: http://lancetchat.com/ . Peço que, se alguém testar, como nosso leitor, notifique abaixo se funcionou com sucesso.

Abraços,

http://idevar.wordpress.com/2010/02/03/onde-esta-o-net-send-no-windows-7-e-no-windows-vista/

MS-dos Lista de comandos

2013-03-11T14:46:00.002-07:00

ASSOC -> Exibe ou modifica associações de extensões de arquivo.

AT -> Agenda comandos e programas para serem executados em um computador.

ATTRIB -> Exibe ou altera atributos de arquivos.

BREAK -> Define ou limpa a verificação estendida CTRL+C.

CACLS -> Exibe ou modifica listas de controle de acesso (ACLs) de arquivos.

CALL -> Chama um programa em lotes a partir de outro.

CD -> Exibe o nome da pasta atual ou faz alterações nela.

CD.. -> Volta a janela.

CHCP -> Exibe ou define o número da página de código ativa.

CHDIR -> Exibe o nome da pasta atual ou faz alterações nela.

CHKDSK -> Verifica um disco e exibe um relatório de status.

CHKNTFS -> Exibe ou modifica a verificação do disco na inicialização.

CLS -> Limpa a tela.

CMD -> Inicia uma nova instância do interpretador de comandos do Windows.

COLOR -> Define as cores padrão de primeiro plano e do plano de fundo do console

COMP -> Compara o conteúdo de dois arquivos ou grupos de arquivos.

COMPACT -> Exibe ou altera a compactação de arquivos em partições NTFS.

CONVERT -> Converte volumes FAT em NTFS. Não é possível converter a unidade atual.

COPY -> Copia um ou mais arquivos para outro local.

DATE -> Exibe ou ajusta a data.

DEL -> Exclui um ou mais arquivos.

DIR -> Exibe uma lista de arquivos e subpastas em uma pasta.

DISKCOMP -> Compara o conteúdo de dois disquetes.

DISKCOPY -> Copia o conteúdo de um disquete para outro.

DOSKEY -> Edita linhas de comando, volta a chamar comandos do Windows e cria macros.

ECHO -> Exibe mensagens ou ativa ou desativa o eco de comandos.

ENDLOCAL -> Encerra a localização de alterações de ambiente em um arquivo em lotes.

ERASE -> Exclui um ou mais arquivos.

EXIT -> Sai do programa CMD.EXE (interpretador de comandos).

FC -> Compara dois arquivos ou grupos de arquivos e exibe as diferenças entre eles.

FIND -> Procura uma seqüência de texto em um arquivo ou arquivos.

FINDSTR -> Procura seqüências de texto em arquivos.

FOR -> Executa um determinado comando para cada arquivo em um grupo de arquivos.

FORMAT -> Formata um disco para uso com o Windows.

FTYPE -> Exibe ou modifica os tipos de arquivo utilizados em associações de extensões de arquivos.

GOTO -> Direciona o interpretador de comandos do Windows para uma linha identificada em um programa em lotes.

GRAFTABL -> Permite que o Windows exiba um conjunto de caracteres estendidos em modo gráfico.

HELP -> Fornece informações de ajuda sobre comandos do Windows.

IF -> Realiza processamento condicional em arquivos em lotes.

LABEL -> Cria, altera ou exclui o rótulo de volume de um disco.

MD -> Cria um diretório.

MKDIR -> Cria um reates a directory.

MODE -> Configura um dispositivo do sistema.

MORE -> Exibe a saída fazendo pausa a cada tela.

MOVE -> Move um ou mais arquivos de uma pasta para outra pasta.

PATH -> Exibe ou define um caminho de pesquisa para arquivos executáveis.

PAUSE -> Suspende o processamento de um arquivo em lotes e exibe uma mensagem.

POPD -> Restaura o valor anterior da pasta atual salva por PUSHD.

PRINT -> Imprime um arquivo de texto.

PROMPT -> Altera o prompt de comando do Windows.

PUSHD -> Salva a pasta atual e, em seguida, altera a mesma.

RD -> Remove uma pasta.

RECOVER -> Recupera informações ainda compreensíveis de um disco defeituoso ou danificado.

REM -> Grava comentários (observações) em arquivos em lotes ou no CONFIG.SYS.

REN -> Altera o nome de um arquivo ou arquivos.

REName -> Altera o nome de um arquivo ou arquivos.

REPLACE -> Substitui arquivos.

RMDIR -> Remove uma pasta.

SET -> Exibe, define ou remove variáveis de ambiente do Windows.

SETLOCAL -> Inicia a localização de alterações de ambiente em um arquivo em lotes.

SHIFT -> Altera a posição dos parâmetros substituíveis em um arquivo em lotes.

SORT -> Classifica a entrada.

START -> Inicia uma janela separada para executar um programa ou comando especificado.

SUBST -> Associa um caminho a uma letra de unidade.

TIME -> Exibe ou ajusta a hora do sistema.

TITLE -> Define o título da janela para uma sessão do CMD.EXE.

TREE -> Exibe graficamente a estrutura de pastas de uma unidade ou caminho.

TYPE -> Exibe o conteúdo de um arquivo de texto.

VER -> Exibe a versão do Windows.

VERIFY -> Faz com que o Windows verifique se os arquivos estão gravados corretamente em um disco.

VOL -> Exibe um rótulo e número de série de volume de disco.

XCOPY -> Copia arquivos e árvores de pastas.

Atualização do Fedora 16 para o Fedora 17, com (Preupgrade)

2013-03-08T10:30:00.001-08:00

1.1 Primeiro realize atualização de todos os pacotes do Fedora 16 com o seguinte comando como root:

yum update

1.2 Instar (preupgrade) como root

yum install preupgrade

1.3 Iniciar o (preupgrade) como root

preupgrade

1.4 Janela de informação do (preupgrade)

1.5 Escolha a distribuição desejada.

1.6 Preparando o sistema para atualização

1.7 Quando estiver pronto, comesse a atualizar e depois reiniciar.

1.8 Selecione a Atualização do Fedora no menu do GRUB

1.9 Instalando os pacotes do Fedora 17

1.10 Iniciando o Fedora 17 com o Grub 2

1.11 Iniciando apenas, atualizado sistema Fedora 17!

1.12 Tela de Login do Fedora 17

2. Fedora 17 “Beefy Miracle” desktop screenshots

Gnome Shell 3.4 plain

Gnome 3.4 Detalhes

2. Tarefas pós-atualização

2.1 Remover pacotes não suportados

Obter a lista com o seguinte comando:

package-cleanup --orphans

Em seguida, retire pacotes listados com o comando seguinte:

yum remove package1 package2 ...

2.2 Verificar todos os arquivos .Rpm salvos e arquivos .Rpm novos

Você encontra esses arquivos com o seguinte comando:

find / -print | egrep "rpmnew$|rpmsave$"

Dependendo das diferenças entre os ficheiros originais e os novos. Você pode precisar mesclar manualmente as novas definições de novos arquivos de configuração.

Fonte: http://fedoraproject.org

Instalando e configurando o roteador Dlink DI-524

2013-02-14T18:04:00.001-08:00

Instalando e configurando o roteador Dlink DI-524

Comprou um roteador e não sabe configurar? Com este tutorial você aprenderá o básico de configurações de roteadores, como alterar o nome padrão da rede sem fio e configurar uma senha criptografada para ninguém usar a sua internet de graça.

Página de Suporte:http://support.dlink.com/products/revision.asp?productId=DI-524Manual: ftp://www.dlinkla.com/pub/drivers/DI-524/MANUAL_DI-524.zip

Cenário

Instruções

Conecte um cabo de rede à porta “INTERNET” do Roteador. Em seguida, conecte a outra ponta do cabo de rede ao seu modem de banda larga.
Conecte seu computador em umas das portas de 1 a 4 do roteador usando um cabo de rede.
Ligue seu modem de banda larga.
Ligue seu roteador.
Ligue seu computador.
Abra seu navegador, e entre com endereço http://192.168.0.1 e dê Enter.
Uma tela de login aparecerá. Em ”Nome de usuário” digite “admin” e em “Senha” deixe em branco.
Se a senha não entrar, atrás do roteador tem um botão chamado “reset”, aperte por 20 segundos e depois tente novamente.

A tela inicial será exibida.

Clique em “WAN“. Se seu provedor usa DHCP, deixe a configuração do jeito que está.

Se seu provedor usa PPPoE, selecione PPPoE no menu e configure seu nome de usuário e senha e clique em “Apply“.

Configurando a segurança.

Clique no menu “Wireless“, e em ” SSID“, você vai digitar o nome da sua rede, no exemplo abaixo foi utilizado o nome do site.

Atualmente existem diversos tipos de algorítmos de segurança, a maioria dos usuários ainda usam o algorítmo WEP para configurar seus roteadores, não vamos utlizar WEP pois hoje em dia qualquer pessoa pode quebrar a chave de uma rede sem fio com WEP configurada. Vamos utilizar WPA ou WPA2 se seu roteador suportar.
No menu, selecione “WPA-PSK” e digite uma senha com no mínimo 8 caracteres e no máximo 63.
Clique em “Apply” e espere o roteador reiniciar.

Vá até Meus Locais de Rede e clique na sua conexão de rede sem fio e conecte na rede que você acabou de criar.

Existem vários modelos de roteadores no mercado, mas quase todos são parecidos na hora de configurar o nome da rede e a segurança, este tutorial mostra apenas as funções básicas de configuração para que qualquer pessoa que não trabalhe com informática aprenda a configurar.

Fonte: http://infohelp.org/thales-laray/configurando-o-roteador-dlink-di-524/

Mudar idioma do fedora pelo terminal

2012-11-08T05:38:00.001-08:00

O live CD do Fedora vem por padrão no idioma americano para quem o inicializa em modo texto. Também é possível que em alguma atualização indesejada, ou mesmo configuração feita pelo próprio usuário, crie-se um cenário idiomático desconfortável.

Em vista disso segue a dica.

Digite o comando:

$ system-config-language

Você entrará em um assistente de configuração de idioma bem simples e intuitivo.

Caso a mudança de idioma não seja feita, outra forma de configurar é mudando o valor da variável de ambiente $LANG:

$ LANG=`cat /usr/share/system-config-language/locale-list | grep -i "brasil"|cut -d" " -f1`

Nestes casos é comum que o teclado também venha com o padrão americano na sua configuração, para ajustar isso digite:

$ system-config-keyboard

Tutorial Sea Tools para DOS

2012-10-08T10:22:00.004-07:00

SeaTools para DOS é uma ferramenta de diagnósticos abrangentee fácil de usar, que o ajuda a determinar rapidamente oque está impedindo que você acesse os dados de seu computadordesktop ou notebook. Ele inclui vários testes que examinarãoo meio físico da unidade Seagate, Maxtor ou de qualquermarca. Esta orientação vale tanto para a versão antiga (texto)quanto para a nova (GUI).
Para usar o SeaTools para DOS, escolha fazer o download da versão em disquete ou da versão de imagem de CD inicializável.

Criação de disquete
Para a versão em disquete, você precisará de um disquete de 1,44 MB. Clique no arquivo .EXE baixado do site da Seagate e siga as instruções da tela.
Criação de um CD usando o arquivo .ISO da imagem de CD inicializável.
Consulte o artigo da BC 201431 para obter detalhes sobre a gravação do arquivo .ISO em um CD.
Apenas copiar os arquivos em um CD não funcionará; o arquivo deve ser gravado no CD como uma imagem.
Depois de criar a mídia inicializável, reinicie o computador com a mídia na unidade. Se o computador não iniciar a partir da mídia, pode ser preciso ajustar a ordem de inicialização no BIOS do computador. Consulte o artigo da BC 184971 ou o guia do usuário do computador para obter informações sobre a alteração da seqüência de inicialização.
Este documento cobre as versões nova e antiga do SeaTools para DOS. O guia para a versão mais recente encontra-se logo abaixo. Para a versão mais antiga, clique aqui.
SeaTools para DOS, versão nova:
Na inicialização, você verá um Contrato de licença de usuário final.

Clique em I Accept (Eu aceito) para continuar.
Com isso você será levado para a página do menu principal.
No menu "Basic" (Básico):

Short test – Executa um teste DST nas unidades Seagate. Se o DST não for compatível com a unidade, o SeaTools executa um teste de leitura. Este teste demora aproximadamente 2 minutos.
Long test – Executa um exame completo da unidade. Ele normalmente é usado para encontrar e reparar setores inválidos.
Acoustic test – Reduz a velocidade da unidade, para que você possa determinar se o ruído de um sistema é causado pela unidade ou por outra coisa.

Recursos avançados

Set Capacity to 32GB – Limita a unidade a 32 GB, para uso com Pentium 3 ou sistemas antigos.
Set Capacity manually – Limita a unidade a um número específico de endereços de blocos lógicos (LBAs), útil quando se substitui um tamanho incomum de unidade em uma RAID.
Set Capacity to MAX – Usado para redimensionar a unidade para a capacidade total (não ignora o jumper de limite de capacidade).
Erase Track Zero – Preenchimento rápido com zeros, para apagar os dados e as partições de uma unidade. Esta opção demora um segundo para ser concluída.
Timed Erase (10 segundos, 20 segundos, 1 minuto, 5 minutos) – Útil para quando o preenchimento rápido com zeros não dá certo (isso é, no caso de carregadores de inicialização…).
Full Erase – Preenche toda a unidade com zeros. Pode ser usado para recuperar setores inválidos; apaga todos os dados. Este não é um "apagamento seguro".

Abaixo, a tela Results and Progress (Resultados e andamento):

Número de modelo e número de série da unidade selecionada.
Exibição do status da unidade e dos recursos suportados.
POH – Exibição das horas em funcionamento; e da temperatura da unidade em graus Celsius.

- Clique em "View log" (Exibir log) para abrir o arquivode log após a conclusão do teste (não mostrará muito maisdo que está na tela).
Versão antiga
Após a inicialização no SeaTools surgirá um contrato de licença.
Leia o contrato e pressione "Y" para aceitar os termos e continuar com o teste, ou pressione "N" para sair do programa. Use as teclas "Page Up" e "Page Down" para rolar a tela.
Após concordar com os termos da licença, a tela do teste aparece.
Veja os vários elementos da tela de teste da versão antiga.

D or 0-9 – Alterna as unidades – Seleciona em que unidade executar as ações (consulte a área de dispositivos para obter o número correspondente).
S – Short test – Executa um autoteste de unidade (DST) nas unidades Seagate. (Se o DST não for suportado o SeaTools executa um teste de leitura). Leva aproximadamente 2 minutos.
L – Long test – Exame completo da unidade. Normalmente usado para encontrar e reparar setores inválidos.
Z – Zero Fill – Limpa os dados da unidade. Bom para apagar partições corrompidas ou incomuns. Apaga TODAS as partições e dados da unidade. Suporta as opções Quick (Rápida) e Long (Completa).
A – Spin down drive (for Acoustic test) – Reduz a velocidade da unidade, para que você possa determinar se o ruído de um sistema é causado pela unidade ou por outra coisa.
C – Set Capacity – Usado para definir a capacidade da unidade, para ultrapassar os limites comuns de 32 GB e 137 GB. Sempre usado para unidades com capacidade diminuída.
V – View log file – Interrompe o arquivo de log para análise.

A explicação para o texto colorido na parte inferior da tela segue abaixo:
Texto branco: O dispositivo (isto é, dispositivo 0) e seus números de modelo e de série.
Texto amarelo: Conjunto de chipes da placa-mãe.
Texto azul-piscina: Indica se a placa-mãe suporta LBA de 48 bits e o LBA máximo para esta unidade, juntamente com sua capacidade.
Texto verde: Status do SMART. Se o SMART falhou, não há necessidade de executar um teste. A unidade deve ser substituída.
Texto verde: Status do suporte a DST (Autoteste da unidade) – Se o DST for suportado, será usado durante o teste.
Texto azul: Status da temperatura de operação – Temperatura atual e máx. registrada – útil para determinar se o calor é um fator no problema ou falha da unidade. Consulte o manual do produto para obter a temperatura de operação especificada. A "Worst Temp" (Pior temperatura) refere-se à temperatura mais alta registrada para a unidade durante toda sua vida útil.
Uma leitura incomum normal exibe 253 Celsius, o quesignifica apenas que a unidade não suporta o recurso deleitura da temperatura. Não há com que se preocupar.
POH = Power on Hours – Indica há quanto tempo a unidade está em funcionamento em toda sua vida útil.

Teste acústico
Uma vez ativado, a unidade diminuirá sua velocidade, para que você possa verificar se o ruído vem da unidade ou de outros componente (como uma ventoinha do computador). A unidade continuará coma velocidade reduzida até que o usuário pressione uma tecla.
A janela pop-up permanecerá aberta por vários segundos, até que a unidade acelere novamente.

Definir capacidade

S – Set 32 GB Capacity: Útil para unidades ATA em placas-mãe antigas.
R – Reset to Drive Maximum: Útil para restituir a capacidade máxima de unidades ATA e SATA que tiveram a capacidade diminuída manual ou espontaneamente.
M – Set Manually: Geralmente útil para unidades ATA e SATA como uma alternativa quando a opção Reset to Maximum (Redefinir para máximo) não funciona.
Q – Back to Main Menu.

Preenchimento com zeros
Opções do menu principal: Z-Erase Drive (Apagar unidade) é a opção de preenchimento com zeros.
Este é o submenu Zero-fill (Preenchimento com zeros).
No submenu Zero Fill tem-se as seguintes opções:

Z - Preenchimento rápido com zeros (primeiros 63 setores da unidade, instantâneo)
A - Preenchimento completo com zeros (todos os setores da unidade, pode demorar várias horas)
F - Preenchimento temporizado com zeros, onde T ajusta o tempo.

Informações da unidade
É o texto em amarelo observado na parte inferior da tela do menu principal.
Mostra os discos rígidos detectados

Device number - Usado para selecionar que unidade testar.
Model number
SN - Número de série
FW - Revisão do firmware – Útil em produtos SCSI e SATA, e em alguns produtos ATA.
Controller – Conjunto de chipes ao qual a unidade está conectada. Útil para algumas unidades SATA e para problemas de capacidade. Caso o conjunto de chipes seja antigo, pode ser aplicado o limite de LBA de 28 bits e, assim, o conjunto de chipes pode suportar apenas velocidades de 1,5Gb/s para SATA.

Se uma unidade não aparecer nesta área, desligue o computador e confirme se a unidade está instalada corretamente.
Consulte a página de assistência à instalação para obter detalhes sobre a configuração de vários tipos de unidades.
Este utilitário não detectará unidades externas. Use o para Windows para testar unidades externas.

Arquivo de log
O arquivo de log é armazenado na mídia de inicialização, se for regravável, ou na memória, para a versão em CD. É armazenado como: Serial#.LOG
Ex: 5NF0R4RC.LOG
Para exibir o log no software, pressione V.
Para sair do visualizador de log, pressione a tecla Esc.

Status do teste (durante um DST)
Durante um teste, a parte superior da tela exibe uma barra de andamento e a área central mostra os resultados.
Após a conclusão do teste, a área central continua a mostrar o resultado e a parte superior volta a mostrar as opções de comando.
Reparação de setores inválidos (Teste completo)
Se forem encontrados blocos inválidos durante um teste completo,surgirá um aviso perguntando como proceder.
A tela abaixo aparece ao final do exame ou se o usuáriocancelar o teste, caso tenham sido descobertos setores inválidosna unidade.
Exemplo:
Siga as instruções da tela para continuar.
Para mais informações sobre o para DOS, consulte o arquivo readme.txt.

Referência:

http://knowledge.seagate.com/articles/pt_BR/FAQ/201271br

Comandos para Fedora

2012-09-24T19:57:00.000-07:00

# getconf LONG_BIT = Mostra se o S.O é 32 ou 64 bits

#grep flags /proc/cpuinfo = Para saber qual a arquitetura do CPU, O comando irá retornar inúmeras "flags". Procure por alguma que tiver "lm" escrito. Por exemplo, "lm constant_tsc".

Se essa flag existir, seu CPU suporta 64 bits :)

Codecs para Linux Fedora - MP3

2012-08-30T13:59:00.000-07:00

Para a reprodução de arquivos multimídia que tenham formatos proprietários, é necessária a instalação de alguns codecs no fedora. Esses codecs lhe darão suporte a formatos de áudio e video como.mp3, .wma, .avi, .wmv, .rmvb entre muitos outros. Para ter acessos a formatos proprietários, tenha certeza que o repositório RPMFusion foi habilitado.

Codecs gstreamer

Para instalar os codecs gstreamer, logue-se como root e instale-os com o comando:

# yum install gstreamer gstreamer-ffmpeg gstreamer-plugins-bad gstreamer-plugins-bad-free 
              gstreamer-plugins-bad-free-extras gstreamer-plugins-bad-nonfree 
              gstreamer-plugins-base gstreamer-plugins-good gstreamer-plugins-ugly

Nota: O comando acima deve ser digitado em uma única linha. Se todos os nomes não couber em uma única linha (muito provável), não se preocupe, continue digitando todos os nomes do pacotes e então depois dê um ENTER.

Codecs da biblioteca xine

Para instalar os codecs da biblioteca xine, logue-se como root e instale-os com o comando:

# yum install xine-lib xine-lib-extras xine-lib-extras-freeworld

Codecs do mplayer

Mplayer é talvez o player de video mais famoso no mundo GNU/Linux. Possui um conjunto de codecs capaz de reproduzir qualquer formato de video. Mesmo que você não o instale no seu sistema, provavelmente irá necessitar dos codecs que ele utiliza, visto que esses também são usados por outras aplicações.

Para instalá-los, logue-se como root e entre com o comando:

# rpm -Uvh http://www.lonelyspooky.com/easylife/mplayer-codecs-all-20071007-1.i386.rpm

O rpm irá baixar e instalar esse pacote pra você.

NOTA: Esse pacote de codecs para o mplayer é somente para um PC de 32 bits! Caso queira, o easyLife pode instalar automaticamente todos os codecs que provavelmente você irá necessitar.

O pacote `libdvdcss`

Um pacote que será muito útil para usuários que pretendem assistir DVD no Fedora é o libdvdcss, mas esse pacote, por alguma razão, não se encontra no RPMFusion. É necessário o repositório livnapra isso.

Para habilitá-lo, logue-se como root e entre com o comando:

# rpm -Uvh http://rpm.livna.org/livna-release.rpm

Depois basta instalar o pacote:

# yum install libdvdcss

O repositório livna pode ser desabilitado depois disso, visto que sua utilidade é somente para a instalação desse pacote. Você pode facilmente fazer isso com o comando:

# sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/livna.repo

como root.

Alternativamente, você pode editar o arquivo /etc/yum.repos.d/livna.repo e trocar a linha

enabled=1

por

enabled=0

Outros pacotes úteis

Logue-se como root e entre com o comando:

# yum install faad2 faac libdca wget compat-libstdc++-33 compat-libstdc++-296

Pronto, os codecs necessários para o seu Fedora reproduzir qualquer formato multimídia devem estar instalados. :-)

#rpm -ivh http://download1.rpmfusion.org/free/fedo…

# rpm -ivh http://download1.rpmfusion.org/nonfree/f…

#rpm -ivh http://rpm.livna.org/livna-release.rpm

Referências:
http://projetofedora.org/wiki/index.php/Codecs

Configurando o Layout de teclado no console Linux Fedora

2012-08-27T09:55:00.001-07:00

Para plataformas RED HAT que necessitam realizar a troca do layout de teclado no modo texto do Linux (console tty, CRTL+ALt+F2, F3, etc…), e que de quebra não possua a ferramenta system-config-keyboard-tui ou system-config-keyboard pode alterar a configuração através do arquivo /etc/sysconfig/keyboard. Neste arquivo deve conter uma linhaKAYTABLE=”LAYOUT DESEJADO”.

Seguem exemplos dos dois mais usados:

KEYTABLE=”br-abnt2″

KEYTABLE=”us”

temporariamente pode se usar o comando loadkeys =D

$loadkeys us
$loadkeys br-abnt2

Reparando o boot do Windows 7

2012-08-22T13:53:00.006-07:00

Quando você inicializa o DVD de recuperação ou instalação do Windows 7, terá uma tela parecida com a da imagem abaixo, onde você deve clicar em "Reparar o computador":

Depois que clicar nesta opção, o sistema irá tentar encontrar as instalações do Windows presentes no seu computador, quando encontrar, clique em "Avançar" para que o sistema tente recuperar a instalação selecionada:

Na maioria dos casos, o sistema não consegue recuperar automaticamente o sistema, sendo necessário realizar a recuperação manualmente:

Neste caso, clique para exibir as opções avançadas de recuperação do sistema:

Dentro das opções avançadas de recuperação, você encontra o "Prompt de Comando", então clique nesta opção para tentarmos recuperar o sistema de boot do seu Windows 7. Existem dois comandos que podem ser úteis nestes casos, um deles repara a MBR do disco rígido e o outro repara o próprio boot do Windows, então tente com as duas opções, exemplo:

bootrec /fixmbr

bootrec /fixboot

Em caso de dúvida, digite: bootrec /? E o sistema irá listar as opções possíveis:

Depois disso, é só reiniciar o seu computador e pronto.

Windows Server 2003 - Modelos de segurança

2012-08-21T13:12:00.001-07:00

Introdução

Utilizamos os modelos de segurança para implementar segurança no Windows Server 2003, tanto a nível local quanto a nível de domínio. Os modelos de segurança são nada mais do que várias diretivas de segurança (as mesmas utilizadas pelas GPOs) configuradas em um arquivo. Podemos utilizar os modelos de segurança padrões do Windows Server 2003 ou criar um novo modelo de segurança.

Antes de aplicarmos os modelos de segurança, devemos verificar quais alterações serão feitas em nosso sistema, e se os modelos padrões atendem nossas necessidades. Os modelos de segurança estão armazenados na pasta %systemroot%\security\templates.

Figura 1 – Modelos de Segurança

Os modelos padrões são os seguintes:

Compatws – Aplica permissões em alguns arquivos e registros do Windows com o intuito de permitir a execução de aplicativos legados. Com isso, o nível de segurança do Windows Server 2003 é reduzido.

DC Security – Aplica as configurações padrões de um Controlador de Domínio.

Hisecdc – É um modelo de segurança extremamente forte, que aumenta o nível de segurança do NTLM, desabilita serviços não necessários e aplica permissões em arquivos e no registro do Windows. Além disso, remove todos os usuários que estão no grupo Power Users.

Hisecws – É um modelo de segurança extremamente forte, que aumenta o nível de segurança do NTLM, aplica permissões em arquivos e no registro do Windows, remove todos os usuários que estão no grupo Power Users e limita o grupo local Administrators aos membros Domain Admins e Administrator.

Iesacls – Aplica permissões em chaves do registro do Windows relacionadas ao Internet Explorer. Adiciona a permissão Read e Full Control para o grupo Everyone.

Rootsec – Aplica permissões na raiz do drive do sistema.

Securedc – Aplica diversas configurações de segurança, aumentando a complexidade das políticas de senhas. Aplica também restrições ao Lan Manager.

Securews – Aplica diversas configurações de segurança, aumentando a complexidade das políticas de senhas. Aplica também restrições ao Lan Manager.

Setup security – Aplica as configurações padrões do Windows, configuradas logo após a instalação do Windows.

Através do console Security Configuration and Analysis (Configuração e Análise de Segurança), podemos analisar um modelo de segurança, comparando-o com as configurações já definidas em um computador. Podemos também aplicar um modelo de segurança no computador.

Exemplo prático – Analisar um modelo de segurança e salvar o console.

Clique em Iniciar, Executar, digite mmc e tecle Enter.

No menu Arquivo clique em Adicionar/remover snap-in.

Clique em Adicionar.

Clique sobre Configuração e análise de segurança e clique em Adicionar.

Figura 2 – Configuração e análise de segurança

Clique em Fechar e OK.

Clique com o botão direito sobre Configuração e análise de segurança e clique em Abrir banco de dados.

Digite teste.sdb e clique em Abrir.

Escolha o modelo de segurança que deseja analisar e clique em Abrir. Para o nosso exemplo escolha o modelo de segurança hisecdc.

Figura 3 – Modelos de segurança

Agora clique com o botão direito sobre Configuração e análise de segurança e clique em Analisar computador agora.

Clique em OK e aguarde até que a análise seja executada.

Expanda todas as opções do lado esquerdo da tela e verifique do lado direito as diferenças entre as configurações do modelo de segurança escolhido (hisecdc) e as configurações do computador.

Figura 4 – Configuração e Análise de Segurança

Verifique que aparecerão várias diretivas com um “X” vermelho. Isso significa que as configurações do modelo de segurança e as configurações aplicadas no computador estão diferentes.

Agora vamos salvar esse console. Para isso clique no menu Arquivo e clique em Salvar.

Defina o nome do console e o local onde este será salvo. Clique em Salvar.

Feche o console.

Exemplo prático – Aplicar um modelo de segurança.

Abra o console criado anteriormente.

Clique com o botão direito sobre Configuração e análise de segurança.

Clique em Configurar computador agora. Lembre-se que o modelo de segurança que será aplicado é o hisecdc, o qual selecionamos e efetuamos a análise no exercício anterior.

Clique em OK.

Aguarde até o que novo modelo seja aplicado e feche o console mmc.

Para visualizar todas as configurações de segurança do Windows Server 2003 utilizamos o console Diretivas de segurança local, localizado em Ferramentas administrativas.

Figura 5 – Diretivas de segurança local

Para visualizarmos todos os modelos de segurança disponíveis e suas configurações, utilizamos o console Modelos de segurança. Nesse console podemos também criar um novo modelo de segurança a partir de um modelo pronto.

Exemplo prático – Visualizar os modelos de segurança padrão e suas configurações e criar um novo modelo de segurança.

Clique em Iniciar, Executar, digite mmc e tecle Enter.

No menu Arquivo clique em Adicionar/remover snap-in.

Clique em Adicionar.

Clique sobre Modelos de segurança e clique em Adicionar.

Clique em Fechar e OK.

Expanda as opções até que os modelos de segurança sejam exibidos. Verifique as configurações das diretivas de segurança de cada modelo de segurança.

Figura 6 – Modelos de Segurança

Clique com o botão direito sobre o modelo de segurança hisecdc e clique em Salvar como.

Digite o nome do arquivo e clique em Salvar. Para esse exemplo digite ModeloCustomizado e clique em Salvar.

Figura 7 – Salvar um novo modelo de segurança

Observe que o novo modelo de segurança foi criado e já aparece na lista de modelos de segurança.

Figura 8 – Novo modelo de segurança

Agora é só fazer as configurações desejadas no novo modelo de segurança e fechar o console. Ao fechar o console será perguntado se deseja salvar as alterações feitas no novo modelo de segurança, caso alguma alteração tenha sido feita. Clique em Sim para salvar ou em Não para descartar as alterações.

Figura 9 – Salvar alterações no novo modelo de segurança

Quando estamos utilizando as diretivas de segurança de domínio (GPO’s), podemos importar um modelo de segurança para uma GPO e aplicar esse modelo em todos os computadores do domínio.

Exemplo prático – Importar um modelo de segurança para uma GPO.

Efetue logon com uma conta de usuário com direitos administrativos.

Abra o console Usuários e Computadores do Active Directory.

Clique com o botão direito sobre o domínio e escolha a opção Propriedades.

Clique na aba Diretiva de grupo.

Figura 10 – Diretiva de grupo de domínio

Dê 2 cliques sobre a GPO desejada ou selecione a GPO e clique em Editar.

Acesse a opção Configuração do computador, Configurações do Windows, Configurações de segurança.

Figura 11 – Diretiva de grupo de domínio

Clique com o botão direito sobre Configurações de segurança e escolha a opção Importar diretiva.

Figura 12 – Importar Diretiva

Será exibida a tela acima, com todos os modelos de segurança disponíveis. Selecione o modelo de segurança desejado (que será importado para a diretiva de segurança do domínio) e clique em Abrir.

Pronto, agora todas as configurações do modelo de segurança selecionado acima serão aplicadas em todos os computadores do domínio, via GPO. Percebam como é bem mais fácil importar um modelo de segurança para uma GPO do que configurar diretiva por diretiva em uma GPO.

Contamos ainda com um comando utilizado para configurarmos os modelos de segurança. Esse comando é o secedit. Com a utilização desse comando teremos alguns recursos adicionais.

Apresentamos abaixo alguns parâmetros que podem ser utilizados com o secedit:

Secedit /analyze – esse comando analisa a segurança do sistema. Podemos utilizar os seguintes parâmetros:

/db – Fornece o caminho para um banco de dados que contém a configuração armazenada, na qual a análise será executada. Esse é um argumento necessário.

/cfg – Este argumento é válido somente quando for utilizado com o parâmetro /db. É o caminho para o modelo de segurança que será importado no banco de dados para análise. Se este argumento não for especificado, a análise é executada em relação a qualquer configuração já armazenada no banco de dados.

/log – O caminho para o arquivo de log para o processo. Se este não for fornecido, o arquivo padrão é usado.

/quiet – Suprime a saída de log e de tela. Você ainda poderá ver resultados da análise usando o console Configuração e análise de segurança.

Secedit /configure – esse comando configura a segurança do sistema aplicando um modelo de segurança. Podemos utilizar todos os parâmetros utilizados no comando secedit /analyze, e mais os seguintes parâmetros:

/overwrite – Este argumento é válido somente quando o parâmetro /CFG também for usado. Especifica se o modelo de segurança no argumento /CFG deve sobrescrever qualquer modelo ou modelo composto armazenado no banco de dados, em vez de acrescentar os resultados ao modelo armazenado. Se este argumento não for especificado, o modelo no argumento /CFG será acrescentado ao modelo armazenado.

/areas – Especifica as áreas de segurança a serem aplicadas ao sistema. O padrão é "todas as áreas". Cada área deve ser separada por um espaço. As áreas podem ser:

SECURITYPOLICY – Diretiva local e diretiva de domínio para o sistema, incluindo diretivas de conta, de auditoria e assim por diante.

GROUP_MGMT – Definições de grupo restritas para quaisquer grupos especificados no modelo de segurança.

USER_RIGHTS – Direitos de logon de usuário e concessão de privilégios.

REGKEYS – Segurança em chaves de registro local.

FILESTORE – Segurança no armazenamento de arquivo local.

SERVICES – Segurança para todos os serviços definidos.

Secedit /refreshpolicy – esse comando não existe mais no Windows Server 2003. Foi substituído pelo comando gpupdate.

Secedit /export – esse comando exporta um modelo armazenado em um banco de dados para um arquivo de modelo de segurança. Podemos utilizar todos os parâmetros utilizados no comando secedit /analyze, acrescido do parâmetro /areas, e mais o seguinte parâmetro:

/mergedpolicy – Mescla e exporta configurações de segurança de diretiva local e de domínio.

Secedit /validate – esse comando valida a sintaxe de um modelo de segurança que você deseja importar para um banco de dados para análise ou aplicação no sistema. O único parâmetro utilizado é:

Nome_do_arquivo: nome do arquivo do modelo de segurança.

Tutoriais diversos

Instalar o Webmin no Ubuntu Server 12.04 LTS

Teste para pagamento no mercado pago "Cabo adaptador"

Guia sobre Linux: bash, comandos, permissões, rede, e outros.

A história do Linux

Introdução

O que é Linux?

O que é kernel?

Então, o Linux é um kernel?

A história do Linux

A relação do Linux - e do MINIX - com o UNIX

O surgimento do Linux

O nome Linux

GNU/Linux

Distribuições Linux

Versões do kernel

A licença do Linux

A história dos sistemas operacionais

Fonte: www.tecmundo.com.br

Instalação e configuração do Samba usando o Swat

Um Pouco de História

Instalando o Samba

Cadastrando Usuários

Usando o Swat

Ativando o Swat

Opções Gerais do Swat

Criando Compartilhamentos

Dicas e configurações adicionais do Samba

Montagem permanente dos compartilhamentos

Portas e firewall

Mantendo o horário sincronizado

Compartilhando impressoras no Samba

Compartilhando a impressora no Samba

Configuração nos clientes

Disponibilizando drivers de impressão para os clientes

Compartilhando impressoras através do Cups

Configuração das impressoras nos clientes

Usando o Samba como PDC

Logando Clientes Windows

Corrigindo problemas

Cadastrando as máquinas sem usar a conta de root

Ajustando as permissões locais

Logando clientes Linux no domínio

Usando o PDC para autenticação local no Linux

Configuração Avançada do Samba

Ajustando as permissões de acesso

A Seção [Global]

A Seção [Homes]

A Conta Guest

Lixeira no Samba

Auditando Acessos

Backends: smbpasswd ou tdbsam

Ativando o TouchPad no Linux Fedora

Lista de Compiladores de C e C++

Clix Sense PTC

Lista AntiSpam

Onde está o NET SEND no Windows 7 e no Windows Vista?

MS-dos Lista de comandos

Atualização do Fedora 16 para o Fedora 17, com (Preupgrade)

1.1 Primeiro realize atualização de todos os pacotes do Fedora 16 com o seguinte comando como root:

1.2 Instar (preupgrade) como root

1.3 Iniciar o (preupgrade) como root

1.4 Janela de informação do (preupgrade)

1.5 Escolha a distribuição desejada.

1.6 Preparando o sistema para atualização

1.7 Quando estiver pronto, comesse a atualizar e depois reiniciar.

1.8 Selecione a Atualização do Fedora no menu do GRUB

1.9 Instalando os pacotes do Fedora 17

1.10 Iniciando o Fedora 17 com o Grub 2

1.11 Iniciando apenas, atualizado sistema Fedora 17!

1.12 Tela de Login do Fedora 17

2. Fedora 17 “Beefy Miracle” desktop screenshots

Gnome Shell 3.4 plain

Gnome 3.4 Detalhes

2. Tarefas pós-atualização

2.1 Remover pacotes não suportados

2.2 Verificar todos os arquivos .Rpm salvos e arquivos .Rpm novos

Instalando e configurando o roteador Dlink DI-524

Instalando e configurando o roteador Dlink DI-524

Cenário

O pacote `libdvdcss`