Saber 3. Documentação do Sistema. Roney Alves dos Santos Walter Maciel Junior Supervisão: Rogério Maues. São Paulo, 08 de Novembro de 2013 -(versão 2)

Saber 3 Documentação do Sistema Roney Alves dos Santos Walter Maciel Junior Supervisão: Rogério Maues São Paulo, 08 de Novembro de 2013 -(versão 2)

Sumário Netserver Servidor de Rede...8 DHCP Dinamyc Host Configuration Protocol...8 ATFPT - Advanced Trivial File Transfer Protocol...10 NFS - Network File System...12 NTP - Network Time Protocol...13 Squid...14 Dansguardian...15 Munin...16 Apache...17 Cups...18 Usuários...19 SSH - Secure Shell...20 APT - Advanced Packaging Tool...21 Clients-cfg - Configuração Individual dos Clients...22 ip_fixo_for_client - Configuração de IP fixo dos Clients...23 OCS Inventário de Hardware...24 Fwsaber Iptables...26 ram2ram Solução de transferência Inteligente...27 Thinclient...29 Toram Sistema carregado na RAM do thinclient...30 Infra Estrutura...31 SSH Secure Shell...33 ALSA - Advanced Linux Sound Architecture...34 Munin...35 Inittab e Mingetty...37 Xorg...38 LXDE - Lightweight X11 Desktop Environment...40 Área de Trabalho...63 Papel de Parede...65 Icones...66 Navegador Firefox...67

Minidistro...70 Servidor de Som - esound...75 Conexão USB...76 Finalizar e reiniciar a sessão...77 Pacotes Instalados Minidistro...79 Pacotes Instalados - Toram...94

Objetivo Atualmente os Telecentros da Cidade de São Paulo possuem duas versões do Sistema Operacional Saber, uma para thinclients com baixo desempenho (Saber Lenny) e outro para desktop diskless dependente de uma rede Gigabit (Saber 2). Isto se deve ao fato de que o hardware utilizado nos Telecentros é hetorogêneo e possui tecnologias de diferentes gerações, o que dificulta e muitas vezes impede o desenvolvimento e aplicação de novas tecnologias, sendo este o maior desafio da equipe de desenvolvimento do Saber GNU/Linux. Em resposta a essa dificuldade, muito foi estudado para se criar uma nova estrutura de funcionamento do Saber GNU/Linux. Assim surgiu o Saber GNU/Linux 3, que une a necessidade de funcionar em equipamentos ultrapassados e o real aproveitamento da capacidade dos equipamentos de melhor performance.

Saber 3 O Sistema Operacional Saber GNU/Linux é baseado nos pacotes da distribuição Debian GNU/Linux Squeeze. Modelado pela equipe de desenvolvimento de forma a atender as necessidades do programa de inclusão digital da Prefeitura de São Paulo. Graças a nova solução ram2ram, o Saber 3 é um sistema capaz de atender a realidade de hardware do Programa Telecentros, seu diferencial é o de funcionar adequadamente em diferentes gerações e desempenho de equipamentos, ainda assim fornecendo aplicativos atualizados com as mais novas tecnologias disponíveis, proporcionando rica experiência ao frequentador das diversas unidades espalhadas. Essa complexa estrutura é formada por três sistemas operacionais que trabalham em conjunto. O Netserver é o servidor de rede além de possui todos os programas necessários para um ambiente Desktop. A Minidistro é um sistema pequeno e básico para controlar o hardware do thinclient com RAM de 128 MB á 1.5 GB. O Toram é um sistema completo e avançado que é carregado diretamente na RAM (diskless) de cada computador com RAM acima de 2 GB.

Netserver Servidor de Rede DHCP Dinamyc 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 3 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 "/ipxelinux.0" informa que o gerenciador de boot será o ipxe que solicitará o kernel e o initrd via HTTP (Hipertext Transfer Protocol). Afim de evitar possíveis conflitos de rede, o IP/MASK padrão foi alterado para 192.168.80.1/24. 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 Server-identifier 192.168.80.1; ignore unknown-clients; ddns-update-style ad-hoc; default-lease-time 43200; max-lease-time 86400; option subnet-mask 255.255.255.0; option broadcast-address 192.168.80.255; option routers 192.168.80.1; option domain-name "saber.local"; option domain-name-servers 8.8.8.8; next-server 192.168.80.1; option root-path "192.168.80.1:/opt/saber/minidistro"; option space ipxe; option ipxe.no-pxedhcp code 176 = unsigned integer 8; Documentação Saber 3-8

option ipxe.no-pxedhcp 1; option ipxe-encap-opts code 175 = encapsulate ipxe; option option-128 code 128 = string; option option-129 code 129 = text; if substring (option vendor-class-identifier,0,9)="pxeclient" { filename "ipxelinux.0"; } subnet 192.168.80.0 netmask 255.255.255.0 { range 192.168.80.11 192.168.80.35; } group { host ecid1 { hardware ethernet c8:9c:dc:c9:11:19; fixed-address 192.168.80.11; option host-name "ecid1"; } }... -- EOF Diferentemente das versões anteriores, agora o administrador do sistema deve incluir as configurações dos clientes no DCHP obrigatoriamente, caso contrário o ambiente gráfico pode não carregar corretamente. Um ponto bastante importante é a linha option domain-name-servers 8.8.8.8; que identifica qual o DNS será enviado aos thinclients, no caso está configurado para o DNS do Google, mas pode ser alterada conforme a necessidade. Essa linha será bastante utilizada quando for necessário que os thinclients acessem a internet de forma direta sem passar pelo proxy.

ATFPT - Advanced Trivial File Transfer Protocol É o serviço responsável pela entrega do ipxe ao thinclient, sua configuração é bastante peculiar e pode ser vista no arquivo /etc/default/atftpd. Nas versões anteriores, este serviço também era responsável por entregar o Kernel e o Initrd, entretanto quando o servidor está com sua placa de rede transmitindo seu máximo, o atftp apresenta um desempenho muito abaixo do necessário, por esse motivo, foi necessário a inclusão do ipxe. -- /etc/default/atftpd... USE_INETD=false OPTIONS="--daemon --port 69 --tftpd-timeout 300 --retry-timeout 5 --no-timeout --mcast-port 1758 --mcast-addr 192.168.255.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /opt/saber/boot/"... -- EOF Documentação Saber 3-10

ipxe Preboot Execution Environment É uma solução livre para firmware de inicialização via rede. Fornece muitas implementações se comparadas com o PXE proprietário. Uma dessas implementações é a capacidade de carregar arquivos através do protocolo HTTP, sendo este o principal motivo da sua inserção no sistema, melhorando muito a maneira como o Kernel e o Initrd são entregados ao thinclient. Seu arquivo de configuração é o /opt/saber/boot/pxelinux.cfg/default -- /opt/saber/boot/pxelinux.cfg/default... #!ipxe kernel http://${next-server}/pxe/3.6.2-client ip=dhcp root=/dev/nfs nfsroot=${nextserver}:/opt/saber/minidistro imagetoram=saber-3.0.img nfsmnt=/opt vga=791 noapic pci=noacpi irqpoll quiet initrd http://${next-server}/pxe/initrd.img boot... -- EOF Obs: a opção vga=791 deve ser alterada com o valor 788 em clientes da marca Positivo, pois durante o boot aparece a mensagem no monitor Out of Range. -- /etc/dhcp/dhcpd.conf option space ipxe; option ipxe.no-pxedhcp code 176 = unsigned integer 8; option ipxe.no-pxedhcp 1; option ipxe-encap-opts code 175 = encapsulate ipxe; -- EOF Documentação Saber 3-11

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. 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/ 192.168.80.0/255.255.255.0(rw,no_root_squash,no_subtree_check,sync,no_all_squash) /opt/ 192.168.80.0/255.255.255.0(ro,no_root_squash,no_subtree_check,sync,no_all_squash)... -- EOF Documentação Saber 3-12

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 127.127.1.0 fudge 127.127.1.0 stratum 13... -- EOF Documentação Saber 3-13

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 3126. A localização dos arquivos de cache é /var/cache/squid pode ser ajustada através do parâmetro cache_dir 64 16 256 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...... -- EOF acl Safe_ports port 443 563 # https, snews Documentação Saber 3-14

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 http://netserver/dglog (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 diariamente, sua alteração pode ser feita através do comando: -- crontab -e... 05 13 * * * /usr/local/sbin/get_dansguardian.sh > /var/log/get_dansguardian.log 2>&1... -- EOF Documentação Saber 3-15

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 http://netserver/munin, compartilha login e senha do DGlog que podem ser alteradas através do arquivo /etc/apache2/.dglog com comando htpasswd. Documentação Saber 3-16

Apache O servidor HTTP do Saber, tem por função fornecer infra-estrutura para os serviços ipxe, DGlog e Munin. É pelo Apache que o Kernel, Initrd e o Saber.img são enviadas ao client. 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 /etc/apache2/conf.d/boot-client.conf alias /pxe /opt/saber/boot/ <Directory "/opt/saber/boot/"> AllowOverride None Order deny,allow Allow from 192.168.0.0/255.255.0.0 ::1/24 </Directory> --EOF Documentação Saber 3-17

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 http://127.0.0.1:631 quando conectado diretamente no servidor, ou http://netserver:631 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. Documentação Saber 3-18

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. 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 usuario --ingroup users --disabled-password usuario 2 - Adicione o usuário aos grupos audio e video. 3 - Adicione o novo usuário ao arquivo /etc/hosts, obedecendo a sua rede: -- /etc/hosts... 192.168.80.71 usuario... -- EOF 4 - Adicione o usuário no servidor DHCP: -- /etc/dhcp/dhcpd.conf... host usuario { hardware ethernet 00:30:18:d0:3c:6b; fixed-address 192.168.80.71; option host-name "usuario"; } -- EOF O sistema por padrão tem 60 usuários, ecid1 até ecid60. Documentação Saber 3-19

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 e que rodam apenas um determinado comando. 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. O script ssh_keys é usado para recriar as chaves necessárias para o funcionamento dos thinclients que utilizam a minidistro, dessa forma a minidistro quando carregada no client pode acessar o seu respectivo usuário no Netserver sem precisar colocar a senha. Os scripts de detecção de dispositivos USB, o session também usam o recurso das chaves para acesso direto ao seu usuário no Netserver. Documentação Saber 3-20

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 http://www.telecentros.sp.gov.br/saber/distro/ saber3 main deb http://ftp.br.debian.org/debian/ squeeze main deb http://security.debian.org/ 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::http::Proxy "http://127.0.0.1:3126";... -- EOF Documentação Saber 3-21

Clients-cfg - Configuração Individual dos Clients Contém os arquivos que reunem as principais configurações do comportamento dos clients. O arquivo default possui configurações padrão válida a todos os clientes, quando não existir um arquivo específico para cada client. No caso de haver necessidade de ter configurações para diferentes clientes, podese criar um arquivo único para cada cliente devendo ser nomeado com o HOSTNAME do respectivo cliente. Ex.: o arquivo deve ser nomeado como "ecid12" e possuir as configurações específicas. As opções possíveis são: TORAM=Y deve ser utilizada quando o client utilizar a RAM do Client para carregar todo o sistema usando a tecnologia do Saber 2.0. WALLPAPER=Y As vezes é necessário não atualizar automaticamente o papel de parede, portanto a opção pode ser configurada para 'N', assim o script de atualização deixa de funcionar automaticamente. ICON=Y define que o ícones da área de trabalho serão atualizadas automaticamente. OCS_SERVER=200.200.201.202 informa o IP local ou remoto do servidor OCS. OCS_U=xxxx define o usuário do servidor OCS OCS_P=xxxx define a senha do servidor OCS VIDEODETECT=Y define que o sistema irá detectar as configurações do monitor e placa de video. Quando é necessária uma configuração fixa as outras opções (VIDEOCARD, DEPTH...) são complementares ao configurar o VIDEODETECT=N. SMOUSE=Y define se o sistema irá configurar o mouse como SERIAL. VIDEOCARD=XXXX define qual é o driver de video utilizado pelo Xorg. DEPTH=24 define a profundidade de cor. RESOLUTION=1024x768 define a resolução do monitor. HSYNC=xx-xx define o syncronismo horizontal do monitor. VFRESH=xx-xx define a atualização vertical do monitor. Documentação Saber 3-22

ip_fixo_for_client - Configuração de IP fixo dos Clients As vezes o ambiente de rede de uma unidade de Telecentro não é controlada pelos Analistas de campo, podendo ser de administração de terceiros podendo causar conflitos de configuração da rede. Um exemplo é a existência de um outro servidor DHCP na mesma rede, causando problemas para o correto funcinamento dos clientes e vezes até impedindo o boot. Para evitar esse problema foi criado o script ip_fixo_for_client. Ele identifica os clients configurados no dhcpd.conf e gera arquivos nomeados com o MAC- ADDRESS de cada client na pasta /opt/saber/boot/pxelinux.cfg/ utilizado o arquivo default como base, inserindo as variáeis ip=192.168.80.x hostname=ecidx que definem o ip e o hostname. Desta maneira o client irá solicitar apenas DHCP no momento do carregamento do PXE e ipxe. Documentação Saber 3-23

OCS Inventário de Hardware Tendo em vista a dificuldade de saber rapidamente quais equipamentos fazem parte de uma unidade de Telecentros, foi adicionado ao sistema um agente do OCS Inventory para enviar à um servidor central todas as informações de hardware facilitando a consulta ao parque de equipamentos ativos em todas as unidades de Telecentro. - - /etc/ocsinventory/ocsinventory.sh PROG=/usr/bin/ocsinventory-agent if [! -x "$PROG" ]; then exit 0 fi INV="/home/.saber/inventario/`hostname`/`hostname`" TC=$(hostname) if [! -x "$PROG" ]; then exit 0 fi. /opt/saber/client-cfg/default test -d $INV mkdir -p $INV inventario () { uno=1 while [ $uno -le ] ; do $PROG --tag=$tc --basevardir=$inv \ --server=http://$ocs_server/ocsinventory \ --realm="inventario" --proxy=http://localhost:3126 \ --user=$ocs_u --password=$ocs_p > /var/log/ocsinventory.log 2>&1 sleep 30 grep 'Cannot establish communication' /var/log/ocsinventory.log uno=$((uno+4)) echo tentativa $uno >> /var/log/ocsinventory.log Documentação Saber 3-24

uno=((uno+1)) sleep 5m done } - - EOF

Fwsaber Iptables Afim de proteger os serviços de rede do Netserver, foi inserido um pequeno e simples script que aplica regras de Iptables, fechando portas da rede externa e limitando o acesso a apenas alguns protocolos. O script não tem a proposta de ser uma solução de firewall, mas reduz drasticamente a possibilidade de utilização de uma possível brecha de segurança. O acesso aos servidores da Receita Federal para entrega do Imposto de Renda é configurado neste script, conforme visto abaixo: - - /etc/init.d/fwsaber # nat para programa receita echo 1 > /proc/sys/net/ipv4/ip_forward iptables -A POSTROUTING -t nat -p udp --dport 53 -j MASQUERADE iptables -A POSTROUTING -t nat -p tcp --dport 3456 -d 161.148.0.0/255.255.0.0 -j MASQUERADE --EOF O arquivo pode ser configurado conforme a necessidade do ambiente, entretanto já possui configurações suficientes para o funcionamento padrão do sistema. Documentação Saber 3-26

ram2ram Solução de transferência Inteligente O desenvolvimento do Saber 2 trouxe grandes evoluções graças a sua solução de utilizar os recursos de hardware da nova geração de thinclients. Com isso não mais necessitava da compra de servidores de alto desempenho e caros. Entretanto havia a necessidade de utilizar ao menos 1 ponto de rede Gigabit (entre servidor e switch) para que a transferência da imagem de cerca de 800MB fosse carregada na RAM de cada thinclient rapidamente. Após alguns meses analisando a fundo as vantagens e desvantagens, foi desenvolvido a solução ram2ram baseada no sistema Netram GNU/Linux, que por sua vez é baseada na tecnologia Peer to Peer. A solução ram2ram possibilita que ao mesmo tempo que um thinclient está copiando a imagem saber.img do servidor, também está distribuindo à outros clients da rede aumentando consideravelmente a velocidade total de transferência e diminuindo drasticamente o tempo de boot de todos os thinclients. Além de não mais haver um limite de thinclients da rede, ainda possibilita que um Switch simples com portas 10/100 consiga sustentar uma rede onde todos os thinclient utilizam a tecnologia do carregamento da imagem na RAM. Essa é sem dúvida a maior evolução deste sistema, pois pode-se aproveitar as estações diskless das unidades de Telecentro que ainda não contava com uma rede Gigabit. Este novo e importante recurso colocará o Programa Telecentros em novo patamar de qualidade, oferencendo o máximo possível de desempenho e tecnologia aos utilizadores. Documentação Saber 3-27

O script abaixo é utilizado para disponibilizar a imagem Toram para os thinclients: -- /etc/init.d/bttrack... btmakemetafile $i http://$ipserver:$port/announce 2>/dev/null > /dev/null screen -dms rtorrent nice -n 20 /usr/bin/rtorrent -o upload_rate=$speed,dht=auto $i EOF Arquivos utilizados pela estrutura ram2ram: /opt saber boot 3.6.2-client Kernel config-3.6.2-client initrd.img ipxelinux.0 pxelinux.cfg c8:9c:dc:c9:11:19.exemplo default saber-3.0.img saber-3.0.img.torrent Documentação Saber 3-28

Thinclient O Saber 3 é caracterizado pela capacidade de funcionar tanto em equipamentos antigos e ultrapassados, como em equipamentos de última geração. Para tanto foi necessário uma estrutura relativamente complexa onde o sistema se comporta de maneira diferente em cenários de hardware distintos e até mesmo misturados. Quando o sistema é carregado em um thinclient de baixa performance (RAM abaixo de 1,5 GB) ele se comporta do modo que chamamos de Minidistro. Quando o sistema é carregado em uma estação diskless (RAM acima de 1,5GB) ele se comporta do modo que chamamos de Toram. Em ambos os casos o ambiente gráfico apresentado ao utilizador é exatamente o mesmo, diferindo apenas o de programas que exigem alto desempenho de hardware (como o openshot ou blender), onde obviamente um thinclient de baixa performance consegue carregar e prejudicaria o desempenho do Servidor. Documentação Saber 3-29

Toram Sistema carregado na RAM do 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 diskless, ao invés de o thinclient montar um sistema básico através do NFS ele monta um sistema completo na RAM. O modo Toram é o que possui todos os softwares profissionalizantes que requerem alto desempenho de hardware. Documentação Saber 3-30

Infra Estrutura Após o carregamento do Kernel, Initrd e Saber.img 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 HOSTNAME=`hostname` CAMI='/etc/client-cfg' [ -f $CAMI/default ] && export CLI_CFG="$CAMI/default" [ -f $CAMI/$HOSTNAME ] && export CLI_CFG="$CAMI/$HOSTNAME" echo "nameserver $(grep -q "^DNS=" $CLI_CFG cut -d\= -f2)" > /etc/resolv.conf rm -rf /root/id* ntpdate netserver > /dev/null 2>&1 & echo "127.0.0.1 localhost.local localhost" > /etc/hosts Documentação Saber 3-31

echo "${IPSERVER} netserver" >> /etc/hosts echo "$IP_CLIENT `hostname`.local `hostname`" >> /etc/hosts sed -i s/hostname/`hostname`/g /etc/inittab if [ -e /etc/imagetoram ];then fi mount -t tmpfs -o size=1m,mode=1777 tmpfs /media/ mount -t nfs ${IPSERVER}:/home/ /home -o vers=3,nolock,exec,rsize=8192,wsize=8192,rw ssh root@netserver 2> /dev/null && for i in passwd shadow group cups/ppd cups/printers.conf; do rsync -uqap /home/.saber/infra/$i /etc/$i ;done sed -i '/DeviceURI/cDeviceURI ipp://netserver:631/printers/impressora' /etc/cups/printers.conf sed -i s/accepting\ No/Accepting\ Yes/g /etc/cups/printers.conf sed -i s/'#controle1'/`hostname`/g /etc/munin/munin-node.conf sed -i s/'#controle2'/$ipserver.1/g /etc/munin/munin-node.conf rm -rf /root/* init q EOF

SSH Secure Shell 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 confere com o seu know_hosts. -- /etc/ssh/ssh_config Host *... StrictHostKeyChecking no... SendEnv LANG LC_* HashKnownHosts yes GSSAPIAuthentication yes GSSAPIDelegateCredentials no EOF Documentação Saber 3-33

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 niveis de audio" 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 Documentação Saber 3-34

Munin O Munin possibilita a analise 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 script 'infra.sh' 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 Documentação Saber 3-35