Lançamento do cPanel & WHM: novas funcionalidades e estratégias de atualização seguras

Distinguir claramente o cPanel do WHM

Embora o cPanel e o WHM façam parte do mesmo produto, servem níveis diferentes de um servidor de alojamento. cPanel é a interface de uma conta de alojamento individual: é aí que os clientes gerem, por exemplo, domínios, caixas de correio eletrónico, ficheiros, bases de dados e as funcionalidades de segurança disponibilizadas para a sua conta. As áreas que estão visíveis e disponíveis para utilização são determinadas, sobretudo, pelas listas de funcionalidades, pelos pacotes, pelo tema, pelos direitos de acesso à conta e pela configuração do fornecedor de alojamento.

O WHM, por outro lado, é o nível administrativo do painel de alojamento. Nele, os administradores de servidor configuram contas, pacotes, listas de funcionalidades e serviços a nível do servidor, enquanto os fornecedores de alojamento gerido definem, adicionalmente, normas para o aprovisionamento, atualizações e assistência técnica. Os revendedores trabalham com uma área limitada do WHM, dependendo dos direitos que lhes foram delegados; isso não implica automaticamente acesso ao sistema operativo, aos serviços globais ou a todas as políticas do servidor.

A Atualização do cPanel Por isso, não se trata apenas de uma nova visualização na conta do cliente. As alterações podem afetar a atribuição de temas, as funcionalidades disponíveis nos modelos de pacotes e os processos automatizados. A nível do sistema, acrescentam-se ainda as interfaces, as verificações de direitos, as extensões instaladas e a interação com o sistema operativo. O «Release Tier» determina, neste contexto, qual a versão do produto e qual a compilação que ficam disponíveis para o servidor, e não diretamente a visibilidade de funcionalidades específicas numa determinada conta de cliente.

Um exemplo prático é a implementação do Meridian: se o tema for definido através de um pacote WHM, essa decisão influencia a interface de contas novas ou atribuídas. Se os scripts de provisionamento utilizarem simultaneamente APIs ou se os manuais de suporte pressupuserem determinados percursos de menu, a política de temas, o modelo de pacote e a automatização devem ser analisados em conjunto. Caso contrário, uma alteração isolada do tema pode ter consequências funcionalmente corretas, mas inesperadas para os clientes e para o suporte.

Distinguir entre versões, compilações e níveis de lançamento

Para um planeamento de atualizações fiável, é necessário que Versão principal, a compilação e o nível de lançamento devem ser considerados separadamente. De acordo com a informação documentada, o cPanel & WHM 138 é a versão principal de produção mais recente lançada. A versão 134 é o ramo LTS atual, com um período de suporte mais longo e previsível. Embora a versão 136 explique a origem de alterações específicas, o fim do seu suporte regular ocorreu já em agosto de 2026; por isso, não constitui um novo alvo de atualização viável.

Uma versão principal identifica um ramo de lançamento, por exemplo, 138. O número de compilação especifica uma versão concreta dentro desse ramo; no registo de alterações, estão documentadas as alterações para a versão 138 até à compilação 138.0.13. Isso não significa que todos os servidores recebam esta compilação ou que sejam atualizados para a versão 138. O canal de distribuição público utilizado pelo servidor também é determinante.

O Nível de lançamento determina o nível de teste e a frequência com que as atualizações são disponibilizadas. LTS, STABLE, RELEASE, CURRENT e EDGE não são, portanto, meros rótulos para a mesma versão do software. Um servidor no nível LTS pode, deliberadamente, estar numa ramificação de versão principal diferente da de um sistema no nível RELEASE, embora a 138 seja, em geral, a versão principal de produção mais recente.

É necessário ter especial cuidado com os números de versão cujo número principal seja ímpar. Estes pertencem à versão de desenvolvimento do ramo EDGE e não devem ser equiparados a uma versão de produção publicada. A sua existência não comprova nem que o desenvolvimento esteja concluído, nem que sejam adequadas para os servidores dos clientes. Por conseguinte, no âmbito da gestão de alterações e da comunicação de suporte, os administradores devem sempre documentar em conjunto a versão instalada, a compilação específica e o nível (tier) selecionado.

Por que razão é necessário planear uma atualização do cPanel

A Mudança de versão No cPanel & WHM, a reversão não é possível sem consequências: não é suportado o downgrade para uma versão principal anterior ou para um nível de lançamento anterior. No caso de saltos de versão mais significativos, o programa de atualização passa pelas versões intermédias necessárias e verifica a compatibilidade antes de cada passo. Isto reduz as tentativas de atualização inadequadas, mas não substitui uma avaliação técnica prévia do próprio ambiente.

Os requisitos técnicos podem impedir uma atualização ou determinar o seu percurso. Entre estes contam-se o sistema operativo utilizado e espaço livre suficiente em /usr/local/cpanel e bloqueios ativos do gestor de pacotes. Como exemplo documentado, o Ubuntu 22 não pode ser atualizado para o cPanel & WHM 136. Estas indicações não constituem um apelo para se recorrer a uma versão anterior, mas sim um motivo para esclarecer antecipadamente o estado do sistema operativo e o percurso de migração previsto.

Para além do sistema base, a atualização inclui uma lista de verificação operacional. As alterações documentadas nas autorizações da API SSL e na remoção de auxiliares de contabilidade indicam que as automatizações próprias ou integrações de faturação podem ser afetadas. Além disso, as alterações no Meridian e no CSF tornam as atribuições de temas, as listas de funcionalidades, os ajustes no firewall local e as extensões associadas pontos de verificação importantes. Não se trata de verificações prometidas pelo programa de atualização, mas sim de dependências que deve avaliar de forma específica no seu ambiente.

Como medida de precaução operacional, a atualização só deve ser iniciada com um plano de recuperação adequado ao próprio ambiente, um estado de cópia de segurança previamente verificado e responsabilidades claramente definidas. A documentação do fabricante recomenda que uma nova versão principal seja inicialmente testada num sistema de teste compatível; só após os testes funcionais internos é que a produção deve seguir de forma controlada. Uma vez que não está prevista uma reversão para uma versão anterior, uma eventual recuperação a partir de cópias de segurança não deve ser confundida com o retrocesso do nível de lançamento.

Selecionar níveis de lançamento de acordo com o objetivo operacional

O nível de lançamento determina qual a versão de desenvolvimento e teste que um servidor recebe; trata-se, portanto, de uma decisão operacional e não de uma mera configuração para atualizações automáticas. Durante o seu período de vigência, o LTS concentra-se em atualizações de segurança, críticas e de compatibilidade. A versão STABLE é lançada com menos frequência do que a RELEASE, enquanto a RELEASE é a norma documentada para novas instalações.

A versão CURRENT é atualizada com maior frequência e pode incluir funcionalidades que ainda estão em desenvolvimento. A versão EDGE é submetida apenas a testes básicos e, por isso, deve ser utilizada exclusivamente em ambientes de teste controlados. Os números de versão principal ímpares identificam versões de desenvolvimento no ramo EDGE; não indicam que estejam prontas para produção nem que haja disponibilidade segura de uma determinada funcionalidade.

Para um alojamento partilhado programável, é LTS É aconselhável quando é mais importante garantir um nível de funcionalidade previsível a longo prazo do que uma nova interface ou funcionalidades de automatização precoces. Isto não significa suspender as atualizações: as correções de segurança e as correções críticas continuam a fazer parte da operação. A RELEASE defende a adoção de novos servidores, desde que as dependências sejam verificadas antecipadamente e as janelas de manutenção sejam planeadas.

A escolha deve, além disso, ser adequada à organização do teste. Tal como acontece com outros painéis de alojamento, não é um único número de versão que é determinante, mas sim a interação entre o painel, as extensões, o sistema operativo e a pilha do cliente. O artigo Planear de forma controlada as atualizações do Plesk para os fornecedores de alojamento ilustra este princípio geral para outra plataforma. De acordo com a documentação da atualização, um atraso de vários dias úteis afeta apenas as atualizações automáticas para a próxima versão principal no nível RELEASE e apenas nas condições aí especificadas; os níveis EDGE, CURRENT, STABLE e LTS estão excluídos desta regra.

Verificar as novas funcionalidades da versão 138

A versão 138 introduz Meridiano como interface do cliente. Para os responsáveis pelo WHM, não é apenas o layout alterado que é relevante: a seleção do tema, a atribuição de pacotes, as listas de funcionalidades, os materiais de formação e os processos de apoio técnico têm de estar em sintonia. O nível de lançamento determina se a versão necessária do produto e da compilação está disponível no servidor; por outro lado, as áreas visíveis por uma conta específica dependem sobretudo do tema, do pacote, das listas de funcionalidades e da configuração do fornecedor.

No Meridian, uma transição em grande escala sem uma política definida é arriscada. As contas criadas no Meridian que nunca utilizaram o Jupiter não podem regressar ao Jupiter por iniciativa própria. No entanto, os administradores podem definir o tema através do WHM, de um pacote ou da API. Por isso, os modelos de pacotes e a comunicação com um pequeno grupo-piloto devem ser coordenados de forma vinculativa antes da implementação em larga escala.

A função WHM-API-1 set_primary_domain_docroot pode alterar a raiz de documentos de um domínio primário e foi retroportado para as versões 134 e 136. Isto facilita a implementação ou a migração, mas não substitui a verificação da aplicação. Um CMS, um redirecionamento, direitos de ficheiro ou um script de implementação podem continuar a pressupor o caminho anterior; uma execução bem-sucedida do Updater não reconhece automaticamente esta suposição técnica.

A partir da versão 138.0.10, as funções da API para recuperar certificados SSL e chaves requerem a funcionalidade sslinstall ou sslmanager. Por isso, as listas de funcionalidades limitadas e as integrações de faturação externas devem ser analisadas de forma específica. Além disso, o cPanel removeu ficheiros auxiliares obsoletos de Cpanel/Accounting; as integrações diretas em soluções de faturação individuais constituem um caso de adaptação, não uma questão de compatibilidade resolvida automaticamente.

A versão 138.0.13 altera também os requisitos relativos a ACLs de revendedores na configuração dos servidores de nomes. Os revendedores que gerem o clustering de DNS podem necessitar do privilégio all, para alterar as definições dos servidores de nomes do servidor. Por isso, antes da atualização, verifica os modelos operacionais delegados, as funções dos revendedores utilizados e os processos automatizados do cluster DNS. Este privilégio alarga significativamente o acesso e não deve ser atribuído de forma generalizada, mas apenas após uma verificação das funções e da segurança.

Preparar atualizações com inventário e fase piloto

Antes da atualização, é primeiro registada a situação atual: versão instalada, nível de lançamento, sistema operativo, plug-ins de terceiros, chamadas à API própria, ajustes na firewall, bem como procedimentos de cópia de segurança e recuperação. É possível determinar a versão no terminal sem alterar o sistema. Este inventário associa os componentes técnicos aos seus responsáveis e evita que dependências pouco claras só se tornem visíveis após a atualização.

/usr/local/cpanel/cpanel -V

Para um processo de atualização, o cPanel requer, no mínimo, 5 GB de espaço livre em /usr/local/cpanel. Os bloqueios ativos do gestor de pacotes podem impedir o processo; o caminho do sistema operativo também pode impor limitações, dependendo da versão. Estes aspetos devem ser tratados antes da janela de manutenção, tal como uma restauração cujo procedimento e direitos de acesso tenham sido previamente esclarecidos.

Segue-se então Encenação num sistema de teste separado e comparável. Aí, os pacotes, temas, plugins e integrações de API relevantes são testados com contas de teste simuladas. Teste processos típicos, como o início de sessão, a automatização de certificados, o aprovisionamento e a operação das aplicações. A documentação do fabricante recomenda expressamente que a atualização seja primeiro testada num sistema de teste, antes de se proceder à atualização do sistema de produção.

Um teste piloto de produção deve ser tratado separadamente. As contas reais de clientes só são incluídas após autorização expressa, com âmbito limitado, monitorização e um canal de apoio previamente comunicado. Defina antecipadamente quais os testes funcionais a realizar, quem toma as decisões em caso de falha e quais as medidas de recuperação possíveis para a conta ou o servidor em questão. Um teste em contas simuladas não substitui esta autorização de operação; inversamente, um teste com clientes não constitui um ambiente de teste isento de riscos.

No WHM, a opção „Upgrade to Latest Version“ atualiza para a versão mais recente do nível de lançamento selecionado. Por conseguinte, esta função não garante a mudança para a versão principal mais recente em geral. Além disso, no caso do RELEASE, pode aplicar-se um atraso automático; uma atualização forçada contorna esse atraso. As medidas operacionais relacionadas com a segurança, nomeadamente no que diz respeito a acessos, cópias de segurança e firewall, devem ser mantidas em paralelo com o processo de atualização; os princípios práticos são explicados neste artigo Segurança do painel de controlo de alojamento no WHM e no cPanel.

Operar o Meridian e o CSF de forma controlada

No cPanel & WHM 138, o Meridian é mais do que uma nova visualização do cliente. O tema agrupa tarefas em áreas como websites, e-mail, ficheiros, bases de dados, segurança e desempenho. Por isso, para o funcionamento, não importa apenas se a interface é visualmente apelativa, mas sim se os clientes continuam a conseguir localizar e executar claramente as tarefas previstas com as funcionalidades que subscreveram.

Antes da aprovação, o administrador deve emitir uma Política de temas Definir: Quais contas recebem o Meridian, quais modelos de pacote atribuem o tema e quais listas de funcionalidades limitam as funcionalidades individuais? Estas definições estão interligadas. Embora um pacote possa definir um tema, uma funcionalidade ausente na lista de funcionalidades continuará a não estar disponível para a conta correspondente.

Na prática, recomenda-se um grupo-piloto limitado com planos representativos, como, por exemplo, uma conta simples de alojamento web, uma conta com vários domínios e um cenário de revenda. Verifique, para o efeito, os canais de apoio típicos, como a gestão de caixas de correio, o acesso à base de dados e a pesquisa de funcionalidades de segurança. A comunicação com os clientes deve indicar a data, as alterações visíveis e um canal de apoio acessível, em vez de anunciar a mudança como sendo meramente cosmética.

A mudança de volta para o Jupiter tem de fazer parte deste planeamento. As contas criadas com o Meridian e que nunca utilizaram o Jupiter não podem mudar por si próprias de volta para o Jupiter. Os administradores podem continuar a alterar o tema no WHM, através de um pacote ou via API. Daí decorre que a atribuição do tema e o processo responsável têm de estar definidos antes de novas contas serem criadas por predefinição com o Meridian.

O CSF deve ser considerado separadamente da versão principal do cPanel & WHM. A WebPros disponibiliza o fork nas versões suportadas do cPanel & WHM como um pacote com numeração de versão separada cpanel-csf pronto; é instalado e atualizado através do gestor de pacotes do cPanel. A migração, previamente anunciada, de instalações do CSF não suportadas ou desatualizadas para o fork suportado foi retroportada para todas as versões suportadas do cPanel e do WHM. Por isso, não é possível determinar com fiabilidade a versão do CSF apenas com base na compilação do cPanel instalada.

Para fazer o teste, precisas de ter instalado o Versão do pacote cpanel-csf, o registo de alterações (changelog) separado do CSF, o estado da gestão de pacotes e a configuração local. Verifique e compare as suas próprias regras, listas de permissão e de restrição, hooks, notificações, bem como plugins ou scripts de implementação. Verifique também se existem ferramentas externas que exijam ficheiros ou comandos de uma instalação anterior do CSF. A versão do cPanel continua a ser relevante no contexto geral da atualização, mas não substitui nem esta verificação de pacotes nem a avaliação da configuração local da firewall.

Identificar sistematicamente os erros após a atualização

Se, após uma atualização, algumas funcionalidades deixarem de funcionar, a análise começa com o nível de versão (Release Tier) selecionado e a compilação (Build) efetivamente instalada. A versão principal mais recente, em geral, não corresponde automaticamente ao estado atual de um servidor; o que é determinante é a compilação que foi fornecida no nível de versão configurado. Anote também a data e hora, as contas afetadas e a funcionalidade específica antes de efetuar quaisquer alterações com o objetivo de corrigir o suposto erro.

Em seguida, analisas os registos de atualizações e possíveis Bloqueador de atualizações . Em saltos de versão mais significativos, o programa de atualização passa por versões intermédias e realiza verificações de compatibilidade; bloqueios ativos do gestor de pacotes ou caminhos incorretos do sistema operativo podem influenciar o processo. Uma atualização interrompida ou concluída apenas parcialmente não justifica uma repetição cega com opções forçadas, mas sim, em primeiro lugar, o esclarecimento da causa registada.

Em seguida, testa as dependências numa ordem fixa: primeiro as chamadas à API do WHM ou do cPanel, depois as listas de funcionalidades e as atribuições de temas, e, por fim, os plugins e as regras da firewall. Desta forma, a deteção de erros permite distinguir uma alteração central nas autorizações de uma conta de cliente individual ou de uma extensão. As alterações devem ser documentadas de forma compreensível e, sempre que possível, testadas primeiro num ambiente de staging ou numa conta isolada.

Um problema específico diz respeito às automatizações SSL: a partir da versão 138.0.10, as funções da API para recuperar certificados e chaves SSL requerem a funcionalidade sslinstall ou sslmanager. Se, após a atualização, um script deixar de fornecer dados de certificados, deve, por isso, verificar primeiro a lista de funcionalidades atribuída à conta e as autorizações do acesso utilizado, e não apenas a rede ou o conjunto de certificados.

No caso de alterações nas raízes dos documentos, uma chamada à API bem-sucedida também não garante que o site esteja a funcionar corretamente. A função set_primary_domain_docroot pode definir o caminho do domínio principal, enquanto as configurações do CMS, os redirecionamentos, os direitos de acesso aos ficheiros, as definições de VHost ou os scripts de implementação continuam a apontar para o caminho antigo. Por isso, teste separadamente a apresentação, a área de administração e as operações de escrita da aplicação.

As integrações de contabilidade implementadas individualmente também podem ser afetadas, uma vez que os ficheiros auxiliares PHP desatualizados de Cpanel/Accounting foram removidos. Se um processo de faturação for essencial para o negócio e não houver nenhuma adaptação compatível disponível, é mais adequado interromper a manutenção ou proceder à recuperação a partir de uma cópia de segurança verificada do que realizar mais uma atualização forçada. A documentação do fabricante e os registos fornecem, nesse caso, a base para um plano de adaptação sólido.

Definir de forma vinculativa a estratégia de atualização adequada

Uma estratégia de atualização sustentável começa com o objetivo operacional, e não com o número de versão mais elevado visível. São determinantes o período de suporte, a necessidade de novas funcionalidades, o impacto esperado nos clientes, a capacidade de teste disponível, as dependências de fornecedores terceiros e as operações de segurança. Estes critérios devem ser avaliados por cada grupo de servidores: um cluster de alojamento partilhado, uma nova plataforma gerida e um sistema de testes interno apresentam riscos e ritmos de alteração diferentes.

O LTS é adequado quando é mais importante ter uma versão que permita um planeamento a longo prazo do que a introdução contínua de novas funcionalidades. Durante o seu período de vigência, esta ramificação recebe principalmente atualizações de segurança, críticas e de compatibilidade. Por conseguinte, o LTS não significa suspender as atualizações, nem substitui os testes de cópia de segurança, de recuperação e de dependências. Para ofertas de alojamento partilhado já estabelecidas, esta limitação às alterações de funcionalidades pode tornar o suporte mais previsível.

A versão STABLE é lançada com menos frequência do que a RELEASE e foi submetida a mais testes públicos. A versão RELEASE está funcionalmente completa e é o padrão para novas instalações. Ambas são opções válidas quando são necessárias novas funcionalidades, mas os testes são realizados antes da implementação em larga escala. A escolha entre as duas versões depende, portanto, de se é mais importante para a respetiva plataforma uma disponibilidade antecipada ou um período adicional de testes.

A versão CURRENT é atualizada com maior frequência e pode incluir funcionalidades que ainda estão em desenvolvimento. A versão EDGE é submetida apenas a testes básicos e destina-se exclusivamente a ambientes de teste controlados. Os números ímpares das versões principais correspondem a versões de desenvolvimento no ramo EDGE; não indicam que uma funcionalidade esteja disponível de forma estável para produção. Por isso, para servidores de produção dos clientes, o EDGE não constitui um atalho para funcionalidades anteriores.

Coloca o Política de Lançamento por escrito: número permitido de instâncias por classe de servidor, responsáveis pelas aprovações, âmbito mínimo do teste de staging, janela de manutenção e critérios para a interrupção do processo. Um atraso de vários dias úteis aplica-se exclusivamente a atualizações automáticas para a versão principal seguinte no nível RELEASE, desde que a atualização não seja iniciada manualmente ou forçada e apenas salte uma versão principal. As camadas EDGE, CURRENT, STABLE, LTS e as versões fixadas não estão sujeitas a este atraso.

Exemplos típicos de decisões erradas são o EDGE na produção e a fixação de números de compilação específicos em /etc/cpupdate.conf, a ausência de um ambiente de teste e a suposição de que as versões LTS não requerem atualizações de segurança. Igualmente problemático é equiparar uma execução bem-sucedida do programa de atualizações a uma aprovação técnica. Só quando as funcionalidades do cliente, as automatizações, os plug-ins e os mecanismos de proteção forem testados na extensão prevista é que uma atualização técnica se transforma numa transição operacional controlada.