Obs. Está disponível também no sistema o preview do Gnome 3.0!

Mais informações no site oficial do projeto…

=ERROR REPORT==== 23-Jun-2010::00:59:19 ===
Mnesia(node@server): ** WARNING ** Mnesia is overloaded: {dump_log, write_threshold}

This warning event is usually shown when using mnesia disc_copies tables and doing a lot of writes to disk all at once (considering you are using asynchronous writes), and of course it can get really annoying when they start happening every second. We can drastically reduce the occurrence of this error changing 2 configuration parameters, the dc_dump_limit and dump_log_write_threshold.

dc_dump_limit
This parameter controls how often disc_copies tables are dumped from memory, the default value is 4 that means if the log size is greater than the table size divided per 4 (table size / 4) it starts the dump. You can make dumps happen more often increasing this value.

dump_log_write_threshold
This parameter defines the maximum number of writes to the transaction log before a new dump is performed, using the default value 100 a new transaction log dump is performed after every 100 writes. You can increase this value giving more time to the write process to finish, but be sure that you have enough RAM on your server to maintain the transactions running.

And now, what does it mean?
Mnesia activity is recorded in transaction logs, that gets dumped to table logs, which in turn are dumped to table files on disk. By increasing the dump_log_write_threshold, transaction logs are dumped much less often, giving more time to the last dump be completed before the next dump is triggered. By the way, increasing the dc_dump_limit helps ensure that the disk table is dumped form the logs more often.

You can configure the parameters using the following syntax:

{mnesia, [{dc_dump_limit, 40}, {dump_log_write_threshold, 50000}]}
* Remember to change the values according to your needs!

Obs. Reloading modules is also possible via the web interface since ejabberd 0.9.1.

Open an Erlang console on the ejabberd node with:
# ejabberdctl debug

And select the module you wish to compile with:
c(mod_version).

If you just want to reload the .beam file (without recompiling the module), use:
l(mod_version).

Obs. Replace “mod_version” with the name of the file you want to recompile / reload.

There’s no automated way to export all users like Openfire does, but we can dump our entire database, consider that you are using the internal erlang mnesia database, to a text file and filter just the values we want (in this case, users and passwords) using the following steps:

1. Dump the database to a text file:

# ejabberd_ctl ejabberd@localhost dump /tmp/mnesia.dump

2. Filter the dump to get only registered users

# cat /tmp/mnesia.dump | grep ‘{passwd,{‘ > /tmp/tmplist.txt

3. Convert your temporary generated file to the format you prefer, in this case getting a list (username, hostname, password):
   

   # sed -e ‘s/{passwd,{“//g;s/”,”/ /g;s/”},”/ /g;s/”}.//g’ /tmp/tmplist.txt > /tmp/userlist.txt

Obs. The database registers that store user information in the dump have the following format:
{passwd,{“USER”,”VIRTUAL-HOST”},”PASSWORD”}.

Dando uma pesquisada mais a fundo encontrei mais pessoas que tinham o mesmo problema, e também encontrei uma solução muito simples que funcionou em praticamente 100% dos casos. Simplesmente faça um backup completo do memory card e realize a formatação dele diretamente pelo celular para refazer a tabela de alocação de arquivos.

Esse problema acontece devido a formatação inicial presente no memory card que interrompe a gravação contínua do fluxo de dados enquanto os blocos são realocados.

Após a formatação do memory card simplesmente restaure seus arquivos e começe a gravar os vídeos normalmente, todos eles serão gravados e executados sem as terríveis pausas!

Obs. Após o restore dos arquivos é interessante desligar e ligar o aparelho para que todas as aplicações sejam carregadas novamente.

Verificando a estrutura de diretórios do pacote, percebi que a pasta dos plugins do Chrome não fazia referência a pasta de plugins do sistema (/usr/lib/browser-plugins/) e também não tinha nenhum plugin instalado localmente.
Desta forma fica fácil chegar-mos na solução do problema, simplesmente vamos criar um link simbólico apontando para o diretório correto:

cd /opt/google/chrome
ln -s /usr/lib/browser-plugins/ plugins

Para descobrir se está funcionando corretamente, simplesmente abra uma nova aba e navegue algum site que utilize Flash.

Primeiramente vamos criar um arquivo temporário para a validação das regras:

# vim /etc/iptables.test.rules

E então colocamos nossas regras dentro dele seguindo o padrão do próprio iptables, como no exemplo abaixo:

 *filter
 
 # Allows loopback traffic and drop all traffic to 127/8 that doesn't use lo0
 -A INPUT -i lo -j ACCEPT
 -A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT
 
 # Accepts all established inbound connections
 -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
 # Allows all outbound traffic
 # You could modify this to only allow certain traffic
 -A OUTPUT -j ACCEPT
 
 # Allows HTTP and HTTPS connections from anywhere
 -A INPUT -p tcp --dport 80 -j ACCEPT
 -A INPUT -p tcp --dport 443 -j ACCEPT
 
 # Allows SSH connections
 -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
 
 # Allow ping
 -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
 
 # log iptables denied calls (access via 'dmesg' command)
 -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
 
 # Reject all other inbound - default deny unless explicitly allowed policy:
 -A INPUT -j REJECT
 -A FORWARD -j REJECT
 
 COMMIT

Após a criação do arquivo com suas regras carregue-as com:

# iptables-restore < /etc/iptables.test.rules

Verifique se as regras estão corretas e se é necessária alguma alteração, e caso seja necessário simplesmente repita os procedimentos citados acima.

Depois de todas as regras carregadas corretamente salve-as em um arquivo definitivo como no exemplo abaixo:

# iptables-save > /etc/iptables.up.rules

Para garantir que nossas regras sejam carregadas durante o boot do sistema é necessário criar uma entrada para o iptables juntamente com os scripts de inicialização da rede:

# vim /etc/network/if-pre-up.d/iptables

Adicionando o seguinte conteúdo:

#!/bin/bash
 
 /sbin/iptables-restore < /etc/iptables.up.rules

Não podemos esquecer de dar permissão de execução para nosso script de chamada:

# chmod +x /etc/network/if-pre-up.d/iptables

Outra maneira muito comum de armazenar e carregar regras de iptables em sistemas Linux é com a utilização de um script de init, por exemplo /etc/init.d/firewall, adicionando sua inicialização nos runlevels do sistema.

Lembrando que todos os procedimentos e informações a respeito deste tipo de configuração em sistemas Debian Linux podem ser encontrados no wiki e também na documentação oficial do Debian em http://wiki.debian.org/.

Para alterar o timezone atual, primeiramente entre no diretório /etc:
# cd /etc

Crie/recrie o link simbólico localtime fazendo referência ao arquivo correto:
# ln -sf /usr/share/zoneinfo/EST localtime

Em algumas distribuições (Red Hat like) o path dos arquivos de timezone é:
/usr/share/zoneinfo/dirname/zonefile.

Segue um exemplo para configurar o timezone da máquina para São Paulo / Brasil:
# cd /etc
# ln -sf /usr/share/zoneinfo/America/Sao_Paulo localtime

Você pode utilizar a variável de ambiente TZ para setar a data correta nas aplicações:
$ export TZ=America/Sao_Paulo
$ date

Para instalar e configurar o timezone através do utilitário, simplesmente prossiga com:
# yum install system-config-date
# system-config-date

Após finalizar as configurações de timezone elas entrarão em vigor imediatamente.

Além da configuração realizada através do utilitário também é possível utilizar o método genérico de configuração de timezone através do /etc/localtme, que assim que possível irei disponibilizar no próximo e último post da série de timezone.

Como grande parte das distribuições atuais seguem o padrão Red Hat ou Debian, vou postar aqui inicialmente os métodos para configuração do timezone na plataforma Debian e no próximo artigo os procedimentos para Red Hat / CentOS.

Primeiramente verifique em qual timezone seu sistema está configurado com:

luizxx@kanu:~# tzconfig
Your current time zone is set to America/Sao_Paulo
Do you want to change that? [n]:

Caso o timezone apresentado esteja incorreto pressione y para configurá-lo corretamente seguindo as instruções apresentadas na tela.

Caso você queira configurar o timezone de um local dentro do Brasil, instale o pacote tz-brasil para agilizar as configurações de horário de verão:

luizxx@kanu:~# apt-get install tz-brasil

No Debian temos algumas particularidades na estrutura de configuração dependendo da versão do sistema operacional, na versão Etch e posteriores o arquivo /etc/localtime é uma cópia idêntica do datafile original, já nas versões anteriores ao Sarge ele é um link para o arquivo original, como apresentado no exemplo abaixo:

Debian Etch:
$ diff -s /etc/localtime /usr/share/zoneinfo/`cat /etc/timezone`
Files /etc/localtime and /usr/share/zoneinfo/America/New_York are identical

Debian Sarge:
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 48 Mar 31 11:19 /etc/localtime -> /usr/share/zoneinfo/America/Sao_Paulo

Considere o esquema de particionamento abaixo:

Não LVM:
/boot – 128MB

LVM:
/ – 10GB
/home – 20GB
/var – 35GB
swap – 8GB

As entradas no kickstart para limpar a tabela de partições e aplicar o esquema acima serão as seguintes:

clearpart –all
part /boot –fstype ext3 –size=128
part pv.4 –size=0 –grow
volgroup VolGroup00 pv.4
logvol / –fstype ext3 –name=root –vgname=VolGroup00 –size=10240
logvol /home –fstype ext3 –name=usr –vgname=VolGroup00 –size=20480
logvol /var –fstype ext3 –name=var –vgname=VolGroup00 –size=35840
logvol swap –fstype swap –name=swap –vgname=VolGroup00 –size=8192

Caso você queira fixar a partição /boot em um determinado disco (por exemplo /dev/sda) é possível adicionando a opção “–ondisk=sda” na linha referente ao /boot. A opção –grow especificada ao criar o pv (phisical volume) informa que todo o restante do disco será utilizado para o LVM.

Mais informações sobre opções disponíveis para kickstart podem ser encontradas na documentação oficial Red Hat.

Looking for some information on VirtualBox forums and on CentOS bugtracker, I found some information that shows up how to solve this problem in a very simple way, just changing the default divider kernel parameter to 10 (adjusting the system clock rate to 100Hz) directly at boot time.

Note: Since Red Hat Enterprise Linux 5.1 / CentOS 5.1 the default system clock rate that is set to 1000Hz and can be changed at boot time, with no need to recompile you kernel, remember that Xen guests don’t need the system clock rate to be modified because they already have a 250Hz kernel.

For those that are not familiar changing kernel parameters, just edit your grub menu.lst file (usually /boot/grub/menu.lst), add divider=10 in the end of the kernel line and reboot your system.

Ps. Sorry for the long time without new posts… Now I’m back!

ImportError: cannot import name ImmutableSet

After some research I found that when upgrading the module to version 1.2.1 (or newer) the file sets.py, that was used on 1.2.0 or prior versions, still on system and this doesn’t contain ImmutableSet that’s defined as a default bult-in set in the recent versions of MySQLdb.

To solve this problem (tested on Python 2.4 and 2.6) just remove the sets.py from your MySQLdb installation directory.

luizxx@Revy ~ $ vi .gtkrc-2.0

Then add the following lines to your file:

style “modpanel”
{
fg[NORMAL] = “#FFFFFF”
}
widget “*PanelWidget*” style “modpanel”
widget “*PanelApplet*” style “modpanel”
widget “*fast-user-switch-applet*” style “modpanel”

Now you can logout and logon to activate the changes, or you can simply reload the panel with:

luizxx@Revy ~ $ killall gnome-panel

Note that you can change the fg[NORMAL] value to any color you want to use, from #000000 to #FFFFFF.