Install logwatch Centos 6

Logwatch is a wonderfull Linux tool that informs us (by email if you like) to what happened to a server during the previous day (configurable).

EDIT: I’ve just tried with CentOS 6.3 minimal install, with the default mirrors configured and logwatch (yum install logwatch) installed just perfectly.

In CentOS 6, there’s a problem installing it (at least in all my servers with CentOS 6 i had it) because of perl-Date-Manip, with the error: [Errno -1] Package does not match intended download.

I guess it’s because of the version…

The solution: Get perl-Date-Manip-5.54-4.el6.noarch.rpm from the internet (ie and before installing it, install all it’s dependencies.

NOTE: This version is i686. For x86_64 just replace the arch.

Go to and download it.

Edit (new package):

Before installing, install all it’s dependencies:

yum install mailx perl perl-Module-Pluggable perl-Pod-Escapes perl-Pod-Simple perl-YAML-Syck perl-libs perl-version

And then, install perl-Date-Manip that we have downloaded before:

rpm -ivh perl-Date-Manip-5.54-4.el6.noarch.rpm

and next, we can install logwatch:

yum install logwatch

This way, logwatch is installed


If you want to have logwatch mailed to you, you need to install sendmail (or postfix). According to logwatch.conf, only sendmail (and mailers that support output stream) can be used

From logwatch.conf:

# By default we assume that all Unix systems have sendmail or a sendmail-like system. # The mailer code Prints a header with To: From: and Subject:. # At this point you can change the mailer to any thing else that can handle that output # stream. TODO test variables in the mailer string to see if the To/From/Subject can be set # From here with out breaking anything. This would allow mail/mailx/nail etc….. -mgt

Installing sendmail

yum install sendmail

Configuring the email address

Now, we have two choices – or we just put our email address in logwatch configuration file – or we put it in /etc/aliases, thus receiving all email to root from the system. The latter is better, since we catch all email from our system.

Editing aliases

vi /etc/aliases

Go to line 96, uncomment the line (remove the ‘#’) and change the name to your email address:

# Person who should get root’s mail

Save and run:


Start sendmail

/etc/init.d/sendmail start

and you can see how things are going by watching /var/log/maillog

tail -f /var/log/maillog

 Note: If you get an error because of Perl-Date-Manip and the timezone, that’s a problem and i couldn’t find a solution.

Upgrade Linux Mint 11 (Katya) to version 12 (Lisa)

Well, Linux Mint 12 is out and it’s time to upgrade and take advantaged of the new features…

There are many ways of upgrading, as you can read here: Please read it carefully before proceeding with the upgrade. You can turn your current installation useless.

Both are valid, but not without possible problems.

I have Linux Mint 11 transformed in a Media Center, running XBMC and connected to my Video Projector! And now, i’m ready to upgrade, using the “C2 – Packages Upgrades”.

NOTE: After altering the sources.list and start the upgrade, there’s no turning back.

Warning: I’ve tried and it didn’t work for me… I had errors about apparmor and udev… Had to install all over again… But this method is supported and i’ve tried twice (from Mint 9 to 10 and from 10 to 11) and always had worked.


Warning: It didn’t work for me. It didn’t work for me.It didn’t work for me. It didn’t work for me. It didn’t work for me. It didn’t work for me. It didn’t work for me.


This means that, i’m going to edit the file sources.list of apt, and change the sources.

First, let’s upgrade Linux Mint 11 –

apt-get update

apt-get dist-upgrade

After Linux Mint 11 updates itself, let’s go to update the sources.list. First, copy the file, so we can have a backup (just in case, but after you start to upgrade, there’s no turning back…)

So, i’ll transform the following lines:


deb katya main upstream import backport

deb natty main restricted universe multiverse

deb natty-updates main restricted universe multiverse

deb natty-security main restricted universe multiverse

deb natty partner

deb natty main

deb natty free non-free



deb lisa main upstream import backport

deb oneiric main restricted universe multiverse

deb oneiric-updates main restricted universe multiverse

deb oneiric-security main restricted universe multiverse

deb oneiric partner

deb oneiric main

deb oneiric free non-free

Basically, just alter katya to lisa and natty to oneiric

After you change the sources, let’s update the packages:

apt-get update

apt-get dist-upgrade



1133 upgraded, 373 newly installed, 23 to remove and 0 not upgraded.

Need to get 786 MB of archives.

After this operation, 987 MB of additional disk space will be used.

Do you want to continue [Y/n]?

Just press <enter> and let the “games” begin…

Good Luck

EDIT: Even if you get some errors when apt is upgrading, and the errors does not seam to be critical, ignore them and reboot the machine. After rebooting, just run apt-get upgrade and apt-get dist-upgrade so apt can update any package and configure again the “broken” configurations… I’m not saying the upgrade will work, but i’m finished and everything seems working.

Install core fonts Centos 6

Centos 6 does not comes with the Core Fonts from M$. Here 's how can we add them

yum install ttmkfdir cabextract rpm-build

For chkfontpath, we need the ATrpms repository or download the file directly from

Note: The chkfontpath has dependencies, so it's best to add the ATrpms repository…

If you want to add the ATRPMS repository, just download the rpm to add the repository from here:

rpm -ivh atrpms-repo-6-4.el6.i686.rpm

yum install chkfontpath


rpmbuild -bb msttcorefonts-2.0-1.spec

cd rpmbuild/RPMS/noarch



rpm -ivh msttcorefonts-2.0-1.noarch.rpm

cd /usr/share/fonts/msttcorefonts



Voilá! We have now the M$ core fonts installed and available to us.


Gnome 3 open with custom applications

Gnome 3 is an excellent piece of software ! Is just amazing, but lacks some things. In gnome 2, when we wanted to open an file with an application not in the menu, we could use “Open With” and choose an application – All in graphic mode.

Well, in gnome 3, that’s not possible (at least, after searching a lot, could not find) –


If we choose “Open With Other Application”, we get the “Recommended Applications” and we can choose “Show other Applications”, but the application does not appear.

So, how can we add an application not in the list ?

I want to open AVI files with mplayer and not with Totem. So we get to the command line. Using mimeopen, we can set the default application for files:


Using the -d parameter, we set the default application. The application asks for the application to open, and we can choose “3) Other” and is done.

Disco Rígido (hdd) não detectado antes da instalação

Já me aconteceu, algumas vezes (bem, demasiadas vezes), quando quer instalar um Linux e chega à parte de criar partições, o disco não é detectado.

Isto tem a ver com os novos modos dos discos nas bios, em AHCI ou IDE. Por várias vezes isto tras problemas, mesmo nos mais recentes Linux.

Como resolver?

Bem, existem várias formas:

 - Ás vezes resolve trocar o modo de operação da drive de AHCI para IDE, mas perde-se performance.

 - Outras vezes, é, na linha de arranque de kernel, colocar pci=nomsi . É so arrancar e esperar pelo melhor.

 – Uma das ultimas que descobri (quando nenhuma das anteriores funcionou) é a seguinte:

Arranquem com o Live CD (ou DVD) e entrem no ambiente de trabalho. Se o instalador não detectar o vosso disco, experimentem o seguinte:

Abram uma consola (usem sudo antes dos comandos se não puderem passar para root – comandos executados como root):

fdisk -l

Deverá dar uma listagem dos discos disponíveis (sim, mesmo que o instalador não reconheça o vosso disco, ele aparece listado).

Depois executem:

dmraid -E -r <a vossa drive - caminho completo>

(confirmem sim, que desejam apagar a informação do raid). 

Experimentem novamente o instalador e o disco já deve aparecer.

O que significam os parâmetros:

-r : Lista todos os dispositivos de RAID encontrados como formato, nível de RAID, sectores usados, etc…

-E : Elimina a metadata. Juntamente com o -r, toda a metadata do RAID é eliminada condicionalmente.



Configurar http proxy com filtro de conteúdos (dansguardian)

Activar repositórios necessários.



rpm -ivh rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm

Instalar a chave GPG de DAG

rpm --import


O Repositório EPEL (Extra Packages for Enterprise Linux) é um repositório construído por voluntários do projecto do Fedora para criar um repositório de pacotes adicionais de grande qualidade que complementa o Red Hat Enterprise Linux e distribuições compatíveis (tipo o CentOS). Este repositório fornece muitos pacotes para CentOS/RHEL, que não são parte dos repositórios oficiais, mas que são desenhados para trabalhar com estas distribuições.


rpm -ivh epel-release-5-4.noarch.rpm

Verificar os repositorios

yum repolist

Após o comando anterior, vão aparecer os repositórios disponiveis e a quantidade de pacotes em cada um deles.

Instalar o Squid e o dansguardian

yum install squid dansguardian


Editar o squid.conf

vi /etc/squid/squid.conf

O ficheiro de configuração do squid parece extenso, mas está muito bem documentado. De qualquer forma, as unicas linhas necessárias para uma minima configuração do squid são:


http_port 3128

#Definicao de ACLS

# Redes permitidas
acl AllowedNetworks src

# Se preferirem, em vez de colocar as redes separadas por espaco, podem ser colocadas num ficheiro e adicionadas aqui:
# acl <nome_da_acl> src "ficheiroComRedes"

# Maquinas sem acesso - Se quiserem que maquinas nao tenham acesso a internet
acl Nonet src "ficheiroIPsSemAcesso"

# Sites nao autorizados 
acl sitesDeny dstdom_regex "ficheiroComListaSitesParaNaoAcederemAEles"

#Permitir / Negar ACLS definidas em cima

# Redes
http_access allow AllowedNetworks

# Localhost
http_access allow localhost

# Sites negados
http_access deny sitesDeny

# Negar tudo o resto
http_access deny all

icp_access allow AllowedNetworks
icp_access allow all

hierarchy_stoplist cgi-bin ?

#Cache stuff
cache_replacement_policy lru

# Definicao da cache - tamanho (ate 80% do espaco disponivel) NumerodeDirectoriasPrimeiroNivel NumeroDirectoriasSegundoNivel
cache_dir ufs /cache/cache1 16384 16 256
cache_dir ufs /cache/cache2 16384 16 256

store_dir_select_algorithm round-robin

# Qual o tamanho maximo de objectos a guardar na cache
maximum_object_size 31457280 KB

access_log /var/log/squid/access.log squid
acl QUERY urlpath_regex cgi-bin ?

cache deny QUERY
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern .               0       20%     4320
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache

visible_hostname <hostname da maquina visivel>
cache_mgr <email gestor da maquina>
cache_effective_user squid
cache_effective_group squid

coredump_dir /var/spool/squid

Guardar o ficheiro.
Para iniciar a cache (antes de arrancar com o squid):
squid -z 
Arrancar com o squid:
/etc/init.d/squid start
Para ter a certeza que este inicia aquando de um reboot ao servidor:
chkconfig --levels 35 squid on


O Dansguardian é um filtro de conteúdos bastante bom. Também podem filtrar conteúdos com o squid, mas o Dansguardian foi criado só para isso, e é muito bom. Mantendo a filosofia de Unix – Write programs that do one thing and do it well.
Os ficheiros de configuração encontram-se em /etc/dansguardian
A configuração do dansguardian é efectuada em dansguardian.conf
As opcoes mais relevantes são:

filterip =  
filterport = 8080
proxyip =
proxyport = 3128
As opções:
  • filterip diz respeito ao IP onde o dansguardian deverá escutar por pedidos. Se deixado em branco, escuta em todos os IPs que a máquina tiver. Preencham sempre.
  • filterpor a porta onde escutar. Esta é porta que devem configurar nos clientes
  • proxyip o IP onde o squid está à escuta. Por defeito, é a propria maquina. Se o squid estiver numa maquina diferente, coloquem aqui o IP.
  • proxyport a porta onde o SQUID escuta. Configurada no squid como http_port . Não deverá ser a mesma que o dansguardian.

No ficheiro dansguardianf1.conf encontram-se algumas opções relativamente à filtragem de conteúdos.

Tenham atenção à opção naughtynesslimit.

As listas de conteúdos para filtrar, vamos retirar de Vão a download e retirem o ficheiro.

Assim que tiverem o ficheiro, descomprimam para /etc/dansguardian/. Automaticamente é criada a directoria blacklists. A configuração das listas que desejam que o dansguardian filtre é feita em vários ficheiros:

  • bannedsitelist
  • bannedurllist

Nestes ficheiros encontram-se linhas comentadas que podem ser descomentadas. Atenção que, um dos ficheiros diz respeito a sites e outro aos URLs. Tenham atenção a isso. A seguinte listagem exemplo é do ficheiro bannedurllist.












Descomentem as que desejarem.  Se desejarem, podem adicionar, seguindo as mesmas linhas. Podem haver categorias nas blacklists que não estejam aqui.
Dentro da directoria blacklists encontram um ficheiro chamado CATEGORIES que contém as categorias todas das listas e o conteúdo.
Quando efectuarem alguma alterção com o dansguardian em execução, para que ele leia novamente a configuração:
dansguardian -r
Para iniciar o dansguardian:
/etc/init.d/dansguardian start
Para se certificarem que ele arranca aquando de um reboot do servidor:
chkconfig --levels 35 dansguardian on

Ligação entre dansguardian e squid.

Para que exista ligação entre o dansguardian e o squid, é necessário activar algumas opções:

No squid, existem duas linhas de configuração que temos que activar:

# Para permitir o dansguardian

acl_uses_indirect_client on

# Se nao funcionar, experimentem, na linha seguinte, alterar localhost para o nome da acl para as vossas redes permitidas

follow_x_forwarded_for allow localhost 

No Dansguardian, as linhas são as seguintes:

# if on it adds an X-Forwarded-For: <clientip> to the HTTP request

# header.  This may help solve some problem sites that need to know the

# source ip. on | off

forwardedfor = on

# if on it uses the X-Forwarded-For: <clientip> to determine the client

# IP. This is for when you have squid between the clients and DansGuardian.

# Warning - headers are easily spoofed. on | off

usexforwardedfor = on

Desta forma, os vossos clientes ligam-se ao Dansguardian, onde é efectuada a filtragem de conteúdos e é passada para o squid a informação dos clientes, nomeadamente o IP e os headers necessários.
Neste momento, já deverão ter o squid e o dansguardian em perfeita sintonia.
Nota: Em vez de configurar IPTABLES para negar ligações directas à porta do squid (3128 por defeito), é mais simples, na tag de configuração do squid http_port, escrever:
Desta forma, apenas a máquina local (neste caso o dansguardian; o dispositivo de loopback) pode efectuar ligações directas. Simples e eficaz.
Configuração usando IPTABLES
Até agora, nada impede (a não ser politicas de domínio ou outras restrições) que os vossos clientes chegem ao browser e troquem a porta do proxy, deixando de se ligar ao dansguardian e ligando directamente ao squid, passando assim a filtragem de conteúdos. Para evitar isso, usem a seguinte regra de IPTABLES que nega ligações à porta 3128 excepto do localhost (funciona se o squid e o dansguardian estiverem na mesma maquina – Se assim não for, troquem o ip pelo IP do vosso dansguardian):
Primeiro, permitimos ligações à porta do squid (3138) da própria maquina – Se o Dansguardian estiver noutra maquina, troquem o IP:
iptables -A INPUT -i eth0 -s -p tcp --destination-port 3128 -j ACCEPT
Seguidamente, negamos todas as ligações:
iptables -A INPUT -i eth0 -p tcp --destination-port 3128 -j DROP
Desta forma, se alguém se tentar ligar directamente à porta do squid, não vai conseguir ligação.


Instalar Koha 3.00.06 em Centos 5.5

install koha-3.00.06 on Centos 5.5

Koha é um ILS (Integrated Library System – Sistema de Gestão de Bibliotecas) gratuito e Open Source. É usado em todo o mundo, demonstrando a sua robustez.

Sendo todo baseado em PERL, não é dificil de instalar, mas tem muitas dependências e o processo é demorado.

Activar repositórios necessários


rpm -ivh rpmforge-release-0.5.1-1.el5.rf.x86_64.rpm

Repositórios Opcionais – Não necessárias à instalação do Koha

O Repositório EPEL (Extra Packages for Enterprise Linux) é um repositório construído por voluntários do projecto do Fedora para criar um repositório de pacotes adicionais de grande qualidade que complementa o Red Hat Enterprise Linux e distribuições compatíveis (tipo o CentOS). Este repositório fornece muitos pacotes para CentOS/RHEL, que não são parte dos repositórios oficiais, mas que são desenhados para trabalhar com estas distribuições.

rpm -ivh epel-release-5-4.noarch.rpm

Verificar repositorios

yum repolist

Instalar o plugin yum-priorities

yum install yum-priorities

Este plugin vai-nos permitir definir prioridades nos repositorios para evitar problemas com actualizações e preferências ao instalar determinados pacotes

editar o ficheiro /etc/yum/pluginconf.d/priorities.conf e verificar que está activado
enabled = 1

A cada repositorio, adicionamos (ou configuramos) a prioridade, de 1 a 99.
priority=N (mais pequeno, mais prioritario)

Definições recomendadas são:
Mirrors do Centos [base], [addons], [updates], [extras] com priority=1
[contrib] .. priority=2

Repositorios de terceiros, superior a 10

Antes de se começar a instalar o koha propriamente dito, é necessário ter algumas aplicações necessárias instaladas.

HTTP SERVER – Servidor Web

yum install httpd

configurem o apache como desejarem

vim /etc/httpd/conf/httpd.conf

Adicionem o apache aos serviços de arranque
chkconfig --levels 345 httpd on

Base de dados – MySQL

yum install mysql-server

Adicionar ao arranque
chkconfig --levels 345 mysqld on

Configurar o Mysql
/etc/init.d/mysqld start


Criar a base de dados para o koha
mysql -uroot -p
create database koha;
create user 'kohaadmin'@'localhost' identified by '<password>';
grant select, insert, update, delete, create, drop, alter, lock tables on koha.* to  'kohaadmin'@'localhost';
flush privileges;

Instalar o memcached

O memcached (que é usado pelo koha, se instalado) é um sistema de distribuição de objectos em memória, de alta-performance.

Por problemas com o pacote perl-Net-SSLeavy, temos que o instalar à mão. O que está disponivel (e instalado) é a versão 1.30 e precisamos pelo menos da versão 1.33.
Remover o anterior
yum remove perl-Net-SSLeay

rpm -ivh perl-Net-SSLeay-1.36-1.el5.rfx.x86_64.rpm

Instalar o memcached e adicionar ao arranque da máquina

yum install memcached

/etc/init.d/memcached start
chkconfig --levels 345 memcached on

O memcached corre no porto 11211
Para verificar definições:

echo "stats settings" | nc localhost 11211
STAT maxbytes 67108864
STAT maxconns 1024
STAT tcpport 11211
STAT udpport 11211
STAT verbosity 0
STAT oldest 0
STAT evictions on
STAT domain_socket NULL
STAT umask 700
STAT growth_factor 1.25
STAT chunk_size 48
STAT num_threads 4
STAT stat_key_prefix :
STAT detail_enabled no
STAT reqs_per_event 20
STAT cas_enabled yes
STAT tcp_backlog 1024
STAT binding_protocol auto-negotiate
STAT auth_enabled_sasl no
STAT item_size_max 1048576

Mais informações no site do memcached

Instalar Zebra Utilities

Necessario gcc e automake
yum install gcc (retira as dependencias necessarias)

Instalar aplicacoes necessarias
yum install bison libxml2-devel libxslt-devel libicu-devel tcl-devel libxlt-devel expat-devel

Efectuar o download da aplicacao YAZ

tar -zxvf yaz-4.1.1.tar.gz
cd yaz-4.1.1.tar.gz
make install

cd idzebra-2.0.44
make install

Adicionar utilizador e grupo koha

group add koha
useradd -d /usr/share/koha -g koha -s /bin/false koha

Dependencias do KOHA

DBI 1.53

Agora temos duas opcoes – Segundo o INSTALL do koha, podemos executar o ficheiro perl e ele instala todas as dependencias via CPAN, ou instalamos manualmente:

Os que podemos instalar via yum:

yum install -y perl-Algorithm-CheckDigits perl-CGI-Session perl-Class-Accessor perl-Class-Factory-Util perl-DBD-MySQL perl-Data-ICal perl-Date-Calc perl-Date-Manip perl-Date-ICal perl-Digest-SHA perl-Email-Date perl-GD perl-GD-Barcode perl-List-MoreUtils perl-Lingua-Stem perl-IPC-Cmd perl-HTML-Template perl-HTML-Template-Pro perl-HTML-Scrubber perl-Mail-Sendmail perl-MARC-Record perl-MIME-Lite perl-PDF-API2 perl-Schedule-At perl-POE perl-Text-CSV perl-Text-CSV_XS perl-Text-Iconv perl-XML-Dumper perl-XML-LibXML perl-XML-LibXSLT perl-XML-RSS perl-XML-SAX-Writer perl-YAML-Syck

NOTE: O koha posteriormente queixa-se das versoes instaladas: Aqui ficam algumas actualizacoes:


rpm -Uvh perl-DBI-1.616-1.el5.rfx.i386.rpm

rpm -Uvh perl-DBD-MySQL-4.014-1.el5.rfx.x86_64.rpm

Os restantes, instalamos via CPAN
perl -MCPAN -e shell

install Biblio::EndnoteStyle
install CGI::Session::Serialize::yaml
install HTTP::OAI
install DBI (apesar de estar disponivel pelo yum, o koha queixou-se)
install MARC::Charset MARC::Crosswalk::DublinCore
install MARC::File::XML
install Net::LDAP::Filter
install PDF::API2::Page PDF::API2::Util
install PDF::Reuse PDF::Reuse::Barcode
install SMS::Send
install Text::CSV::Encoded
install XML::Simple

O ZOOM corre bem (compilação é efectuada), mas falha nos testes e não instala. Podemos forcar a instalação com o seguinte comando:
force install Net::Z3950::ZOOM

tar -zxvf koha-3.00.06-all-translations.tar.gz (ou seja qual o nome do vosso ficheiro)
cd koha-3.00.06

perl Makefile.PL
Responder a questoes colocadas pelo ficheiro de instalacao.
Eu fiz assim:

Installation mode - Standard
Base installation directory - /usr/share/koha
User Account - koha
Group - koha
DBMS - Mysql
Database server - localhost
DMBS - 3306
Name of Database (criado em cima) - koha
Username - kohaadmin
password - <password>
Install zebra configuration files - yes
MARC Format for zebra indexing - <depende da vossa biblioteca>
Primary language - en
Authorities indexing mode - dom (mais recente, mais rapido)
Zebra database user - kohauser
zebra database password - zebrastripes
SRU cinfiguration files - yes
SRU database host - localhost
SRU port for bibliographic data - 9998
SRU port for authority data - 9999
PazPar2 - yes
Zebra bibliographic server host - localhost
PazPar2 port - 11001
PazPar2 host - localhost
PazPar2 port - 11002
Database test suit - no

O koha a seguir mostra as dependencias do perl que ainda nao estejam satisfeitas.
No meu caso, ele queixa-se do DBI que não encontra… mas ele está instalado.

make install

Seguindamente, a instalação pede-nos para definirmos duas variáveis de ambiente. O melhor local para as colocar será em /etc/profile

vi /etc/profile e acrescentar:

export KOHA_CONF=/etc/koha/koha-conf.xml
export PERL5LIB=/usr/share/koha/lib

Para as definir imediatamente, executem
source /etc/profile

Para definir as configurações para o servidor do koha

ln -s /etc/koha/koha-httpd.conf /etc/httpd/conf.d/

Para o koha funcionar bem, precisamos que o apache tenha o mod_rewrite activado. Para verificar,

grep mod_rewrite /etc/httpd/conf/httpd.conf

e tem que aparecer a seguinte linha:
LoadModule rewrite_module modules/
Editar o ficheiro /etc/httpd/conf/httpd.conf e acrescentar:

(manter a linha Listen 80)
Listen 8080

Reiniciamos o apache
/etc/init.d/httpd restart

Servicos Zebra

Agora, temos que arrancar com o zebrasrv, mas vamos colocar em background (daemon mode):
zebrasrv -D -f /etc/koha/koha-conf.xml
e vamo-nos certificar que inicia sempre que efectuarmos um reboot ao servidor, adicionando a seguinte linha a /etc/rc.local

echo "/usr/local/bin/zebrasrv -D -f /etc/koha/koha-conf.xml" >> /etc/rc.local

Para finalizar, navegar ate:
http://<vosso_servidor_koha>:8080/ e finalizar a instalação


O Koha mantem os logs em /var/log/koha. Se tiverem algum problema sera aqui que devem comecar a verificar a origem do mesmo.

Dependências de PERL
Se o koha se queixar de algum problemad de dependências, verifiquem se foi instalado o pacote do qual ele se queixa por RPM.
rpm -qa | grep -i <pacote | parte do nome>
Se obtiverem resultados, significa que foi instalado por RPM.
Neste caso, instalem o mesmo pacote pelo CPAN.


Monitorizar sistema de ficheiros com inotify

Existem muitas ocasiões onde é necessário monitorizar o nosso sistema de ficheiros, para saber o que se passa com algum ficheiro ou directoria. Existem muitas soluções, mas há algumas melhores que outras. Em Linux existe algo que se chama inotify.

A maioria dos sitemas Linux mais recentes já traz suporte para o inotify.

grep -i inotify /boot/config-$(uname -r)



Como o inotify está no kernel, todos os programas desenvolvidos para Linux podem tirar partido dele sem usar nenhuma biblioteca especial.

Existe um conjunto de ferramentas, inotify-tools, que contém programas para usar esta funcionalidade fantástica do kernel. Esta ferramenta inclui aplicações como inotifywait e inotifywatch.

Primeiro, vamos instalar o inotify-tools. Em CentOS 6 não existe qualquer pacote nos repositorios oficiais, mas, estão disponiveis RPMs.

Em, há pacotes para CentOS 6.

Se usarem o CentOS 6, o wget também não vem instalado e precisam de o instalar:

yum install wget


rpm -ivh inotify-tools-3.13-1.el6.rf.x86_64.rpm

Para terem uma ideia do que o inotifywatch faz, experimentem:

Por exemplo, para monitorizar a nossa home

inotifywatch -r ~

Numa outra consola, abram o firefox, ou alguma outra aplicação.

Agora, na consola onde têm o inotifywatch aberto, interrompam a execução (Ctrl + C) e vejam as estatísticas que ele devolve:

total  attrib  close_write  close_nowrite  open  create  delete  filename

15     1       1            4              5     1       3       /root/

Com esta ferramenta, podem ver estatisticas .

Este comando vai verificar, recursivamente, todos os eventos que ocorrem na nossa home (neste caso). Podemos também refinar o nosso comando e apenas monitorizar os eventos que desejamos, usando a opção -e:

inotifywatch -e create, delete, delete_self -r ~

Desta forma, apenas quando ficheiros (ou directorias) forem criadas ou apagadas é que serão gerados eventos. Para saberem quais os eventos que podemos monitorizar:

inotifywatch --help


access file or directory contents were read

modify file or directory contents were written

attrib file or directory attributes changed

close_write file or directory closed, after being opened in writeable mode

close_nowrite file or directory closed, after being opened in read-only mode

close file or directory closed, regardless of read/write mode

open file or directory opened

moved_to file or directory moved to watched directory

moved_from file or directory moved from watched directory

move file or directory moved to or from watched directory

create file or directory created within watched directory

delete file or directory deleted within watched directory

delete_self file or directory was deleted

unmount file system containing file or directory unmounted

Com este comando, iremos ver (quando o terminarmos) o que aconteceu.

Existe um comando melhor, que permite visualizar em tempo real o que está a acontecer, ao contrário do inotifywatch. Esse comando chama-se inotifywait.

No entanto, o que desejamos é realmente que alguma acção seja realizada consoante um determinado evento seja detectado. Para isso, vamos usar o iwatch –
O iwatch faz isto tudo se algum evento acontecer na directoria ou ficheiro escolhidos. Depende de quatro módulos de PERL:
yum install perl-Event perl-Mail-Sendmail perl-XML-Simple perl-XML-SimpleObject perl-Linux-Inotify2
O iwatch pode-se executar de duas formas, ou como um daemon ou directamente na linha de comandos.

Linha de comandos

Para verem o que pode ser feito com o iwatch, vamos fazer um teste. Abram duas consolas.
Na primeira, executem o iwatch com o evento de criacao de ficheiros e onde envia um email a notificar:
./iwatch -r -e create,delete -m <nome>@<dominio> /tmp
e deixem estar.
Na outra consola, vão até à directoria /tmp e criem um ficheiro:
touch istoficheiro

Reparem que na consola com o iwatch a correr, ja apareceram eventos:
IN_CREATE /tmp/istoficheiro
[12/Jan/2011 19:35:44] * Send email to <nome>@<dominio>

Os eventos vistos pelo iwatch são vários. Estes foram apenas um exemplo.
Ao apagar um ficheiro (ou directoria):

IN_DELETE /tmp/istoficheiro
[12/Jan/2011 19:36:51] * /tmp/istoficheiro is deleted
[12/Jan/2011 19:36:51] * Send email to <nome>@<dominio>
Como podem ver, é simplesmente genial.
Agora, imaginem que não querem enviar um email, mas executar uma acção (duas consolas – numa executam o comando em baixo e na outra criam e removem ficheiros de tmp):
(primeira consola)
./iwatch -r -e create,delete -c "top" /tmp
(segunda consola)
touch ficheiro
(primeira consola)
[14/Jan/2011 14:30:33] IN_CREATE /tmp/ola
[14/Jan/2011 14:30:33] * /tmp/ola is deleted
[14/Jan/2011 14:30:33] * Command: top

Desta forma o iwatch executa o comando especificado quando algum dos eventos monitorizados acontecer.

Daemon mode

Este modo é talvez o melhor, pois não precisamos de indicar tudo na linha de comandos. O iwatch, neste modo, usa um ficheiro de configuração onde constam as directorias a monitorizar, os eventos e as acções.
O ficheiro chama-se iwatch.xml e a configuração é bastante simples. A sua sintaxe é xml. Em baixo está um exemplo.
<config charset="utf-8">
  <guard email="root@localhost" name="IWatch"/>
    <title>Public Website</title>
    <contactpoint email="webmaster@localhost" name="Web Master"/>
    <path type="single" syslog="on">/var/www/localhost/htdocs</path>
    <path type="single" syslog="off">/var/www/localhost/htdocs/About</path>
    <path type="recursive">/var/www/localhost/htdocs/Photos</path>
    <path type="single" events="default,access" alert="off" exec="(w;ps)|mail -s '%f is accessed at %{%H:%M:%S}d' root@localhost">/tmp/dir3</path>
    <path type="exception">/etc/mail/statistics</path>

Exemplo de configuração a funcionar:
Esta configuração monitoriza a directoria /var/www/html por ficheiros alterados, apagados ou criados. Quando algum desses eventos é gerado, executa o rsync para sincronizar a directoria com o servidor remoto.

<config charset="utf-8">
  <guard email="iwatch@localhost" name="IWatch"/>
    <title>Public Website</title>
    <contactpoint email="webmaster@localhost" name="webmaster"/>
    <path type="recursive" alert="off" events="create,delete,modify" exec="rsync -avz --delete -e ssh /var/www/html/ root@otherHost:/var/www/html">/var/www/html</path>

Podemos especificar várias directorias a monitorizar, onde podemos monitorizar apenas a directoria ou recursivamente todas as que se encontrem por baixo dela (type). 
Para cada directoria podemos especificar se queremos ser notificados por email (alert), executar um comando (exec), quais os eventos a monitorizar (events), se queremos que seja escrito algo no syslog (syslog), etc..

Assim que tiverem criado um ficheiro de configuração, temos que efectuar algumas operações.
Copiar o ficheiro iwatch.xml e iwatch.dtd para /etc
cp iwatch.xml iwatch.dtd /etc
Copiar iwatch (o binário) para /usr/local/bin
cp iwatch /usr/local/bin
Para executar o iwatch em daemon mode, antes de colocarmos automático no arranque do computador, vamos experimentar
/usr/local/bin/iwatch -d -v
O parametro -d coloca o iwatch em daemon mode e o -v  coloca-o em verbose mode. Ao usarem o verbose mode, ele coloca no syslog as directorias em monitorização e quando acontece algum evento.
Vamos verificar se está em execução:
ps -aef | grep -i iwatch

root      3377     1  1 15:10 ?        00:00:00 /usr/bin/perl -T /usr/local/bin/iwatch -d -v
Agora, recordem as directorias que especificaram no ficheiro de configuração e façam testes.
Para que o iwatch fique em execução no reboot da máquina, em CentOS (e variantes Red Hat) podemos colocar o comando em /etc/rc.local
E já está. Um sistema completo de monitorização e notificação para o que precisarem. Muito simples e eficiente.

Aplicação Prática

Onde se pode aplicar isto?
Bem, imaginem que têm servidores expostos na Internet, e por questões de segurança, configuram dois servidores, um principal e outro secundário. O principal está na vossa rede interna e o secundário está exposto à Internet.
Os utilizadores alteram e actualizam o principal (interno) que automaticamente sincroniza as alterações para o externo, que contém uma firewall e que apenas deixa passar os portos do MySQL (para a replicação) e do rsync (ambos para tráfego vindo da rede interna), que é executado cada vez que há uma alteração no /var/www/html, que está a ser monitorizado pelo iwatch.
Simples, não é ?

Replicação entre servidores MySQL

MySQL é uma das base de dados Open Source mais utilizadas no mundo. 

Este tutorial vai mostrar como criar um servidor de replicação do MySQL.

A replicação no MySQL permite que tenhamos um ou mais servidores exactamente iguais.

Nota: A replicação não é nenhum processo de Backup. Tudo o que for efectuado no servidor Master será imediatamente replicado para o servidor Slave.

Vamos mostrar como replicar uma base de dados (exemplodb) já existente no master para o servidor slave.

Configurar o Master


Agora, vamos entrar no MySQL e criar um utilizador para replicação

mysql -uroot -p

grant replication slave on *.* to '<utilizador_replicacao>'@'%' identified by '<password>';

flush privileges;

Seguidamente, configurar o servidor para a replicação:

Editar o ficheiro /etc/my.cnf para activar a funcionalidade de network no MySQL. Se as seguintes linhas existirem, têm que as comentar:


#bind-address            =

Seguidamente, temos que indicar ao MySQL para que base de dados deve escrever logs,  (estes logs vão permitir ao servidor slave verificar o que se passa no servidor Master),  que ficheiro usar para os escrever e indicar que este servidor é o Master.

Relativamente aos logs, eu gosto de os manter separados, assim, criei uma directoria em /var/logs chamada mysqld.

cd /var/log

mkdir mysqld

chown mysql:mysql -R mysqld

Novamente, editamos o ficheiro /etc/my.cnf e acrescentamos as seguintes linhas na zona [mysqld]:




Guardamos e reiniciamos o servidor Master.

/etc/init.d/mysqld restart

Neste momento, ja temos o MySQL a criar logs binários.

Configuração Slave

No servidor slave, vamos editar o ficheiro /etc/my.cnf e na secção [mysqld]:



master-host= <tambem podem user o hostname>


master-user=utilizador_replicacao (criado em cima)






Agora, reiniciem o serviço:
/etc/init.d/mysqld restart

Inserir os dados no SLAVE

No servidor Master

Assumindo que têm um slave vazio. Se o servidor master estiver constantemente a ser acedido, temos que prevenir o acesso às tabelas antes de as replicar. Se não houver dados a serem acedidos no servidor, podem passar este passo.

mysql -uroot -p

mysql> flush tables with read lock;

Agora, iremos usar o mysqldump para retirar os dados:

mysqldump -uroot -p exemplodb > exemplodb.sql

Copiem o ficheiro exemplodb.sql para o servidor slave.


No servidor Slave

mysql -uroot -p

create database exemplodb

mysql -uroot -p -D exemplodb < exemplodb.sql


Colocar a replicação a funcionar

A partir deste momento, estamos prontos para colocar os servidores a replicar

No servidor Master

mysql -uroot -p

Precisamos de saber qual a posição nos logs onde o master está:

mysql> show master status;


| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |


| mysqld-bin.000001 |       98 | exemplodb     |                 | 


Escreva a informacao em cima, vamos precisar dela para o servidor slave. Esta informação vai permitir saber desde quando o servidor slave vai replicar os dados. Se não colocarmos esta informação, só começa a replicar a partir do momento que o slave iniciar.

mysql> quit;

No servidor Slave

mysql -uroot -p

Agora vamos parar o slave e indicar-lhe exactamente onde procurar no log do servidor master. Usamos os valores do resultado anterior no servidor Master.

slave stop

change master to master_host='', master_user='utilizador_replicacao', master_password='password', master_log_file='mysqld-bin.000001', master_log_pos=98;

slave start



master_host : o endereço (ou hostname) do servidor Master
master_user : o utilizador criado em cima para efectuar a replicação
master_password : a password dada ao utilizador em cima
master_log_file : o ficheiro visto em cima quando vimos o status do master
master_log_pos : o valor também mostrado na tabela vista em cima.

O servidor Slave vai agora ficar à espera de alterações, mas antes, ainda existe uma coisa a fazer.

De volta ao Master

mysql -uroot -p

unlock tables;

Nota: Só é preciso efectuar o comando em cima se foi efectuado o comando FLUSH TABLES WITH READ LOCK;


O manual do Mysql indica que, se as tabelas forem InnoDB, que se devem adicionar os seguintes parâmetros ao my.cnf, em [mysqld]:


Pronto. Neste momento todos os dados do Master já se encontram no slave. Qualquer alteração efectuada no Master será replicada para o slave. Atenção, isto é válido para qualquer comando, até drop. Como foi dito no inicio, a replicação não é uma forma de bakcup.


Wiithon em Caixa Mágica

Wiithon é um gestor de WBFS. Para quem não sabe, o WBFS é o sistema de ficheiros usado na Wii. Isto permite criar backups dos nosso jogos para a Wii e jogar com os mesmos em vez dos originais, para os preservarmos.

O Wiithon por defeito existe para Ubuntu, mas como é feito em Linux, podemos agarrar no código fonte e compilar nós mesmos. Que no caso do Wiithon, não é complicado.

Vamos buscar o código fonte do Wiithon à página do launchpad, que é um repositório de código Open Source.

O launchpad é baseado no Bazaar, que é um gestor de software, tal como o subversion, o CVS e o GIT. Temos que o instalar na nossa máquina.

Abram uma consola, ou usem o Synaptic e instalem o Bazaar.

apt-get install bzr

A partir deste momento, já temos o bazaar e já podemos ir buscar o código.

Na consola (já não têm que ser root – para já) e executem:

bzr branch lp:wiithon

Agora, o bzr vai descarregar o código. Quando terminar, teremos uma directoria chamada wiithon.

Antes de podermos compilar, temos que nos certificar que temos todas as dependências necessárias.

Segundo a página, estas são os pacotes que temos que ter instalados:

  • libc6 (>= 2.4), libc6-dev (>= 2.4), python (>= 2.5)
  • gcc-multilib (>= 4.4) [solo para amd64] (no Caixa Mágica a 64bits este pacote não se encontra. De qualquer forma, não é necessário. O GCC normal serve perfeitamente.
  • python-sqlalchemy (>= 0.4)
  • imagemagick
  • gnome-icon-theme
  • libgtk2.0-0 (>= 2.16), python-gtk2 (>= 2.16), python-glade2 (>= 2.16)
  • python-libxml2
  • unzip

Para procurar algum pacote, usem as palavras mais relevantes, pois em CM alguns dos pacotes não têm as mesmas designações

Procurar pelo python-sqlalchemy:

apt-cache search alchemy

python-sqlalchemy - SQL toolkit and object relational mapper for Python
python-elixir - Declarative mapper on top of SQLAlchemy

Este é o noss resultado. Para o instalar:

apt-get install  python-sqlalchemy

Desta forma, conseguem todas as dependências (alguns pacotes já devem estar instalados)

Uma vez todas as dependências resolvidas, vamos compilar.

Dentro da directoria Wiithon, devem encontrar um ficheiro chamado Makefile.

Só têm que escrever make e vai começar a diversão.


Assim que terminar, e sem erros, vamos instalar:

(como root)

make install

Para poderem executar o Wiithon com o vosso utilizador, têm que o adicionar ao grupo disk, para que possa manipular à vontade o disco onde vão guardar os jogos.

gpasswd -a <utilizador> disk.

Têm que terminar a sessão e voltar a entrar para que as alterações aos vossos grupos sejam activadas.

Para usarem um disco externo para os backups dos vossos jogos, têm que o formatar em FAT32 e posteriormente, com o Wiithon, converter para WBFS.