Conflitos com arquivos de configuração do PAM ao atualizar o sistema

Question

Eu tenho um VPS que roda o Ubuntu 14.04.4 LTS; foi instalado como um todo com o Plesk by OVH. Eu fiz um apt-get upgrade , e em algum momento eu recebi uma mensagem sobre o PAM. O sistema está em francês, mas basicamente diz:

At least one file of /etc/pam.d/common-{auth,account,password,session} was modified locally. Please indicate if local changes should be discarded and stick with the standard configuration. Otherwise you will have to configure the authentication system by yourself.

Eu decidi manter as alterações locais, e o APT também relatou:

pam-auth-update: Local modifications to /etc/pam.d/common-*, not updating.
pam-auth-update: Run pam-auth-update --force to override.

Eu quero saber quais são as diferenças entre as alterações locais e os arquivos que a atualização deseja configurar. Como posso fazer isso?

    

Answer 1

Como eu não queria alterar a configuração ao vivo do PAM no sistema, acabei usando uma chroot jail para configurar uma configuração padrão do PAM para poder ver as diferenças:

# lsb_release --codename
Codename:       trusty
# debootstrap trusty /tmp/foo
I: Retrieving Release 
I: Retrieving Release.gpg 
  ...

Veja as diferenças:

for f in common-{account,auth,password,session,session-noninteractive}; do
  echo ==== $f ====
  diff --unified /etc/pam.d/$f /tmp/foo/etc/pam.d/$f
done

    

Answer 2

dpkg deve avisar e permitir que você veja um diff ( com D ) caso haja alterações feitas nos seus arquivos de configuração:

Configuration file '/etc/bash.bashrc'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** bash.bashrc (Y/I/N/O/D/Z) [default=N] 

Atualização: do comentário abaixo, o problema é com pacotes que não soltam arquivos de configuração completos (que é onde o comportamento acima é acionado), mas com arquivos que usam uma abordagem com script para gerar arquivos de configuração. O manual de políticas do Debian descreve isso como:

E.2 Fully-featured maintainer script configuration handling

For files which contain site-specific information such as the hostname and networking details and so forth, it is better to create the file in the package's postinst script.

This will typically involve examining the state of the rest of the system to determine values and other information, and may involve prompting the user for some information which can't be obtained some other way.

When using this method there are a couple of important issues which should be considered:

If you discover a bug in the program which generates the configuration file, or if the format of the file changes from one version to the next, you will have to arrange for the postinst script to do something sensible - usually this will mean editing the installed configuration file to remove the problem or change the syntax. You will have to do this very carefully, since the user may have changed the file, perhaps to fix the very problem that your script is trying to deal with - you will have to detect these situations and deal with them correctly.

If you do go down this route it's probably a good idea to make the program that generates the configuration file(s) a separate program in /usr/sbin, by convention called packageconfig and then run that if appropriate from the post-installation script. The packageconfig program should not unquestioningly overwrite an existing configuration - if its mode of operation is geared towards setting up a package for the first time (rather than any arbitrary reconfiguration later) you should have it check whether the configuration already exists, and require a --force flag to overwrite it.

Isso significa que você precisa contar com o programa packageconfig , para que o PAM /usr/sbin/pam-auth-update forneça uma opção de execução a seco ou visualização prévia.

E, até onde eu sei, /usr/sbin/pam-auth-update não oferece esse recurso.

    

Answer 3

Você pode fazer uma cópia de todo o diretório e, em seguida, executar um diff em cada arquivo para verificar as diferenças

cp -r /etc/pam.d/ /home/<user>/
pam-auth-update --force
diff /etc/pam.d/ /home/<user>/pam.d

Uma vez cuidadosamente passando por cada diferença, você pode decidir se deseja manter as alterações ou reverter as antigas. A reversão é tão simples quanto copiar os arquivos de volta para onde eles estavam

    

Answer 4

Acabei de ter este problema. No final, deixei pam-auth-update --force alterar os arquivos - depois notei que ele também salvou uma cópia dos arquivos antigos (por exemplo, como /etc/pam.d/common-foo.pam.old). O abaixo de uma linha então me mostrou os diffs:

for old in *.pam-old; do new="${old:0:-8}"; echo "=== $new ==="; diff $old $new; done

1. Faz um loop pelas cópias de backup;
2. Retira os últimos 8 caracteres para obter o nome do novo arquivo;
3. Echos o nome do arquivo (para que possamos ver qual contém cada alteração); e
4. Diferencia os arquivos antigos e novos