Prized Season software

Arranjei maneira de encaixar o Freesco de forma mais suave numa máquina VM-ware. Para já descobri a forma de emular o CD do PC para arranque, bem como a disquete. Na versão original (por exemplo a última, hoje a v0.3.6) o Freesco consegue correr a partir de uma disquete, eventualmente também a partir da RAM. Como extensão alterei alguns ficheiros na ramdisk para permitir que o arranque ocorra para um file-system Linux (ext2). Supreendentemente o Kernel que vem por defeito com esta distribuição ainda não permite nativamente ISO-9660 (CD-ROM ISO support) nem NFS, algo que eu acho útil para quem quer que a sua máquina Freesco possa, por exemplo, ser backed-up de forma fácil. Provavelmente a razão é de manter o número de módulos e compiled-in features nativas limitadas para que o tamanho do Kernel consiga caber numa disquete. Esta é a beleza do Freesco, e simultâneamente a sua maior fraqueza: embora permita mover as aplicações para o disco rígido (mv2hdd.bat), o modo out-of-the-box cabe numa disquete de 1.44 Mb.

Feita esta introdução, importa notar que os scripts que permitem arrancar na ramdisk drive, isto é, logo após o Kernel arrancar, mais especificamente o etc/rc, não é muito inteligente ao ponto de "adivinhar" qual o tipo de file-system instalado. Isto é irritante para quem queira ter um file-system ext2: pelo que alterei algumas funções de arranque para detectarem, por exemplo, que o primeiro disco primário IDE (através do parâmetro de arranque BOOTDEV=hda1) onde será montado o sistema raíz, tenha uma qualquer partição:

• umsdos (DOS FAT12/16 com distinções especiais para ficheiros Unix, por exemplo, soft-links)
• ISO-9660 (arranque por CD-ROM)
  
• ext2
• ...etc
  

Curiosamente os scripts para fazerem a paragem do sistema (poweroff, ou mais propriamente o halt suportado) também não são muito inteligentes, pelo que a partição não é desmontada antes dos discos serem desligados. A consequência é que no arranque se pode iniciar a partir de um sistema de ficheiros que não está completamente consistente. Além de prevenir essas situações (quando o sistema é desligado), fiz com que no arranque fosse feito uma verificação automática da consistência do sistema de ficheiros antes do rc_boot. Pode parecer trivial, mas a inclusão do e2fsck ocupa um espaço não negligenciável na ramdisk. Como tal, tive que apagar alguns ficheiros da ramdisk que não são tão utilizados -- nomeadamente módulos de placas de rede algo antigas.

Como cada caso é um caso... e isto pode não ser suficiente, melhorei a detecção e verificação automática de módulos a carregar (parâmetro de arranque MODULES=2.0.39-2, ou algo análogo ajustavel e compatível ao Kernel que utilizar). Alguns módulos da versão do Kernel 2.0.40 nem sequer são compiláveis, pelo que me fiquei pelo Kernel 2.0.39, aliás aconselhado pela team de desenvolvimento do Freesco. Isto é algo minucioso: colocar muitos módulos na ramdisk irá fazer com que o espaço por ela ocupada, adicionada ao Kernel e a outros ficheiros básicos, não caiba numa disquete (e este é um dogma do Freesco, pela própria natureza desta distribuição); por outro lado, colocar módulos a menos não permitiria inicializar coisas tão básicas como...a rede.
Este balanceamento do que colocar, ou não, na disquete de arranque, é de certa forma penoso. Pelo que optei por explorar também o modo de arranque (igualmente via máquina VM-ware) em CD-ROM: aí poderão ser colocadas toneladas de aplicações úteis.
O CD-ROM aliado com a potencialidade de uma máquina com alguma memória RAM (128 kb são suficientes!) permitirá correr um leque apreciável de aplicações, das quais destaco:

• Apache
• Admin web-server
• ssh / telnet server
  
• ftp server
• Samba server
• MTA server
• Squid
• dhcpd (DHCP server)
  
• phpsysinfo
  

Feitas as contas, com menos de 100 Mb consegui ter uma distribuição capaz de servir uma SOHO (Small-Office Home-Office) com cerca de 20 empregados, protegida pelo arranque de emergência em CD-ROM e não usando discos (utilizando-se uma disquete para guardar algumas informações de configuração).
O próximo passo seria o de descarregar as configurações via NFS (ou por ftp, usando-se a aplicação nativa snarf) para evitar a utilização de disquetes, algo obsoletas nos dias que correm.

Isto é apenas um simulador que permite verificar a consistência dos reboots rapidamente, sem ter que re-iniciar enúmeras vezes o seu PC de desenvolvimento. Caso esteja a fazer testes exaustivos num PC que espelhe a realidade da firewall que pretende instalar (usando o Freesco), a utilização do VM-ware torna tudo mais fácil e rápido de explorar.

Como nota final: fiquei um pouco decepcionado com a lentidão do PC enquanto corria este peso médio, ou direi mesmo -- leve. O VMware-Player não tem o desempenho na preempção (preemtive Windows kernel scheduling) que eu experimentei com outras máquinas virtuais. A razão para esta lentidão é ainda, para mim, desconhecida. Mas ainda assim, em vez de utilizar a minha máquina de acesso à internet 24x7 (i.e., permamente ligada) para fazer experiências, utilizei esta máquina leão... é sempre mais seguro fazer testes de novas aplicações separadamente, para evitar soluços no acesso (permanente) à internet.

Experimentem, vale a pena.

Já falei nas qualidades impressionantes que o VM-Player da VMware permite fazer. Como efeito visual interessante podem ver o meu computador pessoal a correr 2 máquinas Linux: uma distribuição Debian Sarge (em cima) e uma máquina Freesco (em baixo).

A box Debian está preparada com X (nesta foto apenas vêem os logs e terminais de texto) e tenho lá Openwebmail a funcionar como agregador de POP3. A máquina virtual está equipada com placa de som e leitor de disquetes.

A máquina virtual Freesco está equipada com leitor de CDs e apenas uma placa de rede (teria mais interesse usar duas placas para poder simular o routing de 2 redes, mas assim também simula uma leased line). Tem cerca de 500 Mb em dois discos, sendo o segundo disco utilizado como servidor de desenvolvimento para aplicações da libc-5 utilizada pelo Freesco. Fiz o fine-tunning desta máquina, alterando a ramdisk que vem no Freesco v032 e o Kernel -- para suportar nativamente ext2, desmontar os discos de forma limpa (mount /dev/hda1 /mnt/bootdev -n -o ro,remount é executado no rc_shutdown) e sobretudo detectar os discos e partições convenientemente. Artilhei o Kernel para suportar nfs (como cliente) e qual o meu espanto, funcionou à primeira. O Samba-client não funcionou, deduzo que por limitação da aplicação 2.0.x (ou da aplicação pela utilização que faz das primitivas do Kernel). Finalmente, a ramdisk ficou de facto algo espaçosa (adicionei o tftp-client e o e2fsck -- sempre útil e chamado aquando do arranque, para verificar a consistência dos file-systems). Portanto, ultrapassei o dogma do Freesco: caber numa disquete. Mas não me importo: as disquetes são objectos do século passado, e o meu próximo passo é pôr o Freesco num CD-bootable (já vi que funciona, mas falta knoppixar esta distro de forma algo profunda.) É que mesmo com um Kernel tão antigo, com os módulos apropriados (e isto consegue ser uma dôr de cabeça -- os módulos foram recompilados para o Kernel 2.0.39) uma série de possibilidades se abrem para arrancar com o sistema: a mais básica é usar o próprio snarf (ftp://local-net.somewhere/main-parts.tgz) para descarregar os binários vitais, evitando a utilização de um disco. Passaria a correr tudo a partir de memória, o que é bom para quem tenha preocupações de consumo de electricidade. A mais consistente parece-me ser o tftp, uma vez que exige menos parâmetros de configuração (nem sequer é preciso password para descarregar a tralha necessária para a máquina arrancar.)

Experimentem correr estas 2 máquinas no vosso computador, ficarão espantados ao verificar que o ambiente Windowzed corre perfeitamente em paralelo (embora o balanceamento entre as máquinas em termos de carga relativa dependa fortemente das aplicações que lá correm -- isto é substancialmente pior do que o User-mode Linux, mas, por outro lado, muito mais rápido de pôr a funcionar consistentemene.)

O melhor da simplicidade do Freesco: no ambiente controlado das máquinas virtuais os developers de Freesco poderão mais facilmente testar as suas aplicações e pacotes sem danificar o router original, ou ter que correr uma máquina com Zipslack (que é um pouco penoso).
Em contraste com esta simplicidade, aconselho vivamente a darem uma espreitadela na fabulosa distribuição Debian Sarge, que é o paraíso para todos os administradores de sistema -- poupa tempo na configuração e updates de segurança. E porque tempo é dinheiro, é uma mais valia ter estas duas distros tão catitas a correr ao mesmo tempo. Para os seguidores de Linux, como eu.