Dicas e configurações adicionais do Samba

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