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)

CONFIG_INOTIFY=y

CONFIG_INOTIFY_USER=y

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 http://pkgs.repoforge.org/inotify-tools/, 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

wget http://pkgs.repoforge.org/inotify-tools/inotify-tools-3.13-1.el6.rf.x86_64.rpm

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

Events:

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 – http://iwatch.sourceforge.net/index.html
 
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"/>
  <watchlist>
    <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>
  </watchlist>
</config>

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"/>
  <watchlist>
    <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>
  </watchlist>
</config>

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:

#skip-networking

#bind-address            = 127.0.0.1

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]:

log-bin=/var/log/msqyld/mysql-bin.log

binlog-do-db=exemplodb

server-id=1

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]:

 

server-id=2

master-host=10.20.30.10 <tambem podem user o hostname>

master-connect-retry=60

master-user=utilizador_replicacao (criado em cima)

master-password=<password_do_utilizador>

replicate-do-db=exampledb

relay-log=/var/log/mysqld/slave-relay.log

relay-log-index=/var/log/mysqld/slave-relay-log.index

 

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='10.20.30.10', master_user='utilizador_replicacao', master_password='password', master_log_file='mysqld-bin.000001', master_log_pos=98;

slave start

 

Valores:

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;

Notas:

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

innodb_flush_log_at_trx_commit=1
sync_binlog=1

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.

Referências

http://aciddrop.com/2008/01/10/step-by-step-how-to-setup-mysql-database-replication/

http://www.howtoforge.com/mysql_database_replication

Instalar winetools em CM15

Wine é uma ferramenta fantástica para Linux. Permite-nos correr algumas aplicações de windows em Linux sem ter que recorrer aquele sistema operativo proprietário.

No entanto, a sua configuração e instalação de aplicações pode ser um pouco complicado. Felizmente, existem projectos que nos facilitam nestas tarefas.

Winetools é uma das ferramentas mais utilizadas no mundo, e é bastante robusta e eficaz.

Para o Caixa Mágica não existe um RPM. Desta forma, temos que o instalar manualmente (nada de complicado) mas que exige a instalação de algums pacotes.

O site oficial do winetools é http://www.von-thadden.de/Joachim/WineTools/, mas eu não consegui efectuar o download do winetools do site, pois dava um erro. Assim, consegui efectuar o download daqui: http://www.sfr-fresh.com/linux/misc/winetools-0.9jo-III.tar.gz/, sendo a ultima versão do winetools a 0.90jo-III.

Uma vez efectuado o download, só tem que descomprimir:

tar -zxvf winetools-0.9jo-III.tar.gz

Uma vez descomprimido, vamos até à directoria criada:

cd winetools-0.9jo-III

Agora, temos que passar para root para efectuar a instalação.

su

<password>

./install

Não liguem aos erros que dá, são totalmente inofensivos.

Antes de poder ser utilizado, alguns pacotes têm que ser instalados:

apt-get install Xdialog lib64gtk+1.2

Nesta fase, temos tudo pronto, mas o winetools usa uma versão do Xdialog que ele próprio traz, e que não funciona, dando erro que não encontra a biblioteca lib64gtk+1.2.so.0.

Vamos até /usr/local/winetools. Nesta directoria está a instalação do winetools.

Uma vez lá dentro, façam ls. Vão encontrar dois ficheiros chamados Xdialog. Um é um link simbolico para o Xdialog.builtin e o outro é o Xdialog.builtin.

Para que isto funcione, vamos apagar o Xdialog (o link simbolico), e criar um nosso para a localização do Xdialog instalada no nosso sistema.

rm -f Xdialog

ln -s /usr/bin/Xdialog

Desta forma, o winetools já vai funcionar sem problemas.

Nota: O meu sistema é amd64. Não sei se este problema tem a ver com isto ou não, mas de qualquer forma, aqui fica a correcção.

Blackberry e problemas em montar o cartão de memória em CM15 (Caixa Mágica)

O Blackberry é um telemóvel fantástico. A ligação USB permite que seja montado em Linux como um dispositivo de armazenamento. Por vezes há um problema que ele não é montado e em /var/log/messages aparecem as seguintes informações:

 

kernel: usb 1-3: new high speed USB device using ehci_hcd and address 7

Nov 24 10:09:30 localhost kernel: usb 1-3: New USB device found, idVendor=0fca, idProduct=8004

Nov 24 10:09:30 localhost kernel: usb 1-3: New USB device strings: Mfr=1, Product=5, SerialNumber=3

Nov 24 10:09:30 localhost kernel: usb 1-3: Product: RIM Composite Device

Nov 24 10:09:30 localhost kernel: usb 1-3: Manufacturer: Research In Motion

Nov 24 10:09:30 localhost kernel: usb 1-3: SerialNumber: E2388D276808D284F38B1A5E1259EFDCF770D8DD

Nov 24 10:09:30 localhost kernel: scsi9 : usb-storage 1-3:1.1

Nov 24 10:09:30 localhost kernel: usb 1-3: usbfs: interface 1 claimed by usb-storage while 'bcharge' sets config #1

Nov 24 10:09:31 localhost kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 7

onde em vez de ser reconhecido o cartão de memória, aparece a aplicação bcharge que não permite que isso aconteça.

Isto é "um problema" com as regras de udev. Coloquei "um problema" entre parêntesis porque não é realmente um problema.

Isto torna-se simples de corrigir.

Como root, vamos remover esta regra do udev.

cd /etc/udev/rules.d

Aí, vamos encontrar um ficheiro chamado 10-blackberry.rules

É neste ficheiro que se encontra a regra que, ao colocar um blackberry, a aplicação bcharge entra em funcionamento, não deixando o cartão de memória ser reconhecido e montar correctamente.

Movemos o ficheiro para a directoria anterior (não vamos apagar o ficheiro).

mv 10-blackberry.rules ../

Posteriormente, dizemos ao udev para tornar a ler as regras.

udevadm control –reload-rules

Podem desligar o BlackBerry e tornar a ligar que o cartão de memória já vai ser reconhecido e montado automaticamente.

 

Nov 24 10:14:26 localhost kernel: usb 1-3: USB disconnect, address 7

Nov 24 10:14:31 localhost kernel: usb 1-3: new high speed USB device using ehci_hcd and address 8

Nov 24 10:14:31 localhost kernel: usb 1-3: New USB device found, idVendor=0fca, idProduct=8004

Nov 24 10:14:31 localhost kernel: usb 1-3: New USB device strings: Mfr=1, Product=5, SerialNumber=3

Nov 24 10:14:31 localhost kernel: usb 1-3: Product: RIM Composite Device

Nov 24 10:14:31 localhost kernel: usb 1-3: Manufacturer: Research In Motion

Nov 24 10:14:31 localhost kernel: usb 1-3: SerialNumber: E2388D276808D284F38B1A5E1259EFDCF770D8DD

Nov 24 10:14:31 localhost kernel: scsi10 : usb-storage 1-3:1.1

Nov 24 10:14:36 localhost kernel: scsi 10:0:0:0: Direct-Access     RIM      BlackBerry SD    0002 PQ: 0 ANSI: 0 CCS

Nov 24 10:14:36 localhost kernel: sd 10:0:0:0: Attached scsi generic sg2 type 0

Nov 24 10:14:36 localhost kernel: sd 10:0:0:0: [sdb] Attached SCSI removable disk

Nov 24 10:14:39 localhost kernel: sd 10:0:0:0: [sdb] 15523840 512-byte logical blocks: (7.94 GB/7.40 GiB)

Nov 24 10:14:39 localhost kernel: sd 10:0:0:0: [sdb] Assuming drive cache: write through

Nov 24 10:14:39 localhost kernel: sd 10:0:0:0: [sdb] Assuming drive cache: write through

Nov 24 10:14:39 localhost kernel: sdb: sdb1

 
Esta solução não é optima, mas funciona. O BlackBerry carrega na mesma e podemos mexer à vontade no cartão de memória.
 
Funciona para CM15, mas em qualquer outra distribuição de Linux também funcionará. Se o ficheiro não existir, basta procurarem pela palavra bcharge:
 
grep -i bcharge *
 
o -i signifca não ligar à capitalização das letras
e deverá aparecer algum resultado, como o nome do ficheiro onde se encontra:
 
10-blackberry.rules:# Note: the following rules may appear wasteful, in that bcharge is run
10-blackberry.rules:#       CONFIG_USB_SUSPEND enabled.  The second time bcharge is run
10-blackberry.rules: RUN="/usr/sbin/bcharge -p %p",
10-blackberry.rules: RUN="/usr/sbin/bcharge"
10-blackberry.rules: RUN="/usr/sbin/bcharge -p %p"
10-blackberry.rules: RUN="/usr/sbin/bcharge -p %p"
10-blackberry.rules: RUN="/usr/sbin/bcharge -p %p"
 
Assim que identificarem o ficheiro, basta move-lo para outra localização e efectuarem o reload das regras do udev.
 
 

SVN (Subversion) Proxy Settings

Para quem usa subversion para retirar ficheiros, ou mesmo efectuar o upload de ficheiros, e está por trás de um proxy, não consegue.

Existe uma forma em Linux de usar um proxy, que é exportar variáveis de ambiente:

export http_proxy=http://proxy.dominio.com:porta/

export ftp_proxy=http://proxy.dominio.com:porta/

e colocar estas variáveis no ~/.bashrc para o utilizador ou em /etc/profile para o sistema. Embora funcione para muitas aplicações de linhas de comandos, o subversion (svn) não usa.

Assim, é necessário um pequeno truque para "obrigar" o subversion a usar um proxy.

Basta editar o ficheiro servers e configurar as variáveis com os valores correctos.

vi ~/.subversion/servers

[global]
http-proxy-exceptions = *.dominio.com
http-proxy-host = proxy.dominio.com
http-proxy-port = porta_proxy

Guardar e experimentar novamente. Desta vez o subversion já irá funcionar.

No mesmo ficheiro também encontram variáveis para preencher caso precisem de um utilizador e uma password

Referências:

http://blogs.sun.com/venu/entry/svn_proxy_settings

Problemas com apt-get e proxy (squid)

Recentemente começei a usar o apt para actualizar a minha distribuição (Caixa Mágica 15) e instalar pacotes, e desde então começei a ter problemas quando fazia apt-get update (para actualizar a listagem de pacotes), devolvendo-me sempre isto:

Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_main pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_main_updates pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_main32 pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_main32_updates pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_contrib pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_contrib_updates pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_contrib32 pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_contrib32_updates pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_non-free pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_non-free_updates pkglist
  Connection failed
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_non-free32 pkglist
  The http server sent an invalid reply header
Hit http://ftp.caixamagica.pt media_info/synthesis.hdlist_non-free32_updates pkglist
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_contrib pkglist
  The http server sent an invalid reply header

Pensei que fosse alguma coisa com os mirrors da Caixa Mágica, mas em minha casa não acontece nada disto. No meu local de trabalho uso um proxy (Squid 3.1) e pensei que fosse este o problema, então comecei a investigar.

Existe uma opção no Squid que controla como gerir um tipo de pedido – "If-Modified-Since" – dos clientes. Por defeito, o Squid responde baseado na idade do objecto que tem na cache e não no objecto real na página web. Os comentários no ficheiro de configuração do squid indicam que alguns clientes usam pedidos IMS quando pedem uma actualização. – APT é um desses clientes.

Assim, é necessário alterar uma opção no squid para que este, quando detecte um pedido destes, envie a ultima versão do objecto pedido.

Um pedido IMS – If-Modified-Since" é um mecanismo de revalidação na especificação 1.1 do HTTP que garante que os dados em cache estão actualizados.

vi /etc/squid/squid.conf

e acrescentar/alterar

refresh_all_ims on

squid -k reconfigure

Desta forma, os erros já não aparecem.

 

Referências:

http://veejoe.net/blog/2009/05/trouble-with-apt-get-and-squid/

http://www.squid-cache.org/Doc/config/refresh_all_ims/

http://www.cisco.com/en/US/docs/internetworking/technology/handbook/Net_caching.html

Instalar Remmina em CM15

Remmina é uma aplicação cliente de desktop remoto, em GTK, que permite ligar-se a outros computadores por uma variedade de protocolos – VNC, RDESKTOP, NX, XDMCP – e até pode usar tuneis de SSH. É uma das melhores aplicações para administração remota que conheço.

Visitem o site do Remmina para mais informações.Remmina main window

O CM15 não tem este pacote disponivel nos repositorios. Assim, temos que o instalar nós mesmos.

Para começar, efectuamos o download do Remmina desde o site, ou vamos buscar a ultima versão do Remmina através de Subversion:

svn co https://remmina.svn.sourceforge.net/svnroot/remmina/ remmina

Antes de poder configurar e instalar, precisamos de instalar alguns pacotes na nossa box.

Segundo o site do Remmina, precisamos de alguns pacotes:

  • GTK+ 2.0 (>=2.16) required
  • libpthread for multi-threaded feature
  • libssh (>=0.4) for all SSH related feature
  • libavahi-ui for Avahi feature
  • libvte for terminal feature
  • libgcrypt for password encryption
  • libunique for managing unique process
  • (Para os Plugins)
  • FreeRDP libraries and plugins for RDP protocol
  • zlib (required by libvncclient) for VNC protocol
  • libjpeg (required by libvncclient) for VNC protocol
  • libgnutls (required by libvncclient) for VNC protocol
  • libtelepathy-glib (>= 0.9.0) for Telepathy feature
  • libssh (>=0.4) for NX protocol
  • nxproxy for NX protocol (runtime dependency only)
  • Xephyr for XDMCP protocol (runtime dependency only)
  • (Para Gnome)
  • libpanelapplet-2.0 (>= 2.20) required
  • libavahi-client for Avahi feature
  • (Para XFCE)
  • libxfce4util-1.0 (>= 4.3.99.2) required
  • libxfce4panel-1.0 (>= 4.3.99.2) required
  • libavahi-client for Avahi feature

Alguns destes já se encontram na nossa instalação do CM15, mas outros não. Precisamos de alguns pacotes de desenvolvimento. Numa consola, como root, executar:

Nota: A minha instalação é a 64bits

apt-get install apt-get install lib64gtk+-devel lib64avahi-ui-devel lib64vte-devel lib64gcrypt-devel lib64unique-devel lib64jpeg-devel lib64ssh-devel libgnutls-devel lib64vte9 lib64unique0 lib64avahi-ui1

zlib1  gnutls nxproxy x11-server-xephyr lib64avahi-client3

Estas são as dependências necessárias para o Remmina.

Agora, vamos instalar alguns pacotes necessários à compilação de ficheiros na nossa máquina.

apt-get install gcc automake libtool intltool autogen

Agora, já temos tudo o que precisamos para compilar o Remmina.

(os seguintes passos não têm que ser como root)

cd remmina/branches/0.7/remmina

Agora, executamos o autogen.sh para gerar os ficheiros de configuração

sh autogen.sh

Se tudo correu bem, teremos o ficheiro configure

Vamos configurar os pacotes

./configure

O programa de configuração vai agora procurar as dependências necessárias ao remmina.

Se tudo correu bem, no final da configuração, iremos ter o seguinte resultado:

Remmina configure result:

* NLS support: yes
* VNC support: yes
* Multi-threaded support: yes

* SSH support: yes
* Avahi support: yes
* Terminal support: yes
* Encryption support: yes
* Unique-App support: yes

(os proximos passos já têm que ser como root)

Agora, só temos que fazer make e make install

make && make install

E pronto, já temos uma das melhores aplicações de administração remota instaladas.

 

Gnome suporte

A instalação em cima já coloca os icons do Remmina no painel do gnome, mas também existe uma pasta chamada remmina-gnome que deve trazer funcionalidades em Gnome.

cd remmina/branches/0.7/remmina-gnome/

 

 

 

Vamos instalar pacotes que precisamos:

apt-get install lib64panel-applet-2-devel lib64avahi-client-devel

sh autogen.sh

./configure

No final temos o seguinte resumo:

Remmina-Gnome configure result:

* Remmina main program: yes
* NLS support: yes
* Avahi support: yes

make && make install

E já temos o suporte gnome instalado.

Converter HTML directamente para PDF – xhtml2pdf

Muitas vezes, quem trabalha em informática, pode ter a necessidade de realizar pequenos scripts que convertam uma página HTML directamente para um PDF para depois poder imprimir automáticamente (num cron) ou enviar por email, etc…

Existe um pequeno programinha, extraordinário, xhtml2pdf, que faz este trabalho fantasticamente.

XHTML2PDF é um conversor para HTML/XHTML e CSS e um pacote para Python.

Este programa, além de ser muito bom, aceita TAGS directamente inseridas no HTML para poder formatar o PDF da maneira que queiramos. Aceita TAGS conhecidas de CSS para realizar essa tarefa. Leiam adocumentação para saberem mais.

A instalação é muito simples,mas tem algumas dependências que precisamos de resolver.

Pacotes necessários:

ReportlabToolkit 2.1+ (obrigatório)

html5lib 0.11.1+ (obrigatório)

pyPdf 1.11+ (opcional)

PIL 1.1.6+ (opcional)

Esta instalação foi efectuada num Centos 5

Instalar o PIL

Instamos o PIL (python-imaging) com o YUM, pois este encontra-se nos repositorios do Centos

yum install python-imaging

Instalar o ReportLab

Para instalar o ReportLab, efectuamos o download e compilamos nós mesmos.

wget http://www.reportlab.org/ftp/ReportLab_2_3.tar.gz

tar -zxvf ReportLab_2_3.tar.gz

cd ReportLab_2_3

Para instalar um pacote python é a coisa mais simples:

python setup.py install (o pacote deverá ter um ficheiro chamado setup.py)

No meu caso, ele queixou-se que não tinha o módulo setuptools instalado, e foi preciso instalar antes de continuar com a instalação. Nada mais simples:

yum install python-setuptools

Assim que instalei, já pude continuar

python setup.py install

Instalar o Html5Lib

Para Instalar o html5lib, temos que efectuar o download e compilar nós mesmos, pois não se encontra nos repositorios.

wget  http://html5lib.googlecode.com/files/html5lib-0.11.1.zip

unzip html5lib-0.11.1.zip

cd html5lib-0.11.1

python setup.py install

Instalar o pyPdf

wget  http://pybrary.net/pyPdf/pyPdf-1.12.tar.gz

tar -zxvf pyPdf-1.12.tar.gz

cd pyPdf-1.12

python setup.py install

e neste momento já temos todas as dependências resolvidas. Vamos instalar o xhtml2pdf.

Agora, temos duas formas:

ou não efectuamos o download do pacote e usamos a aplicação easy_install, que se vai encarregar de efectuar o download

easy_install pisa

ou efectuamos o download e instalamos normalmente:

Efectuar o download do PISA (nome do pacote) daqui:  http://pypi.python.org/pypi/pisa/

tar -zxvf pisa-3.0.32.tar.gz

cd pisa-3.0.32

python setup.py install

Desta forma, já temos o xhtml2pdf instalado.

Podem começar a converter as vossas páginas html em PDF’s facilmente com esta aplicação.

Linux numa Flash de 32MB para rdesktop de um windows

Linux é um Sistema Operativo do melhor que existe. Muitas vezes gastamos imensos recursos para fazer uma coisa simples, como um computador que apenas faz remote desktop para um computador windows. Valerá apena instalar um Windows ou um Linux completo numa máquina só para ela arrancar e executar um Remote Desktop ?

Se responderam não, então, o thinstation é a vossa solução (e a minha).

(more…)