anakin a écrit 256 commentaires

Ok, mais dans ce cas, il faut mettre des regexp pour chaque type de fichier ?
Quelle est l'expression régulière permettant que ce soit appliqué à tous les fichiers ? (sans pour autant que cela gêne la coloration syntaxique propre à des fichiers sources d'autres langages)

Merci

Bon bah en fait ca marche pas cette commande...
Comment faire pour faire l'équivalent de M-x conf-mode à chaque démarrage ?

Merci ;)

Oui ca marche merci.
Bon bah en m'inspirant de ce qu'il y avait dans mon .emacs après ça (des lignes mis automatiquement par tuareg-mode), j'ai mis ça finalement :

(autoload 'conf-mode "conf-mode" "Run the Conf Mode for UNIX conf files" t)


Comme ça, c'est chargé automatiquement ;)

@++

En fait, le problème vient d'Icecast je pense finalement. Etant donné que le port 1337 lorsqu'il est ouvert avec Waste, possède exactement les mêmes caractéristiques que le port 8000 (même retour dans nmap, même règles iptables, etc...).
Donc Icecast doit se planter quelque part dans la gestion du réseau.

Bon il se passe des trucs vraiment bizarre mais je crois que j'arrive à cibler un peu plus le problème :
J'ai testé avec Waste le port 1337 en tant que serveur, et là aucun problème la connexion s'établit bien de l'extérieur.
Donc le problème vient uniquement de l'attribution du port 8000.

En se connectant depuis un autre ordinateur, je me suis rendu compte qu'est apparu furtivement dans les connexions actives de firestarter, la bonne entrée, c'est à dire source : ip distante, destination : ip privée locale, port : 8000. Mais la connexion durait pas...pourtant dans les règles de firestarter, 8000 est bien autorisé pour tout le monde.
Mais en fait, c'est là que je me rend compte que la ligne contenant 127.0.0.1:
http://www.hiboox.com/lang-fr/image.php?img=hbdsnp31.jpg
est active en permanence, dés l'activation de Icecast. Le fait qu'elle soit présente lorsqu'une autre connexion, de l'extérieur elle, se fait doit poser problème, d'où la faible durée de vie...

Nan, en fait j'ai dit une bêtise, dans tous les cas le port est filtered d'après nmap sur l'adresse publique....
Rien à faire

Bon bah j'ai testé de l'extérieur c'est pareil !
Mais le problème vient surement de Icecast qui n'arrive pas à ouvrir correctement le port 8000 qui reste filtered vu de l'extérieur.
Alors que si j'utilise deluge par exemple avec le port 8000, là ca marche...Et le test d'ouverture du port fonctionne aussi là

Bon apparemment, on ne peut pas accéder de l'intérieur du réseau à l'adresse IP publique...
D'après ce post sur les forums d'ubuntu http://ubuntuforums.org/showthread.php?t=772125&highligh(...)


Are you trying to can your public address from inside a router? That cannot be done - the router won't NAT a connection that comes from the inside to the inside. You'll have to ue an external service like grc shields-up to scan your public address.


ET effectivement, lorsque j'essaye sur GRC, le port 8000 est bien ouvert...
Reste à tester sur une machine distante

Une autre curiosité aussi. Lorsque je fais
lsof -i:8000
Voilà le résultat :

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
icecast2 32535 icecast2 0u IPv4 275940 TCP localhost:8000->localhost:43293 (ESTABLISHED)
icecast2 32535 icecast2 4u IPv4 275787 TCP *:8000 (LISTEN)
mpd 32575 mpd 7u IPv4 275939 TCP localhost:43293->localhost:8000 (ESTABLISHED)


Le 43293 est juste un port aléatoire qui change (après redémarrage de icecast et de mpd).
On se rend compte quand même là qu'il y a un bouclage pas trop normal, non ? localhost:8000 > localhost:43293> localhost:8000

Bizarre...

Le problème, c'est que je diffuse pas 24/24...donc ca va pas être facile.
J'essayerai de tenter depuis une autre machine quand je pourrai ;)

Voici quelques détails en plus
- La version de MPD est compilée à partir des sources svn. Cela dit, je ne pense pas que le problème vienne de là, étant donné qu'en local, le son marche.

-Un truc aussi que je me demandais, on peut bien utiliser l'adresse http://`mon_ip_publique`:8000/mpd.ogg même si l'on est sur une machine derrière cette adresse publique ?
Il me semble que ca marchait avant, mais je voudrais en être sûr...
Car en fait, lorsque je dis que je teste de l'extérieur, j'entends par là que j'utilise explicitement l'adresse IP publique dans l'adresse du flux à lire...

J'ai bien la ligne
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN

Merci
@++

Oui je voulais naturellement parler non pas de toutes les barres d'outils possibles, mais des plus utilisées pour ma part (barre pour les numérotations automatiques et barre pour les tableaux entre autres).

Voici ce que je viens de voir sur un post du forum ubuntu-fr lui-même révélant les dires de OVH :


Communiqué de OVH :
Bonjour,
Une importante faille de sécurité a été mise en évidence ce week-end
sur l'ensemble des noyaux Linux 2.6.XX que vous pouvez utiliser chez
Ovh (et pas seulement). Aucun patch de sécurité (grsecurity, PaX,
Openwall, etc) ne bloque ce bug. La seule possibilité de fixer le
bug est de mettre à jour votre kernel vers la dernière version de
Linux 2.6.24.2 (mis à jour hier soir à 21H51 !!).

Ce bug est TRÈS dangereux: n'importe quel utilisateur du serveur
permet d'avoir les droits de root en moins de 10 secondes !! Très très
simplement. En suite c'est foutu car il fait réinstaller le serveur.
Même si vous ne proposez pas de shell/bash sur vos serveurs, à travers
les scripts php, cgi etc on peut avoir l'accès root sur la machine.

Ne remettez pas à demain ou à ce soir cette mise à jour ! Il y a 1h
environ, on vient de bloquer le 1er serveur hacké avec cette méthode.
Et avec ce bug, c'est la sécurité du réseau qui est en dangers. Nous
n'allons donc pas hésiter 1 seconde de bloquer votre serveur s'il est
hacké. Prenez donc 10 minutes là pour exécuter ces quelques commandes
simples.

Ovh propose des noyaux patchés, verifiés et sécurisés contre ce bug
de sécurité. Aussi, le nouveau noyau supporte mieux les cartes réseaux
utilisés sur le hardware chez Ovh, l'iSCSI, ainsi qu'une tonne de
petits bugs du Kernel.

Comment mettre à jour le noyau en moins de 5 minutes ? Très simplement.
Même si vous n'avez jamais fait, vous allez réussir cette mise à jour smile

1.)
Connectez vous sur le serveur en SSH et tapez (copier coller):
# wget -q ftp://ftp.ovh.net/made-in-ovh/dedie/pat … e-sysfs.sh -O - | /bin/bash
# wget -q ftp://ftp.ovh.net/made-in-ovh/rtm/install_rtm.sh -O - | /bin/bash
Ceci met à jour votre RTM, le patch sysfs, 3ware. Une sécurité de plus
avant le reboot.

2.)
Dans le manager, choisissez "netboot" et puis "ipv4", puis la version
"32bits" ou "64bits" (ça dépend la distribution que vous utilisez)
Par exemple "bzImage-xxxx-std-ipv4-32"
En suite reconnectez sur sur le serveur en SSH et tapez
# reboot
Attendez le redémarrage du serveur (entre 2 et 5 minutes en fonction du
serveur) puis reconnectez-vous sur le serveur en SSH puis tapez:
# uname -a
La commande doit vous renvoyer la version 2.6.24.2. Par exemple:
# uname -a
Linux oles2.ovh.net 2.6.24.2-xxxx-std-ipv4-32 #1 SMP Mon Feb 11 14:51:26

Si vous n'utilisez pas le netboot, vous pouvez telecharger nos noyaux
sur ftp://ftp.ovh.net/made-in-ovh/bzImage
bzImage-2.6.24.2-xxxx-std-ipv4-32
bzImage-2.6.24.2-xxxx-std-ipv4-32-hz1000
bzImage-2.6.24.2-xxxx-std-ipv4-64-hz1000
bzImage-2.6.24.2-xxxx-std-ipv6-32
bzImage-2.6.24.2-xxxx-std-ipv4-32-filer
bzImage-2.6.24.2-xxxx-std-ipv4-64
bzImage-2.6.24.2-xxxx-std-ipv4-64-rescue
bzImage-2.6.24.2-xxxx-std-ipv6-64

Les noyaux GRSecurity ne sont pas encore disponible. Le patch sera dispo
sous quelques jours.

Si vous compilez vous-même le noyau, vous pouvez trouver notre .tar.gz
ainsi que les .config sur ftp://ftp.ovh.net/made-in-ovh/bzImage

Si vous avez des problèmes, merci d'utiliser le forum ou la mailing list
afin qu'on vous aide très directement. N'oubliez pas mettre le nom de
votre serveur dédié dans vos messages (chaque message). Sur le forum:
http://forum.ovh.com/showthread.php?t=31396

Merci à tous et bon patch !

Les clients qui ont pris l'option sécurité totale sont en cours de mise
à jour (déjà).

Amicalement
Octave

Pareil aucun problème visible apparemment en appliquant ce patch. Ca ne veut pas dire qu'il ne posera pas problème ailleurs.

Le navigateur Opera permet de personnaliser par site quels trucs on veut activer (Flash, Java, Javascript, Cookies, etc...)
Ca doit être possible sous Firefox (via une extension ?), j'ai jamais essayé ;)

Bon il semblerait qu'un classique remplissage de zéro par la commande :
dd if=/dev/zero of=fichier bs=1M
Jusqu'à atteindre un taux presque plein de la partition, puis suivi d'un sync et enfin, de la suppression de fichier arrive à faire apparemment le ménage ! Ouf
Faut que je continue à faire des essais mais à priori, c'est sur la bonne voie ;)
Je suis en train de regarder la doc de secure-delete qui contient certains outils un peu plus évolué que shred :
cf
http://www.techthrob.com/tech/securedelete.php
Notamment un outils permettant de nettoyer l'espace libre (comme la commande au dessus)

Voilà, qu'en pensez-vous ?

Il se pourrait qu'il reste encore des fichiers en fait sur la partition.
J'ai beau cherché, impossible de trouver un fichier qui contiendrait ça...
J'ai déjà regardé tous les fichiers dans firefox, fais quelques grep par ci par là, mais rien...
Le problème de strings, c'est qu'il ne dit pas à quel endroit il lit le flux de données...
Mais comme je sais pas si ces infos sont dans un fichier ou pas, c'est plus dur...
Il faudrait faire une recherche sur tous les fichiers du disque dur (ou du moins dans certains répertoires) qui contiennent tels chaîne de caractère... J'ai tenté avec un grep sur une sortie d'un cat, mais il me dit parfois que la liste d'arguments est trop longue...Bizarre non ?

Impossible de me défaire de certaines métadonnées qui apparaissent toujours dans le grep en sortie du strings sur une partition.
J'ai pourtant fais plusieurs redémarrage (donc démontage de partition) depuis pourtant...et j'ai cherché les fichiers dans lequel pouvait rester encore des traces : j'ai cru un moment avoir réussi puisque le grep renvoyait moins de chose, mais là c'est revenu...A croire que le système de fichier reiserfs fait ce qu'il veut avec les données.
En gros, il est facile de récupérer des données de cookies de firefox avec ce système...malgré tous les effacements qu'on peut imaginer.
J'ai regardé l'outils sync, mais ca n'a pas l'air de faire grand chose...
Ce qu'il faudrait faire c'est monter la partition reiserfs avec des paramètres adéquat (quitte à le faire qu'une seule fois de temps en temps), personne n'a d'idée ? KiKouN signalait l'option notail ?

Merci ;)

Ok, merci pour vos réponses.
J'envisageais effectivement (avant cette découverte) de changer de système de fichier (repasser à ext3). L'ennui, c'est que c'est la partition système ;)
Qu'entends-tu par l'option notail ?
Et pour le sync, je sais pas si l'option est dispo pour du reiserfs ?

En tout cas, si je fais un grep de texte par exemple d'historique d'un navigateurs internet, on peut remonter assez loin...;) Et ces données ne sont pas dans le cache, l'exemple du fichier texte, c'était...pour l'exemple.
Si je dois faire de temps en temps des montages avec certaines options pour virer ces infos, pourquoi pas ?

Même problème sous Gnome + Compiz. J'ai beau tester toutes les configurations possibles du focus dans Compiz, impossible d'obtenir un comportement comme sous Windows ;)

Et cela peut aussi favoriser les migrations futures...

Par panique, j'ai posté trop vite, c'était juste un problème de partition. L'utilisation de cet outils a modifié le type de la première partition de manière assez curieuse (la première partition du disque). J'ai restauré une image de la partition que j'avais faite et tout est rentré dans l'ordre.
En absence de message d'erreur, j'avais pas pensé que ca pouvait être ce problème, je pensais à un truc plus grave du côté du matériel ;)

Personne n'a d'idée sur la question ?
Je ne sais pas si le problème vient de emacs ou de Gnome...

Dans ce cas, si ce n'est pas un bug mais une fonctionnalité, j'ose espérer que c'est désactivable dans les nombreuses options de emacs ? ;)
Merci
@++