IL SEMBLE QUE VOUS UTILISEZ ADBLOC POUR BLOQUER LA PUBLICITÉ, AUCUNE PUB INTRUSIVE SUR FDZ ET PAS DE POPUP
FDZ EST GRATUIT DONC MERCI DE DÉSACTIVER VOTRE ADBLOCK ET DE BIEN VOULOIR PARTICIPER ET JOUER LE JEU


PAR SUITE D'ABUS LES SERVEURS CCCAM ET ABONNEMENT NE SONT PAS TOLÉRÉS SUR LE FORUM

Affichage des résultats 1 à 9 sur 9
Share |

Discussion: Ubuntu - insserv - très dangereux !

  1. #1
    Date d'inscription
    septembre 2009
    Messages
    90
    Remerciements
    1
    Remercié 1 fois dans 1 message
    Pouvoir de réputation
    9

    Par défaut [ Résolu ] Ubuntu - insserv - très dangereux !

    J'utilise Ubuntu depuis quelques jours et à chaque démarrage le message suivant apparait:

    EXT3FS: recovery required on read-only filesystem ...

    Ce système de fichier est la racine (/) ce qui signifie que la racine n'est pas démontée correctement avant le reboot ou le stop.

    Après investigation j'ai pu constaté qu'aucun système de fichier n'est démonté.

    Le problème est du à l'utilisation de insserv. Commande qui m'a permis de désactiver certains services.

    insserv à un bug sérieux semble-t-il. Lorsque l'on reboot on entre dans le runlevel 6, le système exécute les scripts présents dans le répertoire /etc/rc6.d, (en fait des liens vers les scripts de /etc/init.d) lançant d'abord ceux commençant par K puis ceux commençant par S. C'est un héritage de Unix System V. Chaque script se voit affecté un préfixe en K ou S et un numéro compris entre 00 et 99. Le système les lance dans l'ordre numérique puis lexicographique pour ceux ayant le même numéro.

    Mais insserv attribue a reboot le préfixe S01 , alors qu'il attribue à umountfs, umountroot et sendsigs (arrêt des processus) le même numéro mais leur nom commence par u et s, ils sont donc lancés après. Donc le script /etc/init.d/reboot (tout comme /etc/init.d/halt dans le runlevel 0) redémarre (stop) sans avoir invité les processus restant à quitter et sans avoir démonté les systèmes de fichier montés.

    Me voilà donc obligé de gérer les liens des répertoires /etc/rc6.d (reboot) et /etc/rc0.d (halt) à la main. A chaque utilisation de insserv ils sont perdus.

    Si quelqu'un connait une meilleur solution merci de m'en informer.
    Dernière modification par djezzyman ; 02/10/2009 à 20h11.

  2. #2
    Date d'inscription
    septembre 2009
    Messages
    90
    Remerciements
    1
    Remercié 1 fois dans 1 message
    Pouvoir de réputation
    9

    Par défaut sysvconfig - la solution

    sysvconfig est l'équivalent sous debian de system-config-services sous RedHat et Fedora.

    De toute évidence je vais me fier à cette utilitaire plutôt qu'à insserv dont je ne comprend pas ce qu'il fait encore dans la distribution Ubuntu. insserv inverse tout simplement l'ordre dans lequel les scripts critiques doivent être lancés, tout du moins lors de l'arrêt du système. Au point que je me demande s'il ne faut pas revoir complètement le contenu des dossiers /etc/rc*.d/.

    Menu principal:

    Cliquer ici pour agrandir

    Activation/Désactivation des services

    Cliquer ici pour agrandir

    Source : www.cyberciti.biz

    Ubuntu / Debian Linux: Services Configuration Tool to Start / Stop System Services
    Dernière modification par djezzyman ; 28/09/2009 à 03h09.

  3. #3
    Date d'inscription
    mars 2009
    Localisation
    Entre la chaise et le clavier
    Messages
    461
    Remerciements
    0
    Remercié 0 fois dans 0 messages
    Pouvoir de réputation
    9

    Par défaut Re : Ubuntu - insserv - très dangereux !

    Tu peux aussi voir de ce côté → http://ubunblox.servhome.org/gestion...ianubuntu.html

  4. #4
    Date d'inscription
    septembre 2009
    Messages
    90
    Remerciements
    1
    Remercié 1 fois dans 1 message
    Pouvoir de réputation
    9

    Par défaut Merci

    Je vais l'essayer aussi. L'arborescence /etc/rc?.d est endommagée. J'espère pouvoir revenir à la normale mais c'est compliqué. Même en relançant les configurations post-installation des paquets intégrant un service j'ai des problème avec l'ordre dans lequel les scripts sont lancés.

    Je vais tenter de générer un script de récupération à partir des scripts post-installaton du dossier /var/lib/dpkg/info.

    Merci.

  5. #5
    Date d'inscription
    mars 2009
    Localisation
    Entre la chaise et le clavier
    Messages
    461
    Remerciements
    0
    Remercié 0 fois dans 0 messages
    Pouvoir de réputation
    9

    Par défaut Re : Ubuntu - insserv - très dangereux !

    Tu peux peut-être récupérer ceux du live cd ?

  6. #6
    Date d'inscription
    septembre 2009
    Messages
    90
    Remerciements
    1
    Remercié 1 fois dans 1 message
    Pouvoir de réputation
    9

    Par défaut j'ai récupéré les configurations d'origine - résolu

    Utiliser le Live CD est une bonne idée je vais monter l'image squashfs du live CD pour voir. De toute façon j'ai téléchargé le DVD et j'ai copié l'arborescence dans une partition ext3 dédiée. Je peux au choix démarrer Ubuntu ou le DVD depuis le disque dur. Ce n'est pas dur avec GRUB.

    J'ai déjà récupéré les configurations d'origine depuis les scripts postinst de la base de donnée dpkg. Les scripts sont en fait des fichiers texte situés dans le dossier /var/lib/dpgk/info/, ils ont l'extension .postinst.

    Les paquets débian utilisent update-rc.d pour installer et supprimer les liens vers les services. Le paquet initscripts installe les services du niveau S ( phase du boot non interactive et utilisée aussi en mode recovery). Il définie une fonction updatercd qui appelle le vrai update-rc.d avec les mêmes arguments:

    Voici la partie interessante de la sortie de la commande: grep -E "update\-?rc" /var/lib/dpkg/info/initscripts.postinst

    updatercd mountkernfs.sh start 1 S .
    updatercd hostname.sh start 2 S .
    updatercd mountdevsubfs.sh start 11 S .
    #updatercd bootlogd start 5 S .
    updatercd checkroot.sh start 20 S .
    updatercd mtab.sh start 22 S .
    updatercd checkfs.sh start 30 S .
    updatercd mountall.sh start 35 S .
    updatercd mountall-bootclean.sh start 36 S .
    updatercd mountoverflowtmp start 37 S . stop 63 0 6 .
    updatercd mountnfs.sh start 45 S .
    updatercd mountnfs-bootclean.sh start 46 S .
    updatercd bootmisc.sh start 55 S .
    updatercd urandom start 55 S . start 30 0 6 .
    updatercd halt start 90 0 .
    updatercd reboot start 90 6 .
    updatercd umountroot start 60 0 6 .
    updatercd umountfs start 40 0 6 .
    updatercd umountnfs.sh start 31 0 6 .
    updatercd sendsigs start 20 0 6 .
    updatercd killprocs start 30 1 .
    updatercd single start 90 1 .
    updatercd bootlogs.sh start 70 1 2 3 4 5 .
    updatercd ondemand start 99 2 3 4 5 .
    updatercd rc.local start 99 2 3 4 5 .
    updatercd rmnologin start 99 2 3 4 5 .
    #updatercd stop-bootlogd-single start 99 S .
    #updatercd stop-bootlogd start 99 2 3 4 5 .

    On y voit par exemple que halt et boot ont le numéro 90 avec le préfixe S alors que insserv leur attribue le numéro 01 avec le même préfixe. Ils sont donc lancés les derniers alors qu'avec insserv ils étaient lancés les premiers.

    Le runlevel S contient pas mal de scripts critiques (checkfs mountall) et une initialisation désordonnée peut être catastrophique.

    J'ai pu ainsi retrouvé la commande d'installation de chaque service.

    grep -E "update\-?rc" /var/lib/dpkg/info/*.postinst

    et généré un script de réinstallation après avoir supprimé tous les liens des dossiers /etc/rc*.d/.

    Avec rpm les informations sur les paquets sont contenus dans une base de donnée au format Berkeley DB3 (ou DB4). On obtient les scripts avec la commande:

    rpm -q --scripts nom-du-paquet

    La sortie est un peu plus compliquée à traiter que sous débian car tous les scripts (preinst postinst preuninst postuinst ...) sont affichées en même temps.

    Conclusion:

    Toujours utiliser update-rc.d pour gérer les services actifs ou non au démarrage.

    Pour désactiver un service au démarrage:

    update-rc.d -f nom-du-service remove

    Pour le réactiver se référer au script d'installation pour récupérer les paramètres de la commande update-rc.d. Par exemple pour gdm:

    update-rc.d gdm defaults 30 01
    Dernière modification par djezzyman ; 29/09/2009 à 20h34.

  7. #7
    Date d'inscription
    mars 2009
    Localisation
    Entre la chaise et le clavier
    Messages
    461
    Remerciements
    0
    Remercié 0 fois dans 0 messages
    Pouvoir de réputation
    9

    Par défaut Re : Ubuntu - insserv - très dangereux !

    Content que ton problème sois résolu, n'oublie de le mettre dans le titre Cliquer ici pour agrandir

    Voyant tes compétences, je te conseille d'essayer Archlinux, on plus tu ne risque pas d'avoir le même problème et qui te permet de connaitre mieux GNU/Linux, car elle n'a pas d'outils spécifique à elle Cliquer ici pour agrandir

  8. #8
    HAVOC Visiteurs

    Par défaut Re : Ubuntu - insserv - très dangereux !

    Cliquer ici pour agrandir Envoyé par Tuxargon Cliquer ici pour agrandir
    Content que ton problème sois résolu, n'oublie de le mettre dans le titre Cliquer ici pour agrandir

    Voyant tes compétences, je te conseille d'essayer Archlinux, on plus tu ne risque pas d'avoir le même problème et qui te permet de connaitre mieux GNU/Linux, car elle n'a pas d'outils spécifique à elle Cliquer ici pour agrandir
    Bahhh... y'a pas d'outils graphiques sous archlinux mais c'est quand même mieux foutu que sous certaines autres distrib... là sous Debian des fois je galère pour un rien...enfin bon... j'ai enfin retenu les différentes commandes d'apt-get, apt-cache et apt-file... Là on s'asmuse avec chroot et debootstrap en TP.

  9. #9
    Date d'inscription
    septembre 2009
    Messages
    90
    Remerciements
    1
    Remercié 1 fois dans 1 message
    Pouvoir de réputation
    9

    Par défaut Résolu - Merci

    Je vais essayer ArchLinux. Cela ne coute rien.

    Je commence à me faire à cette distribution Ubuntu mais il demeure des problèmes majeurs.

    Comme le support Selinux. J'ai du compilé le noyau 2.6.31 et abandonner le noyau Ubuntu. De plus Ubuntu utilise un système de fichier tmpfs en mémoire pour les dossiers /var/run et /var/lock par exemple. Ils sont montés à chaque démarrage et démontés à l'arrêt. Or le dossier /var/run est utilisé par les services pour y stocker leurs fichiers .pid ou fichiers de socket pour les communications unix dans un sous dossier portant leur nom (dbus, setroubleshoot, cupsd, avahi-daemon ...).

    Mais voilà, à chaque arrêt ou redémarrage l'arborescence /var/run est dédruite. Par exemple à chaque démarrage le service dbus (bus système) échoue car le dossier /var/run/dbus n'éxiste pas. Mais dbus est très important. Sans lui hald, cups et beaucoup d'autres échoueront. Sans hal, gdm bloque (souris et clavier inaccessible). Il n'y a alors qu'une chose à faire. Appuyer sur le bouton power et attendre l'arrêt de la machine puis redémarrer Ubuntu en mode single.

    Compte-tenue de la taille du système de fichier /var/run (très petite 132k) j'ai choisi de désactiver le montage au démarrage avec l'option RAMRUN=no du fichier /etc/default/rcS. /var/run devient persistant entre les démarrages et c'est bien mieux car même restorecond échoue dans la surveillance du dossier /var/run/dbus.

    Théoriquement il doit veiller à ce que ce dossier ait le bon label selinux mais au démarrage il n'existe pas et il doit donc abandonner la surveillance. Et lorsque dbus démarrera /var/run/dbus n'aura pas le bon label s'il existe.

    Conclusion:

    /etc/default/rcS:
    RAMRUN=no
    RAMLOCK=no

    Sauvegarde et restauration de l'arborescence /var/run:

    find /var/run -type d|awk 'BEGIN{} {print "mkdir -p \x22"$0"\x22"} END{print "restorecon -R /var/run"}' >restore-var-run-tree.sh

    Il suffit maitenant de redémarrer avec les options selinux=1 single et dans un shell root:

    sh chemin/vers/restore-var-run-tree.sh

    puis continuer le démarrage avec resume.

Discussions similaires

  1. Les Cyclomotoristes à mobylette dangereux...
    Par zenagui dans le forum Actualités diverses
    Réponses: 1
    Dernier message: 02/06/2012, 11h24
  2. Le programme e-Algérie avance très très lentement
    Par salimdz dans le forum Actu - News High-Tech
    Réponses: 0
    Dernier message: 08/11/2011, 12h09
  3. [Actualités] Angry Alien – 30 secondes de lapins très très crêtins
    Par NewsBot dans le forum Actu - News High-Tech
    Réponses: 0
    Dernier message: 26/04/2010, 09h20
  4. [Problème] Pertes Synchronisations Fawri tres Fréquentes, Marge SNR Tres basse
    Par mDm dans le forum ADSL Algérie
    Réponses: 5
    Dernier message: 04/11/2009, 20h18
  5. [Problème] Alerte Telechergement dangereux
    Par BEN.YAS dans le forum Sécurité Informatique
    Réponses: 5
    Dernier message: 02/08/2009, 18h37

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •  
[Auto utilitaire DZ] [Webimag] [Algérie Info] [Guide Algérie] [Mosquée ALBADR MEAUX] [Photographe MARIAGE]

is PageRank Checking Icon