Aller au contenu
Règlement du forum ×
IPTV et arnaques ×

Ubuntu - insserv - très dangereux !


djezzyman

Messages recommandés

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.

Modifié par djezzyman
Lien vers le commentaire
Partager sur d’autres sites

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:

 

sysvconfig-1.jpg

 

Activation/Désactivation des services

 

sysvconfig-2.jpg

 

Source : http://www.cyberciti.biz

 

Ubuntu / Debian Linux: Services Configuration Tool to Start / Stop System Services

Modifié par djezzyman
Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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

Modifié par djezzyman
Lien vers le commentaire
Partager sur d’autres sites

Content que ton problème sois résolu, n'oublie de le mettre dans le titre :)

 

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 :)

 

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.

Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

  • Messages

    • @laliche je viens d'essayer mais ca ne marche pas, le seul moyen d'accéder au mode superadmin c'est de décrypter le fichier de configuration xml.. je viens de trouver le tutoriel que tu as publié   
    • Plus de 15 applications VPN gratuites sur Google Play utilisaient un SDK malveillant, transformant les appareils Android en proxys résidentiels. Les chercheurs de Human Security ont découvert que toutes les applications en question utilisaient un kit de développement logiciel (SDK) de LumiApps, qui contenait « ProxyLib », une bibliothèque golang pour effectuer le proxy. En mai 2023, ils ont identifié la première application utilisant ProxyLib, un VPN Android gratuit appelé Oko VPN. Par la suite, les chercheurs ont trouvé la même bibliothèque utilisée par le service de monétisation des applications Android LumiApps, comme ils l'indiquent dans leur rapport : « À la fin du mois de mai 2023, l'équipe de Satori a remarqué une activité sur des forums de hackers et de nouvelles applications VPN faisant référence à un SDK de monétisation, lumiapps[.]io. » Après une enquête poussée, il apparaît que ce SDK possède exactement les mêmes fonctionnalités et utilise la même infrastructure de serveur que les applications malveillantes analysées lors de l'enquête sur la version précédente de ProxyLib. LumiApps est utilisé légalement à des fins d'études publicitaires. Ils ont pu ainsi répertorier un ensemble de 28 applications qui utilisaient la bibliothèque ProxyLib pour transformer les appareils Android en proxys :     Lite VPN     Anims Keyboard     Blaze Stride     Byte Blade VPN     Android 12 Launcher (by CaptainDroid)     Android 13 Launcher (by CaptainDroid)     Android 14 Launcher (by CaptainDroid)     CaptainDroid Feeds     Free Old Classic Movies (by CaptainDroid)     Phone Comparison (by CaptainDroid)     Fast Fly VPN     Fast Fox VPN     Fast Line VPN     Funny Char Ging Animation     Limo Edges     Oko VPN     Phone App Launcher     Quick Flow VPN     Sample VPN     Secure Thunder     Shine Secure     Speed Surf     Swift Shield VPN     Turbo Track VPN     Turbo Tunnel VPN     Yellow Flash VPN     VPN Ultra     Run VPN Toutefois, on ignore si les développeurs d'applications gratuites savaient que le SDK transformait les appareils de leurs utilisateurs en serveurs proxy susceptibles d'être utilisés pour des activités indésirables. Les chercheurs pensent quant à eux que les applications malveillantes sont liées au fournisseur russe de services proxy résidentiels Asocks, après avoir observé les connexions effectuées sur le site web du fournisseur de proxy. Le service Asocks est souvent promu par les cybercriminels sur les forums de piratage.
    • Je ne connais pas cette astuce  mais essaye d'ajouter les 3 chiffres de l'indicatif international qui est 213 au début du numéro du fixe, je n'ai ni la fibre ni ce modem pour confirmer moi-même c'est juste une idée.
    • Normalement ca coûte rien moi heureusement que j'ai un accès total du modem sinon je vais acheté un autre 
    • C'est pas officiel , bruit de couloir de la radieuse , c l'oncle dun ami  qui m'a dit "débit min fibre 20 méga pr 2000da"
×
×
  • Créer...