| Capítulo 5. Problemas a estar atento na jessie | ||
|---|---|---|
 |  | |
| Capítulo 5. Problemas a estar atento na jessie | ||
|---|---|---|
| | | |
Índice
base-passwd.perl.Por vezes, as alterações introduzidas num novo lançamento têm efeitos secundários que não podemos evitar razoavelmente, ou aparecerão bugs noutro lado. Esta secção documenta os problemas que conhecemos. Por favor leia também a errata, a documentação dos pacotes relevantes, relatórios de bugs e outra informação mencionada em Secção 6.1, “Leitura adicional”.
Existem alguns pacotes onde Debian não pode prometer disponibilizar backports mínimos para problemas de segurança. Estes estão cobertos nas seguintes subsecções.
Note que o pacote debian-security-support, introduzido em
Jessie, ajuda a seguir o estado do suporte de segurança aos pacotes
instalados.
O debian 8 inclui diversos motores de navegador de internet que são afectados por um fluxo regular de vulnerabilidades de segurança. A alta taxa de vulnerabilidades e a falta parcial de suporte dos criadores sob a forma de lançamentos com largos períodos de suporte, torna muito difícil suportar estes navegadores através da adaptação de correcções de segurança (backports). Além disto, as interdependências entre bibliotecas tornam impossível a actualização para versões originais mais recentes. Como tal, os navegadores criados sob os motores webkit, qtwebkit e khtml estão incluídos no Jessie, mas não estão cobertos pelo suporte de segurança. Estes navegadores não devem ser utilizados para aceder a sites que não sejam de confiança.
Para um navegador web recomendamos o Iceweasel ou Chromium.
Chromium - apesar de construído sob o código do Webkit - é um pacote leaf, o qual irá ser mantido actualizado ao recompilar o actual lançamento do Chromium para stable. O Iceweasel e Icedove também irão ser mantidos actualizados ao recompilar os actuais lançamentos ESR para stable.
A plataforma Node.js é construída sob libv8-3.14, a qual experimenta um grande volume
de problemas de segurança, mas actualmente não existem voluntários dentro do
projecto ou da equipa de segurança suficientemente interessados e
disponíveis para utilizar uma grande quantidade de tempo necessário para
resolver esses problemas.
Infelizmente, isto significa que libv8-3.14, nodejs, e o ecossistema de pacotes node-*
associados actualmente não devem ser utilizados com conteúdo não-confiável,
tal como dados por tratar da Internet.
Além disso, estes pacotes não irão receber quaisquer actualizações de segurança durante o tempo de vida do lançamento Jessie.
O suporte de segurança do autor para a série 1.19 do mediawiki termina durante o tempo de vida
esperado do Jessie. O pacote mediawiki é incluído em Debian para satisfazer
as dependências noutros pacotes.
O suporte de segurança para o mediawiki irá
terminar em conjunto com o suporte para a Wheezy em Abril de 2016.
Numa tentativa para tornar mais segura a configuração predefinida, a
configuração do openssh-server irá
agora estar predefinida para "PermitRootLogin without-password". Se depender
de autenticação por palavra-passe para o utilizador root,
poderá ser afectado por esta alteração.
O openssh-server irá tentar detectar
tais casos e aumentar a prioridade da pergunta debconf.
Se quiser manter a autenticação por palavra-passe para o utilizador
root, poderá também fazer preseed a esta questão ao
utilizar:
$ echo 'openssh-server openssh-server/permit-root-login boolean true' | debconf-set-selections
Se estiver a utilizar Puppet, por favor tenha atenção que o Puppet 3.7 não é retro-compatível com Puppet 2.7. Entre outras coisas, o escopo das regras foi alterado e foram removidos muitos constructs depreciados. Veja as notas de lançamento de Puppet 3.x para algumas alterações, além de estar atento a que existem mais alterações no 3.7.
Verificar os ficheiros log do seu actual puppetmaster para avisos de depreciação e resolver todos esses avisos antes de proceder com a actualização irá ser muito mais fácil para completar a actualização. Em alternativa, ou adicionalmente, testar os manifests com uma ferramenta como o Puppet catalog test poderá também encontrar potenciais problemas antes da actualização.
Ao actualizar um sistema gerido pelo Puppet de Wheezy para Jessie, tem de
assegurar que o puppetmaster correspondente corre pelo menos a versão 3.7 do
Puppet. Se o mestre estiver a correr o puppetmaster do Wheezy, o sistema Jessie gerido
não será capaz de se ligar a ele.
Para mais informação sobre alterações de incompatibilidade, por favor veja em Telly upgrade issues e "The Angry Guide to Puppet 3".
A actualização para Jessie inclui uma actualização de PHP de 5.4 para 5.6. Isto pode afectar quaisquer scripts locais de PHP e é aconselhado a verificar esses scripts antes de actualizar. Em baixo está um conjunto selecionado desses problemas:
Para prevenir ataques man-in-the-middle contra transferências encriptadas, os streams de cliente agora verificam, por predefinição, os certificados dos pares.
Como resultado desta alteração, o código existente que utilize stream wrappers ssl:// ou tls:// (e.g. file_get_contents(), fsockopen(), stream_socket_client()) podem já não ligar com sucesso sem manualmente desligar a verificação dos pares através da definição do contexto do stream "verify_peer".
Para mais informação acerca deste problema em particular, por favor leia este documento.
PHP altera como lida com insensibilidade a maiúsculas/mínusculas em muitos casos:
Toda a insensibilidade interna a lidar com maiúsculas/minúsculas para classe, função e nomes de constantes é feita de acordo com regras ASCII. As definições dos locales actuais são ignoradas.
As palavras-chave "self", "parent" e "static" são agora sempre insensíveis a maiúsculas/minúsculas.
A função json_decode() já não aceita variantes sem serem minúsculas de valores "boolean".
As funções GUID logo (e.g. php_logo_guid()) foram removidas.
Já não é possível sobrescrever chaves em static scalar arrays. Por favor veja PHP bug 66015 para um exemplo e mais informação sobre este problema em particular.
As funções mcrypt_encrypt(); mcrypt_decrypt() e mcrypt_{MODE}() já não aceitam chaves ou IVs com tamanhos incorrectos. Além disso um IV é agora necessário se o modo do bloco de cifra necessitar dele.
Por razões legais, a implementação JSON empacotada com PHP foi substituída pela versão disponibilizada pelo módulo PECL "jsonc". O código que faça suposições acerca dos detalhes mais finos da implementação do parser JSON de PHP poderá necessitar ser revisto.
A definição "short_open_tag" está agora desabilitada por predefinição. Está planeado que os short tags ("<?" and "?>") venham a ser removidos em PHP7.
Para mais informação acerca da lista completa de potenciais problemas, por favor dê uma vista de olhos à lista original de alterações incompatíveis para PHP 5.5 e 5.6.
![[Nota]](images/note.png) | Nota |
|---|---|
Esta secção é apenas aplicável a sistemas que têm o servidor Apache HTTPD instalado e configurado manualmente. |
Houve várias alterações na configuração do servidor Apache HTTPD na versão 2.4. Do lado dos autores originais, a sintaxe mudou. Notavelmente, as directivas de controlo de acesso mudaram consideravelmente e necessitará de migração manual para as novas directivas.
O módulo mod_access_compat é mencionado no guia de
actualização original como uma possível alternativa à migração imediata. No
entanto, os relatos sugerem que nem sempre funcionará.
A gestão dos ficheiros dos configuração também foi alterada no empacotamento
Debian. Em particular, todos os ficheiros de configuração e sites têm agora
de terminar em ".conf" para serem, por omissão, analisados. Esta alteração
também substitui o actual uso de /etc/apache2/conf.d/.
| Nota |
|---|---|
Durante a actualização, poderá também ver avisos sobre ficheiros de
configuração colocados em |
Para mais informação a a lista completa de alterações, por favor veja:
O documento Upgrading to 2.4 from 2.2 disponibilizado pelo Apache do lado dos autores.
O ficheiro /usr/share/doc/apache2/NEWS.Debian.gz
disponibilizado por apache2
Jessie é lançado com systemd-sysv
como sistema init predefinido. Este pacote é instalado
automaticamente nas actualizações.
Se tiver preferência por outro init tal como o sysvinit-core ou upstart, é recomendado definir o pinning do APT
antes da actualização. Isto também pode ser necessário se estiver a
actualizar containers LXC antes do host. Neste caso, por favor remeta para
Secção 5.8.1, “Actualizar guests LXC que correm em máquinas Wheezy”.
Como exemplo, para prevenir systemd-sysv de ser instalado durante a
actualização, pode criar um ficheiro chamado
/etc/apt/preferences.d/local-pin-init com o seguinte
conteúdo:
Package: systemd-sysv Pin: release o=Debian Pin-Priority: -1
![[Cuidado]](images/caution.png) | Cuidado |
|---|---|
Esteja avisado de que alguns pacotes podem ter um comportamento degradado ou falta de capacidades sob um sistema init que não o predefinido. |
Por favor note que a actualização pode instalar pacotes contendo "systemd"
no seu nome mesmo com o APT pinning. Estes por si não
alteram o seu sistema init. Para utilizar systemd como o seu sistema init, o
pacote systemd-sysv tem que ser
anteriormente instalado.
Se o APT ou aptitude tiverem problemas a determinar um caminho de
actualização com o pin em uso, poderá ser capaz de ajudar ao instalar
manualmente ambos sysvinit-core e
systemd-shim.
O novo sistema init predefinido, systemd-sysv, lida de forma mais rigorosa com
mounts "auto" durante o arranque comparado com sysvinit. Se falhar o mount
com um "auto" (sem a opção "nofail"), o systemd irá largar para uma shell de
emergência em vez de continuar com o arranque.
Recomendamos que todos os pontos de montagem amovíveis ou "optional"
(e.g. drives de rede não-críticas) listadas em
/etc/fstab tenham a opção "noauto" ou "nofail".
Se estiver a actualizar a partir de lançamentos anteriores, o seu sistema poderá conter init-scripts disponibilizados por pacotes (agora) removidos. Estes scripts podem conter metadados incorrectos ou mesmo sem dependências, o que pode levar a ciclos de dependências na sua configuração de init.
Para evitar isto, nós recomendamos que corra e reveja a lista de pacotes que estão no estado "rc" ("Removed, but Config-file remain"), e purgar pelo menos os que contenham init-scripts.
Por favor veja Secção 4.8.1, “Purgar pacotes removidos” para detalhes sobre como encontrar e purgar pacotes removidos.
| Nota |
|---|---|
Esta secção apenas se aplica a sistemas onde os scripts init disponibilizados por Debian foram modificados localmente. |
Se modificou alguns dos init scripts disponibilizados por Debian, por favor saiba que estes podem ter sido agora substituídos por um ficheiros de unidade systemd ou pelo próprio systemd. Se tiver o debsums instalado, pode pesquisar por scripts init modificados localmente ao utilizar o seguinte comando.
debsums -c -e | grep ^/etc/init.d
Em alternativa, pode ser utilizado o seguinte na ausência do debsums.
dpkg-query --show -f'${Conffiles}' | sed 's, /,\n/,g' | \
grep /etc/init.d | awk 'NF,OFS=" " {print $2, $1}' | \
md5sum --quiet -c
Se quer o comando sinalizar quaisquer ficheiros e os seus pacotes
correspondentes ou o systemd agora disponibilizar um ficheiro de
unidade systemd para esse serviço, o ficheiro de unidade do systemd tomará
precedência sobre o seu init script modificado localmente. Dependendo da
natureza da mudança, existem formas diferentes para fazer a migração.
Se necessário, é possível ultrapassar o ficheiro de unidade systemd de forma a iniciar o script sysvinit. Para mais informação sobre ficheiros de unidade, por favos dê uma vista de olhos nos seguintes recursos.
Como Converto Um Init Script SysV Para Um Ficheiro de Serviço systemd?
My Service Can't Get Realtime! (também contém uma menção muito curta sobre invocação de scripts init a partir de ficheiros unit)
Se o seu arranque for interactivo (e.g. necessitar de uma palavra-passe para
um disco encriptado), por favor certifique-se que tem instalado e
configurado o plymouth. Por favor refira-se a
/usr/share/doc/plymouth/README.Debian para informação
acerca de como configurar o plymouth.
Sem o plymouth, pode descobrir que a
prompt de arranque desaparece. Existem relatórios que sugerem que a prompt
do cryptsetup mesmo assim aceita entradas apesar de não serem visíveis. Se
experimentar este problema, pode funcionar escrever a palavra-passe correcta
mesmo que não seja visível.
Os eventos ACPI podem ser lidados pelo logind ou pelo acpid. No caso de ambos os serviços serem configurados a lidar com os eventos de diferentes formas, isto pode levar a resultados indesejados.
Nós recomendamos migrar quaisquer definições não-standard para o logind e desinstalar o acpid. Em alternativa também é possível configurar o logind para ignorar eventos ACPI ao acrescentar:
HandlePowerKey=ignore HandleSuspendKey=ignore HandleHibernateKey=ignore HandleLidSwitch=ignore
para /etc/systemd/logind.conf. Note que isto pode
alterar o comportamento dos ambientes de trabalho que dependam do logind.
Existem algumas funcionalidades do cryptsetup que infelizmente não são suportadas quando correndo com o systemd como sistema init. Estas são:
precheck
check
checkargs
noearly
loud
keyscript
Se o seu sistema depender de quaisquer um destes para arrancar, terá de
utilizar o sysvinit (sysvinit-core)
como sistema init. Por favor veja Secção 5.6, “Actualizar instala o novo sistema init predefinido em Jessie” sobre como evitar um
determinado sistema init.
Pode verificar se qualquer uma destas opções está em uso no seu sistema ao correr o seguinte comando:
grep -e precheck -e check -e checkargs -e noearly -e loud -e keyscript /etc/crypttab
Se não houver saída do acima, o seu sistema não utiliza quaisquer das opções afectadas.
Foi reportada uma regressão no systemd após o lançamento Jessie. Este bug ocorre durante o desligar ou durante o reínicio, onde o systemd não dá um atraso razoável antes de enviar SIGKILL a todos os processos. Isto pode levar a perda de dados em processos que não tenham ainda salvaguardado todos os seus dados na altura do reiniciar (e.g. bases de dados em execução).
Este problema é seguido no bug Debian #784720.
| Nota |
|---|---|
Esta secção é apenas para pessoas que compilem o seu próprio kernel. Se utilizar kernels compilados por Debian, pode ignorar esta secção. |
As seguintes configurações do kernel são agora ou necessárias ou recomendadas para Jessie (além das existentes dos lançamentos anteriores):
# Necessário para udev CONFIG_DEVTMPFS=y # Necessário para *alguns* serviços systemd CONFIG_DEVPTS_MULTIPLE_INSTANCES=y # Necessário para *alguns* serviços systemd CONFIG_DEVPTS_MULTIPLE_INSTANCES=y # Necessário para "bluez" (GNOME) CONFIG_BT=y # Necessário para cups + systemd. CONFIG_PPDEV=y
Os serviços systemd que necessitam de CONFIG_DEVPTS_MULTIPLE_INSTANCES=y irão usualmente conter pelo menos uma das seguintes directivas:
PrivateTmp=yes PrivateDevices=yes PrivateNetwork=yes ProtectSystem=yes
Se você não usa o systemd, ou pode afirmar que nenhum dos serviços do systemd irá usar os directórios em cima, a opção config pode não ser necessária para o seu sistema em particular.
Para mais informação sobre os requisitos, por favor consulte a secção
chamada "REQUIREMENTS" no ficheiro README
do pacote systemd.
| Nota |
|---|---|
Esta secção apenas se aplica a sistemas que tenham containers e máquinas de LXC. Os sistemas de utilizador final normais geralmente não têm isto. |
A actualização de Wheezy para Jessie irá migrar por predefinição o seu sistema para o sistema systemd (veja Secção 5.6, “Actualizar instala o novo sistema init predefinido em Jessie”).
Quando se actualiza um container LXC ou uma máquina virtual LXC, isto irá ter consequências diferentes dependendo de se o sistema anfitrião já foi actualizado para Jessie ou ainda não.
Se você está a actualizar um guest container de LXC que está a correr num sistema em máquina Wheezy, então você precisa de prevenir que o guest seja automaticamente migrado para o systemd. Você previne a migração via "pinning", como descrito em Secção 5.6, “Actualizar instala o novo sistema init predefinido em Jessie”.
Isto é necessário pois a máquina Wheezy não tem a funcionalidade de arrancar um sistema que corre systemd.
você será capaz de mudar para o systemd dentro do guest LXC assim que tiver actualizado o sistema anfitrião para Jessie. Veja o próximo parágrafo para coisas que precisam ser adaptadas em máquinas Jessie.
De modo a ser capaz de arrancar guests LXC com systemd, irá necessitar de
adaptar a configuração do seu container LXC. A configuração do container
pode normalmente ser encontrada em
/var/lib/lxc/.
Necessitará acrescentar as seguintes duas definições à configuração:
CONTAINER_NAME/config
lxc.autodev = 1 lxc.kmsg = 0
Pode encontrar informação adicional sobre LXC em Debian no wiki Debian.
| Nota |
|---|---|
Esta secção é para quem configurou os seus próprios discos encriptados LUKS utilizando a hash whilpool. O debian-installer nunca suportou criar tais discos. |
Se criou manualmente um disco encriptado com LUKS whirlpool irá ter que migrar manualmente para uma hash mais forte. Pode verificar se o seu disco está a utilizar whirlpool utilizando o seguinte comando:
# /sbin/cryptsetup luksDump <disk-device> | grep -i whirlpool
Para mais informação acerca da migração, por favor veja "8.3 Gcrypt 1.6.x and later break Whirlpool" do cryptsetup FAQ.
O ambiente GNOME 3.14 em Jessie já não tem o suporte de recurso para máquinas sem gráficos 3D básicos. Para correr adequadamente, necessita de um PC recente o suficiente (qualquer PC construído nos últimos 10 anos deve ter o necessário suporte SSE2) ou, para arquitecturas que não i386 ou amd64, um adaptador de gráficos 3D acelerado com drivers EGL.
Ao contrário de outros controladores OpenGL, o controlador AMD FGLRX para adaptadores Radeon não suporta o interface EGL. Como tal, várias aplicações GNOME, incluindo o núcleo do ambiente GNOME, não irão arrancar quando este controlador estiver em uso.
Em vez disso é recomendado utilizar o controlador livre
radeon, que é o predefinido em jessie.
Os atalhos de teclado predefinidos no ambiente GNOME foram alterados de modo a coincidirem mais com alguns de outros sistemas operativos.
As definições dos atalhos que foram previamente modificadas pelo utilizador serão mantidas após a actualização. Estas definições podem ainda ser configuradas a partir do centro de controlo do GNOME, que é acessível a partir do menu no canto superior direito ao clicar no ícone "Definições".
A actualização do pacote base-passwd
irá fazer reset à shell de alguns utilizadores para a shell "nologin". Isto
inclui os seguintes utilizadores:
daemon
bin
sys
sync
games
man
lp
news
uucp
proxy
www-data
backup
list
irc
gnats
nobody
Se a sua configuração local necessitar que qualquer desses utilizadores tenha uma shell, deve dizer não à migração, ou então migrar e posteriormente alterar a shell dos utilizadores correspondentes. Exemplos notáveis incluem backups locais feitos através do utilizador "backup" com autenticação "ssh-key".
| Cuidado |
|---|---|
A migração irá ocorrer automaticamente se a prioridade das questões debconf for "high" ou superior. |
Se souber que quer manter a shell actual de um dado utilizador, pode fazer preseed às questões ao utilizar o seguinte:
echo 'base-passwd base-passwd/system/username/shell/current-shell-mangled/_usr_sbin_nologin boolean false' | debconf-set-selections
Onde username é o nome do utilizador em questão e
current-shell-mangled é o nome alterado da
shell. A alteração é feita ao substituir todos os caracteres que não sejam
alfanuméricos, traços e traços inferiores por traços
inferiores. E.g. /bin/bash torna-se _bin_bash.
O sistema Kontact Personal Information Management recebeu uma actualização maior. A nova versão faz maior uso da indexação de metadados e os dados de cada utilizador tem de ser migrado para os novos índices.
E-mail, eventos de calendário, e lista de contactos são migrados automaticamente quando o utilizador se identificar e o componente relevante for iniciado. Algumas definições avançadas tais como filtros de e-mail e templates personalizados necessitam de intervenção manual. Mais detalhes e sugestões de resolução de problemas são coleccionados no Wiki Debian.
| Nota |
|---|---|
Este problema está actualmente reportado como corrigido em Jessie. Se ainda for capaz de o reproduzir, então por favor siga o Debian Bug#766462. Note que poderá ter primeiro de desarquivar o problema (por favor consulte a documentação Debian BTS control server sobre como desarquivar bugs). |
Se tiver instalado vários ambientes de trabalho, pode experimentar que nenhuma das "consolas virtuais" mostre uma prompt de login.
Este problema parece ocorrer quando o plymouth, systemd, e GNOME estão instalados. Este problema
foi reportado como Debian Bug#766462.
Foi reportado que remover o argumento "splash" da linha de comandos do
kernel poderá contornar o problema. Por favor veja
/etc/default/grub e lembre-se de correr
update-grub após actualizar o ficheiro.
Existe um problema de compatibilidade no grub-pc com placas gráficas mais antigas
(e.g. com a "ATI Rage 128 Pro Ultra TR") que pode fazer com que apareça o
ecrã em branco durante o arranque. Pode aparecer uma mensagem "VGA signal
out of range" (ou algo similar).
Uma forma simples de contornar é definir
GRUB_TERMINAL=console no
/etc/default/grub.
O programa crontab é agora mais rígido e pode recusar-se
a gravar um ficheiro alterado se este for inválido. Se experimentar
problemas com crontab -e, por favor reveja o seu crontab
em erros existentes.
Desde a versão 5.18 (e 5.20, a qual foi incluída em Jessie), Perl irá
terminar com um erro fatal se encontrar caminhos não-legíveis para módulos
em @INC. O comportamento anterior era saltar tais
entradas. É recomendado verificar o conteúdo de @INC no
seu ambiente por directórios que não legíveis por todos, e tomar ação
apropriada.
Pode ver @INC predefinido para Perl ao correr
perl -V.
A versão de ganeti (2.12.0-3)
lançada com Jessie não suporta migrações de instalações que corram a versão
2.5 ou anteriores (incluindo Wheezy) em casos em que existam instâncias com
discos DRBD. É desejado que este problema venha a ser corrigido num
lançamento pontual, e é recomendado que entretanto não actualize os clusters
Ganeti afectados. Poderá encontrar mais informação sobre este problema no
Debian Bug#783186.
O procedimento recomendado para actualizar um cluster Ganeti da versão
(2.5.2-1) do ganeti do Wheezy para a
do Jessie (2.12.0-3) é parar todas as instâncias, depois actualizar e depois
reiniciar todos os nós de uma vez. Isto irá assegurar que todas as
instâncias correm o hypervisor com a versão do Wheezy e que todos os nós
correm as mesmas versões do Ganeti e de DRBD.
Note que correr um cluster com nós 2.5 e 2.12 misturados não é suportado. Note também que, dependendo do hypervisor, a migração live de instâncias poderá não funcionar entre versões de Wheezy e Jessie.
Se um cliente pedir um ficheiro para ser "aberto para execução", então o Samba4 necessitará que o bit executável esteja definido no ficheiro além das normais permissões de leitura. Isto também faz com que os scripts "netlogon" sejam ignorados silenciosamente se lhes faltar este bit executável.
| Nota |
|---|---|
Esta secção aplica-se apenas a quem alterou manualmente o seu
|
Se tiver instalados ambos os busybox e cryptsetup e configurado o initramfs para
não utilizar busybox, então poderá tornar o seu sistema
não iniciável.
Se tiver ambos os pacotes instalados por favor verifique o valor da sua
definição BUSYBOX em
/etc/initramfs-tools/initramfs.conf. Neste momento, as
formas conhecidas de contornar este problema são desinstalar busybox ou definir BUSYBOX=y
em /etc/initramfs-tools/initramfs.conf.
![[Atenção]](images/warning.png) | Atenção |
|---|---|
Se teve de efectuar quaisquer alterações, por favor lembre-se de correr
|
Por favor veja o Bug#496169 Debian para mais informações.
| | | |
| Capítulo 4. Actualizações a partir de Debian 7 (wheezy) |  | Capítulo 6. Mais informação acerca de Debian |