Sistemas Operacionais II: infelizmente, havia Windows
Um resumo dos conceitos de Sistemas Operacionais II passando por processos, escalonamento, virtualização, diagnóstico, serviços, SFC, DISM, chkdsk e Active Directory, com alguns paralelos inevitáveis com Unix e POSIX.
Este provavelmente será o único post sobre Windows e Windows Server deste blog.
Não por falta de assunto.
Por infelicidade do destino.
A disciplina de Sistemas Operacionais II da minha faculdade resolveu concentrar boa parte do conteúdo no ecossistema da Microsoft. Meu habitat natural fica consideravelmente mais perto de Unix, então eu teria preferido passar essas horas entre processos, sinais, permissões e syscalls. A grade curricular, contudo, decidiu que Active Directory e Windows Server eram um destino inevitável, e contra a ementa infelizmente ainda não existe kill -9.
Windows, afinal, continua extremamente presente em desktops domésticos e ambientes corporativos.
Se me permitem uma explicação estatística que definitivamente não passou por revisão por pares, a média sempre tende para baixo.
Ainda assim, existe uma parte boa nisso. Por trás do Gerenciador de Tarefas, svchost.exe, Active Directory e das várias ferramentas que o Windows possui para tentar reparar o próprio Windows, os conceitos continuam sendo conceitos de sistemas operacionais.
Processos continuam sendo processos. Escalonamento continua sendo escalonamento. Memória continua tendo limites físicos. Virtualização continua dependendo de hardware. Autenticação continua sendo uma tentativa organizada de responder à pergunta “quem é você e por que eu deveria acreditar nisso?”.
Meu domínio técnico tende muito mais para Unix, Linux e ferramentas alinhadas ao padrão POSIX do que para administração de Windows. Por isso, ao longo do texto, vou fazer alguns paralelos com esse mundo. Não porque tudo tenha um equivalente perfeito, mas porque comparar abstrações conhecidas com abstrações novas é uma forma bem melhor de estudar do que decorar uma coleção de nomes de serviços da Microsoft e torcer para que eles apareçam na prova na mesma ordem.
O sistema operacional está no meio de tudo
A definição mais útil apresentada na matéria é simples: o sistema operacional atua como uma camada entre o hardware e os aplicativos.
Parece uma frase produzida especificamente para uma questão de múltipla escolha, mas é uma abstração muito boa.
Um programa normalmente não precisa saber como programar o controlador NVMe, configurar diretamente uma interrupção do processador, administrar tabelas de páginas ou conversar com uma placa de rede no nível elétrico. Ele pede alguma coisa ao sistema operacional, e o sistema operacional expõe interfaces que escondem boa parte dessa complexidade.
No mundo POSIX isso fica particularmente claro porque muita coisa vira uma chamada de sistema com um nome razoavelmente direto. Abrir um arquivo pode começar em open(). Criar um processo pode envolver fork(). Substituir a imagem de um processo passa pela família exec(). Esperar um processo filho pode usar wait().
A ideia é a mesma no Windows, ainda que a API e o desenho interno sejam diferentes: aplicações usam abstrações fornecidas pelo sistema em vez de pilotar o hardware diretamente.
O sistema operacional administra CPU, memória, dispositivos, arquivos, processos, usuários, permissões e comunicação entre componentes. É uma camada de mediação, proteção e organização.
Boa parte da elegância de um SO está em fazer máquinas extremamente complicadas parecerem apenas um conjunto razoável de arquivos, processos, sockets e chamadas.
Multiusuário é mais do que várias contas na tela de login
Um sistema multiusuário permite que diferentes usuários compartilhem a mesma máquina mantendo identidades, permissões e contextos separados.
Isso significa que o sistema precisa saber quem está executando determinado processo, quais arquivos aquela identidade pode acessar, quais recursos pode modificar e até onde vai seu privilégio.
Em Unix isso é quase impossível de ignorar porque UID, GID, usuário proprietário e grupo aparecem em toda parte. O modelo tradicional de permissões rwx é simples, às vezes simples demais, mas pedagógico. Quando não basta, entram ACLs, capabilities e outros mecanismos.
No Windows, o modelo é mais centrado em tokens de acesso, SIDs, ACLs e uma infraestrutura de segurança mais verbosa. O efeito prático continua sendo semelhante: dois processos podem executar o mesmo programa e ainda assim possuir poderes completamente diferentes porque pertencem a identidades diferentes.
Isso é importante para entender a distinção entre um processo executado por um usuário normal e um processo executado como SYSTEM.
SYSTEM não é apenas “mais um usuário”. É uma identidade interna altamente privilegiada usada por componentes do próprio Windows. Se eu precisasse criar um paralelo didático com Unix, pensaria em algo mais próximo de um serviço executado com privilégios muito elevados do que de uma sessão comum de usuário.
O paralelo não é perfeito, mas ajuda mais do que decorar “SYSTEM = importante”.
Multitarefa preemptiva: o programa não decide sozinho quando sair da CPU
Em um sistema moderno, dezenas ou centenas de processos parecem estar executando ao mesmo tempo.
Parte disso é paralelismo real, porque processadores possuem vários núcleos. Parte disso é alternância extremamente rápida entre tarefas.
O componente responsável por decidir quem recebe tempo de CPU é o escalonador.
Em um sistema de multitarefa preemptiva, o sistema operacional pode interromper uma tarefa e entregar a CPU a outra. O programa não precisa cooperar voluntariamente.
Esse detalhe separa um sistema moderno de uma situação em que cada aplicação precisaria dizer educadamente “terminei por agora, outra pode executar”.
Unix, Linux, Windows e praticamente qualquer sistema de propósito geral moderno trabalham com preempção em algum nível. O kernel mantém controle sobre o processador, agenda tarefas e troca contextos conforme suas políticas internas.
A ideia da matéria é menos sobre decorar algoritmos específicos de escalonamento e mais sobre entender que o sistema operacional divide o recurso CPU entre processos concorrentes.
Quando alguém diz que “vários programas estão executando simultaneamente”, o que existe por baixo dessa frase é uma combinação de paralelismo, concorrência, interrupções, prioridades e escalonamento.
Processos têm genealogia
Um processo pode criar outros processos, que por sua vez podem criar outros.
Isso forma uma árvore de relacionamento entre processo pai e processo filho.
No mundo Unix essa genealogia faz parte do modelo mental desde cedo. Um shell inicia um comando, o comando pode iniciar outro processo, e utilitários como ps, pstree e /proc ajudam a visualizar essa relação.
No Windows, uma ferramenta particularmente boa para isso é o Sysinternals Process Explorer.
Ele mostra processos em uma árvore hierárquica, o que é muito mais informativo do que uma lista plana de executáveis. Quando um aplicativo abre workers, helpers, renderers ou subprocessos auxiliares, a árvore deixa claro de onde aquilo veio.
O Process Explorer também diferencia duas operações importantes.
Kill Process encerra apenas o processo selecionado.
Kill Process Tree encerra o processo selecionado e os seus descendentes.
O paralelo com Unix seria pensar na diferença entre enviar um sinal para um PID específico e trabalhar com um grupo ou árvore de processos. Não é uma equivalência exata de implementação, mas conceitualmente a pergunta é parecida: quero matar um processo ou todo o conjunto que nasceu a partir dele?
É uma distinção útil em aplicações que geram vários subprocessos, especialmente quando matar apenas o processo principal deixa parte da bagunça viva em segundo plano.
Handles e DLLs: processos vivem cercados de dependências
O Process Explorer também permite inspecionar DLLs e handles associados a um processo.
Uma DLL é uma biblioteca carregável dinamicamente. Isso lembra naturalmente os objetos compartilhados .so de sistemas Unix, embora os formatos, carregadores e APIs sejam diferentes.
Já um handle é uma referência usada pelo processo para acessar algum objeto gerenciado pelo sistema. Pode representar arquivos, eventos, processos, threads, chaves do Registro, pipes e vários outros recursos.
Em Unix, muitos recursos são expostos através de descritores de arquivo, o que cria uma uniformidade extremamente conveniente. Arquivo, pipe, socket e terminal acabam frequentemente representados por inteiros manipulados por APIs parecidas.
O Windows preferiu um universo maior de tipos de objeto e handles.
Não vou fingir surpresa.
O ponto útil é que, quando um programa “está segurando” um arquivo, uma chave ou outro recurso, ferramentas de inspeção ajudam a descobrir exatamente quem mantém aquela referência aberta.
Esse tipo de diagnóstico é muito mais interessante do que reiniciar o computador e fingir que aprendemos alguma coisa.
VirusTotal não é um oráculo
O Process Explorer pode integrar resultados do VirusTotal.
Um valor como:
0/76
significa que nenhum dos 76 mecanismos que responderam marcou aquele hash como malicioso naquele momento.
Só isso.
Não significa que o arquivo seja matematicamente seguro. Não significa que nenhum comportamento malicioso exista. Não significa que o arquivo tenha recebido um certificado cósmico de inocência.
É apenas um sinal.
Malware novo pode ainda não ser detectado. Um arquivo pode mudar de hash. Um mecanismo pode errar. Um programa legítimo pode se comportar de forma perigosa dependendo de contexto e permissões.
Segurança raramente oferece valores booleanos confortáveis.
O Gerenciador de Tarefas é a versão civilizada
Para investigações mais simples, o Gerenciador de Tarefas já resolve bastante coisa.
A aba Processos mostra consumo por aplicação e processo. A aba Desempenho mostra o comportamento geral de CPU, memória, disco e rede. A aba Inicializar controla programas que sobem automaticamente durante o logon.
O raciocínio de diagnóstico mais útil é simples.
Se a máquina está lenta, primeiro descubra qual recurso está saturado. Depois procure qual processo está associado à saturação.
CPU permanentemente próxima de 100% sugere gargalo de processamento. Disco continuamente ocupado pode apontar para I/O. Memória esgotada pode gerar paginação pesada. Rede saturada pode limitar aplicações dependentes de tráfego.
Um pico temporário não é necessariamente um problema.
Abrir um programa pesado, compilar um projeto ou descompactar um arquivo pode consumir 100% de um recurso por alguns segundos. Isso pode significar apenas que o hardware está finalmente justificando a compra.
O problema costuma estar no consumo sustentado acompanhado de impacto perceptível.
O curioso caso do System Idle Process
O Windows possui um excelente teste de interpretação chamado System Idle Process.
Se ele aparece com 90% de CPU, isso não significa que algum processo misterioso está roubando 90% do processador.
Significa aproximadamente o contrário.
Valor alto indica tempo ocioso da CPU.
Em termos práticos:
System Idle alto = CPU livre
System Idle baixo = CPU ocupada
É uma abstração estranha à primeira vista, mas coerente: o “processo ocioso” representa justamente a parte do tempo em que não havia trabalho real para executar.
Unix costuma expor essa ideia de maneira menos teatral através de métricas de idle em ferramentas como top, htop, vmstat e afins.
Alguns processos que apareceram nas práticas
A matéria também usou alguns executáveis do Windows como exemplos de funções de sistema.
| Processo | Papel geral |
|---|---|
MsMpEng.exe | mecanismo do Microsoft Defender Antivirus |
SearchIndexer.exe | indexação usada pelas pesquisas do Windows |
RuntimeBroker.exe | intermedia determinadas permissões e operações de aplicativos |
svchost.exe | hospeda serviços do Windows |
O importante não é decorar uma coleção infinita de nomes terminados em .exe.
O modelo mental mais útil é perguntar quem iniciou o processo, em qual contexto ele executa, quais recursos consome, quais subprocessos criou e quais objetos mantém abertos.
Esse raciocínio funciona no Windows, no Linux, em BSD e em praticamente qualquer sistema que não tenha sido projetado especificamente para punir administradores.
svchost.exe: vários processos, uma ideia relativamente sensata
Quem abre o Gerenciador de Tarefas encontra várias instâncias de svchost.exe.
Isso é normal.
O svchost.exe funciona como um hospedeiro para serviços, especialmente serviços implementados em DLLs. Diferentes serviços podem ser agrupados ou separados em processos distintos, o que ajuda a melhorar isolamento, segurança e gerenciamento de falhas.
No mundo Unix, o modelo costuma ser mais visualmente direto: um daemon normalmente aparece como seu próprio executável ou serviço gerenciado por algo como systemd, OpenRC ou outro init.
No Windows, parte dessa estrutura fica encapsulada em hosts genéricos.
Não é necessariamente uma ideia ruim. Só é menos transparente para alguém acostumado a olhar systemctl status e descobrir imediatamente qual unidade está sendo executada.
A existência de várias instâncias de svchost.exe, portanto, não é automaticamente suspeita.
A existência de um svch0st.exe perdido em uma pasta aleatória talvez mereça mais carinho investigativo.
Encerrando processos pela linha de comando
Quando sabemos o nome do executável e queremos encerrá-lo pela linha de comando, o material trabalhou com:
taskkill /IM nomedoprograma.exe /F
/IM indica o nome da imagem. /F força o encerramento.
O paralelo POSIX quase se escreve sozinho: kill, pkill e killall cumprem papéis semelhantes, com a vantagem de que o ecossistema Unix teve a gentileza histórica de usar nomes razoavelmente curtos.
Forçar encerramento continua sendo uma ferramenta de último recurso.
Matar um processo interrompe execução. Não garante flush de buffers, fechamento elegante de arquivos, commit de estado ou limpeza de recursos feita pela própria aplicação.
Às vezes é necessário.
Às vezes também é a forma mais rápida de transformar um problema temporário em corrupção persistente.
Desabilitar uma conta não é excluir uma conta
Outro comando abordado foi:
net user NomeDeUsuario /active:no
Isso desabilita a conta sem removê-la.
Para reativar:
net user NomeDeUsuario /active:yes
O conceito administrativo é simples: suspender acesso não precisa significar destruir identidade, perfil e arquivos.
Em Unix, a mesma intenção pode ser implementada de várias formas, como bloquear senha, alterar shell de login ou usar ferramentas específicas da distribuição. Não existe uma única equivalência perfeita porque política de contas varia bastante.
O importante é separar duas operações diferentes: impedir autenticação e apagar o usuário.
Parece óbvio até alguém escolher a segunda opção para resolver um afastamento temporário de três meses.
msinfo32: inventário em vez de diagnóstico pontual
A ferramenta Informações do Sistema, acessível com:
msinfo32
reúne dados sobre hardware, BIOS, memória, recursos e configuração do ambiente.
Ela é útil quando a pergunta não é “qual processo está usando CPU agora?”, mas “o que exatamente existe nesta máquina?”.
No Unix, essa função acaba distribuída entre ferramentas como lscpu, lsblk, lspci, lsusb, dmidecode, uname, /proc e /sys.
É uma diferença cultural interessante.
Windows tende a concentrar muita informação em painéis e utilitários integrados.
Unix tende a responder “claro, aqui estão oito comandos pequenos, agora combine-os como quiser”.
Eu prefiro a segunda abordagem, o que provavelmente explica por que este texto precisa explicar a primeira.
Sistemas de arquivos são uma abstração gigantesca fingindo ser simples
Para o usuário, um arquivo parece apenas existir em algum caminho.
No Windows:
C:\Users\alguem\Documents
No Unix:
/home/alguem/Documents
Por baixo disso há metadados, permissões, estruturas de diretório, blocos, journaling, cache, operações de leitura e escrita e regras de consistência.
O sistema operacional oferece interfaces para criar, abrir, remover e modificar arquivos sem que cada aplicação precise conhecer a geometria física do armazenamento.
Esse é um dos grandes triunfos das abstrações de sistemas operacionais.
O outro é termos passado décadas fingindo que caminhos com letra de unidade são normais.
No mundo POSIX, a árvore de diretórios parte de uma única raiz /, e volumes podem ser montados dentro dela. No Windows, letras de unidade continuam sendo parte do modelo tradicional, embora o NT internamente possua uma organização bem mais rica do que a interface sugere.
A matéria não exige esse mergulho, mas a comparação ajuda a perceber que “sistema de arquivos” é uma interface lógica, não apenas “a pasta onde ficam os documentos”.
32 bits, 64 bits e os famosos 4 GB
A distinção entre 32 e 64 bits apareceu principalmente pelo limite de endereçamento.
Com 32 bits, temos 2^32 combinações possíveis, cerca de 4,29 bilhões.
Se cada endereço representa um byte, isso produz aproximadamente 4 GiB de espaço de endereçamento.
Daí vem a regra didática de que sistemas de 32 bits ficam limitados a algo em torno de 4 GB de memória endereçável.
A realidade é mais cheia de detalhes. PAE permitiu a determinados sistemas de 32 bits endereçar mais memória física. Sistemas reservam partes do espaço para kernel e dispositivos. Processos individuais também podem ter limites próprios.
Mas como modelo inicial, a transição para 64 bits aumenta enormemente o espaço de endereçamento possível.
Isso não significa que um sistema de 64 bits “cria” memória.
Ele apenas consegue representar uma faixa muito maior de endereços.
Infelizmente ainda não implementaram malloc() diretamente no cartão de crédito.
Virtualização: computadores imaginários que continuam pagando aluguel para o hardware real
Virtualização permite executar máquinas virtuais sobre recursos fornecidos por uma máquina física.
Uma VM recebe CPUs virtuais, memória, armazenamento, interfaces de rede e outros dispositivos simulados ou paravirtualizados.
A camada que gerencia isso é o hypervisor.
A classificação tradicional divide hypervisores em Tipo 1 e Tipo 2.
| Tipo | Ideia |
|---|---|
| Tipo 1 | executa diretamente sobre a plataforma de hardware |
| Tipo 2 | depende de um sistema operacional host |
É uma classificação útil didaticamente, ainda que implementações modernas consigam borrá-la bastante.
KVM é um bom exemplo. Em Linux, o próprio kernel fornece capacidades de virtualização e ferramentas em espaço de usuário constroem VMs em cima disso. Chamar tudo apenas de “Tipo 1” ou “Tipo 2” às vezes simplifica demais uma arquitetura muito mais interessante.
No Windows, Hyper-V também integra profundamente a virtualização ao sistema.
Na matéria, o ponto importante é entender a diferença conceitual entre um hypervisor que forma a camada principal sobre o hardware e outro que executa como aplicação sobre um host existente.
Por que usar máquinas virtuais?
Virtualização traz isolamento, consolidação, testes, snapshots e a possibilidade de executar vários sistemas sobre o mesmo hardware.
É particularmente útil quando queremos experimentar sem tocar diretamente no host.
Essa é uma das poucas áreas em que usuários de Windows e Unix conseguem concordar rapidamente: destruir uma VM é muito mais agradável do que destruir a própria estação de trabalho.
Virtualização, porém, não elimina o hardware físico.
Quatro VMs com 8 GB de RAM continuam precisando encontrar essa memória em algum lugar.
A abstração é poderosa.
A abstração não fabrica DIMMs.
Não entregue toda a RAM para a VM
Durante a configuração de uma máquina virtual existe sempre a tentação de alocar o máximo possível.
Se a máquina possui 16 GB, alguém inevitavelmente pensa em entregar 16 GB para o guest.
O pequeno problema é que o host continua existindo.
O sistema operacional hospedeiro, o hypervisor, o cache de arquivos e os demais programas também precisam de memória.
A alocação deve equilibrar as necessidades do guest e do host.
Em Linux com KVM, em VirtualBox, em VMware ou em Hyper-V, a física continua igualmente inconveniente.
Dar todos os recursos para a VM é como emprestar a casa inteira e depois descobrir que você também mora nela.
Snapshot não é backup
Snapshots são excelentes para registrar o estado de uma VM antes de instalar software, modificar configuração ou executar um experimento.
Se algo der errado, podemos voltar ao estado anterior.
Mas snapshot não é automaticamente backup.
Se VM e snapshots estão no mesmo disco e o disco morre, todos podem participar do mesmo funeral.
Esse conceito vale muito além de virtualização.
Btrfs, ZFS, LVM e hypervisors oferecem snapshots excelentes, mas uma cópia armazenada no mesmo dispositivo não substitui estratégia de backup.
É um princípio tão universal que provavelmente deveria ser ensinado antes de qualquer interface gráfica.
SFC: algum arquivo do Windows quebrou
O System File Checker verifica arquivos protegidos do sistema.
O comando trabalhado na matéria foi:
sfc /scannow
Ele procura arquivos ausentes ou corrompidos e tenta restaurar versões corretas.
Conceitualmente, isso lembra verificações de integridade de pacotes que usuários Unix conhecem por ferramentas como rpm -V, debsums, bancos de integridade de pacotes ou sistemas declarativos que conseguem comparar o estado real com um estado conhecido.
A diferença é que o SFC está fortemente integrado ao mecanismo de proteção e recuperação de arquivos do Windows.
O problema começa quando a própria fonte usada para restaurar arquivos está corrompida.
É então que entra o DISM.
DISM: consertando a fonte usada para consertar o Windows
O Deployment Image Servicing and Management, ou DISM, trabalha com imagens e com o repositório de componentes do Windows.
O comando abordado foi:
DISM /Online /Cleanup-Image /RestoreHealth
Nesse contexto, /Online aponta para o sistema em execução, /Cleanup-Image seleciona operações relacionadas à imagem e /RestoreHealth tenta reparar corrupção no repositório.
A sequência estudada foi clara.
Primeiro:
sfc /scannow
Se o SFC não conseguir reparar:
DISM /Online /Cleanup-Image /RestoreHealth
Depois:
sfc /scannow
A lógica é boa.
O SFC tenta consertar arquivos instalados.
O DISM tenta consertar a fonte usada para consertar esses arquivos.
É como descobrir que o mecânico não consegue reparar seu carro porque a caixa de ferramentas do mecânico também precisa de manutenção.
No mundo Linux essa situação costuma ser resolvida de forma diferente porque o modelo de pacotes e repositórios é outro. Muitas vezes reinstalar um pacote é suficiente para restaurar arquivos pertencentes a ele. Em sistemas declarativos, o estado desejado pode ser reconstruído a partir da configuração.
Nenhum modelo elimina corrupção.
Alguns apenas tornam mais claro de onde deve vir a cópia correta.
chkdsk: talvez o problema seja o disco
Quando o problema está no sistema de arquivos ou no armazenamento, entra o Check Disk.
O comando estudado foi:
chkdsk C: /r
O parâmetro /r procura setores defeituosos, tenta recuperar informações legíveis e inclui a correção lógica associada ao /f.
Em volumes do sistema, a verificação pode precisar ser agendada para a próxima inicialização porque o Windows não consegue desmontar livremente o volume em uso.
O paralelo Unix seria pensar em ferramentas como fsck, e2fsck e utilitários específicos de cada sistema de arquivos.
A comparação, porém, precisa de cuidado.
Ferramentas de verificação de filesystem não são intercambiáveis e muitas exigem que o volume esteja desmontado. Rodar reparos agressivos em um filesystem montado porque “parece com chkdsk” é uma excelente forma de criar material para um próximo post sobre recuperação de desastre.
Podemos resumir o escopo das ferramentas assim:
| Ferramenta | Foco principal |
|---|---|
SFC | arquivos protegidos do Windows |
DISM | imagem e repositório de componentes |
chkdsk | sistema de arquivos e mídia de armazenamento |
Executar todos aleatoriamente até alguma coisa melhorar ainda não constitui metodologia.
Embora seja um método bastante popular.
Ponto de restauração não é Redefinir o PC
Um Ponto de Restauração serve para voltar determinados componentes do sistema a uma configuração anterior.
É útil depois de um driver ruim, de alguma alteração problemática ou de certas atualizações.
A intenção é reverter estado do sistema sem simplesmente apagar os documentos do usuário.
Redefinir este PC é uma operação bem mais ampla. Dependendo da opção escolhida, o Windows pode reinstalar o sistema preservando arquivos pessoais ou removendo-os.
O material da disciplina trabalhou especificamente o cenário em que a redefinição retorna a máquina à configuração inicial apagando programas e arquivos.
O ponto conceitual é separar rollback de configuração de reinstalação ampla.
Em Unix, essa separação aparece em outros mecanismos. Um snapshot de Btrfs ou ZFS pode reverter estado do sistema. Uma reinstalação da distribuição é outra coisa. Restaurar /etc de um backup é outra coisa ainda.
Misturar todas essas operações sob a palavra “restaurar” é uma ótima maneira de apagar justamente o que a pessoa queria preservar.
Backup continua sendo backup
A regra mais útil é simples: recuperação de sistema e recuperação de dados são problemas diferentes.
Pontos de restauração existem para estado do sistema.
Backups existem para preservar dados.
Snapshots podem ajudar em ambos os casos dependendo do desenho, mas não substituem automaticamente uma estratégia de cópia independente.
Um arquivo excluído só pode ser recuperado de forma confiável se existir outra cópia em algum lugar ou se ainda houver dados recuperáveis no armazenamento.
Isso não é uma peculiaridade do Windows.
É uma peculiaridade da realidade.
Serviços: programas que trabalham quando ninguém está olhando
Um serviço é um componente projetado para executar em segundo plano realizando alguma função do sistema.
No Windows, esses componentes aparecem no Service Control Manager e em ferramentas como services.msc.
No mundo Unix moderno, o paralelo mais imediato são daemons e unidades de serviço gerenciadas por systemd, OpenRC, runit ou outro init.
O conceito é bastante parecido, embora a cultura de ferramentas seja diferente.
A matéria trabalhou vários serviços importantes.
| Serviço | Função |
|---|---|
DHCP Client (Dhcp) | obter e renovar IP, máscara, gateway e DNS |
User Profile Service (ProfSvc) | carregar e descarregar perfis de usuário |
Server (LanmanServer) | compartilhamento SMB de arquivos e impressoras |
| Print Spooler | gerenciar fila de impressão |
Windows Search (WSearch) | indexação usada nas pesquisas |
Windows Update (wuauserv) | detectar e coordenar atualizações |
Delivery Optimization (DoSvc) | cache e distribuição de conteúdo de atualização |
Diagnostic Policy Service (DPS) | detectar e diagnosticar problemas |
Windows Defender Firewall (mpssvc) | aplicar filtragem e regras de rede |
WLAN AutoConfig (WlanSvc) | gerenciar redes e perfis Wi-Fi |
A melhor maneira de estudar esse bloco não é decorar nomes.
É associar sintoma e função.
A impressora parou de imprimir
Se trabalhos entram na fila e ficam presos, o primeiro serviço óbvio para verificar é o Print Spooler.
Ele cuida da fila, dos trabalhos e da comunicação com o subsistema de impressão.
Em sistemas Unix, CUPS cumpre um papel comparável em muitos ambientes.
A diferença de nome é menos importante do que a abstração.
Existe uma fila de trabalhos, existe um componente responsável por gerenciá-la e existe uma série de pontos onde aquilo pode falhar.
Impressoras são uma das poucas tecnologias capazes de unir administradores de Windows e Linux em sofrimento genuinamente multiplataforma.
O computador não recebe endereço IP
Se a máquina não recebe automaticamente IP, máscara, gateway e DNS, o DHCP Client é um componente importante para investigar.
DHCP automatiza a configuração de rede.
Em Unix, clientes como dhclient, dhcpcd, NetworkManager ou systemd-networkd podem desempenhar esse papel dependendo da distribuição.
A abstração é a mesma: um cliente conversa com um servidor DHCP e obtém parâmetros de rede.
No Windows, se aparece um endereço 169.254.x.x, isso costuma indicar que o sistema caiu para APIPA porque não conseguiu obter uma configuração DHCP adequada.
É o equivalente elegante a dizer “ninguém me respondeu, então inventei um endereço local e espero que alguém perceba”.
O Wi-Fi sumiu
Se o computador não consegue localizar ou gerenciar redes sem fio, um dos serviços diretamente relacionados é o WLAN AutoConfig, WlanSvc.
Ele participa do gerenciamento de adaptadores, perfis e redes Wi-Fi.
No Linux, a cadeia pode envolver NetworkManager, wpa_supplicant, iwd, drivers e firmware.
O paralelo é útil porque deixa claro que “Wi-Fi” não é um único componente.
Existe hardware, driver, firmware, serviço de gerenciamento, autenticação e configuração de rede.
O Windows esconde parte disso atrás de uma interface mais integrada.
Linux normalmente expõe o suficiente para você descobrir exatamente qual peça está quebrada.
Às vezes isso é uma vantagem.
Às vezes você só queria conectar ao roteador.
DPS: o serviço que tenta descobrir por que outros componentes estão sofrendo
O Diagnostic Policy Service, DPS, ajuda o Windows a detectar e diagnosticar problemas relacionados a rede, disco, áudio, energia e outros componentes.
É parte da infraestrutura usada pelos mecanismos automáticos de solução de problemas.
Não é onisciente.
Se fosse, administradores de sistemas seriam uma lembrança histórica.
Automático e Manual não descrevem exatamente o estado atual
Serviços podem possuir diferentes tipos de inicialização.
No material, os dois mais importantes foram Automático e Manual.
Automático significa que o Windows pretende iniciar o serviço durante o boot ou pouco depois.
Manual significa que o serviço pode permanecer parado até que algum componente precise dele.
Isso é diferente de perguntar se o serviço está executando neste exato instante.
No systemd a distinção entre uma unidade habilitada e uma unidade ativa ajuda a construir um paralelo útil. enabled fala sobre política de inicialização. active fala sobre estado atual.
No Windows, o conceito é semelhante: modo de inicialização e estado do serviço não são a mesma propriedade.
É uma diferença pequena no papel e importante no diagnóstico.
E finalmente chegamos ao Active Directory
Se a primeira metade da matéria já estava bastante comprometida com Windows, a segunda encontrou uma maneira de colocar ainda mais Windows dentro do Windows.
O Active Directory Domain Services, AD DS, é um serviço de diretório usado para centralizar identidades e recursos de uma organização.
Ele organiza usuários, computadores, grupos e outros objetos, além de dar suporte a autenticação, autorização, políticas e descoberta de recursos.
Para alguém vindo de Unix, uma comparação aproximada seria imaginar uma infraestrutura que combina diretório, identidade, autenticação centralizada, políticas e descoberta de serviços de forma profundamente integrada ao ecossistema.
LDAP sozinho não é “o equivalente ao Active Directory”. Kerberos sozinho também não. DNS sozinho certamente não.
AD DS é justamente a integração dessas peças com uma camada administrativa própria.
É uma solução grande para um problema grande.
E, sendo Microsoft, vem acompanhada de nomes suficientes para justificar outro semestre.
Diretório não é apenas um banco de usuários
É fácil reduzir o Active Directory à frase “um banco de contas”.
Isso perde boa parte da ideia.
Um serviço de diretório representa objetos e relações dentro de uma organização.
Usuários, computadores, grupos e outros recursos passam a existir em uma estrutura consultável e administrável.
O AD DS também se integra a DNS, Kerberos, Group Policy e controladores de domínio.
O objetivo é permitir que identidade e política deixem de ser uma configuração local repetida em centenas de máquinas.
Administrar 500 computadores criando manualmente os mesmos usuários em cada um deles seria possível.
Também seria uma excelente justificativa para abandonar a carreira.
DNS: antes de autenticar, precisamos encontrar o servidor certo
O Active Directory depende fortemente de DNS.
DNS não serve apenas para traduzir nomes em endereços IP.
No AD, registros específicos permitem localizar serviços e controladores de domínio.
Antes de autenticar ou consultar determinados serviços, a máquina precisa descobrir onde eles estão.
No universo Unix, DNS também é infraestrutura básica, mas muitas implementações de identidade centralizada podem usar componentes menos acoplados entre si.
No AD, usar DNS “qualquer” de forma descuidada é uma ótima maneira de produzir sintomas estranhos e depois culpar a rede inteira.
A tradição de culpar DNS, aliás, é verdadeiramente multiplataforma.
Kerberos: prove quem você é sem entregar sua senha para cada serviço
O protocolo de autenticação destacado na matéria foi Kerberos.
A ideia central é trabalhar com tickets e criptografia de chave secreta.
De forma simplificada, o usuário se autentica e recebe credenciais que permitem solicitar tickets para serviços específicos. Esses tickets são apresentados aos serviços em vez de reenviar a senha repetidamente.
No ecossistema Unix, Kerberos não é estranho. Ele existe há décadas e pode ser integrado a LDAP, PAM, NFS e outros componentes.
A diferença é que no Active Directory ele faz parte do pacote padrão de identidade de domínio.
Isso torna o paralelo particularmente útil: Kerberos não é “uma tecnologia do Windows”. É um protocolo de autenticação que a Microsoft adotou e integrou fortemente ao AD.
Em outras palavras, até o Windows melhora quando rouba ideias boas de ambientes acadêmicos e Unix.
Domínios, árvores e florestas
A estrutura lógica do Active Directory usa uma terminologia curiosamente botânica.
Domínios organizam identidades e recursos dentro de um namespace e de limites administrativos.
Árvores conectam domínios relacionados.
Florestas agrupam uma ou mais árvores que compartilham informações fundamentais de diretório.
Dentro de domínios, Organizational Units, OUs, ajudam a organizar objetos e aplicar políticas.
A metáfora vegetal é estranha, mas pelo menos é consistente.
Domínio, árvore e floresta descrevem relações lógicas.
Eles não dizem necessariamente onde cada máquina está fisicamente.
Para isso entram Sites e sub-redes.
Estrutura lógica não é estrutura física
Essa distinção é uma das mais importantes do conteúdo.
A estrutura lógica responde como objetos do diretório estão organizados.
A estrutura física responde como a rede está distribuída e como os componentes se comunicam.
| Estrutura lógica | Estrutura física |
|---|---|
| Domínios | Sites |
| OUs | Sub-redes |
| Árvores | Topologia de comunicação |
| Florestas | Distribuição física da rede |
Um Site do Active Directory representa, em linhas gerais, uma ou mais sub-redes com boa conectividade entre si.
Isso ajuda o AD a tomar decisões melhores sobre autenticação, localização de controladores e replicação.
Sites não precisam espelhar domínios.
Uma empresa pode ter um domínio único distribuído em várias cidades.
Também pode existir um Site contendo recursos de mais de um domínio.
Misturar estrutura lógica e física é como insistir que a árvore de diretórios de um servidor precisa imitar a planta do prédio.
São problemas diferentes.
Controladores de Domínio
O Domain Controller, DC, executa o Active Directory Domain Services, armazena a base do diretório e participa de sua replicação.
Ter mais de um controlador aumenta disponibilidade.
Se existe apenas um DC e ele desaparece, autenticação, consultas e outros serviços podem sofrer bastante.
Com múltiplos controladores, a infraestrutura consegue continuar atendendo usuários enquanto os dados são replicados entre servidores.
No mundo Unix, alta disponibilidade para identidade centralizada também exige redundância, seja em LDAP, Kerberos, DNS ou outros componentes.
A diferença é que o AD empacota grande parte dessa experiência em uma arquitetura mais integrada.
É conveniente.
Também significa que quando a integração quebra, os sintomas conseguem aparecer em vários lugares ao mesmo tempo, o que é sempre divertido para quem está de plantão.
Sites ajudam a controlar replicação
Imagine uma empresa com escritórios em São Paulo, Rio de Janeiro e Curitiba.
Essas unidades podem participar do mesmo domínio lógico.
Mas a rede entre máquinas do mesmo prédio costuma ser melhor do que a rede entre cidades.
Sites e sub-redes permitem representar essa topologia física.
Assim, o Active Directory consegue otimizar tráfego de replicação e localização de controladores.
A abstração é boa porque aceita uma realidade óbvia que algumas arquiteturas gostam de ignorar: rede tem latência, links têm custo e distância física continua existindo mesmo quando tudo ganhou um nome bonito em cloud.
Group Policy: porque configurar 500 máquinas manualmente seria crueldade
Group Policy Objects, GPOs, permitem aplicar configurações de forma centralizada a usuários e computadores.
Elas podem controlar segurança, scripts, comportamento do sistema, configurações de usuário, restrições e várias outras políticas.
As GPOs podem ser vinculadas a Sites, domínios e OUs.
No material da disciplina, a ordem aparece como:
Site -> Domain -> Organizational Unit
Em documentação e administração de Windows, é comum encontrar o mnemônico LSDOU, acrescentando a política Local antes desses níveis:
Local -> Site -> Domain -> Organizational Unit
Quando existem OUs aninhadas, políticas mais específicas entram depois das mais gerais.
Existem ainda mecanismos como herança, bloqueio de herança, Enforced, filtragem de segurança e filtros WMI.
A versão curta para a matéria é entender a hierarquia.
A versão prática é saber que GPO é uma ferramenta poderosa o suficiente para configurar centenas de máquinas e também poderosa o suficiente para configurar centenas de máquinas errado ao mesmo tempo.
Unix historicamente não possui uma única tecnologia equivalente tão universal.
Ambientes grandes costumam combinar LDAP, Kerberos, sudoers centralizado, Ansible, Puppet, Salt, Chef, políticas de configuração e outras ferramentas.
É menos integrado.
Também significa que ninguém precisa abrir um editor de política chamado “Group Policy Management Console” para descobrir por que um wallpaper foi imposto a 900 computadores.
O que esta matéria realmente está ensinando
Apesar do foco no Windows, os conceitos mais importantes da disciplina são muito mais amplos do que a plataforma.
Ela passa por identidade, processos, escalonamento, memória, sistemas de arquivos, virtualização, diagnóstico, serviços, autenticação, diretórios e administração centralizada.
Isso tudo existe fora do Windows.
O que muda é a implementação e, principalmente, a interface administrativa.
No Windows, muita coisa aparece como serviços, consoles MMC, ferramentas Sysinternals e comandos específicos.
Em Unix, a mesma categoria de problema costuma aparecer em processos, daemons, arquivos de configuração, chamadas POSIX, /proc, /sys, sinais, sockets, permissões e ferramentas pequenas que fazem uma coisa de cada vez.
Nenhum dos dois mundos é simples.
Eles apenas distribuem a complexidade em lugares diferentes.
Windows frequentemente tenta esconder detalhes até o momento em que você precisa deles.
Unix frequentemente entrega todos os detalhes imediatamente e considera isso uma gentileza.
Tenho uma preferência bastante clara entre as duas filosofias.
Um resumo mental para não decorar tudo como uma lista telefônica
Se eu precisasse condensar o conteúdo inteiro da matéria em algumas ideias, ficaria assim.
O sistema operacional existe para gerenciar recursos e fornecer abstrações aos programas.
Multitarefa preemptiva significa que o sistema pode interromper tarefas e escalonar outras.
Processos possuem relações entre pai e filho, usam recursos e executam sob contextos de segurança.
Virtualização cria máquinas isoladas sobre hardware real, mas não faz hardware desaparecer.
Ferramentas como Task Manager e Process Explorer ajudam a observar comportamento e diagnosticar gargalos.
SFC, DISM e chkdsk resolvem problemas diferentes e devem ser usados pelo motivo certo.
Serviços executam funções em segundo plano, e diagnosticar por sintoma costuma ser mais útil do que decorar nomes.
Active Directory centraliza identidade, autenticação, objetos e políticas.
DNS ajuda a localizar serviços.
Kerberos cuida da autenticação baseada em tickets.
Sites representam a infraestrutura física.
Domínios, árvores, florestas e OUs representam estrutura lógica.
Controladores de domínio armazenam e replicam a base.
GPOs permitem aplicar política em escala.
Nada disso é exclusivamente importante porque aparece no Windows.
São conceitos de sistemas distribuídos, administração, segurança e sistemas operacionais que continuam relevantes em qualquer plataforma.
O Windows é apenas a implementação escolhida pela matéria.
Infelizmente.
Conclusão
Eu provavelmente não vou transformar este blog em uma série sobre Windows Server.
Há limites.
Mas estudar esses tópicos acabou sendo útil justamente porque força uma comparação entre modelos diferentes.
Quem vem de Unix tende a procurar processos, usuários, descritores, sinais, arquivos de configuração e serviços pequenos.
O Windows apresenta muitos dos mesmos problemas através de handles, SIDs, serviços hospedados, consoles administrativos, Group Policy e Active Directory.
As abstrações não coincidem perfeitamente, e tentar forçar equivalências geralmente piora o entendimento.
Mas os princípios continuam reconhecíveis.
Um sistema operacional ainda precisa dividir recursos, proteger memória, controlar acesso, gerenciar processos, organizar armazenamento e fornecer interfaces para aplicações.
Uma rede corporativa ainda precisa autenticar pessoas, localizar serviços, aplicar políticas e sobreviver quando um servidor cai.
E uma impressora continua sendo uma entidade hostil independentemente do sistema operacional.
Se este for realmente o único post sobre Windows deste blog, pelo menos ele cumpriu um propósito: registrar a parte útil da matéria antes que eu possa voltar tranquilamente para sistemas onde /etc existe e um serviço consegue ter um nome que não parece ter sido escolhido por um departamento jurídico.