Instalando o ksh como o shell padrão no Redhat: Foolhardy?

3

Eu não sou um administrador de sistemas, mas minha organização está considerando a substituição de / bin / sh no Red Hat Enterprise Linux 6+ por um link físico para / bin / ksh. Quão imprudente seria isso?

O pano de fundo dessa pergunta é que estamos migrando um aplicativo de terceiros do AIX 5.3 para o RHEL 6+. Este aplicativo executa comandos shell invocando sh. Os próprios comandos shell são definidos pelo usuário e, na prática, foram escritos para o shell Korn (ksh). Isso funciona no AIX porque a IBM oferece sh como um link físico para o ksh. Ao longo dos anos, milhares de comandos definidos pelo usuário foram criados e armazenados por nossa equipe.

Descobrimos que alguns desses comandos falham no Red Hat, porque sh no Redhat é um link simbólico para o bash. Quando invocado como sh, o bash é executado no modo de emulação sh. O problema é que nossos comandos específicos do ksh (por exemplo, print) que costumavam funcionar em "fake sh" no AIX não funcionam em "fake sh" no Red Hat. Ainda não sabemos o escopo completo das incompatibilidades.

No capítulo 10 de Learning the Korn Shell (ISBN 0-596-00195-9), Bill Rosenblatt e Arnold Robbins dizem: "Queremos enfatizar algo sobre a casca de Korn que não se aplica à maioria dos outros. shells: você pode instalá-lo como se fosse o shell Bourne padrão, ou seja, como / bin / sh. " ... "Muitas instalações fizeram isso sem nenhum efeito negativo".

Quão tolo seria fazer isso na Red Hat? Minha preocupação é que scripts do sistema ou de terceiros na instalação do Red Hat possam depender de idiossincrasias sobre como sh é emulado pelo bash. Nesse caso, resolver nosso problema imediato com um link físico para o ksh pode causar uma quebra desconhecida em todo o sistema.

    
por Matt Fisher 04.04.2013 / 16:11

1 resposta

2

Em todo o sistema, isso seria muito imprudente exatamente pela razão que você suspeitar - isso causará uma quebra massiva nos scripts de inicialização e nos utilitários do sistema que dependem de um comportamento compatível com sh. Como Ulrich diz, uma alternativa muito mais segura é criar um chroot, ou simplesmente configurar o shell padrão de todos os novos usuários para / bin / ksh, embora isso não faça exatamente o que você quer.

    
por 04.04.2013 / 19:21