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.