Capítulo 5. Problemas a serem considerados para a jessie

Índice

5.1. Limitações no suporte de segurança
5.1.1. Situação da segurança dos navegadores web
5.1.2. Falta de suporte de segurança para o ecossistema em torno da libv8 e Node.js
5.1.3. Término antecipado do suporte de segurança do MediaWiki
5.2. O servidor OpenSSH predefine PermitRootLogin without-password
5.3. Compatibilidade puppet 2.7 / 3.7
5.4. A atualização para PHP 5.6 tem mudanças de comportamento
5.5. Mudanças incompatíveis no Apache HTTPD 2.4
5.6. A atualização instala o novo sistema init padrão para Jessie
5.6.1. Tratamento mais rigoroso de falhas de montagem durante a inicialização sob systemd
5.6.2. Scripts init obsoletos devem ser expurgados
5.6.3. Scripts init modificados localmente podem precisar ser portados para o systemd
5.6.4. Necessidade do plymouth para prompts de inicialização sob inicializações com systemd
5.6.5. Interação entre logind e acpid
5.6.6. Recursos do crypttab não suportados pelo systemd (por exemplo, keyscript=...)
5.6.7. systemd: envia SIGKILL muito cedo [corrigido na 8.1]
5.6.8. systemd: comportamento do comando halt
5.7. Opções de configuração do kernel necessárias para a Jessie
5.8. Considerações de atualização para hospedeiros e contêineres LXC
5.8.1. Atualizando hóspedes LXC em execução sob hospedeiros Wheezy
5.8.2. Atualizando hóspedes LXC em execução sob hospedeiros Jessie
5.8.3. Informações adicionais
5.9. Migração manual de discos criptografados com LUKS whirlpool (configurações não padrão)
5.10. A área de trabalho GNOME necessita placa gráfica 3D básica
5.11. A área de trabalho GNOME não funciona com o driver FGLRX proprietário da AMD
5.12. Mudanças nos atalhos de teclado padrão do GNOME
5.13. Mudanças do shell padrão dos usuários do sistema fornecidos pelo base-passwd
5.14. Migração para os novos E-mail, Calendário e Contatos (Kontact) do KDE
5.15. Falta de consoles virtuais (gettys) com múltiplos ambientes de área de trabalho
5.16. VGA signal out of range / tela em branco durante a inicialização com o grub-pc
5.17. Validação mais rigorosa de arquivos cron no crontab
5.18. Mudança no tratamento dos caminhos de módulo ilegíveis pelo perl
5.19. Considerações de atualização para clusters Ganeti
5.19.1. Problema ao atualizar clusters Ganeti com instâncias suportadas por DRBD [corrigido na 8.1]
5.19.2. Notas gerais sobre a atualização de clusters Ganeti
5.20. Novos requisitos para execução de arquivos no Samba4
5.21. O cryptsetup pode quebrar a inicialização com BUSYBOX=n

Algumas vezes, mudanças introduzidas em uma nova versão têm efeitos colaterais que não podem ser evitados ou que acabam expondo bugs em outros locais. Esta seção documenta problemas conhecidos. Por favor, também leia a errata, a documentação dos pacotes relevantes, relatórios de bugs e outras informações mencionadas na Seção 6.1, “Leitura complementar”.

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

Há alguns pacotes onde o Debian não pode prometer fornecer portes retroativos mínimos para problemas de segurança. Esses são abordados nas subseções a seguir.

Note que o pacote debian-security-support, introduzido no Jessie, ajuda a acompanhar a situação do suporte de segurança dos pacotes instalados.

5.1.1. Situação da segurança dos navegadores web

O Debian 8 inclui diversos motores de navegadores que são afetados por um fluxo constante de vulnerabilidades de segurança. A alta taxa de vulnerabilidades e a ausência parcial de suporte do upstream na forma de ramos de longo prazo tornam muito difícil o suporte a esses navegadores com correções de segurança portadas retroativamente. Além disso, as interdependências das bibliotecas tornam impossível atualizar para uma versão upstream mais nova. Por isso, navegadores feitos sobre os motores webkit, qtwebkit e khtml foram incluídos no Jessie, mas não estão cobertos pelo suporte de segurança. Esses navegadores não devem ser usados em sites web não confiáveis.

Para uso geral de navegador web recomendamos Iceweasel ou Chromium.

Chromium - enquanto construído sobre a base de código Webkit - é um pacote sem dependência, que será mantido atualizado através da reconstrução das versões atuais do Chromium para a estável. O Iceweasel e o Icedove também serão mantidos atualizados através da reconstrução das versões ESR atuais para a estável.

5.1.2. Falta de suporte de segurança para o ecossistema em torno da libv8 e Node.js

A plataforma Node.js é construída em cima da libv8-3.14, que vivencia um alto volume de problemas de segurança, mas atualmente não há voluntários no projeto ou na equipe de segurança suficientemente interessados e dispostos a gastar a grande quantidade de tempo necessária para conter esses problemas encontrados.

Infelizmente, isso significa que a libv8-3.14, o nodejs e o ecossistema de pacotes node-* associados não devem ser atualmente utilizados com conteúdo não confiável, tal como dados não avaliados oriundos da Internet.

Além disso, esses pacotes não receberão quaisquer atualizações de segurança durante o tempo de vida da versão Jessie.

5.1.3. Término antecipado do suporte de segurança do MediaWiki

O suporte do upstream para a série 1.19 do mediawiki termina durante o ciclo de vida esperado da Jessie. O pacote mediawiki está incluído na Jessie para satisfazer dependências em outros pacotes.

O suporte de segurança para o mediawiki terminará juntamente com o suporte para o Wheezy em abril de 2016.

5.2. O servidor OpenSSH predefine PermitRootLogin without-password

Em uma tentativa de fortalecer a configuração padrão, a configuração do openssh-server agora predefinirá "PermitRootLogin without-password". Caso você confie na autenticação por senha para o usuário root, você pode ser afetado por essa mudança.

O openssh-server tentará detectar esses casos e aumentar a prioridade dos seus avisos do debconf.

Caso você queira manter a autenticação por senha para o usuário root, você também pode predefinir esta pergunta usando:

$ echo 'openssh-server openssh-server/permit-root-login boolean true' | debconf-set-selections

5.3. Compatibilidade puppet 2.7 / 3.7

Caso você esteja usando Puppet, por favor, esteja ciente de que o Puppet 3.7 não é compatível com o anterior Puppet 2.7. Além de outras coisas, as regras de escopo mudaram e muitas estruturas de controle (constructs) obsoletas foram removidas. Veja as notas de lançamento do Puppet 3.x para algumas das mudanças, apesar de estar ciente de que há mudanças adicionais no 3.7.

Verificar os arquivos de log do seu puppetmaster atual em busca de advertências de código obsoleto e resolver todas essas advertências antes de proceder com a atualização fará com que seja muito mais fácil completar a atualização. Alternativamente, ou adicionalmente, testar os manifestos com uma ferramenta como o teste de catálogo Puppet também pode encontrar possíveis problemas antes da atualização.

Quando atualizar um sistema gerenciado pelo Puppet de Wheezy para Jessie, você deve garantir que o puppetmaster correspondente execute, pelo menos, a versão 3.7 do Puppet. Caso o mestre esteja executando o puppetmaster do Wheezy, o sistema Jessie gerenciado não será capaz de conectar ao mesmo.

Para mais informações sobre as alterações incompatíveis, por favor, dê uma olhada em problemas de atualização Telly e The Angry Guide to Puppet 3.

5.4. A atualização para PHP 5.6 tem mudanças de comportamento

A atualização para Jessie inclui uma atualização do PHP de 5.4 para 5.6. Isso pode afetar quaisquer scripts PHP e você é aconselhado a verificar esses scripts antes de atualizar. Abaixo, está um subconjunto selecionado desses problemas:

  • Para prevenir ataques do tipo man-in-the-middle contra transferências criptografadas, os streams de clientes agora verificam os certificados dos pares por padrão.

    Como resultado dessa mudança, um código existente usando wrappers de stream ssl:// ou tls:// (por exemplo, file_get_contents(), fsockopen(), stream_socket_client()) pode não conectar-se mais com sucesso sem desabilitar manualmente a verificação de pares através do ajuste verify_peer no contexto do stream.

    Para mais informações sobre esse problema específico, por favor, leia este documento.

  • PHP muda o tratamento de insensibilidade a maiúsculas e minúsculas em muitos casos:

    • Todo tratamento interno de insensibilidade a maiúsculas e minúsculas para nomes de classes, funções e constantes é feito de acordo com as regras ASCII. As regras do locale atual são ignoradas.

    • As chaves self, parent e static agora são sempre insensíveis a maiúsculas e minúsculas.

    • A função json_decode() não aceita mais variantes não minúsculas dos valores boolean.

  • As funções de GUID logo (por exemplo, php_logo_guid()) foram removidas.

  • Não é mais possível sobrescrever chaves em matrizes escalares estáticas. Por favor, veja o bug 66015 do PHP para um exemplo e mais informações sobre esse problema específico.

  • As funções mcrypt_encrypt(), mcrypt_decrypt() e mcrypt_{MODE}() não aceitam mais chaves ou VIs com tamanhos incorretos. Além disso, um VI agora é necessário caso o modo de codificação de bloco utilizado o requeira.

  • Por razões legais, a implementação do JSON distribuída com o PHP foi substituída pela versão fornecida pelo módulo PECL jsonc. O código que faz suposições sobre os detalhes de implementação mais finos do parser JSON PHP pode precisar de ser revisado.

  • O ajuste short_open_tag agora está desabilitado por padrão. As tags curtas (<? e ?>) estão planejadas para remoção no PHP7.

Para mais informações ou a lista completa de possíveis problemas, por favor, dê uma olhada na lista do upstream de mudanças incompatíveis com versões anteriores para o PHP 5.5 e 5.6.

5.5. Mudanças incompatíveis no Apache HTTPD 2.4

[Nota]Nota

Esta seção se aplica apenas a sistemas que tenham um servidor Apache HTTPD instalado e configurado manualmente.

Houve uma série de mudanças na configuração do servidor HTTPD Apache na versão 2.4. No lado do upstream, a sintaxe mudou. Notavelmente, as diretivas de controle de acesso mudaram consideravelmente e precisarão de migração manual para as novas diretivas.

O módulo mod_access_compat é mencionado no guia de atualização do upstream como uma alternativa possível para migração imediata. Porém, os relatos sugerem que ele pode nem sempre funcionar.

O gerenciamento dos arquivos de configuração também mudou no empacotamento do Debian. Em particular, todos os arquivos de configuração e sites agora devem terminar com .conf para serem analisados por padrão. Essa mudança também substitui o uso já existente do /etc/apache2/conf.d/.

[Nota]Nota

Durante a atualização, você também pode ver avisos sobre arquivos de configuração colocados em /etc/apache2/conf.d/, que são fornecidos por pacotes do Debian. Este aviso é inevitável, mas inofensivo, pois os pacotes afetados moverão suas configurações uma vez que suas atualizações sejam concluídas (o que geralmente acontecerá depois que o HTTPD Apache emitir o seu alerta).

Para mais informações e a lista completa das mudanças, por favor, consulte:

5.6. A atualização instala o novo sistema init padrão para Jessie

A Jessie vem com o systemd-sysv como sistema init padrão. Esse pacote é instalado automaticamente nas atualizações.

Caso você tenha uma preferência por outro init, tal como sysvinit-core ou upstart, é recomendado configurar o pinning do APT antes da atualização. Isso também pode ser necessário se você estiver atualizando contêineres do LXC antes do hospedeiro. Nesse caso, por favor, consulte Seção 5.8.1, “Atualizando hóspedes LXC em execução sob hospedeiros Wheezy”.

Como um exemplo, para evitar que o systemd-sysv seja instalado durante a atualização, você pode criar um arquivo 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 ciente de que alguns pacotes podem ter um comportamento degradado ou podem faltar recursos sob um sistema init não padrão.

Por favor, note que a atualização pode instalar pacotes contendo systemd em seu nome, mesmo com o pinning do APT. Esses sozinhos não alteram o seu sistema init. Para usar o systemd como o seu sistema init, o pacote systemd-sysv deve ser instalado primeiro.

Caso o APT ou aptitude tenham problemas para calcular um caminho de atualização com o pinning habilitado, é possível que você seja capaz de ajudá-los instalando manualmente tanto o sysvinit-core quanto o systemd-shim.

5.6.1. Tratamento mais rigoroso de falhas de montagem durante a inicialização sob systemd

O novo sistema init padrão, systemd-sysv, tem um tratamento mais rigoroso das falhas de montagem do tipo auto durante a inicialização, comparado ao sysvinit. Caso ele falhe ao montar uma montagem do tipo auto (sem a opção nofail), o systemd cairá em um shell de emergência em vez de continuar a inicialização.

Recomendamos que todos os pontos de montagem removíveis ou opcionais (por exemplo, unidades de rede não críticas) listados em /etc/fstab tenham a opção noauto ou a nofail.

5.6.2. Scripts init obsoletos devem ser expurgados

Caso você esteja atualizando a partir de uma versão anterior, o seu sistema pode conter scripts init obsoletos fornecidos por pacotes (agora) removidos. Esses scripts podem ter metadados de dependência imprecisos ou inexistentes, que podem levar a ciclos de dependência na sua configuração de init.

Para evitar isso, recomendamos que você reveja a lista de pacotes que estão em estado rc (Removido, mas permanecem arquivos de configuração), e expurgue, pelo menos, todos aqueles que contenham scripts init.

Por favor, veja Seção 4.8.1, “Expurgando pacotes removidos” para detalhes sobre como encontrar e expurgar pacotes removidos.

5.6.3. Scripts init modificados localmente podem precisar ser portados para o systemd

[Nota]Nota

Esta seção se aplica apenas aos sistemas onde os scripts init fornecidos no Debian foram modificados localmente.

Caso você tenha modificado alguns dos scripts init fornecidos pelo Debian, por favor, esteja ciente que esses podem agora ter sido substituídos por um arquivo de unidade systemd ou pelo próprio systemd. Caso você tenha o debsums instalado, você pode verificar scripts init modificados localmente usando o seguinte comando shell.

debsums -c -e | grep ^/etc/init.d

Alternativamente, pode ser usado 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

Caso um dos comandos sinalize quaisquer arquivos e seus pacotes correspondentes ou o systemd agora forneça um arquivo de unidade systemd para esse serviço, o arquivo de unidade systemd prevalecerá sobre o seu script init modificado localmente. Dependendo da natureza da mudança, há formas diferentes de realizar a migração.

Caso necessário, é possível substituir o arquivo de unidade systemd para que inicie o script sysvinit. Para mais informações sobre arquivos de unidade systemd, por favor, dê uma olhada nos seguintes recursos.

5.6.4. Necessidade do plymouth para prompts de inicialização sob inicializações com systemd

Caso a sua inicialização seja interativa (por exemplo, precise de uma senha para um disco criptografado), por favor, certifique-se de que você tem o plymouth instalado e configurado. Por favor, consulte o /usr/share/doc/plymouth/README.Debian para informações sobre como configurar o plymouth.

Sem o plymouth, você pode descobrir que o prompt de inicialização desaparece. Relatos sugerem que o prompt do cryptsetup ainda aceita entrada apesar de não estar visível. Se você enfrentar esse problema, digitar a senha correta pode ainda funcionar.

5.6.5. Interação entre logind e acpid

Eventos ACPI podem ser tratados pelo logind ou acpid. No caso de ambos os serviços estarem configurados para tratarem os eventos de maneiras diferentes, isso pode levar a resultados indesejáveis.

Recomendamos migrar todas as configurações não padrão para logind e desinstalar o acpid. Alternativamente, também é possível configurar o logind para ignorar eventos ACPI adicionando:

HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=ignore

ao /etc/systemd/logind.conf. Note que isso pode mudar o comportamento dos ambientes de área de trabalho que dependem do logind.

5.6.6. Recursos do crypttab não suportados pelo systemd (por exemplo, keyscript=...)

Há alguns recursos do cryptsetup que, infelizmente, não são suportados quando se está usando o systemd como sistema init. Esses são:

  • precheck

  • check

  • checkargs

  • noearly

  • loud

  • keyscript

Caso o seu sistema dependa de qualquer um desses recursos para inicializar com sucesso, você terá que usar o sysvinit (sysvinit-core) como sistema init. Por favor, consulte Seção 5.6, “A atualização instala o novo sistema init padrão para Jessie” para saber como evitar um sistema init em particular.

Você pode verificar se alguma dessas opções está em uso em seu sistema executando o seguinte comando:

grep -e precheck -e check -e checkargs -e noearly -e loud -e keyscript /etc/crypttab

Se não houver saída no comando acima, o seu sistema não utiliza nenhuma das opções afetadas.

5.6.7. systemd: envia SIGKILL muito cedo [corrigido na 8.1]

[Nota]Nota

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

Uma regressão foi relatada no systemd após o lançamento da Jessie. A falha ocorre durante o desligamento ou reinicialização, onde o systemd não dá nenhum atraso razoável antes de enviar SIGKILL aos processos. Isso pode levar à perda de dados em processos que não tenham salvado todos os dados no momento da reinicialização (por exemplo, bancos de dados em execução).

Esse problema é monitorado no bug #784720 do Debian

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 faz o sistema parar, mas não desliga a máquina. Para fazer a máquina parar e desligá-la, use o comando poweroff.

Veja também o bug #760923 do Debian

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

[Nota]Nota

Esta seção é apenas para pessoas que compilam o seu próprio kernel. Caso você utilize os kernels compilados pelo Debian, pode ignorar esta seção.

As seguintes opções de configuração do kernel agora são necessárias ou recomendadas para a Jessie (além das existentes de versões anteriores):

# Necessária para udev
CONFIG_DEVTMPFS=y
# Necessária para *alguns* serviços do systemd
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# Necessária para "bluez" (GNOME)
CONFIG_BT=y
# Necessária para cups + systemd.
CONFIG_PPDEV=y

Os serviços do systemd que requerem CONFIG_DEVPTS_MULTIPLE_INSTANCES=y tipicamente conterão, pelo menos, uma das seguintes diretivas:

PrivateTmp=yes
PrivateDevices=yes
PrivateNetwork=yes
ProtectSystem=yes

Se você não usar o systemd, ou puder afirmar que nenhum dos serviços do systemd usará as diretivas acima, a opção de configuração pode não ser necessária para o seu sistema em particular.

Para mais informações sobre os requisitos, por favor, consulte a seção chamada REQUIREMENTS no arquivo README para o pacote systemd.

5.8. Considerações de atualização para hospedeiros e contêineres LXC

[Nota]Nota

Esta seção se aplica apenas a sistemas que tenham contêineres e hospedeiros LXC. Sistemas de usuários finais normais geralmente não dispõem disso.

A atualização de Wheezy para Jessie migrará o seu sistema para o sistema init systemd por padrão (veja Seção 5.6, “A atualização instala o novo sistema init padrão para Jessie”).

Ao atualizar um contêiner LXC ou uma máquina virtual LXC, isso terá diferentes consequências dependendo se o sistema do hospedeiro já tiver sido atualizado para Jessie ou não.

5.8.1. Atualizando hóspedes LXC em execução sob hospedeiros Wheezy

Caso você esteja atualizando um contêiner hóspede LXC que esteja sendo executado em um sistema hospedeiro Wheezy, então você precisará evitar que o hóspede seja automaticamente migrado para systemd. Você evita a migração através de pinning, como descrito em Seção 5.6, “A atualização instala o novo sistema init padrão para Jessie”.

Isso é necessário porque o hospedeiro Wheezy não possui funcionalidades para inicializar um sistema executando o systemd.

Você deve ser capaz de mudar para o systemd dentro do hóspede LXC uma vez que você tenha atualizado o sistema hospedeiro para Jessie. Veja o próximo parágrafo para as coisas que precisam ser adaptadas em hospedeiros Jessie.

5.8.2. Atualizando hóspedes LXC em execução sob hospedeiros Jessie

Para ser capaz de inicializar hóspedes LXC com systemd, você precisa adaptar a sua configuração do contêiner LXC. A configuração do contêiner pode normalmente ser encontrada em /var/lib/lxc/NOME_DO_CONTEINER/config. Você precisa adicionar os dois seguintes ajustes na configuração:

lxc.autodev = 1
lxc.kmsg = 0

5.8.3. Informações adicionais

Você pode encontrar informações adicionais sobre LXC no Debian no wiki do Debian.

5.9. Migração manual de discos criptografados com LUKS whirlpool (configurações não padrão)

[Nota]Nota

Esta seção é apenas para pessoas que criaram discos criptografados com LUKS utilizando a hash whirlpool. O debian-installer nunca suportou a criação de tais discos.

Caso você tenha configurado manualmente um disco criptografado com LUKS whirlpool, precisará migrá-lo manualmente para uma hash mais forte. Você pode verificar se o seu disco está usando whirlpool utilizando o seguinte comando:

# /sbin/cryptsetup luksDump <disk-device> | grep -i whirlpool

Para mais informações sobre migração, por favor, veja o item 8.3 Gcrypt 1.6.x and later break Whirlpool da FAQ cryptsetup.

[Cuidado]Cuidado

Caso você tenha um tal disco, o cryptsetup recusará descriptografá-lo por padrão. Caso o seu disco raiz ou outros discos de sistema (por exemplo, /usr) estejam criptografados com whirlpool, você deve migrá-los antes da primeira reinicialização após atualizar o cryptsetup.

5.10. A área de trabalho GNOME necessita placa gráfica 3D básica

A área de trabalho GNOME 3.14 na Jessie não tem mais suporte alternativo para máquinas sem placas gráficas 3D básicas. Para funcionar adequadamente, é necessário um PC suficientemente recente (qualquer PC fabricado nos últimos 10 anos deve ter o suporte necessário a SSE2) ou, para arquiteturas diferentes de i386 e amd64, um adaptador gráfico com aceleração 3D com drivers EGL.

5.11. A área de trabalho GNOME não funciona com o driver FGLRX proprietário da AMD

Ao contrário de outros drivers OpenGL, o driver FGLRX da AMD para placas Radeon não suporta a interface EGL. Como tal, vários aplicativos GNOME, incluindo o núcleo da área de trabalho GNOME, não iniciarão quando esse driver estiver em uso.

Em vez disso, é recomendado usar o driver livre radeon, que é o padrão na jessie.

5.12. Mudanças nos atalhos de teclado padrão do GNOME

O atalhos de teclado padrão na área de trabalho GNOME mudaram para melhor corresponder aos utilizados em alguns outros sistemas operacionais.

As definições de atalho previamente modificadas pelo usuário serão preservadas na atualização. Essas definições ainda podem ser configuradas pelo centro de controle do GNOME, acessível a partir do menu superior direito, clicando no ícone configurações.

5.13. Mudanças do shell padrão dos usuários do sistema fornecidos pelo base-passwd

A atualização do pacote base-passwd redefinirá o shell de alguns usuários do sistema para o shell nologin. Isso inclui os seguintes usuários:

  • daemon

  • bin

  • sys

  • sync

  • games

  • man

  • lp

  • mail

  • news

  • uucp

  • proxy

  • www-data

  • backup

  • list

  • irc

  • gnats

  • nobody

Caso a sua configuração local necessite que qualquer um desses usuários tenha um shell, você deve dizer não à migração, ou migrar e então mudar o shell dos usuários correspondentes. Exemplos notáveis incluem backups locais feitos através do usuário backup com autenticação ssh-key.

[Cuidado]Cuidado

A migração acontecerá automaticamente se a sua prioridade de pergunta do debconf for alta ou superior.

Caso você saiba que quer manter o shell atual de um determinado usuário, você pode pré-configurar as perguntas usando o seguinte:

echo 'base-passwd base-passwd/system/nome_do_usuario/shell/shell-atual-modificado/_usr_sbin_nologin boolean false' | debconf-set-selections

Onde nome_do_usuario é o nome do usuário em questão e shell-atual-modificado é o nome modificado do shell. A modificação é feita substituindo todos os caracteres que não sejam alfanuméricos, hifens e sublinhados por sublinhados. Por exemplo, /bin/bash torna-se _bin_bash.

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

O sistema de gerenciamento de informações pessoais Kontact recebeu uma grande atualização. A nova versão torna muito maior o uso da indexação de metadados e os dados de cada usuário devem ser migrados para esses novos índices.

E-mail, eventos do calendário e contatos da lista de endereços são automaticamente migrados quando o usuário fizer login e o componente relevante for iniciado. Algumas configurações avançadas, tais como filtros de e-mail e modelos personalizados, necessitam de intervenção manual. Detalhes adicionais e sugestões de solução de problemas estão coletados na Wiki do Debian.

5.15. Falta de consoles virtuais (gettys) com múltiplos ambientes de área de trabalho

[Nota]Nota

Esse problema está atualmente relatado como corrigido na Jessie. Se você ainda for capaz de reproduzi-lo, então, por favor, acompanhe o bug #766462 do Debian. Note que você pode ter que desarquivar o problema primeiro (por favor, consulte a documentação do servidor de controle BTS do Debian sobre como desarquivar bugs).

Caso você tenha múltiplos ambientes de área de trabalho instalados, é possível que nenhum dos consoles virtuais apresente um aviso de login.

Esse problema parece ocorrer quando plymouth, systemd e GNOME estão todos instalados. Esse problema está relatado como bug #766462 do Debian.

Foi relatado que removendo o argumento splash da linha de comando do kernel pode-se contornar o problema. Por favor, veja o /etc/default/grub e lembre-se de executar update-grub após atualizar o arquivo.

5.16. VGA signal out of range / tela em branco durante a inicialização com o grub-pc

Há um problema de compatibilidade no grub-pc com placas gráficas mais antigas (por exemplo, a ATI Rage 128 Pro Ultra TR) que pode fazer com que uma tela em branco seja mostrada durante a inicialização. O monitor pode emitir uma mensagem VGA signal out of range (ou algo semelhante).

Uma solução simples é definir GRUB_TERMINAL=console em /etc/default/grub.

5.17. Validação mais rigorosa de arquivos cron no crontab

O programa crontab agora é mais rigoroso e pode se recusar a salvar um arquivo cron modificado caso ele seja inválido. Caso você tenha problemas com o crontab -e, por favor, revise o seu crontab em busca de erros existentes.

5.18. Mudança no tratamento dos caminhos de módulo ilegíveis pelo perl

A partir da versão 5.18 (e 5.20, que está incluída na Jessie), o Perl sairá com um erro fatal caso ele encontre caminhos de módulo ilegíveis em @INC. O comportamento anterior era ignorar tais entradas. É recomendado verificar o conteúdo do @INC em seu ambiente em busca de diretórios que não possam ser lidos por todo mundo e tomar a medida apropriada.

Você pode ver o @INC padrão para Perl executando perl -V.

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

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

[Nota]Nota

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

A versão do ganeti (2.12.0-3) lançada com a Jessie não suporta migrações de instalações que utilizam a versão 2.5 ou mais antigas (incluindo Wheezy) nos casos onde há instâncias com discos DRBD. Espera-se que esse problema seja corrigido em um lançamento pontual, e recomenda-se que você não atualize clusters Ganeti afetados enquanto isso. Você pode encontrar mais informações sobre esse problema no bug #783186 do Debian.

5.19.2. Notas gerais sobre a atualização de clusters Ganeti

O procedimento recomendado para atualizar um cluster Ganeti da versão do ganeti da Wheezy (2.5.2-1) para o da Jessie (2.12.0-3) é parar todas as instâncias e então atualizar e reinicializar todos os nós de uma só vez. Isso garantirá que todas as instâncias funcionem com a versão do hypervisor da Jessie e que todos os nós funcionem com as mesmas versões do Ganeti e DRBD.

Note que a execução de um cluster com um misto de nós 2.5 e 2.12 não é suportado. Também note que, dependendo do hypervisor, migrações em tempo real de instâncias podem não funcionar entre as versões do hypervisor da Wheezy e da Jessie.

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

Caso um cliente solicite que um arquivo deve ser aberto para execução, o Samba4 exigirá que o bit executável esteja ativado no arquivo, além das permissões normais de leitura. Isso também faz com que os scripts netlogon sejam silenciosamente ignorados caso eles não tenham esse bit executável ativado.

5.21. O cryptsetup pode quebrar a inicialização com BUSYBOX=n

[Nota]Nota

Esta seção se aplica apenas a pessoas que alteraram manualmente o seu /etc/initramfs-tools/initramfs.conf para não usar o busybox.

Caso você tenha tanto o busybox quanto o cryptsetup instalados, além do initramfs configurado para não usar o busybox, então ele pode tornar o seu sistema não inicializável.

Por favor, verifique o valor do sua configuração do BUSYBOX no /etc/initramfs-tools/initramfs.conf caso você tenha ambos os pacotes instalados. Neste momento, alternativas conhecidas são desinstalar o busybox ou definir BUSYBOX=y no /etc/initramfs-tools/initramfs.conf.

[Atenção]Atenção

Caso você tenha que fazer alguma mudança, por favor, lembre-se de executar update-initramfs -u para atualizar o seu initramfs. Caso contrário, você ainda pode acabar com uma inicialização quebrada.

Por favor, veja o bug #783297 do Debian para mais informações.