Samba com LDAP sem smbldap-tools

Quando se pensa em uma integração de Samba com LDAP normalmente utiliza-se o pacote smbldap-tools. Mas é possível fazer com que o Samba acesse a base LDAP diretamente.

Fiz um artigo com os procedimentos necessários. Não me apeguei muito a configuração do Samba e do OpenLDAP, pois há diversos tutorias sobre eles na Internet.

O artigo está disponível no Megaupload.

Segundo o man do Samba, o processo de login no domínio fica bem mais rápido configurando-se dessa forma.

Banco de Dados

Para facilitar algumas buscas em um arquivo CSV em meu trabalho, resolvi carregar esse arquivo em um banco de dados relacional MySQL. Obs.: Como trabalho em uma área que mexe com diretórios LDAP, eu deveria ter carregado em uma base LDAP, mas algumas buscas são realmente mais fáceis com SQL.

Eu precisava saber os tipos de funcionários existentes na empresa. Fiz então a seguinte busca:


SELECT codigoCaracteristica, quadro
FROM  `Empregados` 
GROUP BY codigoCaracteristica

E ela trouxe os dados como deveria.

Pensando um pouco, imaginei que isso poderia ser feito de outras maneiras, e pensei também que, isso poderia ter um desempenho diferente.

Levando-se em conta que o campo codigoCaracteristica é um campo indexado, e o campo quadro não é. O banco tem 11.411 registros. O banco tinha acabado de ser criado, portanto não havia cache.
Realizei 3 buscas diferentes, com os seguintes tempos de resposta:


SELECT DISTINCT codigoCaracteristica, quadro
FROM  `Empregados` 
Mostrando registros 0 - 3 (4 total, Consulta levou 0.0194 segundos)


SELECT codigoCaracteristica, quadro
FROM  `Empregados` 
GROUP BY codigoCaracteristica
Mostrando registros 0 - 3 (4 total, Consulta levou 0.0141 segundos)


SELECT codigoCaracteristica, quadro
FROM  `Empregados` 
GROUP BY quadro
Mostrando registros 0 - 3 (4 total, Consulta levou 0.0335 segundos)

A diferença entre fazer um group by em um campo indexado foi significativa. Mas não considerei relevante a diferença entre fazer um distinct e um group by em um campo indexado.

Acredito que buscas utilizando distinct e group by, mas utilizando mais de uma tabela, deva trazer diferenças mais significativas, mas não fiz testes para verificar.

Configuração de teclado: udev + UPower

Final de semana fui atualizar meu Gentoo, e uma das atualizações disponíveis era a do gnome. Finalizada a instalação percebo que existem algumas diferenças no funcionamento do teclado e do mouse.

Antes, o teclado e mouse funcionavam com o HAL, e agora utilza udev. Devido a isso, meu teclado, que é padrão Americano Internacional, não estava mais acentuando.

Após muita pesquisa, verifiquei que o HAL é considerado obsoleto, e que no lugar dele, usa-se o udev e UPower.

A dificuldade foi que, com o HAL, era possível desativar a inserção automática de dispositivos e configurá-los através do arquivo /etc/X11/xorg.conf. Com o udev/UPower, isso não foi possível. Mas quando o udev carregava a configuração do teclado, ele definia o layout como us, e não como us_intl.

Era possível verificar tudo isso através do log do servidor X (/var/log/Xorg.0.log) que exibia uma mensagem como a abaixo:

[  3955.251] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)
[  3955.251] (**) Option "xkb_rules" "evdev"
[  3955.251] (**) Option "xkb_model" "evdev"
[  3955.251] (**) Option "xkb_layout" "us"

Verificado isso, comecei nova pesquisa, e nesta wiki do ArchLinux, a solução foi encontrada. Para configurar o teclado agora, é preciso editar o arquivo /etc/X11/xorg.d/10-evdev.conf, que tem uma sintaxe muito parecida com o xorg.conf.

No meu caso, precisei criar o diretório xorg.conf.d dentro de /etc/X11, e copiar um arquivo base de /usr/share/X11/xorg.conf.d.

Feito isso somente inseri algumas linhas na área definida para o teclado, ficando como o abaixo:

Section "InputClass"
        Identifier "evdev pointer catchall"
        MatchIsPointer "on"
        MatchDevicePath "/dev/input/event*"
        Driver "evdev"
EndSection

Section "InputClass"
        Identifier "evdev keyboard catchall"
        MatchIsKeyboard "on"
        MatchDevicePath "/dev/input/event*"
        Driver "evdev"

    Option "XkbLayout" "us_intl,br"
    Option "XkbOptions" "grp:menu_toggle,grp_led:scroll"

EndSection

Section "InputClass"
        Identifier "evdev touchpad catchall"
        MatchIsTouchpad "on"
        MatchDevicePath "/dev/input/event*"
        Driver "evdev"
EndSection

Section "InputClass"
        Identifier "evdev tablet catchall"
        MatchIsTablet "on"
        MatchDevicePath "/dev/input/event*"
        Driver "evdev"
EndSection

Section "InputClass"
        Identifier "evdev touchscreen catchall"
        MatchIsTouchscreen "on"
        MatchDevicePath "/dev/input/event*"
        Driver "evdev"
EndSection

As linhas adicionadas são as em negrito.

Aproveitei a oportunidade e pesquisei também como fazer para definir mais de um layout de teclado para o caso de eu querer ligar um teclado abnt2. Como pode-se ver, a linha Option "XkbLayout" "us_intl,br" define dois layouts, o us_intl e o br. A linha seguinte Option "XkbOptions" "grp:menu_toggle,grp_led:scroll" diz que, se pressionar o botão de "menu de contexto" do teclado, haverá a troca de layout, e o led de scroll lock irá indicar esta troca.


A tecla de "menu de contexto" foi uma escolha pessoal, visto que é uma tecla que eu não utilizava para nada. Outras opções podem ser vistas nesta wiki do Gentoo.

Palestra: Processo de desenvolvimento do Kernel e do QEMU

Hoje tive a oportunidade de assistir uma palestra em minha empresa sobre o Processo de desenvolvimento do Kernel Linux e do Qemu.

O palestrante, Glauber Costa, é engenheiro e mestre em computação pela Unicamp. É envolvido com o processo de desenvolvimento do kernel Linux desde 2004. Está envolvido no projeto Qemu a cerca de 3 anos. Já trabalho no Linux Technology center da IBM e atualmente trabalha no grupo de virtualização da Red Hat.

O objetivo da palestra foi mostrar como funciona o processo de desenvolvimento de dois softwares livres.

Segundo Glauber, o processo de desenvolvimento do kernel funciona como uma árvore de confiança. O mantenedor do kernel não revisa todo o código. Ele confia no mantenedor de cada ramo da árvore de desenvolvimento, que por sua vez, confia nos sub-ramos, se eles existirem. Cada mantenedor fica responsável por garantir que todo o código de sua árvore é confiável, seja revisando, seja confiando em outra pessoa que revisaram.

Isso é necessário porque não é possível alguém revisar todas as alterações, pois atualmente o kernel tem mais de 14 milhões de linhas.

O Qemu é utilizado para virtualização, e começou como um projeto individual de Fabrice Bellard.

Por ser um projeto individual, as colaborações muitas vezes demoravam para serem inseridas a ele. Isso tornava a evolução lenta.

Com o advento da virtualização, alguns desenvolvedores viram que era interessante investir no Qemu, mesmo que fosse necessário um pouco de tempo para melhorar o processo de desenvolvimento colaborativo.

Glauber concluiu que, mesmo o Qemu tendo um processo de desenvolvimento complicado, ele era sim, um software bem sucedido, pois atendia as expectativas do desenvolvedor.

Ou seja, mesmo tendo processos de desenvolvimento diferentes, tanto o kernel Linux como Qemu, são softwares livres bem sucedidos.

Glauber destacou que, num processo colaborativo como o do kernel, muitas vezes tem-se conflitos, mas isso nem sempre é algo ruim. Normalmente isso ajuda na evolução do software. Alguns desses conflitos podem gerar forks, e esses forks podem acabar ou seguir por muito tempo.

O fato de ter Red Hat e Suse, que são concorrentes, trabalhando no kernel não é ruim para ambas, muito pelo contrário, pois os custos de melhoria do kernel acaba sendo dividido entre várias empresas.

Glauber também enfatizou que a Red Hat figura atualmente como a maior contribuidora, responsável pelo desenvolvimento de aproximadamente 12% do kernel. Ou seja, se ela parar de contribuir, causará algum impacto, mas não impossibilitará a continuidade do projeto.