 |
| Bellacosa Mainframe e o sistema de arquivos linux |
☕ Um Café no Bellacosa Mainframe
O Sistema de Arquivos Linux Explicado Para um Programador COBOL Padawan
Muito Além do /home e do /etc: Como Pensar Como um Engenheiro DevOps, Entender a Filosofia "Everything is a File" e Descobrir as Semelhanças Entre Linux, IBM z/OS e os Grandes Data Centers do Mundo
"No Linux, cada diretório tem um propósito. No Mainframe, cada Dataset também. O profissional que entende essa filosofia deixa de decorar comandos e começa a compreender a arquitetura."
Introdução
Se existe uma característica comum entre os grandes profissionais de tecnologia, ela não é saber centenas de comandos de memória nem decorar parâmetros obscuros de configuração.
O verdadeiro diferencial é compreender como os sistemas foram projetados.
Quando um programador COBOL começa a estudar Linux, normalmente acontece algo curioso.
Ele abre um terminal, executa:
ls /
e aparece algo parecido com isto:
bin
boot
dev
etc
home
lib
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var
A primeira reação costuma ser:
"Quem inventou essa bagunça?"
Mas a resposta é exatamente o contrário.
Não existe bagunça alguma.
Existe uma organização extremamente rigorosa.
Cada diretório possui uma finalidade específica.
Cada arquivo está onde deveria estar.
Essa organização é resultado de mais de cinquenta anos de evolução dos sistemas UNIX e Linux.
Curiosamente, quem já trabalhou com IBM Mainframe possui uma enorme vantagem.
Por quê?
Porque o z/OS também foi construído sobre uma filosofia semelhante:
cada recurso possui um lugar definido, cada componente possui uma responsabilidade e a organização vale mais do que a improvisação.
É exatamente isso que iremos explorar neste café.
A filosofia antes dos comandos
Um erro muito comum entre iniciantes é querer aprender Linux decorando comandos.
ls
pwd
cd
mkdir
grep
find
chmod
systemctl
Isso é importante.
Mas não é suficiente.
Imagine entregar um martelo para alguém.
Ele pode aprender a usar o martelo.
Mas isso não significa que saiba construir uma casa.
O mesmo acontece com Linux.
Os comandos são ferramentas.
O sistema de arquivos é a arquitetura da casa.
A metáfora da casa
A imagem apresentada faz uma analogia fantástica.
Imagine que o computador é uma casa.
Existe uma porta principal.
Existem quartos.
Existe uma garagem.
Existe um depósito.
Existe uma oficina.
Existe um escritório.
Você não guarda ferramentas dentro da geladeira.
Também não coloca roupas dentro da caixa de correio.
Cada ambiente possui uma função.
Linux funciona exatamente assim.
Tudo começa no diretório raiz
/
Esse caractere é conhecido como Root Directory.
Aqui aparece uma das primeiras confusões dos iniciantes.
Muitos pensam que:
/
é o mesmo que
/root
Não é.
São coisas completamente diferentes.
O símbolo
/
representa a raiz da árvore inteira.
Já
/root
é apenas a pasta pessoal do usuário administrador.
É exatamente como dizer que:
"O Brasil"
não é a mesma coisa que
"Brasília".
Uma coisa contém a outra.
Uma única árvore
No Windows estamos acostumados com letras.
C:
D:
E:
Cada disco possui sua própria árvore.
Linux faz diferente.
Existe apenas uma árvore.
/
Todos os discos são conectados em algum ponto dessa árvore.
Por exemplo.
Um SSD adicional pode ser montado em
/dados
Um pendrive pode aparecer em
/media
Um NAS pode ser montado em
/mnt/storage
Tudo pertence ao mesmo sistema.
Essa decisão torna a administração muito mais elegante.
O diretório /home
Na imagem, o /home representa os quartos da família.
É uma comparação perfeita.
Ali vivem os usuários.
Exemplo:
/home/joao
/home/maria
/home/vagner
Cada usuário possui seus documentos.
Downloads.
Projetos.
Fotos.
Scripts.
Repositórios Git.
VS Code.
Configurações pessoais.
Comparando com Windows
C:\Users\Joao
é praticamente equivalente a
/home/joao
Comparando com IBM Mainframe
No z/OS USS (UNIX System Services), cada usuário também possui um diretório HOME.
Exemplo:
/u/USER01
ou
/home/user01
Ou seja...
Mesmo no mundo Mainframe existe esse conceito.
O diretório /etc
Se existisse um cérebro da configuração do Linux, seria este.
/etc
A imagem chama de livro de regras.
Excelente definição.
Ali ficam praticamente todas as configurações do sistema.
Não são programas.
São parâmetros.
Arquivos famosos
passwd
/etc/passwd
Lista usuários.
shadow
/etc/shadow
Senhas criptografadas.
hosts
/etc/hosts
Tabela local de nomes.
Muito usada por desenvolvedores.
resolv.conf
Define DNS.
ssh
Configuração do servidor SSH.
systemd
Serviços do sistema.
Analogia Mainframe
Quem administra z/OS conhece o PARMLIB.
Lá ficam dezenas de parâmetros essenciais do sistema operacional.
No Linux, esse papel é desempenhado principalmente pelo /etc.
O diretório /var
VAR significa:
Variable.
São dados que mudam constantemente.
A imagem representa um depósito.
Correto.
Mas podemos aprofundar.
Ali encontramos:
logs
cache
spool
mail
bancos de dados
filas
O lugar favorito do administrador
Quando alguma aplicação falha...
Para onde todo administrador corre?
/var/log
Ali estão os registros do sistema.
Sem logs não existe investigação.
Sem investigação não existe diagnóstico.
Sem diagnóstico não existe solução.
Exemplo real
Servidor Apache.
/var/log/apache2
Servidor NGINX.
/var/log/nginx
Jenkins.
/var/log/jenkins
Docker
/var/lib/docker
PostgreSQL
/var/lib/postgresql
Analogia Mainframe
No z/OS fazemos exatamente isso.
Quando um JOB falha procuramos:
JESMSGLG
JESJCL
JESYSMSG
SYSOUT
SYSLOG
OPERLOG
SMF
A lógica é exatamente igual.
O diretório /tmp
A famosa área temporária.
Programas criam arquivos provisórios.
Compiladores armazenam dados temporários.
Editores também.
Arquivos antigos normalmente são removidos automaticamente.
Jamais coloque algo importante aqui.
O diretório /root
Outra confusão clássica.
Não é a raiz.
É apenas a casa do administrador.
Assim como:
/home/joao
pertence ao João,
/root
pertence ao root.
O diretório /usr
A imagem chama de oficina.
Gostei muito dessa comparação.
Ali vivem:
programas
bibliotecas
manuais
executáveis
documentação
/usr/bin
Ferramentas.
git
python
java
awk
grep
curl
find
/usr/lib
Bibliotecas.
Semelhante às DLLs do Windows.
/usr/share
Documentação.
Temas.
Ícones.
Arquivos compartilhados.
/usr/local
Programas instalados manualmente.
Muito utilizado por administradores.
Diretórios que a imagem não mostra
Agora vamos além.
/boot
Arquivos usados durante a inicialização.
Kernel.
GRUB.
Initramfs.
Sem eles o sistema não inicia.
/dev
Talvez o diretório mais genial do Linux.
Ali ficam dispositivos.
/dev/null
/dev/zero
/dev/random
/dev/sda
/dev/tty
O HD é um arquivo.
O teclado também.
A impressora também.
A porta serial também.
"Everything is a File"
Essa é uma das ideias mais elegantes da computação.
No Linux quase tudo pode ser tratado como arquivo.
Isso simplifica enormemente o sistema operacional.
Por exemplo:
cat /proc/cpuinfo
Lemos informações do processador.
cat /proc/meminfo
Informações de memória.
cat /etc/hosts
Configuração.
cat /var/log/messages
Logs.
Sempre usando a mesma ferramenta.
/proc
Não existe fisicamente.
É um pseudo sistema de arquivos.
É criado pelo kernel.
Mostra informações em tempo real.
/sys
Outra interface do kernel.
Muito usada para hardware moderno.
/media
Pendrives.
DVD.
Cartões SD.
/mnt
Montagens temporárias.
Administradores usam frequentemente.
/opt
Softwares opcionais.
Muito comum para:
IBM
Oracle
SAP
WebSphere
Ferramentas corporativas.
O Linux e o IBM z/OS têm mais em comum do que parece
Um programador COBOL acostumado com JCL pode estranhar Linux no início, mas logo percebe vários paralelos:
Ambos valorizam organização e padronização.
Ambos utilizam permissões rigorosas.
Ambos registram eventos em logs.
Ambos permitem automação por scripts (Shell Script e JCL).
Ambos são usados em ambientes de missão crítica.
No z/OS, você prepara um JOB, define DD Statements, controla datasets e acompanha o resultado no SDSF. No Linux, cria scripts Shell, agenda tarefas com cron ou systemd timers, redireciona entradas e saídas e consulta logs no /var/log. O objetivo é o mesmo: automatizar processos com segurança e repetibilidade.
O olhar de um profissional DevOps
DevOps não é apenas instalar Docker ou usar Git.
É compreender como o sistema funciona.
Um pipeline de CI/CD depende diretamente da estrutura do sistema operacional.
Considere um servidor Jenkins:
A configuração da aplicação pode estar em /etc.
Os binários podem estar em /usr/bin.
Os dados persistentes em /var/lib/jenkins.
Os logs em /var/log/jenkins.
Arquivos temporários em /tmp.
Quando algo falha, o engenheiro não "chuta". Ele segue um método, conhece a função de cada diretório e sabe onde procurar.
Lições para um COBOL Padawan
Quem programa em COBOL já aprendeu algo muito importante: organização importa.
Você separa:
IDENTIFICATION DIVISION
ENVIRONMENT DIVISION
DATA DIVISION
PROCEDURE DIVISION
Cada seção possui uma finalidade.
O Linux segue exatamente a mesma filosofia.
Misturar configurações com logs, executáveis e dados de usuários seria tão ruim quanto escrever um programa COBOL inteiro dentro da PROCEDURE DIVISION sem definir arquivos, variáveis ou estruturas.
Conclusão
A imagem da casa é uma excelente porta de entrada para compreender o sistema de arquivos Linux, mas ela é apenas o primeiro passo. Por trás dessa analogia existe uma arquitetura refinada, construída ao longo de décadas, que prioriza organização, modularidade e previsibilidade.
Para um programador COBOL Padawan, essa forma de pensar não é novidade. O mundo IBM Mainframe sempre valorizou ambientes bem estruturados, datasets organizados, bibliotecas especializadas, parâmetros centralizados e processos automatizados. Linux compartilha a mesma essência, apenas utilizando outra terminologia e outras ferramentas.
O grande ensinamento não é decorar que /etc guarda configurações ou que /var/log contém logs. O verdadeiro aprendizado é entender que cada componente do sistema tem uma responsabilidade clara. Essa disciplina reduz erros, facilita a manutenção e torna possível administrar desde um pequeno servidor até um ambiente com milhares de máquinas.
Quando você compreender a filosofia por trás da árvore de diretórios, deixará de enxergar o Linux como uma lista de comandos e passará a vê-lo como uma plataforma de engenharia. É exatamente essa mudança de mentalidade que transforma um iniciante em um profissional preparado para trabalhar com DevOps, Cloud, Containers, Kubernetes e até mesmo com a integração entre Linux e IBM Z.
Porque, no fim das contas, seja em um servidor Linux, em um cluster Kubernetes ou em um IBM z/OS que processa milhões de transações bancárias por dia, a regra continua a mesma:
Os melhores engenheiros não decoram caminhos; eles entendem a arquitetura que dá sentido a cada caminho.
