Forum Linux.debian/ubuntu lancement de Postgres

Posté par (page perso) .
Tags : aucun
0
15
juil.
2009
Bonjour

Exposé de mon problème :
J'ai une debian, une partiton cryptée et je veux faire tourner un server postgres dont les données sont stockées sur cette partition.

Ca marche, mais pas comme je veux.

Le prob c'est que : comme je monte la partiton cryptée après le log de mon user, on ne peut pas lancer postrgres au démarrage.

J'utilise cryptsetup et je me suis fait un script pour que mon user (peyo) puisse monter et demonter la partition cryptée. ça c'est bon avec un peu de sudoers.

Ce que je voudrais c'est que le user 'peyo' puisse démarrer le server postgres et la j'y arrive
pas.

Il n'y a que le user postgres qui puisse le faire. Là ça me dépasse un peu. J'ai ajouté peyo au groupe postgres, nada.

En gros comment je pourrais faire pour que 'peyo' ait tous les droits de 'postgres' ?

voici la ligne que je voudrais executer en tant que peyo :

/usr/lib/postgresql/8.3/bin/pg_ctl -D /mnt/datas/postgresql start

pg_ctl démarre le service. /mnt/datas/postgresql est le rep sur ma partoche cryptée dont tous les droits sont au user postgres



Merci de vos conseils.
  • # sudo est ton ami

    Posté par . Évalué à 1.

    ou à la limite, les groupes, mais je ne suis pas sûr que ça suffise
    • [^] # Re: sudo est ton ami

      Posté par (page perso) . Évalué à 1.

      sudo ne peut pas suffir, il y a besoin de droits dans le répertoire /mnt/datas/postgresql qui appartient au user postrges que ne donne pas sudo

      ou alors j'utilise mal sudo


      Mon script qui a terme doit permettre de monter la partoche cryptée et lancer postgres :
      #!/bin/bash

      case $1 in
      on)
      echo Montage de la partition cryptée
      sudo cryptsetup create datas /dev/hda3
      sudo mount -t ext3 /dev/mapper/datas /mnt/datas/
      echo Partition montée
      # /usr/lib/postgresql/8.3/bin/pg_ctl -D /mnt/datas/postgresql start
      ;;

      off)
      echo Démontage de la partiton cryptée
      sudo umount /mnt/datas/
      sudo cryptsetup remove datas
      echo Partiton démontée
      # /usr/lib/postgresql/8.3/bin/pg_ctl -D /mnt/datas/postgresql stop

      ;;
      esac

      Mon fichier sudoers :

      # /etc/sudoers
      #
      # This file MUST be edited with the 'visudo' command as root.
      #
      # See the man page for details on how to write a sudoers file.
      #

      Defaults env_reset

      # Host alias specification

      # User alias specification

      # Cmnd alias specification
      Cmnd_Alias CRYPTER = /sbin/cryptsetup
      Cmnd_Alias MNT = /bin/mount
      Cmnd_Alias UMNT = /bin/umount
      Cmnd_Alias PG = /usr/lib/postgresql/8.3/bin/pg_ctl

      # User privilege specification
      root ALL=(ALL) ALL
      peyo ALL=(ALL) NOPASSWD: CRYPTER
      peyo ALL=(ALL) NOPASSWD: MNT
      peyo ALL=(ALL) NOPASSWD: UMNT
      peyo ALL=(ALL) NOPASSWD: PG

      # Uncomment to allow members of group sudo to not need a password
      # (Note that later entries override this, so you might need to move
      # it further down)
      # %sudo ALL=NOPASSWD: ALL
  • # Et avec su tout court ?

    Posté par . Évalué à 1.

    Tu montes ta partition avec ton utilisateur peyo, puis tu lances le daemon postgres avec une commande du genre :
    $ su postgres -c "/usr/lib/postgresql/8.3/bin/pg_ctl -D /mnt/datas/postgresql start"
    ou
    $ su - postgres -c "/usr/lib/postgresql/8.3/bin/pg_ctl -D /mnt/datas/postgresql start"

    Evidement, il te demandera dans un cas comme dans l'autre le mot de passe de l'utilisateur postgres. Peut-être que ça peut se contourner en faisant un script contenant l'une ou l'autre de ces commandes, appartenant à root. J'ai pas testé, mais il est probable que ça fonctionne.
    La différence entre les deux commandes, c'est que le "su postgres" lance un shell interactif avec l'utilisateur sans charger l'environnement (/etc/profile et consorts), le "su - postgres" charge l'environnement.
    Voilà, en espérant que ça aide, comme on dit.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.