Forum Linux.redhat accès /dev/null et /dev2/null[RESOLU]

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
21
juil.
2014

Bonjour tout le monde !

Je suis face à une situation bizare :

Amanda Backup ne fonctionne plus car l'accès à /dev/null lui est refusé…

$ /usr/sbin/amcheck -m MyConfig
amcheck: nullfd: /dev/null: Permission denied
pourtant :
#ll /dev/null
crw-rw-rw- 1 root root 1, 3 jui 21 14:25 /dev/null

Le résultat est le même si je met amandabackup en owner ainsi que son groupe.
Le résultat est le même si je supprime /dev/null.
Le résultat est le même si j'exécute l'opération en tant que root (après avoir configuré amandabackup pour cela).

Je ne sais plus quoi faire.

De plus, j'ai depuis quelques temps un dossier /dev2 apparement identique à /dev. J'ignore d'où il vient et à quoi il sert.

RedHat 5.2

Je suis à la recherche de pistes, surtout pour le premier problème…

Merci d'avance.

  • # Curieux.

    Posté par  . Évalué à 4. Dernière modification le 21 juillet 2014 à 16:39.

    Que donne un « ls -ld /dev /dev2 » ?
    Que donne un « getfacl » sur /dev et /dev/null ?
    Que donne un « df -h /dev /dev2 » ?

  • # 50% résolu !

    Posté par  . Évalué à 2. 

    [16:54:10 root@cluster0-0:~ ]# ls -ld /dev /dev2
drwxrwxrwx 12 root nova 4360 jui 21 14:25 /dev
drwxr-xr-x 11 root nova 4096 avr 16 15:07 /dev2
# getfacl /dev
getfacl: Removing leading '/' from absolute path names
# file: dev
# owner: root
# group: nova
user::rwx
group::rwx
other::rwx

# getfacl /dev/null 
getfacl: Removing leading '/' from absolute path names
# file: dev/null
# owner: root
# group: nova
user::rw-
group::rw-
other::rw-

# df -h /dev /dev2
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
-                     7,9G  156K  7,9G   1% /dev
/dev/sda1             118G   16G   96G  14% / 

```MMh ca m'a permis de constater (comment j'ai pu manquer ça ? Oo) les droits sur /dev... après un petit chmod sur /dev l'erreur semble ne plus se produire merci beaucoup !!

Il reste cependant ce /dev2 qui est tout de même étrange non ?

    • [^] # Re: 50% résolu !

      Posté par  . Évalué à 2.

      Tu peux utiliser le lien « Répondre » en bas de chaque commentaire pour préserver le fil de la discussion.

      Pour /dev2, c'est assez étrange. Il n'est pas impossible qu'il s'agisse d'un rootkit, mais c'est un peu voyant tout de même. Le « ls » renvoie la date du 16 avril. Ça te dit quelque chose ?

      • [^] # Re: 50% résolu !

        Posté par  . Évalué à 2.

        Désole pour le commentaire inutile, je m'en suis rendu compte après coup mais impossible de modifier…

        J'ai peut être une piste, mais si c'est ça je sais pas du tout quoi faire (même si a priori ca ne gene pas le fonctionnement du serveur) :

        Suite à une erreur dans un script lancé en root, j'ai eu droit à un "mv / /mnt/backup/" qui à eu le temps de déplacer le /dev

        Après celà j'ai remis le /dev à sa place légitime et tout fonctionne à priori correctement mais peut etre que le /dev2 vient de la…
        Si c'est le cas, j'ai quoi comme solution ?

        • [^] # Re: 50% résolu !

          Posté par  . Évalué à 3.

          Fais un « mount | grep " /dev " » pour voir ce qui émule ton /dev mais, en principe, il s'agit d'un système de fichiers virtuel reconstruit à chaque redémarrage.

          À mon avis, techniquement, tu peux sans risque flanquer /dev2 aux oubliettes, à condition de bien vérifier qu'il n'y a rien d'autre dedans que ce qui ce se trouve déjà dans le /dev ordinaire. Mais avant de le faire, il faut quand même être certain de savoir ce qui l'a mis ici.

          Je pense également que ton « mv / /mnt/backup » n'a rien à voir dans tout cela. Je ne sais pas comment fonctionne Amanda Backup en particulier parce que je ne l'utilise pas, mais il est possible, bien que peu probable, qu'un système de backup quelconque ait voulu restaurer une ancienne copie et ai renommé le répertoire existant parce qu'il existait déjà. Ça paraît douteux quand même. Tu es sûr de ne plus te souvenir d'une opération particulière effectuée le 16 avril ?

          • [^] # Re: 50% résolu !

            Posté par  . Évalué à 1.

            A part le "mv /mnt/backup/dev/* /dev/ " pour remettre les choses à leur place non rien de spécial.

            mount | grep " /dev " ne renvoie absolument rien sur le serveur (mais fonctionne sur ma machine)
            Pour le moment je pense que je vais laisser ça comme c'est puisque tout fonctionne.

            Merci beaucoup en tout cas !

            • [^] # Re: 50% résolu !

              Posté par  . Évalué à 3.

              Je te suggère un petit coup de chkrootkit quand même. Je pense que ce n'est pas superflu dans ce genre de situation.

  • # SELinux?

    Posté par  . Évalué à 3.

    Hello,

    est-ce que SELinux ne serait pas activé?

    Pour le savoir:

    # getenforce

    et si la réponse est enforcing tu peux le mettre en permissive pour checker si ça règle ton problème:

    # setenforce 0

    @+

    • [^] # Re: SELinux?

      Posté par  . Évalué à 1.

      Bonjour !

      getenforce

      Disabled

      On dirait que non :/

Suivre le flux des commentaires

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