Capítulo 5. Problemas a estar atento na jessie

Índice

5.1. Limitações no suporte de segurança
5.1.1. Estado da segurança dos navegadores web
5.1.2. Falta de suporte de segurança para o ecossistema à roda de libv8 e Node.js
5.1.3. Fim antecipado do suporte de segurança do MediaWiki
5.2. Pré-definição do servidor OpenSSH para "PermitRootLogin without-password"
5.3. Compatibilidade Puppet 2.7 / 3.7
5.4. Actualização de PHP 5.6 tem alterações de comportamento
5.5. Alterações incompatíveis em Apache HTTPD 2.4
5.6. Actualizar instala o novo sistema init predefinido em Jessie
5.6.1. Mais rigoroso com mounts falhados durante o arranque sob systemd
5.6.2. init-scripts obsoletos devem ser purgados
5.6.3. Os init-scripts modificados localmente podem necessitar ser convertidos para systemd
5.6.4. É necessário o Plymouth para a prompt da arranque em arranques com systemd
5.6.5. Interação entre logind e acpid
5.6.6. Funcionalidades crypttab não suportadas sob systemd (e.g. "keyscript=...")
5.6.7. systemd: problemas com SIGKILL demasiado cedo [corrigido em 8.1]
5.6.8. systemd: comportamento do comando 'halt'
5.7. Opções de configuração do kernel necessárias para Jessie
5.8. Considerações de actualização para máquinas e containers LXC
5.8.1. Actualizar guests LXC que correm em máquinas Wheezy
5.8.2. Actualizar guests LXC correndo em anfitriões Jessie
5.8.3. Informação adicional
5.9. Migração manual de discos encriptados com LUKS whirlpool (configurações não-standard)
5.10. O Ambiente GNOME necessita de gráficos básicos 3D
5.11. O ambiente GNOME não funciona com o controlador proprietário FGLRX da AMD
5.12. Alterações aos atalhos de teclado predefinidos do GNOME
5.13. Alterações à shell predefinida dos utilizadores do sistema, disponibilizada por base-passwd.
5.14. Migração para o nome E-mail, Calendário e Contactos (Kontact) do KDE
5.15. Consolas virtuais ("getty"s) em falta com vários ambientes de trabalho
5.16. "VGA signal out of range" / ecrã em branco durante o arranque com grub-pc
5.17. Validação mais rígida de ficheiros cron no crontab
5.18. Alteração em lidar com caminhos ilegíveis de módulos de perl.
5.19. Considerações de actualização para clusters Ganeti
5.19.1. Problema ao actualizar clusters Ganeti com instâncias com DRBD [corrigido na 8.1]
5.19.2. Notas gerais sobre actualização de clusters Ganeti
5.20. Novos requisitos para a execução de ficheiros no Samba4
5.21. Cryptsetup pode estragar o arranque com BUSYBOX=n

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”.

5.1. Limitações no suporte de segurança

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.

5.1.1. Estado da segurança dos navegadores web

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.

5.1.2. Falta de suporte de segurança para o ecossistema à roda de libv8 e Node.js

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.

5.1.3. Fim antecipado do suporte de segurança do MediaWiki

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.

5.2. Pré-definição do servidor OpenSSH para "PermitRootLogin without-password"

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

5.3. Compatibilidade Puppet 2.7 / 3.7

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".

5.4. Actualização de PHP 5.6 tem alterações de comportamento

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.

5.5. Alterações incompatíveis em Apache HTTPD 2.4

[Nota]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]Nota

Durante a actualização, poderá também ver avisos sobre ficheiros de configuração colocados em /etc/apache2/conf.d/, os quais são disponibilizados por pacotes de Debian. Este aviso é inevitável mas inofensivo já que os pacotes afectados irão mover a sua configuração assim que a sua actualização for completada (o que geralmente acontece após o Apache HTTPD emitir o seu aviso).

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

5.6. Actualizar instala o novo sistema init predefinido em Jessie

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]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.

5.6.1. Mais rigoroso com mounts falhados durante o arranque sob systemd

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".

5.6.2. init-scripts obsoletos devem ser purgados

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.

5.6.3. Os init-scripts modificados localmente podem necessitar ser convertidos para systemd

[Nota]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.

5.6.4. É necessário o Plymouth para a prompt da arranque em arranques com systemd

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.

5.6.5. Interação entre logind e acpid

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.

5.6.6. Funcionalidades crypttab não suportadas sob systemd (e.g. "keyscript=...")

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.

5.6.7. systemd: problemas com SIGKILL demasiado cedo [corrigido em 8.1]

[Nota]Nota

Este problema foi corrigido no lançamento pontual Jessie 8.1.

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.

5.6.8. systemd: comportamento do comando 'halt'

A implementação do comando halt do sysvinit também desligava a máquina. A implementação do systemd-sysv pára o sistema mas não desliga a máquina. Para parar a máquina e desligá-la utilize o comando poweroff.

Veja também o bug Debian #760923.

5.7. Opções de configuração do kernel necessárias para Jessie

[Nota]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.

5.8. Considerações de actualização para máquinas e containers LXC

[Nota]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.

5.8.1. Actualizar guests LXC que correm em máquinas Wheezy

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.

5.8.2. Actualizar guests LXC correndo em anfitriões 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/CONTAINER_NAME/config. Necessitará acrescentar as seguintes duas definições à configuração:

lxc.autodev = 1
lxc.kmsg = 0

5.8.3. Informação adicional

Pode encontrar informação adicional sobre LXC em Debian no wiki Debian.

5.9. Migração manual de discos encriptados com LUKS whirlpool (configurações não-standard)

[Nota]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.

[Cuidado]Cuidado

Se tiver um desses discos, o cryptsetupirá, por omissão, recusar-se a desencriptar. Se o seu rootdisk ou outros discos de sistema (e.g. /usr) estiverem encriptados com whirlpool, deve migrá-los antes do primeiro reboot e após actualizar o cryptsetup.

5.10. O Ambiente GNOME necessita de gráficos básicos 3D

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.

5.11. O ambiente GNOME não funciona com o controlador proprietário FGLRX da AMD

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.

5.12. Alterações aos atalhos de teclado predefinidos do GNOME

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".

5.13. Alterações à shell predefinida dos utilizadores do sistema, disponibilizada por base-passwd.

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

  • mail

  • 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]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.

5.14. Migração para o nome E-mail, Calendário e Contactos (Kontact) do KDE

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.

5.15. Consolas virtuais ("getty"s) em falta com vários ambientes de trabalho

[Nota]Nota

This issue is currently reported as fixed in Jessie. Should you still be able to reproduce it, then please follow up to Debian Bug#766462. Note that you may have to unarchive the issue first (please refer to the Debian BTS control server documentation on how to unarchive 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.

5.16. "VGA signal out of range" / ecrã em branco durante o arranque com grub-pc

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.

5.17. Validação mais rígida de ficheiros cron no crontab

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.

5.18. Alteração em lidar com caminhos ilegíveis de módulos de perl.

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.

5.19. Considerações de actualização para clusters Ganeti

5.19.1. Problema ao actualizar clusters Ganeti com instâncias com DRBD [corrigido na 8.1]

[Nota]Nota

Este problema foi corrigido no lançamento pontual Jessie 8.1.

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.

5.19.2. Notas gerais sobre actualização de clusters Ganeti

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.

5.20. Novos requisitos para a execução de ficheiros no Samba4

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.

5.21. Cryptsetup pode estragar o arranque com BUSYBOX=n

[Nota]Nota

Esta secção aplica-se apenas a quem alterou manualmente o seu /etc/initramfs-tools/initramfs.conf para não utilizar busybox.

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]Atenção

Se teve de efectuar quaisquer alterações, por favor lembre-se de correr update-initramfs -u para actualizar o seu initramfs. Caso contrário, poderá mesmo assim acabar com um sistema não iniciável.

Por favor veja o Bug#496169 Debian para mais informações.