Gerenciando scripts init rc.d por usuário

3

Eu quero delegar scripts de init do SysV para cada usuário.

Como o init do SysV, cada item em ${HOME}/rc.d começando com S será iniciado na inicialização do servidor com o argumento start . O mesmo para o servidor encerrado com aquele que inicia com K e com o argumento stop .

Eu mesmo pensei em criar scripts, mas talvez já exista algum tipo de implementação por aí 1 . Em resumo, seria um script em /etc/init.d/ que itera todos os usuários e lança runparts como o usuário nos scripts relevantes.

A plataforma aqui é um Linux (sabor Debian), mas eu acho que a solução seria bastante portátil entre várias plataformas do tipo Unix.

Atualização:

O ponto aqui é que os usuários possam criar seus próprios scripts de inicialização que devem ser iniciados em seu nome quando o sistema for inicializado. Como Dan Carley apontou, os serviços não poderão acessar nenhum ativo do sistema (portas privilegiadas, logs do sistema, etc.).

1. Dessa forma, não preciso pensar muito sobre todas as implicações de segurança sutis, como tempos limite de script, por exemplo ...

    
por Steve Schnepp 10.11.2009 / 14:53

5 respostas

4

Sua pergunta basicamente inclui a resposta .... Um script que irá percorrer um subdiretório de cada home de usuários, procurando por scripts executáveis. Então sudo -u user /export/home/user/scripts/scriptname.sh start. Você não terá controle sobre o que os scripts fazem, por isso você precisará confiar em seus usuários.

Insista para que eles escrevam seus scripts para aceitar stop start restart como $ 1 param e que eles não devem usar nenhuma variável de ambiente que tenha sido configurada em seus arquivos .profile, .cshrc ou .bashrc. O script precisa efetivamente ser autônomo.

#!/usr/bin/bash

run_cmd {
cd /export/home
for HOMEDIR in *; do
  for SCRIPT in /export/home/$HOMEDIR/scripts/*;  do
     if [ -x $SCRIPT ]; then
       echo "$ACTION user $HOMEDIR's script $SCRIPT"
       sudo -u $HOMEDIR $SCRIPT $ACTION &
     fi
  done
done

}

case $1 in
    start) ACTION=start;
           run_cmd;;
    stop) ACTION=stop;
           run_cmd;;
    restart) ACTION=stop;
             run_cmd;
             sleep 60;
             ACTION=start;
             run_cmd;;
    *) echo "$1 not recognized as valid cmd";;
esac

exit 0

Você precisará ajustar isso para o seu ambiente, local de bash / homedirs etc.

    
por 10.11.2009 / 17:12
1

The point here is for users to be able to create their own init scripts that should be launch on their behalf when the system boots up.

Isso já é possível na maioria dos sistemas, usando o utilitário cron . Basta instruir seus usuários a fazer o seguinte:

  1. execute o comando crontab -e
  2. adicione uma linha como a seguinte:

    @reboot /home/user/script argument

  3. salvar

Mais informações: link

    
por 26.11.2012 / 23:53
0

Não tenho certeza do que você quer alcançar, mas para mim, parece um pouco semelhante a .profile e .bash_logout, que são executados quando um usuário inicia um shell ou sai de um shell.

A diferença com a sua solução é que os scripts são executados quando o usuário faz login ou inicia um novo shell e não quando o computador é inicializado. Mas tenho que admitir que não me sentiria à vontade para permitir que qualquer usuário executasse scripts na inicialização ...

    
por 10.11.2009 / 15:36
0

Sua construção parece o resultado de um pesadelo:)

Basta fornecer aos seus usuários sudo acesso aos scripts de inicialização existentes, conforme necessário.

    
por 10.11.2009 / 16:30
0

Eu estaria inclinado a não permitir scripts e aplicar uma lista curta muito restrita de scripts e comandos enlatados que um usuário pode referenciar em um arquivo de lista simples que pode ser facilmente validado no momento da inicialização. Os scripts armazenados seriam armazenados em um local comum sem permissões de gravação do usuário. O arquivo de lista nomearia o script ou comando e quaisquer argumentos necessários. Um desses scripts comuns forneceria ao usuário o processamento de parada / início / reinício, se necessário, após o login.

O motivo de toda essa paranóia é em parte devido à segurança, mas mais pelo controle do que acontece durante a inicialização. Quero dizer, você pode imaginar que tipo de pesadelo seria se seus usuários se empolgassem com o início de todo tipo de coisas ao mesmo tempo "só porque eles podem"? Sem mencionar roteiros mal escritos.

Caso contrário, se você puder encontrar uma solução pronta que solucione esses problemas (que é um critério que você mencionou em sua pergunta), esse seria o caminho a ser seguido.

    
por 10.11.2009 / 20:01