A turma do Grande Irmão: Azeredo, Febraban, Fecomercio e outros do mesmo quilate estão fazendo uma força tremenda para nos empurrar o AI5Digital guela abaixo de qualquer forma, vamos aos fatos:

1. A mídia continua repetindo o Mantra da Irracionalidade contra a Internet
2. No dia 05/08/10  O Deputado Pinto Itamaraty do PSDB apresentou parecer favorável ao AI5Digital, ignorando todos os argumentos e movimentos sociais dos últimos três anos.
3. Seis dias depois aparece uma matéria dizendo que os Deputados buscarão acordo para votar a lei de crimes na Internet.
4. E agora um evento para lá de esquisito organizado pela revista Decision Report, uma publicação que parece estar à serviço do Azeredo e do vigilantismo, se anuncia para o dia 31/08 com o título oportuno (para o tripé do atraso) de: Crimes Eletrônicos – A urgência da lei. O curioso e que este evento conta com 19 palestrantes para falarem em 2:30h, o que dá um pouco mais de 7 minutos para cada um.

Por estas e por outras que estamos convocando uma blogagem coletiva para o dia 31/08/10, justamente no dia do tal evento à serviço do Azeredo e do AI5digital, vamos fazer uma blogagem coletiva contra o AI5Digital para lembrar a todos que queremos a Internet como um espaço livre e democrático!!!

UPDATE 31/08/10 – Hoje é dia da Blogagem Coletiva, faça seu post e linke para cá, assim teremos como acompanhar a evolução da blogagem.

fonte: http://meganao.wordpress.com/2010/08/27/blogagem-coletiva-de-repudio-ao-ai5-digital/

Please provide a name for this Disc, such as 'Debian 5.0.3  Disk 1':

Isto ocorre com certa frequência com quem está brincando com customização. O problema é por que você esqueceu o .disk na raiz do sistema.

A solução é copia-la para a sua raiz de edição!

Mas por que esta pasta é tão importante? Qual o conteúdo dela?

A pasta contém 5 arquivos:

• base_installable
• casper-uuid-generic
• cd_type
• info
• release_notes_urls

Estes arquivos são utilizados no processo de inicialização do Live CD e na instalação.

O release_notes_urls , como o nome sugere, contém a url que com as notas de lançamento.

O info é crítico, sem ele o livecd não termina de dá Boot. Ele contém uma string que é processado pelo casper no processo de adição de usuário. Ela usa a versão (10.04) e o tipo do ubuntu (LTS) que preprocessam o arquivo de desktop do ubiquity.

Já casper-uuid-generic contem a uuid do sistema de arquivos. Útil na hora de inicializar o cd-rom.

Os arquivos base_installable e cd_type são usados pelo aptitude para gerencia da base de pacotes debs que está incluída na imagem.

Mas a boa notícia é que tem como fazer isso!

A dica vem de: Interactive Input Editing and History Substitution

Então para ativar o histórico e o autocompletar no interpretador crie um arquivo no seu home chamado .pystartup (note que tem . antes do nome, é para ter. Isto indica que o arquivo é oculto)

Preencha o arquivo com o seguinte conteúdo.
[python]
import atexit
import os
import readline
import rlcompleter

import rlcompleter, readline
#Linha que executa o autocompletar com tab
readline.parse_and_bind(‘tab: complete’)

#Caminho do arquivo que armazenará o histórico do python
historyPath = os.path.expanduser(“~/.pyhistory”)

def save_history(historyPath=historyPath):
import readline
readline.write_history_file(historyPath)

if os.path.exists(historyPath):
readline.read_history_file(historyPath)

atexit.register(save_history)

del os, atexit, readline, rlcompleter, save_history, historyPath
[/python]
Salvo o arquivo é necessário configurar a variável de ambiente PYTHONSTARTUP. Neste momento você já pode testar a navegação acrescentando no arquivo ~/.bashrc com: export PYTHONSTARTUP=~/.pystartup e fazendo:

source ~/.bashrc

Pronto desta forma você sempre terá a opção de navegação quando evocar o interpretador python.
O bom é que também funciona para modo interativo do django (./manager shell)

Para resolver esse problema basta evocar o yum. Mas se você digitar puramente yum install whois obterá uma mensagem de erro.

yum install whois
Plugins carregados: presto, refresh-packagekit
Configurando o processo de instalação
Nenhum pacote whois disponível.
Nada a ser feito

O motivo do post é como se livrar desse erro.

Bom a primeira atitude a ser tomada quando temos um erro desses é executar o search.

yum search [o que procura]

O search é legal por que você pode, por exemplo,  fazer uma busca por uma biblioteca ou arquivo. Tente:

yum search linux.so
Plugins carregados: presto, refresh-packagekit
========Matched: linux.so ===============
jd.x86_64 : A 2ch browser
mod_selinux.x86_64 : Apache/SELinux plus module
uml_utilities.x86_64 : Utilities for user-mode linux kernel

Veja que ele retornou uma lista de pacotes que contém o arquivo linux.so

Para o comando whois:

yum search whois
Plugins carregados: presto, refresh-packagekit
======================== Matched: whois =======================
jwhois.x86_64 : Internet whois/nicname client
perl-Net-Whois.noarch : Get and parse "whois" domain data from InterNIC
perl-Net-Whois-IP.noarch : Perl extension for looking up the whois information for ip addresses
echoping-whois.i686 : WHOIS plugin for checking response times of Whois servers
echoping-whois.x86_64 : WHOIS plugin for checking response times of Whois servers
dnsenum.noarch : A tool to enumerate DNS info about domains
gnome-nettool.x86_64 : Network information tool for GNOME
jakarta-commons-net.noarch : Internet protocol suite Java library
perl-IP-Country.noarch : Fast lookup of country codes from IP addresses
prewikka.noarch : Graphical front-end analysis console for the Prelude Hybrid IDS Framework

Observe a quantidade de pacotes que ele retorna… qual desses prove o whois?
Bom, o caminho a seguir é usar o comando provides (provê em português). Este comando aceita wildcards. Como estou a procura de um comando e este está em algum path, que por padrão deve está contido num certo diretório bin, posso fazer:

yum provides *bin/whois

Que gera:

yum provides *bin/whois
Plugins carregados: presto, refresh-packagekit
jwhois-4.0-19.fc13.x86_64 : Internet whois/nicname client
Repo        : fedora
Resultado a partir de:
Nome de arquivo    : /usr/bin/whois

jwhois-4.0-20.fc13.x86_64 : Internet whois/nicname client
Repo        : updates
Resultado a partir de:
Nome de arquivo    : /usr/bin/whois

Ora, resultou em dois pacotes que a diferença é apenas a versão.
Caso geresse dois pacotes diferente a soluçao seria usar o comando info para obter mais detalhes a cerca do pacote e decidir qual instalar.

Assim, para instalar o pacote whois:

yum install whois

Uma segunda via ao search seria o comando resolvedep que traria um resultado mais e direto. Eu prefiro usar o search para ele me mostrar outras opções e versões.

Em relação ao comando whois no Ubuntu, ele já vem por padrão.

Também sei que podemos fazer consultas ao banco. Mas isso é burrice, por que já tenho isso implementado no django e teria que fazer as consultas individualmente.

A minha atividade atualmente é implementar acesso a um segundo banco de dados num projeto. Então tive que estudar a fundo como é que o django “brinca” com banco de dados. (E percebo o quanto o django é organizado!) Na verdade a experiência de entender a stack de persistência do Django vem desde quando precisei implementar acesso a chamadas de sistema operacional com gerencia de arquivos.

Mas deixemos de bla-bla-bla e vamos a análise. Em outro post eu mostro os códigos implementados. Ainda estão em dev.

Um tiquinho de models.Manager

A documentação do django diz como você pode sobre-escrever métodos de persistência. Aí já contém uma pista por onde começar. Lá fala como customizar o comportamento de Managers, que são as classes que interfaceiam com os bancos de dados. Caso você queira mudar a forma como é feito uma consulta, a forma como é feito um insert recomendo a leitura da documentação já ligada.

Bom, dentro de cada model há pelo menos um Manager, mesmo que esse model seja abstrato. O manager prove o acesso a uma coleção de dados.

Mas do jeito que está a documentação, você não pode mudar qual banco de dados você quer acessar e apenas descreve como adicionar managers e nada em relação a esse manager padrão presente em todas as classes.

Models e Managers

“Ora, se com managers eu não posso mudar a forma como acesso ao banco porque você fala dele?”

Bom, o manager é a classe que faz a interface com o banco de dados. A deixa foi dada. Tenho que investigar o atributo da classe Model que é um manager.

A análise mostra que existe um objeto chamado manager em Model. Mas ele não é um atributo da classe e sim uma variável de um método. Mas essa variavel é _default_manager, um atributo de ModelBase, o super de Model. Assim, posso modificar o Manager padrão da classe Model em questão.

Assim:

class PessoaDeOutroBanco(Models):

_default_manager = MeuManager()

Desta forma mudei o meu manager padrão  (” – eu sei lê inglês, Rômulo!” ¬¬’).

O Manager

O Manager, a classe! Não mesmo! Ela é escrava da classe QuerySet, vai no código que você descobre! Pobre coitada, falei tanto dela…

QuerySet

Dica: veja esse post e veja o quanto é simples navegar no código python, foi muito útil neste estudo.

Quando você abre a classe QuerySet, logo na função __init__ vem: self.query = query or sql.Query(self.model, connection) . query é default nulo. Logo por padrão cai em sql.Query. Continuando a submersão no código,  vou na definição de Query e vejo a dependência pelo parâmetro connection.

Muito sugestivo esse atributo connection. E de fato, como ele sugere, é o wrapper de conexão com o banco.

Aprofundando, quem é connection? Ele é uma entidade importada de django.db, do arquivo __init__.py

Quando você cai na definição de connection vem:

connection = backend.DatabaseWrapper({
‘DATABASE_HOST’: settings.DATABASE_HOST,
‘DATABASE_NAME’: settings.DATABASE_NAME,
‘DATABASE_OPTIONS’: settings.DATABASE_OPTIONS,
‘DATABASE_PASSWORD’: settings.DATABASE_PASSWORD,
‘DATABASE_PORT’: settings.DATABASE_PORT,
‘DATABASE_USER’: settings.DATABASE_USER,
‘TIME_ZONE’: settings.TIME_ZONE,
})

CARAMBOLAS E PIPOCAS! Connection é um wrapper de banco parametrizado pelas definições contidas no settings?!

Ora, voltando ao Query, vejo que connection é uma atributo publico! De fácil acesso.

Concluindo

Vamos rever as coisas…

Se para cada Model criado é instanciado um Manger no atributo _default_manager, que é instanciado um QuerySet que é instanciado um Query que é instanciado um DatabaseWrapper que, por fim, é baseado no settings. Logo, para eu acessar um outro banco de dados… eu preciso ter um outro wrapper  do banco.

Assim em termos de implementação eu preciso ter um wrapper de banco usando uma configuração diferente.

O backend é definido assim: backend = load_backend(settings.DATABASE_ENGINE) , em tempo de execução.

Logo, em teoria, é configurar um novo connection, chamando a função DatabaseWrapper com o dicionário de configuração de banco. Em teoria…

Digo-lhes que a implementação da análise funciona. Já está funcionando comigo, e será tema de um outro post.

A implementação de um outro Manager usando um connection diferente é o jeito mais correto de fazer a configuração de acesso a múltiplos bancos de dados.