After upgrading my HTPC to Ubuntu 10.04, nvidia drivers stopped working without any reason. After googling a bit, all the answers pointed to a problem related with Ubuntu upgrade system not updating restricted drivers. I have tried manually to update and use all the available versions, but without any success…until I found the cause and solution.

It happens that Ubuntu does not remove old drivers correctly, leaving you with multiple versions which were confusing the operating system. The solution was to purge the system from all nvidia drivers and reinstall just one of them.

You can run the following commands to clean the system:

sudo dpkg --get-selections | grep nvidia | grep -v deinstall | awk '{print $1}' | xargs sudo apt-get remove -y
sudo apt-get install nvidia-current
sudo nvidia-xconfig

sudo reboot

The system will then reboot and if everything is OK, Ubuntu will be as good as new.

O port do sistema operativo Android está cada vez mais perto do HTC HD2. Depois de ultrapassados os problemas relacionados com o kernel (que aparentemente estavam relacionados com algumas instruções extra do processador) foi uma questão de dias – mais concretamente dois – até que conseguissem inicializar o Android. Nesta fase ainda há muitos drivers que não se encontram a funcionar e que fazem com que ainda seja inútil para qualquer utilizador, mas foi mais um passo na direcção certa.

Podem inclusive ver um video do processo de inicialização do sistema:

O próximo passo parece estar relacionado com os drivers do touchscreen, o famigerado ELAN B81 que mesmo após alguma insistência sobre o fabricante, este não libertou a informação necessária para ser criado o driver para linux.

Mais informações na thread oficial do port deste sistema operativo:

http://forum.xda-developers.com/showthread.php?t=651632

I believe I have found a vulnerability in ClipBucket 2.0.6 (haven’t tested with prior versions).

ClipBucket is an open source and free script that will let you start your own Video Sharing (Youtube Clone) website in matter of minutes, ClipBucket is fastest growing script with most video sharing websites and social networking features.
current version: 2.0.6

Summary:
The script handling the search features is not sanitizing user input properly making it possible to produce XSS attacks.

Proof of Concept:

Use the search box of your ClipBucket 2.0.6 installation and Input:

 <script>alert(document.cookie);</script>

This will produce an alert with contents of your cookie.

Problem:
$search->key in search_result.php (line 18) is being directly assigned to the title of the search page without sanitizing its value first.

$search->key = $_GET['query'];

Workaround:
Open file search_result.php. Go to line 39:

Replace this:

Assign('search_type_title',sprintf(lang('searching_keyword_in_obj'),$search->key,$search->search_type[$type]['title']));

By this:

Assign('search_type_title',sprintf(lang('searching_keyword_in_obj'),htmlentities($search->key),$search->search_type[$type]['title']));

The ClipBucket team was already notified and the bug was corrected. Either apply this patch or upgrade your version to 2.0.7

Estive com uns problemas na empresa relacionados com o sendmail.
Quando nada fazia prever, o sendmail simplesmente crasha começando a recusar activamente todos os pedidos de envio de email.

Criei um script genérico para verificar se uma determinada porta de um servidor está a responder. Basta editar o endereço, porta e opcionalmente definir um timeout máximo para o pedido.

#!/usr/bin/php -q
<?
 
/*****************************************************
 
    Check For Open Ports - David Gouveia
 
*****************************************************/
 
$address = '127.0.0.1';
$port = 25;
$timeout = 5;  //Max time to wait before give up.
 
$checkport = fsockopen($address, $port, $errnum, $errstr, $timeout);
 
if(!$checkport){
        print "CRITICAL: Host $address at port $port not responding!\n";
        fclose($checkport);
        exit(2);
}
 
print "OK: Host $address at port $port is responding!\n";
fclose($checkport);
exit(0);
 
?>

Coloquem na pasta dos plugins e não se esqueçam de dar as permissões correctas (755).
Alternativamente podem passar o valor do IP e porta como argumentos via consola.

basta trocar isto :

    $address = ’127.0.0.1′;
    $port = 25;

por isto :

    $address = $argv[1];
    $port = $argv[2]

Para quem está a pensar em adquirir uma placa de rede gigabit da Asus para utilizar em sistemas operativos *nix que pense duas vezes em fazê-lo.

O chipset utilizado é o IP1000 que além de não ser suportado directamente pelo kernel e os drivers fornecidos no cd de instalação são tão antigos que é impossível compilar com um kernel relativamente recente (2.6.22 e superiores pelo menos).

Se mesmo assim vão comprar uma placa destas, usem a ultima versão dos drivers que está no site do fabricante do chipset, descomprimam para uma pasta  e executem os seguintes comandos :

make all

cp ipg.ko /lib/modules/`uname -r`/kernel/drivers/net

depmod

modprobe ipg

Podem sacar a ultima versão aqui.

Se usam o Fedora Core 12 e tentarem compilar algum programa que use extensões fornecidas pelo OpenSSL, poderão deparar-se com erros como estes :

/usr/src/php-4.4.9/ext/openssl/openssl.c:182: error: expected specifier-qualifier-list before ‘LHASH’
/usr/src/php-4.4.9/ext/openssl/openssl.c:343: error: expected declaration specifiers or ‘…’ before ‘LHASH’
/usr/src/php-4.4.9/ext/openssl/openssl.c: In function ‘php_openssl_config_check_syntax’:
/usr/src/php-4.4.9/ext/openssl/openssl.c:348: error: ‘config’ undeclared (first use in this function)
/usr/src/php-4.4.9/ext/openssl/openssl.c:348: error: (Each undeclared identifier is reported only once
/usr/src/php-4.4.9/ext/openssl/openssl.c:348: error: for each function it appears in.)
/usr/src/php-4.4.9/ext/openssl/openssl.c: In function ‘add_oid_section’:
/usr/src/php-4.4.9/ext/openssl/openssl.c:366: error: ‘struct php_x509_request’ has no member named ‘req_config’
/usr/src/php-4.4.9/ext/openssl/openssl.c:370: error: ‘struct php_x509_request’ has no member named ‘req_config’
/usr/src/php-4.4.9/ext/openssl/openssl.c: In function ‘php_openssl_parse_config’:
/usr/src/php-4.4.9/ext/openssl/openssl.c:416: error: ‘struct php_x509_request’ has no member named ‘config_filename’
/usr/src/php-4.4.9/ext/openssl/openssl.c:416: error: ‘struct php_x509_request’ has no member named ‘config_filename’
/usr/src/php-4.4.9/ext/openssl/openssl.c:417: error: ‘struct php_x509_request’ has no member named ‘section_name’
/usr/src/php-4.4.9/ext/openssl/openssl.c:417: error: ‘struct php_x509_request’ has no member named ‘section_name’
/usr/src/php-4.4.9/ext/openssl/openssl.c:418: error: ‘struct php_x509_request’ has no member named ‘global_config’
/usr/src/php-4.4.9/ext/openssl/openssl.c:419: error: ‘struct php_x509_request’ has no member named ‘req_config’
/usr/src/php-4.4.9/ext/openssl/openssl.c:419: error: ‘struct php_x509_request’ has no member named ‘config_filename’
/usr/src/php-4.4.9/ext/openssl/openssl.c:421: error: ‘struct php_x509_request’ has no member named ‘req_config’
/usr/src/php-4.4.9/ext/openssl/openssl.c:426: error: ‘struct php_x509_request’ has no member named ‘req_config’
/usr/src/php-4.4.9/ext/openssl/openssl.c:437: error: ‘struct php_x509_request’ has no member named ‘digest_name’

No inicio pensei que pudesse estar relacionado  com o facto de estar a tentar compilar uma versão do php bastante antiga provocando alguma incompatibilidade entre com as extensões actuais, mas na verdade existem mais pessoas com o mesmo problema utilizando software mais recente.

A forma de resolver (ainda que temporariamente) o problema foi copiar as extensões de outra máquina, no meu caso um servidor com Fedora Core 9.

Para o caso de alguém precisar, ficam aqui. Basta descomprimir para o directório /usr/include/openssl.

O PHP4 já foi descontinuado à muito tempo mas infelizmente ainda é necessário em algumas plataformas que não são actualizadas e necessitam desta versão para não ficarem quebradas no PHP5.

A última versão do PHP4 lançada foi a 4.4.9 e é impossível instalar esta versão em conjunto com o Fedora Core 9.

Depois de satisfeitas as dependências, a configuração do php-4.4.9 continua à procura das algumas libs no sitio errado, ou seja, /usr/lib ao contrario de /usr/lib64.

Para agravar o problema, as flags –libdir ou –with-libdir não parecem surtir efeito pois apesar de se indicar o directório /lib64 a configuração continua à procura das libs na pasta /lib.

Para se corrigir isto convém pode-se optar por duas opções :

1ª Copiar todas as bibliotecas que o PHP não encontra e que se encontram em /usr/lib64 e que são necessárias em /usr/lib (podem usar o utilitário strace para saber exactamente o caminho completo necessário).
2ª Instalar a versão de 32 bits das mesmas bibliotecas e criar links simbólicos para a versão base de cada biblioteca (ex. /usr/lib/libjpeg.so.5.2 -> /usr/lib/libjpeg.so).

Só depois de insto corrigido é que será possível. Em alternativa podem optar por uma versão mais antiga que não terá este problemas (por ex, a 4.4.4).

Esta é uma daquelas questões pela qual muita gente já passou… Possuem acesso a uma consola linux, mas sem ambiente gráfico e também não têm uma conta premium num rapidshare/megaupload/depositfiles/etc mas querem fazer downloads múltiplos sem ter de estar sempre a carregar os links ?

A resposta é : slimrat

O Silmrat é um gestor de downloads que pode correr numa consola sem precisar do X. A grande vantagem desta aplicação é que faz a gestão automática dos tempos de espera e tenta efectuar o download novamente caso falhe a primeira vez (que acontece regularmente por exemplo com o rapidshare que diz que não existem slots disponíveis para utilizadores não premium).

Podem saber mais aqui.

Quem usa Ubuntu como base para um HTPC já deve ter passado por esta dor de cabeça :

Como é que posso fazer login automático no Gnome e ligar-me automaticamente numa rede wireless ?

Os forums do ubuntu estão repletos de dúvidas semelhantes, mas a verdade é que no karmic nenhuma delas funciona (pelo menos no que toca a autenticação automática na rede wireless). Todos aqueles truques de acrescentar algumas linhas ao PAM são ignoradas pelo porta-chaves do gnome nesta versão. A dica para conseguir autenticar numa rede wifi passa por criar um novo porta-chaves sem password.

 

0º Utilizem o gdmsetup para configurar o login automático no Ubuntu.

 

1º Eliminem (ou movam se quiserem guardar de backup) todas as entradas dentro da pasta .gnome2/keyrings/ que se encontra na vossa home.

 

2º Reiniciem o computador. No próximo boot já será feito o login automático no Ubuntu. Depois deste login, irá aparecer uma caixa a pedir a password da rede wireless. Insiram-na normalmente e cliquem em OK. Após isto, irá aparecer novamente a caixa do gnome-keyring para criar um novo porta chaves. O segredo está aqui. Criem um porta chaves sem password e desta forma nunca mais vos vai chatear. A partir de agora o Ubuntu efectuará login automático incluindo a vossa rede wireless favorita.

 

PS: Tenham em atenção que desta forma as passwords armazenadas neste porta chaves serão guardadas sem encriptação, por isso cuidado com os conteúdos sensíveis.

Na realidade não é bem assim, o suporte está lá, mas não funciona correctamente…
VLC
A ultima release de Ubuntu possui nos seus repositórios uma versão do VLC que tem alguns bugs no que toca ao suporte a dispositivos de captura que utilizem os drivers video4linux2. A única solução passa mesmo por fazer um downgrade de versão ou upgrade.

No meu caso optei por um upgrade para a versão 1.0.3 para aproveitar alguns binários já disponíveis no launchpad (não me apetecia perder tempo a compilar uns MB valentes de código).

Podem utilizar os binários disponíveis aqui :

https://launchpad.net/~c-korn/+archive/vlc

Problema resolvido :o