JotaEle's Blog

Some 32 bits applications do not follow the selected GTK theme in CentOS/SLC/RHEL 64 bits systems, this occurs because the libraries of 32 bits GTK engines are not installed. Therefore for these applications are presented consistently, you must install the package: sudo yum install gtk2-engines.i686

Iuj 32-bitoj aplikoj ne sekvi la elektitan GTK temon en CentOS/SLC/RHEL 64-bitoj sistemoj, ĉi tiu okazas ĉar la bibliotekoj de 32-bitoj GTK motoroj ne instalita. Sekve por ĉi tiuj aplikoj estas prezentita konstante, vin dev instali la pakon: sudo yum install gtk2-engines.i686

Em sistemas CentOS/SLC/RHEL 6.X de 64 bits, aplicações GTK de 32 bits não seguem o tema do sistema, isso ocorre porque as bibliotecas dos engines GTK de 32 bits não estão instaladas. Portanto para que essas aplicações sejam apresentadas consistentemente, é necessário instalar o pacote: sudo yum install gtk2-engines.i686

Referências: TORACAT - Remover suspend e hibernate do menu gnome , FSYNC(2) - Removing Suspend and Hibernate from the gnome menu on RHEL-6 , man page pklocalauthority section 8 Crie o arquivo denominado /etc/polkit-1/localauthority/50-local.d/10-disable-suspend-hibernate.pkla com o seguinte conteúdo: [Disable suspend] Identity=unix-group:* Action=org.freedesktop.devicekit.power.suspend;org.freedesktop.devicekit.power.hibernate ResultAny=no ResultInactive=no ResultActive=no Feito isso mesmo que um usuário clique em Sistema->Desligar , suas ações a partir deste momento serão bloqueadas.

Instalei o Firefox 7.0.1 no Scientific Linux 6.1 da forma mais simples possível, ou seja, baixando o pacote binário (tar.bz2) do sítio da fundação Mozilla e desempacotando-o em um diretório local (e.g. /opt ). Até aí tudo normal. Só não esperava uma coisa, a atualização automática do Firefox no lançamento da versão 8. Não sabia, até então, que o Firefox podia atualizar-se dessa forma no Linux. Talvez essa função já exista há muito tempo no Firefox, pois nunca havia instalado o Firefox com minhas credenciais, sempre instalava de forma global (root). De qualquer forma a atualização foi tranquila e quase imperceptível.

O uso do utilitário findfs é bem simples, informa-se o rótulo ( label ) ou UUID de um sistema de arquivos e ele retorna o device node . findfs LABEL=label findfs UUID=uuid

Para se obter uma lista dos atributos dos dispositivos de blocos ( block devices ) presente em sistemas RedHat/CentOS utilize o comando blkid , conforme: # /sbin/blkid Os atributos exibidos serão: device node , label , UUID e tipo do sistema de arquivos. Esse comando pode ser usado para gerar listas filtradas ou efetuar buscas.

Para podermos suspender e hibernar o sistema via comando. O sistema utilizado foi o CentOS 5, mas creio que o funcionamento em outras distribuições é bem semelhante. Para suspender use: $ dbus-send --session --dest=org.gnome.PowerManager --type=method_call --print-reply --reply-timeout=2000 /org/gnome/PowerManager org.gnome.PowerManager.Suspend ou: $ dbus-send --system --print-reply --dest="org.freedesktop.Hal" /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0 ou ainda: $ gnome-screensaver-command --lock && sleep 1 ; /usr/bin/pm-suspend Para hibernar use: $ dbus-send --system --print-reply --dest="org.freedesktop.Hal" /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Hibernate ou: $ gnome-screensaver-command --lock && sleep 1 ; /usr/bin/pm-hibernate Obs.: Dependendo do ambiente de trabalho (KDE, XFCE, etc.) e método utilizados é necessário efetuar o bloqueio da ...

O disco externo Maxtor (ID 0d49:7300) de 1 TB ao ser conectado em um computador com CentOS 5.1 apresentava a seguinte mensagem de erro device descriptor read/64, error -71 e nenhum device era criado no diretório /dev, o que impossibilatava qualquer acesso ao disco. Encontrei aqui uma solução para contornar esse problema. Confrome descrito lá, é suficiente remover o módulo ehci_hcd para que o disco funcione normalmente, para tanto execute o seguinte comando: $ sudo /sbin/modprobe -r ehci_hcd Após remover o módulo, mesmo que o disco já esteja conectado, o sistema passa a ter acesso normal ao mesmo.

Após muito tempo trabalhando com NFSv3, chegou agora a hora para começar a estudar o NFSv4. Por isso essa semana comecei a pesquisar sobre o tema e percebi diferenças substanciais entre a versão anterior e a v4. A medida que for pesquisando colocarei aqui dicas, resultado de testes e referências sobre o assunto. Já fiz alguns testes básicos e os primeiros resultados foram impressionantes.

Numa instalação de GNU/Linux com LVM (Logical Volume Manager) podemos aproveitar a capacidade do LVM de gerar snapshots para se ter um ou mais backups de um sistema de arquivos. Cada snapshot gerado é uma cópia do sistema de arquivos original naquele momento, entretanto ocupando menos espaço. Então vem a pergunta: como isto é possível? O que o LVM faz é reservar uma área para guardar os dados originais durante as alterações subseqüentes do sistema de arquivos Coloque o script abaixo (makelvsnapshot.cron) no diretório /etc/cron.weekly e ele será executado semanalmente pelo serviço cron. #!/bin/bash LOCKFILE=/var/lock/makelvsnapshot.lock [ -f $LOCKFILE ] && exit 0 trap "{ rm -f $LOCKFILE; exit 255; }" EXIT touch $LOCKFILE /bin/umount /dev/VG_root/LV_root_snapshot /usr/sbin/lvremove -f /dev/VG_root/LV_root_snapshot && /usr/sbin/lvcreate \ --size 4G --snapshot --name LV_root_snapshot /dev/VG_root/LV_root /bin/mount /.snapshot/LV_root exit 0 Esse script foi testado...