Saber /10/2010 Revisão: 19/09/11 Roney Alves dos Santos Walter Maciel Apoio: Emílio Miranda

Transcrição

1 Saber /10/2010 Revisão: 19/09/11 Roney Alves dos Santos Walter Maciel Apoio: Emílio Miranda

2

3 Conteúdo 1. Netserver Servidor de Serviços de Rede DHCP - Dynamic Host Configuration Protocol ATFPT - Advanced Trivial File Transfer Protocol NFS - Network File System NTP - Network Time Protocol Squid Dansguardian Munin Apache Cups Usuários SSH - Secure Shell APT - Advanced Packaging Tool Thinclient Infra Estrutura SSH ALSA - Advanced Linux Sound Architecture Munin Inittab e Mingetty Xorg LXDE - Lightweight X11 Desktop Environment Área de Trabalho Papel de Parede Icones Navegador Firefox Pacotes Instalados 45 Saber 2.0 Página 1

4 Objetivo D evido ao rápido e constante avanço dos softwares e da Internet, é exigido servidores cada vez mais potentes e caros onde nem sempre são suficientes para suprir a crescente demanda. Por outro lado, equipamentos antes considerados defasados tecnicamente com desempenho pífio se comparado com Desktops, os chamados Thinclients recentemente receberam atenção especial dos Fabricantes alcançando desempenho semelhante ao de Desktops modernos e com o atrativo do baixíssimo custo e simples manutenção, vem se tornando um ótimo candidato a substituição dos velhos e custosos Desktops. Entretanto não existe no mercado um Sistema Operacional que seja capaz de usufruir de todo esse potencial sem ser instalado em um Disco Rígido local, ou um poderoso servidor oferecendo um sistema totalmente pela rede gerando grande tráfego na rede, reduzindo o desempenho global do sistema. Então surgiu a pergunta Como usufruir totalmente dessa nova arquitetura dos Thinclients, diminuindo o consumo excessivo do servidor?. Foi com esse desafio tecnológico que iniciei o projeto Saber 2.0 com grandes contribuições dos Srs. Emílio Miranda, Walter Maciel e Rogério Maues. Esta documentação tem o propósito de fornecer informações técnicas do funcionamento do sistema, assim como diversas peculiaridades, dessa forma tanto outros desenvolvedores como os analistas tenham por onde começar a entender esse novo sistema. Roney Alves Saber 2.0 Página 2

5 Saber 2.0 O Saber 2.0 é um sistema baseado nos pacotes da distribuição Gnu/Linux Debian 6.0 Squeeze para funcionar como servidor de Thinclients oferecendo uma excelente infra-estrutura para um ambiente de inclusão digital e principalmente aprimoramento profissional, uma vez que o objetivo principal é de oferecer softwares de aplicação profissional em diversas áreas. Diferente das versões anteriores onde o servidor além de manter todos os serviços de rede como proxy, compartilhamento de arquivos, filtro de conteúdos, servidor de impressão, etc., também processa todos os programas e todo o ambiente dos thinclients que por sua vez processa apenas uma mini-distro que oferece infra-estrutura para o hardware. Dessa forma o servidor deve possuir um hardware potente para atender a demanda de mais de 20 thinclients. O Saber 2.0 caminha no sentido contrário a isso tudo, o servidor (intitulado de Netserver) tem por princípio oferecer aos thinclients apenas a infra-estrutura de rede, ou seja, apenas os serviços destinados a rede tais como proxy, filtro de conteúdo, distribuição de IPs, compartilhamento de arquivos, servidor de impressão, etc. sem ter de processar qualquer programa que esteja funcionando nos thinclients. Quando um thinclient é ligado ele recebe do servidor uma imagem de um sistema operacional completo que também é baseado no Gnu/Debian, ele carrega o sistema inteiro na sua RAM e por esse motivo dispensa qualquer dispositivo de armazenamento com um HD ou uma memória Flash. Essa estrutura só se tornou viável quando os thinclients começaram a ser fabricado com mais de 1GB de RAM, pois como tudo é carregado diretamente na RAM, transformando-a em um disco virtual, o espaço tem que ser consideravelmente maior do que a imagem do sistema. A vantagem de o sistema rodar inteiramente no thinclient é a de além de aproveitar melhor a sua performance e a possibilidade de incluir softwares mais pesados e aprimorados, não se faz mais necessário ter um servidor cada vez mais robusto e mais caro, podendo inclusive aproveitar servidores, que atualmente são lentos para a demanda do Saber Lenny, serem mais do que suficientes para atender todas as necessidades do Saber 2.0 podendo até triplicar ou quadruplicar a quantidade de thinclients conectados a um mesmo servidor sem haver perda de performance, tendo como limite apenas a infra estrutura de rede. Saber 2.0 Página 3

6 1. Netserver Servidor de Serviços de Rede 1.1 DHCP - Dynamic Host Configuration Protocol É um protocolo de serviço do TCP/IP que é responsável pela distribuição dinâmica de endereços IP e outros parâmetros de configuração dos clientes da rede. Ele é o primeiro serviço a ser solicitado pelo cliente através da placa de rede que possui a tecnologia PXE (Preboot Execution Environment). No Saber 2.0 o DHCP possui uma configuração personalizada e é constituída da seguinte maneira: O arquivo de configuração é o /etc/dhcp/dhcpd.conf e a opção filename "/pxelinux.0"; informa que o gerenciador de boot será o PXE que solicitará o kernel através do TFTP (Trivial File Transfer Protocol). O arquivo ainda contém informações sobre cada cliente, atrelando a este o IP, MAC-ADDRESS e hostname conforme o exemplo abaixo: -- /etc/dhcp/dhcpd.conf # Os usuários devem estar cadastrados corretamente neste arquivo, conforme exemplo abaixo. # Somente dessa forma os clientes idenficarao o usuarios correspondentes. Server-identifier ; #ignore unknown-clients; ddns-update-style ad-hoc; default-lease-time 600; max-lease-time 1600; option subnet-mask ; option broadcast-address ; option routers ; option domain-name "saber.local"; option domain-name-servers ; option root-path " :/opt/saber/root"; filename "/pxelinux.0"; #filename "/ client.etb"; next-server ; option option-128 code 128 = string; option option-129 code 129 = text; if substring (option vendor-class-identifier,0,9)="pxeclient" { filename "/pxelinux.0"; } else if substring (option vendor-class-identifier,0,9)="etherboot" { Saber 2.0 Página 4

7 } filename "/ client.etb"; subnet netmask { range ; } group { host ecid1 { hardware ethernet 00:30:18:d0:3c:6b; fixed-address ; option host-name "ecid1"; } } -- EOF Se o administrador do sistema não optar por incluir as configurações dos clientes, o DCHP irá fornecer os dados corretamente, entretanto sem ordem específica para cada usuário. Um ponto bastante importante é a linha option domain-name-servers ; que identifica qual o DNS vai ser passado para os Clientes, no caso está configurado para o DNS do Google. Essa linha será bastante utilizada quando for necessário que os clientes acessem a internet de forma direta sem passar pelo proxy. Saber 2.0 Página 5

8 1.2 ATFPT - Advanced Trivial File Transfer Protocol É o serviço responsável pela entrega do Kernel e do initrd ao cliente, ele é ideal para servir grandes solicitações de inicialização simultânea, sua configuração é bastante peculiar e pode ser vista no arquivo /opt/saber/boot/pxelinux.cfg/default. O arquivo possui informações importantes para inicialização do Kernel, tais como endereço IP do servidor, resolução do terminal e localização da imagem que contém o sistema cliente. -- /opt/saber/boot/pxelinux.cfg/default append root=/dev/nfs initrd=initrd.img nfsroot= ip=dhcp quiet vga=791 noapic pci=noacpi imagetoram=saber.img nfsmnt=/opt -- EOF 1.3 NFS - Network File System O NFS é o servidor de compartilhamento de arquivos e diretórios, é através dele que se torna possível armazenar os documentos gerados pelos usuários nos clientes em seu diretório pessoal, uma vez que os clientes não possuem dispositivos físicos de armazenamento. È também responsável pelo compartilhamento da imagem que contém o sistema cliente localizado em /opt/saber.img. Portanto o HOME utilizado pelo cliente, na realidade é o HOME do servidor exportado e montando remotamente por cada cliente em seu respectivo usuário obedecendo às regras do sistema Unix de arquivos. Seu arquivo de configuração é o /etc/exports -- /etc/exports /home/ / (rw,no_root_squash,no_subtree_check,sync,no_al l_squash) /opt/ / (ro,no_root_squash,no_subtree_check,sync,no_al l_squash) -- EOF Saber 2.0 Página 6

9 1.4 NTP - Network Time Protocol O NTP é o protocolo encarregado de manter a data e hora dos clientes atualizadas, para isso ele utiliza o daemon NTPD que estabelece a data e hora através da internet ou utiliza-se a configuração atual do seu próprio sistema, no caso aquele que estiver configurado no Netserver. Seu arquivo de configuração é /etc/ntp.conf. -- /etc/ntp.conf server fudge stratum EOF Saber 2.0 Página 7

10 1.5 Squid É o servidor proxy do Netserver encarregado a fornecer aos clientes páginas HTTP, HTTPS, FTP entre outros. Apesar de ser um excelente servidor proxy com muitas atribuições, no Saber ele está encarregado apenas para fornecer um cache de internet com a intenção de acelerar a navegação dos clientes, diminuindo consideravelmente o consumo do link de internet. O arquivo de configuração do squid é /etc/squid/squid.conf. Com ele também se torna possível se conectar a um outro servidor proxy através das seguintes opções, bastando apenas inserir o IP e a Porta do proxy PAI: -- /etc/squid/quid.conf cache_peer IP parent PORT 0 no-query never_direct allow all -- EOF O Squid trabalha através da porta A localização dos arquivos de cache é /var/cache/squid pode ser ajustada através do parâmetro cache_dir onde 64 é o tamanho do cache, 16 é a quantidade de pastas e 256 a quantidade de subpastas. Algumas vezes pode ser necessária a liberação de uma porta no squid para liberar funcionalidades de algum site específico, para isso basta acrescentar mais uma ACL contendo a porta como no exemplo abaixo: -- /etc/squid/squid.conf acl Safe_ports port # https, snews -- EOF Saber 2.0 Página 8

11 1.6 Dansguardian O Dansguardian é o filtro de conteúdo do Saber, sua função é analisar os sites acessados pelos usuários e verificar se este site pode conter conteúdo inadequado através de um complexo cruzamento de informações. O navegador solicita uma página ao Dansguardian, este solicita ao Squid, o squid retorna e o Dansguardian analisa o site e devolve ou bloqueia o site ao navegador do usuário. Suas configurações são bastante flexíveis e podem ser alteradas através de arquivos em /etc/dansguardian, é possível acertar o peso das palavras, exceções de sites e domínios. O acesso pode ser monitorado através do DGlog através do endereço (Login:tcsaber senha:sabertc), com ele é possível analisar o motivo do site ser bloqueado, auxiliando no ajuste do Dansguardian. A atualização do Dansguardian é feita através do script get_dansguardian que é executado pelo CRON a cada 5 minutos, sua alteração pode ser feita através do comando: -- crontab -e * * * /usr/local/sbin/get_dansguardian.sh > /var/log/get_dansguardian.log 2>&1 -- EOF Saber 2.0 Página 9

12 1.7 Munin O Munin é o programa utilizado para gerar gráficos e relatórios de monitoramento do Servidor e de todos os clientes. Com ele é possível analisar e identificar possíveis gargalos em diversas frentes, antes mesmo que o usuário sinta o reflexo de um sistema problemático. Diferente de outros programas de monitoramento, ele abrange quase todo funcionamento do computador dando ao analista responsável uma grande quantidade de informações em tempo real. Foi configurado para recolher informações do servidor e de todos os clientes conectados a ele gerando gráficos em ciclos de 5 minutos. Em cada cliente um daemon do munin (munin-node) coleta informações locais e envia ao servidor do munin. Pode ser acessado através do endereço compartilha login e senha do DGlog que podem ser alteradas através do arquivo /etc/apache2/.dglog com comando htpasswd. Saber 2.0 Página 10

13 1.8 Apache O servidor HTTP do Saber, tem por função fornecer infra-estrutura para os serviços DGlog e Munin. Pode ser utilizado em aulas de PHP, já que possui o módulo PHP, entretanto necessita de configuração específica para tal. A pasta /etc/apache2 possui os arquivos de configuração, inclusive os relacionados com o Munin e DGlog /etc/apache2/sites-available/000-default -- /etc/apache2/sites-available/000-default AuthUserFile /etc/apache2/.dglog -- EOF Saber 2.0 Página 11

14 1.9 Cups Servidor de impressão do Saber, o Cups pode ser configurado de diversas formas de acordo com a necessidade. Podem-se configurar impressoras locais ou de rede e compartilhá-las com os clientes. É possível ainda gerenciar as impressoras pelo frontend através do endereço quando conectado diretamente no servidor, ou quando conectado a qualquer cliente da rede. O Cups do servidor (Netserver) compartilha a impressora ao Cups de cada cliente. Para fazer alterações administrativas no Cups, é necessário autenticar-se como root, por exemplo, ao configurar ou deletar uma impressora. Para ações como deletar trabalhos de impressão ou configurar a impressora para rejeitar trabalhos é necessário autenticar-se com o usuário 'admin' e senha 'admin', logicamente a senha pode ser alterada com o comando passwd conforme a necessidade. Saber 2.0 Página 12

15 1.10 Usuários Os usuários foram criados com uma ordem pré-definida, começam com ecid e terminam com a numeração de 1 a 25, podem ser adicionados mais usuários conforme a necessidade. Todos possuem suas pastas pessoais armazenadas no home do servidor (Netserver), montadas através do NFS. Os usuários criados no servidor são, portanto replicados aos clientes no momento de boot de cada um, portanto os mesmos usuários e senhas são idênticos tanto no Netserver quanto nos clientes, inclusive o root. Desta forma é imprescindível que se tenha uma senha de root forte, já que a senha pré-configurada é '1' e cada usuário ecid não possui senha configurada, uma vez que não há necessidade de efetuar um logon. Os usuários seguem as mesmas características de um usuário Unix, aumentando a segurança de cada sessão e arquivos. Caso seja necessária a inclusão de um novo usuário, siga os procedimentos abaixo: 1 - Crie o usuário no sistema com o seguinte comando: adduser --gecos ecidn --ingroup users --disable-password ecidn 2 - Adicione o novo usuário ao arquivo /etc/hosts, obedecendo a sua rede: -- /etc/hosts ecid1 -- EOF 3 - Adicione o usuário no servidor DHCP: -- /etc/dhcp/dhcpd.conf host ecid1 { hardware ethernet 00:30:18:d0:3c:6b; fixed-address ; option host-name "ecid1"; } -- EOF Não existem limites para a inclusão de usuários, apenas deve ser visto com atenção a largura de banda para a inicialização dos clientes, uma vez que a imagem do sistema transmitido pela rede é maior que 600MB. 10 clientes levam em torno de 1 minuto para estarem prontos para uso em uma rede onde o servidor possui uma placa de rede Gigabit, esse tempo aumenta conforme a quantidade de clientes conectados ao servidor. Saber 2.0 Página 13

16 1.12 SSH - Secure Shell O SSH simultaneamente, um programa de computador e um protocolo de rede que permite a conexão com outro computador na rede, de forma a executar comandos de uma unidade remota. Dessa forma é possível intervir no sistema sem ter a necessidade de um analista presente fisicamente. No Saber o SSH é utilizado também em conexões do servidor durante o boot do cliente, por isso existem chaves na pasta /root/.ssh para que não seja solicitada senha. Por motivo de segurança as chaves utilizadas pelo root do cliente, são apagadas assim que a conexão é finalizada. Nunca apague a pasta /root/.ssh do servidor, pois as chaves seriam perdidas e nenhum cliente conseguiria funcionar corretamente APT - Advanced Packaging Tool O APT é um gerenciador de pacotes para o Sistema Operacional GNU/Linux Debian e derivados como o Saber, uma vez que é baseado no Debian Squeeze. Ele é utilizado para instalar novos programas ou removê-los, para isto basta utilizar o comando aptitude ou o apt-get. Foi criado um repositório no site dos Telecentros para facilitar a manutenção e atualização do sistema. O repositório pode ser configurado conforme a necessidade veja abaixo como estão as configurações: -- /etc/apt/source.lst deb saber2 main deb squeeze main deb squeeze/updates main -- EOF Em alguns locais a conexão é feita através de um Proxy-Pai no qual o Squid se conecta, portanto para que o APT funcione corretamente através do Squid é necessário informá-lo conforme a configuração abaixo: -- /etc/apt/apt.conf Acquire:: " -- EOF Saber 2.0 Página 14

17 2. Thinclient Foi desenvolvido um sistema operacional também baseado nos pacotes do Gnu/Linux Debian 6.0 Squeeze e de soluções adotadas em outros sistemas como Knoppix e Netram, onde sua principal característica é a de funcionar completamente pela RAM. A idéia era a de funcionar como as distribuições LiveCd, que carregam através do CDROM sem a necessidade de serem instalados, mas ao invés de ser carregado pelo CDROM, ser carregado diretamente na RAM do thinclient e depois inicializado com um sistema instalado localmente mas com um grande diferencial que é aproveitar a velocidade da RAM evitando os possíveis gargalos de rede ou de dispositivos de armazenamento locais. O funcionamento é de um sistema thinclient normal a diferença é que ao invés de o thinclient montar um sistema básico através do NFS ele monta um sistema completo na RAM seguindo os mesmos preceitos de uma mini-distro. A imagem é compactada em squashfs e para fazer qualquer alteração no sistema deve-se descompactá-la utilizando o comando unsquashfs Saber 2.0 Página 15

18 2.1 Infra Estrutura Após o carregamento do Kernel através do PXE e do ATFTP explicados anteriormente, uma série de scripts entram em ação para criar a infra-estrutura necessária para ter um ambiente funcional e autenticado automaticamente, veremos alguns deles: O Script 'infra.sh' é o primeiro script fora do padrão Debian a ser executado, ele analisa e configura a interface de rede para que o binário 'estrutura' se encarregue de configurar o hostname, criar e gerenciar a infra-estrutura para o servidor de impressão, inclusão de usuários e grupos clonando-os do Netserver para que ao montar o home de cada usuário não haja incompatibilidades. A configuração da data e hora é feita através do comando 'ntpdate' que busca o servidor de Tempo no Netserver sincronizando o thinclient com servidor. Um ponto importantíssimo nesse script é o fato de ao invés de tratar o Netserver como um IP na rede, ele é tratado pelo seu hostname. Dessa forma todo o sistema que roda no thinclient não precisa de scripts que ficam trocando IP de cada aplicação complicando toda a manutenção do sistema. -- /etc/init.d/infra.sh for ETH in eth0 do TMP=$(LC_ALL=C /sbin/ifconfig $ETH grep inet sed 's/^\ \+//g;s/bcast.*//;s/[a-z :]//g') if [! -z "$TMP" ] then export IP=$TMP export IPSERVER=$(echo $IP cut -d'.' -f4 --complement) fi done dhclient eth0 ntpdate netserver 2> /dev/null & exec estrutura -- EOF Saber 2.0 Página 16

19 2.2 SSH Outra função do binário é conectar-se ao Netserver através do SSH utilizando as chaves públicas guardadas em /root/.ssh sendo removidas no final de todo o processo por questão de segurança. O SSH foi configurado para não questionar quando o MAC-ADDRESS não bate com o seu know_hosts. -- /etc/ssh/ssh_config Host * # ForwardAgent no # ForwardX11 no # ForwardX11Trusted yes # RhostsRSAAuthentication no # RSAAuthentication yes # PasswordAuthentication yes # HostbasedAuthentication no # GSSAPIAuthentication no # GSSAPIDelegateCredentials no # GSSAPIKeyExchange no # GSSAPITrustDNS no # BatchMode no # CheckHostIP no # AddressFamily any # ConnectTimeout 0 StrictHostKeyChecking no # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_rsa # IdentityFile ~/.ssh/id_dsa # Port 22 # Protocol 2,1 # Cipher 3des # Ciphers aes128-ctr,aes192-ctr,aes256- ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc # MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160 # EscapeChar ~ # Tunnel no # TunnelDevice any:any # PermitLocalCommand no # VisualHostKey no # ProxyCommand ssh -q -W %h:%p gateway.example.com SendEnv LANG LC_* HashKnownHosts yes GSSAPIAuthentication yes GSSAPIDelegateCredentials no -- EOF Saber 2.0 Página 17

20 2.3 ALSA - Advanced Linux Sound Architecture O próximo passo é configurar os controles de áudio através do Alsa e ironicamente utilizando o script do aumix :-). O aumix foi descartado, pois não foi possível configurar corretamente os níveis de áudio traseiros e frontais dos clientes mais novos que possuem a INTEL HD. -- /etc/init.d/aumix AMIXER () { echo "Configurando níveis de áudio" amixer -c 0 sset Master,0 80%,80% unmute cap > /dev/null 2> /dev/null amixer -c 0 sset PCM,0 80%,80% unmute cap > /dev/null 2> /dev/null amixer -c 0 sset PCM2,0 60%,60% unmute cap > /dev/null 2> /dev/null amixer -c 0 sset CD,0 60%,60% unmute cap > /dev/null 2> /dev/null amixer -c 0 sset Surround,0 70%,70% unmute cap > /dev/null 2> /dev/null amixer -c 0 sset Front,0 90%,90% unmute cap > /dev/null 2> /dev/null amixer -c 0 sset Line,0 60%,60% unmute cap > /dev/null 2> /dev/null amixer -c 0 sset Mic,0 60%,60% unmute cap > /dev/null 2> /dev/null amixer -c 0 sset "Front Mic",0 60%,60% unmute cap > /dev/null 2> /dev/null } AMIXER -- EOF Saber 2.0 Página 18

21 2.4 Munin O Munin é uma grande evolução, é a primeira vez que será possível analisar em tempo real e via web todo o comportamento do sistema e do hardware do thinclient, ou seja, é possível não acompanhar apenas o servidor, mas também todos os thinclients conectados a ele. Assim o analista técnico pode prever e corrigir erros antes mesmo que eles venham a prejudicar o usuário, essa é uma excelente ferramenta de auxílio técnico. O Binário 'estrutura' se encarrega de alterar o comentário "#controle" para o IP correto do Netserver, uma vez que o arquivo de configuração do munin-node funcionou corretamente ao incluirmos o hostname. -- /etc/munin/munin-node.conf log_level 4 log_file /var/log/munin/munin-node.log pid_file /var/run/munin/munin-node.pid background 1 setsid 1 user root group root # Regexps for files to ignore ignore_file ~$ #ignore_file [#~]$ # FIX doesn't work. '#' starts a comment ignore_file DEADJOE$ ignore_file \.bak$ ignore_file %$ ignore_file \.dpkg-(tmp new old dist)$ ignore_file \.rpm(save new)$ ignore_file \.pod$ # Set this if the client doesn't report the correct hostname when # telnetting to localhost, port 4949 # host_name #controle1 # A list of addresses that are allowed to connect. This must be a # regular expression, since Net::Server does not understand CIDR-style # network notation unless the perl module Net::CIDR is installed. You # may repeat the allow line as many times as you'd like allow ^127\.0\.0\.1$ allow #controle2 # If you have installed the Net::CIDR perl module, you can use # multiple cidr_allow and cidr_deny address/mask patterns. A # connecting client must match any cidr_allow, and not match any # cidr_deny. Example: Saber 2.0 Página 19

22 # cidr_allow /32 # cidr_allow /24 # cidr_deny /32 # Which address to bind to; host * # host # And which port port EOF Saber 2.0 Página 20

23 2.5 Inittab e Mingetty O arquivo inittab foi alterado para utilizar o programa de autenticação automática mingetty para conectar o usuário sempre baseando no hostname do thinclient facilitando a integração de todo o sistema. O mingetty traz o benefício de ser um pacote integrante dos espelhos Debian não necessitando baixar e compilar o fonte como era feito com autologin. -- /etc/inittab # What to do when CTRL-ALT-DEL is pressed. ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now # Action on special keypress (ALT-UpArrow). #kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work." # What to do when the power fails/returns. pf::powerwait:/etc/init.d/powerfail start pn::powerfailnow:/etc/init.d/powerfail now po::powerokwait:/etc/init.d/powerfail stop # /sbin/getty invocations for the runlevels. # # The "id" field MUST be the same as the last # characters of the device (after "tty"). # # Format: # <id>:<runlevels>:<action>:<process> # # Note that on most Debian systems tty7 is used by the X Window System, # so if you want to add more getty's go ahead but skip tty7 if you run X. # #1:2345:respawn:/sbin/getty tty1 1:23:respawn:/sbin/mingetty --autologin HOSTNAME tty1 2:23:respawn:/sbin/getty tty2 #3:23:respawn:/sbin/getty tty3 #4:23:respawn:/sbin/getty tty4 #5:23:respawn:/sbin/getty tty5 #6:23:respawn:/sbin/getty tty6 # Example how to put a getty on a serial line (for a terminal) # #T0:23:respawn:/sbin/getty -L ttys vt100 #T1:23:respawn:/sbin/getty -L ttys vt EOF Saber 2.0 Página 21

24 2.6 Xorg Após a autenticação automática do usuário ecidn feita pelo mingetty, o arquivo profile é executado. Através dele é possível efetuar a detecção das configurações de vídeo utilizadas pelo Xorg, esse arquivo foi aproveitado do Saber Lenny. Um ponto importante é que o script faz alterações no xorg.conf utilizando o sed e por esse mesmo motivo o xorg.conf original deve ser alterado com muita atenção para não inutilizar o script de detecção. -- /etc/profile echo -e "Aguarde detectando a placa de video" DEVS=$(/usr/sbin/xdebconfigurator 2>&1 egrep 'VIDEO CARD: VIDEO DRIVER: MONITOR DEFAULT DEPTH: MONITOR HOR MONITOR VER MOUSE DEVICE:') CARD=$(echo -e "$DEVS" awk '/CARD/ {print $3}') VIDEO=$(echo -e "$DEVS" awk '/DRIVER/ {print $3}') DEPTH=$(echo -e "$DEVS" awk '/DEPTH/ {print $4}') HSYNC=$(echo -e "$DEVS" awk '/HOR/ {print $4}') VREFR=$(echo -e "$DEVS" awk '/REF/ {print $4}') MOUSE=$(echo -e "$DEVS" awk '/MOUSE/ {print $3}') cp -a /etc/x11/xorg.conf.old /tmp/xorg.conf if [ $VIDEO = ati ]; then VIDEO=vesa fi if [ $CARD = VIA ]; then VIDEO=openchrome fi if [ $VIDEO = i810 ]; then VIDEO=intel fi if [! -z $VIDEO ] && [ $VIDEO!= unknown ]; then sed -i "s/vesa/$video/" /tmp/xorg.conf fi if [! -z $DEPTH ]; then sed -i "s/defaultdepth \+8/DefaultDepth $DEPTH/" /tmp/xorg.conf fi if [! -z $HSYNC ]; then sed -i "s/ /$hsync/" /tmp/xorg.conf fi if [! -z $VREFR ]; then sed -i "s/50-70/$vrefr/" /tmp/xorg.conf fi if [ $MOUSE = '/dev/ttys0' ]; then sed -i "s/#servermouse/inputdevice /tmp/xorg.conf \"Serial Mouse\"/" Saber 2.0 Página 22

25 sed -i s:'#inputmouse':"section \"Input Device\"\n Identifier \"Serial Mouse\"\n Driver \"mouse\"\n Option \"CorePointer\"\n Option \"Device\" \"/dev/ttys0\"\n Option \"Protocol\" \"Microsoft\"\n Option \"Emulate3Buttons\" \"true\"\nendsection":g /tmp/xorg.conf fi clear if [ -e /etc/imagetoram ]; then while true; do done else fi -- EOF /usr/local/sbin/session 2> /dev/null startx 2>&1 > /dev/null xinit -- /usr/bin/x11/x 2>&1 > /dev/null -- /etc/x11/xorg.conf.old Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" #servermouse EndSection Section "Files" RgbPath ModulePath FontPath FontPath FontPath FontPath FontPath FontPath FontPath EndSection "/etc/x11/rgb" "/usr/lib/xorg/modules" "/usr/share/fonts/x11/misc" "/usr/share/fonts/x11/100dpi/:unscaled" "/usr/share/fonts/x11/75dpi/:unscaled" "/usr/share/fonts/x11/type1" "/usr/share/fonts/x11/100dpi" "/usr/share/fonts/x11/75dpi" "/usr/share/fonts/x11/encodings" Section "Module" # Load "glx" Load "extmod" # Load "xtrap" # Load "record" # Load "GLcore" # Load "dbe" Load "dri" Load "ddc" EndSection Section "ServerFlags" Option "DontZap" "false" Saber 2.0 Página 23

26 EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "abnt2" Option "XkbLayout" "br" Option "XkbVariant" "abnt2" Option "XkbOptions" "abnt2" EndSection #inputmouse Section "Monitor" Identifier "Monitor0" HorizSync VertRefresh Option "DPMS" EndSection Section "Device" Identifier "Card0" Driver "vesa" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 16 SubSection "Display" Depth 16 Modes 1280x720 "1024x768" EndSubSection EndSection -- EOF Assim que o Xorg é chamado, ele executa o xinitrc onde podemos utilizá-lo para algumas alterações como no caso abaixo ao invocar o 'ck-launch-session': -- /etc/x11xinit/xinitrc #!/bin/sh # /etc/x11/xinit/xinitrc # # global xinitrc file, used by all X sessions started by xinit (startx) # invoke global X session script #. /etc/x11/xsession exec ck-launch-session startlxde --EOF Saber 2.0 Página 24

27 2.7 LXDE - Lightweight X11 Desktop Environment O LXDE foi o ambiente gráfico escolhido para compor o Saber 2.0 principalmente por ser um ambiente leve e possui as mesmas características básicas do gnome, dessa maneira é minimizado o impacto de uma mudança tão drástica para o usuário. Foram feitas diversas alterações para construir um tema que tivesse a mesma facilidade para o usuário sem perder o ar de novidade. Essas alterações foram feitas nos arquivos de configuração do LXDE. -- /usr/share/lxsession/lxde/desktop.conf <?xml version="1.0" encoding="utf-8"?> <!-- Do not edit this file, it will be overwritten on install. Copy the file to $HOME/.config/openbox/ instead. --> <openbox_config xmlns=" <resistance> <strength>10</strength> <screen_edge_strength>20</screen_edge_strength> </resistance> <focus> <focusnew>yes</focusnew> <!-- always try to focus new windows when they appear. other rules do apply --> <followmouse>no</followmouse> <!-- move focus to a window when you move the mouse into it --> <focuslast>yes</focuslast> <!-- focus the last used window when changing desktops, instead of the one under the mouse pointer. when followmouse is enabled --> <undermouse>no</undermouse> <!-- move focus under the mouse, even when the mouse is not moving -- > <focusdelay>200</focusdelay> <!-- when followmouse is enabled, the mouse must be inside the window for this many milliseconds (1000 = 1 sec) before moving focus to it --> <raiseonfocus>no</raiseonfocus> <!-- when followmouse is enabled, and a window is given focus by moving the mouse into it, also raise the window --> </focus> <placement> <policy>smart</policy> <!-- 'Smart' or 'UnderMouse' --> <center>yes</center> <!-- whether to place windows in the center of the free area found or the top left corner --> <monitor>any</monitor> Saber 2.0 Página 25