Bon, après, comme nous on est courtois et serviables, je répond quand même : une fois le paquet xvfb installé, il faut, si on veut qu'il soit lancé au démarrage :
- soit écrire un script d'init ou en récupérer un qui marche (un script prévu pour redhat devra être adapté, j'en avais fait un du temps de la woody mais vu l'ancienneté je ne vais même pas essayer de le retrouver, il y a toutes les chances qu'il marche moyennement et soit crade)
- soit procéder selon la méthodologie éprouvée de La Rache - http://www.la-rache.com : installer anacron et créer un travail cron @reboot pour qu'il soit lancé au démarrage. C'est porc mais ça tourne.
Pour le reste j'en sais rien, j'ai jamais utilisé ça. Pour la conversion PDF j'utilise une imprimante cups.
Généralement les mises à jour sont pas si délicates que ça à faire et je trouve dommage qu'on essaie de ralentir l'évolution d'un système sous prétexte qu'un développement interne risque de ne pas fonctionner.
Je serais assez de cet avis. Mais l'expérience me prouve le contraire. Même des mises à jour de version mineures posent parfois des problèmes majeurs. Le souci, c'est que le client qui a payé pour le développement d'un site ne voit pas pourquoi il devrait payer à nouveau un développement pour prendre en compte la mise à jour (souvent avec un autre prestataire), alors que ça « juste marche ». Du point de vue du client, ça se comprend, on n'a qu'à se démerder. Les marchés publics notamment ont une grande inertie. Bizarrement, la maintenance pour fonctionner avec un système plus récent n'est jamais comprise dans le marché :-)
Quant à dire que php5 est sorti il y a 5 ans, c'est vrai, mais je constate qu'il n'est pas répandu en entreprise depuis si longtemps que ça.
Par contre, personne ne m'a jamais demandé de faire tourner quelque chose en php3 depuis au moins 2001. Comme quoi c'est variable.
Les changements de la distribution de base ne me posent pas de problème. La libc, openssl, le noyau, ce genre de chose, sauf cas très particulier, c'est le problème de l'admin, l'applicatif n'a aucun impact : résultat on se débrouille. Les développements d'un client en php et mysql effectués avec un vieux « php pour les nuls » sous les yeux, c'est une autre paire de manche.
A la limite, les développements internes me posent moins de souci. On peut toujours, effectivement, faire la part des choses entre le coût d'administration d'un système obsolète et le coût d'une évolution du code. Mais le client ne veut pas avoir ce type de problèmes, sinon il ne prendrait pas de prestation d'infogérance.
Je n'ai jamais dit que ce type de support prolongé devait nécessairement être fourni par Debian, ni gratuit. Je pense que ça pourrait aussi se faire via une équipe de volontaires. Les entreprises intéressées contribueraient probablement du temps et des moyens.
Problème minime, problème minime... Après, tout dépend de ce contre quoi tu veux te protéger, hein. C'est juste une histoire de gestion du risque, de confidentialité des données traitées (quand les données en question sont tes données personnelles, tu es bien content que l'entreprise qui en a la charge fasse attention à ce qu'elles ne se retrouvent pas dans la nature).
Pour l'exemple de découverte du réseau, l'icmp c'est quand même le plus vieux protocole pour ça :-)
Sinon, un exemple typique de découverte du réseau et de fingerprinting en une passe : envoyer un paquet icmp echo request sur l'adresse broadcast, et regarder qui répond quoi. Ou encore sur l'adresse du réseau, même principe. Les fonctionnement par défaut des os sont assez disparates (y'a ceux qui répondent normalement, ceux qui l'ignorent, ceux qui répondent un truc spécifique...).
Quand aux dangers du fingerprinting, je suis assez d'accord à la base, mais au final c'est, plus qu'une véritable mesure de sécurisation (assimilable à une porte blindée ou une serrure), un truc qui permet de ralentir ou de décourager le pirate de passage. Ca ne fera que ralentir un peu le vrai gars déterminé, mais déjà si on s'est débarrassé des attaques automatiques et des Jean-Kévin c'est toujours ça de pris. On peut comparer ça au fait de mettre sa maison sur une colline un peu escarpée :-)
Bon, après, le défaut c'est que ça peut avoir l'effet inverse chez le hacker - le vrai - curieux : « tiens ça m'a l'air bien protégé par ici... Est-ce que je vais réussir à passer, et qu'est-ce que ça cache ? » ;-)
En plus on parle théorie, là, dans la vraie vie on n'a pas toujours le loisir de mettre autant de protections de manières systématique. Encore une fois, c'est une question de gestion du risque, il faut faire le rapport entre le risque qu'on prend quand on ne le fait pas et ce que ça coûte (en argent, temps, énergie...).
bon je sais c'est tardif mais c'était les vacances....
Toujours est-il que ce n'est pas forcément une question de confiance, c'est une question de contrat.
Quand on parle de réseau, ce n'est pas forcément un réseau d'utilisateurs... Ca peut être des serveurs, le tunnel icmp peut être une manière furtive de sortir des données, et ça peut poser un problème aux utilisateurs du dit serveur. Il y a peut-être des données confidentielles et personnelles dessus. Si quelqu'un parvient à s'introduire sur le serveur (mettons par une faille php, classique), l'idée est qu'il ne puisse pas sortir d'information sans que ça se voie... En plus j'ai déjà vu un gros truc bien évident (type reverse backdoor bloquée par le firewall, tentatives maladroite d'escalade de privilège) qui servait surtout à dissimuler une fuite d'information via un tunnel icmp ou DNS...
Et puis bon, pour les réseaux interne, la question n'est pas de savoir si c'est bien ou pas, c'est de savoir si tu veux avoir la maîtrise de ton réseau. Si on bloque le ssh à l'extérieur, c'est pas pour laisser passer un truc aussi vieux qu'un tunnel icmp. Si on ne le bloque pas, on loggue au moins les accès externe pour savoir qui se connecte où, et faire la différence entre le gars qui se connecte de temps en temps chez lui pour faire de l'irc (inoffensif et pas gênant a priori) et celui qui uploade une énorme quantité de données en ukraine... Personnellement je n'ai aucun problème à laisser sortir un utilisateur en ssh pour se connecter à un serveur perso entre midi et deux, mais le jour où ça sert à sortir des infos confidentielles, c'est que je n'ai pas joué mon rôle. Sans parler du jour où ça sert à lancer des attaques dictionnaire un peu partout... ;-)
La sécurité, c'est pas simple, ce n'est pas les gentils utilisateurs contre les vilains admins, ni l'inverse ; et surtout ça ne peut se faire que si tout le monde y met du sien. Il ne s'agit pas de s'aliéner les utilisateurs (même si parfois il y a des têtes de c**), mais de se protéger contre les indélicats (le gars qui passe plus de temps à bosser sur des trucs perso que pour l'entreprise, celui qui joue double jeu et tente de récupérer des clients à son compte avant de démissionner...), et contre les maladresses (j'ai cliqué sur le mauvais lien, ça m'a installé un troyen et maintenant on est attaqués en justice parce que notre ip de sortie a servi à pirater un ordinateur du minefi).
Bien sûr qu'un type déterminé y arrivera. Ce n'est qu'une question de savoir faire, de motivation et de temps. Mais moi je suis payé pour lui compliquer la vie ! ;-)
Je m'aperçois que je n'ai peut-être pas été très clair : commente-donc la ligne qui correspond au dépot chez tuxfamily, et réessaye d'installer fusion-icon avec le gestionnaire de paquet de ton choix, après avoir mis à jour les listes de paquets.
De préférence, utilise un gestionnaire de paquets qui sait repérer les paquets installés localement (aptitude fait ça très bien) pour les supprimer et les remplacer par la version debian le cas échéant.
On dirait bien que tu utilises un vieux, très vieux dépot pour fusion-icon.
En ce qui me concerne je n'utilise plus fusion-icon depuis un bon moment, mais je peux te dire que fusion est bien là, dans les dépots officiels, sous le nom compiz-fusion.
Quand ils existent, il faut toujours utiliser les paquets officiels. (Corrolaire : quand ils n'existent pas il faut les faire soi-même et tenter de les faire inclure, comme ça au moins tu sais qu'ils sont fait proprements> à ta convenance ;-) )
Ca dépend aussi (beaucoup) de ta carte graphique. Enfin, de son driver.
Avec une (vieille) nvidia et twinview je n'ai aucun souci pour faire tourner compiz, et le choix d'un cube sur les deux écrans ou de deux cubes (qui tournent en simultané) se fait dans la configuration des effets du cube.
J'ai lu qu'il y a pas mal de problème avec les drivers ATI propriétaires (même que c'est ce qui me freine pour acheter une ATI), mais que ça marche assez bien avec les drivers libre (si ta carte fait de la 3D avec les drivers libres).
Pour les jeux, quoi qu'il arrive, il vaut mieux lancer un serveur X dédié quand tu veux en lancer un. Sinon ça a tendance à tout faire planter avec compiz... Enfin, si le jeu se lance en plein écran (généralement il se lance sur un seul, à condition que la résolution choisie soit supportée par un seul écran).
Dans tous les cas, avec twinview, tu as en fait un seul bureau, avec peut-être quelques pseudos éléments de xinerama (peut-être que tout ça est géré par freedesktop maintenant) qui sont en fait surtout des hints pour les gestionnaires de fenêtres.
Sinon si tu veux vraiment deux bureaux séparés, alors il te faut vraiment du xinerama (avec deux cartes, ou alors j'ai cru comprendre qu'un mode des drivers ATI propriétaires permettaient de faire ça aussi). La tu pourra passer le pointeur d'un écran à l'autre, faire des copier/coller, mais pas déplacer de fenêtres de l'un à l'autre.
Tu peux utiliser utiliser la méthode STONITH (Shoot The Other Node In The Head), chère à keepalived
Je voulais évidemment dire : « chère à heartbeat ». Ma langue a fourché. (et ici, il ne s'agit donc pas d'autosatisfaction récursive mais de contrôle qualité ;-) )
Etienne a bien résumé le problème du LB sur des switches différents. De toutes manières, il n'y a pas d'intérêt à faire du load-balancing ici : il s'agit juste de limiter le risque de bascule intempestive. Donc fail-over.
Je trouve ça court aussi. Je rêve d'un support de sécurité étendu (disons 2 ou 3 ans après la sortie de stable+1 au lieu d'un an) pour un sous-ensemble de paquets, sur un sous-ensemble d'architectures si il le faut. C'est que c'est pas nécessairement facile de passer de php4 à php5, par exemple. Y'a des applis qui le supportent mal, et y'a pas d'argent pour redévelopper, ou alors si mais dans 1 an, d'ici là on laisse comme c'est et tant pis.
Pour les serveurs (ou même les stations de travail) ça serait le pied. Le choix des paquets pourrait se faire à l'avance (le popularity contest ou les mainteneurs qui inscrivent leur paquet dans la liste par exemple), avec une équipe moins fermée que security (comme l'équipe qui s'occupe de la sécurité de testing).
Steve Langasek évoquait quelque chose comme ça il y a un an ou deux il me semble.
En ce qui me concerne, j'ai quelques réticences à basculer sur Ubuntu pour les serveurs, mais la LTS me fait de l'oeil depuis un moment, avec le cycle de support de Debian qui se raccourcit de fait. Ce qui m'embête c'est que la LTS ne sort pas quand elle est prête, mais quand sa date de sortie arrive...
Je proposerai bien cette idée sur debian-project mais j'ai un peu peur de déclencher une flamewar, on va la tester un peu ici d'abord ;-)
Normalement, quand on migre d'un domaine à un autre, on établit une relation d'approbation entre les deux domaines pour que les utilisateurs d'un domaine soient autorisés sur l'autre. C'est une fonctionnalité kerberos, je crois. Voilà pour la théorie.
Après ton vrai souci est que ton PDC samba c'est du NTLM, et le contrôleur de domaine (pas primaire, ça n'existe plus avec AD) c'est de l'AD... Et que ça ne marche pas pareil.
Mais tu dois pouvoir inscrire ton PDC samba (TOTO) sur l'AD (TITI) pour que les utilisateurs de titi soient valides. Par contre il va falloir faire ça soigneusement au niveau nss pour que les utilisateurs de titi et les utilisateurs locaux soient considérés comme valides. Par contre avec une fedora 4 j'ai peur que la compatibilité AD soit pas terrible... Cela dit tu n'y coupera pas si tu veux pouvoir y accéder à partir du domaine TITI.
Tu devrais aller voir les docs Technet de microsoft sur la migration NTLM -> Active directory, il y a sûrement des méthodes que tu pourras adapter.
Je pense que le mieux est (en fonction du nombre d'interfaces évidemment) de faire un bonding 802.3ad avec 2 interfaces sur les firewall pour les connecter aux 2 switches.
Avec une communauté lacp entre les switches, et un peu de spanning tree, ça évite les boucles, et ça devrait résoudre ton souci : avoir à la fois le trunk (2 liens) et l'interface connectée à l'autre switch qui tombe, ça devient vraiment improbable. Tu as plus de chance de voir les deux switches ou les deux firewall cramer en même temps.
Tu peux utiliser utiliser la méthode STONITH (Shoot The Other Node In The Head), chère à keepalived pour t'assurer de n'avoir qu'un master à la fois : tu fais un script qui tombe les interfaces frontales de l'autre firewall (ou désactive les ports du switch...) quand tu passe master si tu arrive toujours à le joindre par une autre interface, et tu l'appelles quand tu passe en état "master".
Il y a sûrement d'autres méthodes, et je suis sûr qu'on peut imaginer d'autres scénarios catastrophe, c'est toujours la m*** quand on mélange L2 / L3 et qu'on veut être redondant.
Je vois que cette version permet de s'authentifier via HTTP POST, et c'est une bonne nouvelle, ça permet de protéger (enfin) des appli comme cacti sans les modifier (anciennement, pour ceux qui ne connaissent pas, il fallait soit un support natif, soit que la reconnaissance des utilisateurs se fasse via les en-têtes).
Par contre je ne trouve pas comment faire dans la doc, ni dans le manager (que ça soit la démo ou la version que j'ai installée vite fait)... Quelqu'un sait ?
Rien à faire, on installe les paquets et ça tourne... Il y a même le shadowing de session locale qui marche (mais c'est pas aussi rapide et pratique que les sessions NX classique, surtout si on a des résolutions différentes entre les deux postes, ou si on utilise plusieurs écrans).
L'analogie de la recette de cuisine, ou des plans en tous genre, marche généralement assez bien.
C'est une connaissance dont découle une chose dont on peut jouir, et il y a traditionnellement une notion de « secret de fabrication ».
Comme toutes les analogies ça a ses limites, mais ça a l'avantage d'être compréhensible par le commun des mortels (tout le monde connaît une oeuvre de fiction dans laquelle il faut récupérer les plans de tel truc ultra-secret, et tout le monde s'est déjà demandé « mais comment font-ils » au restaurant).
Il est dur celui-là.
Je crois que c'est celui sur lequel j'aurais passé le plus de temps. Maintenant on va attendre minuit pour voir ce que ça donne ;-).
Combien y-a-t-il de messages de refus automatiques pour un refus de dépêche ?
réponse : 12 (28 bonnes réponses, dont « douze »)
En ce qui me concerne j'ai mis 11, considérant que le message "dépêche déjà proposée" n'était pas un message automatique de refus. Bon ça peut l'être, une change sur le nombre de dépêche proposée que ça n'en soit pas un. Mais je pensais qu'il y avait un autre message envoyé quand la dépêche était finalement refusée.
J'ai hésité, j'aurais dû suivre mon propre conseil et la jouer bête et méchant : le challenge était de trouver les directives de modérations, pas de les interpréter...
Héhé, c'est ce qui m'a permis de valider, en l'absence de nom complet dans le profil :-)
Comme quoi c'est utile ces entretiens.
Je soupçonne qu'inventer des question en s'assurant que la réponse est trouvable est encore plus drôle que répondre (mais que tant que le concours n'a pas lieu c'est comme répondre aux questions sans participer au concours, il manque un truc)...
Les distributions ont tendance à distribuer pas mal de plugin de base. Enfin je dis ça, j'en sais rien, je pense à Debian et Ubuntu.
En tout cas, en ce qui me concerne, sans synchronisation, je ne suis pas prêt d'utiliser gnote, c'est la killer feature de tomboy.
En même temps je n'ai pas peur de mono plus que ça : le jour où il y a un problème, les forks type gnote se feront très actif. C'est pas plus mal que certains prennent de l'avance au cas où, même si à mon avis ils perdent leur temps : qui sait, ils développeront peut-être des features qui feront basculer les utilisateur ?
Ce qui fait changer les utilisateurs de produit, c'est soit les distributions (xorg...), soit les features. Pas les vitupérations de barbus. On a - malheureusement ou heureusement c'est pas la question - dépassé le stade où seuls des barbus et leurs zélotes utilisaient des logiciels libres.
En ce qui me concerne, je suis rarement pleinement d'accord avec RMS ces derniers temps. Soit je vieillis, soit il se radicalise. Paradoxalement j'étais aussi un peu sceptique par rapport à mono, l'utilisant parce que des applis dont je me sers en avaient besoin et le considérant comme un mal nécessaire. Maintenant que je me suis penché sur le problème, je suis beaucoup plus serein sur la question, merci RMS ;-)
En ce qui concerne les liens et les journaux, je me suis posé la question aussi au début. Puis je me suis dit qu'il n'y avait pas de piège de ce genre et qu'il fallait chercher la réponse la plus cohérente dans la logique du site. C'est un quiz sur LinuxFR, pas un concours "qui jouera le plus sur les mots".
Après peut-être que la suite me donnera tort... Jusqu'ici ça marche ;-)
Cette fois j'avais tout bon. Enfin, je crois, je n'ai pas noté mes réponses...
Reste à être tiré au sort maintenant, mais bon, le plus fun c'est quand même de participer, et la vraie récompense, de voir qu'on ne s'est pas trompé ! [1]
Merci aux organisateurs, en ce qui me concerne je m'amuse comme un petit fou avec vos questions.
[1] La preuve, c'est que je me suis jeté sur les réponses avant même de penser à regarder le nom du gagnant. Comme quoi, hein...
Pour Wikipedia, je pensais à un public large. Mais ma mémoire peut me trahir.
En ce qui concerne kuro5hin je ne saurais dire, vu que je ne me suis jamais intéressé à son système de dépêche, j'en ai juste lu de temps en temps. Cela dit ça m'intéresse ce que tu dis je vais y faire un tour :-)
Ah ! Ben comme ça je le saurais. Merci. Bon ça simplifie pas le filtrage pour les flux qui ne passent pas par la passerelle, mais au moins c'est clair.
Je prends note sur set require-order. J'ai passé pas mal de temps sur cette problématique et la seule réponse que j'avais trouvé c'était que j'étais obligé de respecter l'ordre, et ça me gênait énormément (le pire étant les ancres). Il faut que je regarde ce que ça implique pour les ancres, justement, mais au pire je me passerait d'ancres quitte à générer le pf.conf à la volée pour séparer en plusieurs fichiers.
Moralité, il vaut mieux se plaindre sur DLFP que sur un chan irc, fut-il consacré à *BSD. On a plus de réponses utiles ;-P
Mouais. C'est bien ce que je disais plus haut, c'est super trompeur dès qu'on sort du contexte (le plus répandu je veux bien l'admettre) de la passerelle de lan... Pour mon schéma clair je sens que je vais devoir demander à quelqu'un qui a lu le code (je suis bien conscient qu'étant donné que ça ne fonctionne pas du tout avec des hooks comme netfilter, ce type de schéma n'est pas forcément évident ni même nécessaire pour la compréhension, mais moi ça m'aiderait) ;-)
Exemple de cas gênant : si ma machine c'est une passerelle dont le rôle est de tagguer des vlan (disons 500 interfaces) et de les filtrer, et qui n'est pas « connectée à internet » mais fait partie d'un backbone, in/out ça devient complètement arbitraire comme appellation... Et du coup vachement moins lisible.
D'ailleurs je ne vois pas comment on filtre entre deux vlans à ce compte là, il faudrait que je recreuse.
Le set require-order à no c'est une bonne nouvelle. Je ne savais pas que ça existait. C'est un paramètre noyau ou pf ? Ca existe (même à yes par défaut) dans des versions antérieure ? Faut que j'attende son apparition dans une version stable de FreeBSD pour pouvoir en profiter sur l'existant :-).
(Ben oui les nouveaux trucs, sauf pour la gestion de la QoS, j'ai tendance à les mettre sous linux du coup).
[^] # Re: Je veux, je veux...
Posté par nodens . En réponse au message installation Xvfb sous linux. Évalué à 3.
Je suggère la lecture de how to ask questions the smart way de Eric_Raymond, dont une traduction se trouve ici : http://www.gnurou.org/writing/smartquestionsfr .
Bon, après, comme nous on est courtois et serviables, je répond quand même : une fois le paquet xvfb installé, il faut, si on veut qu'il soit lancé au démarrage :
- soit écrire un script d'init ou en récupérer un qui marche (un script prévu pour redhat devra être adapté, j'en avais fait un du temps de la woody mais vu l'ancienneté je ne vais même pas essayer de le retrouver, il y a toutes les chances qu'il marche moyennement et soit crade)
- soit procéder selon la méthodologie éprouvée de La Rache - http://www.la-rache.com : installer anacron et créer un travail cron @reboot pour qu'il soit lancé au démarrage. C'est porc mais ça tourne.
Pour le reste j'en sais rien, j'ai jamais utilisé ça. Pour la conversion PDF j'utilise une imprimante cups.
[^] # Re: Une pression supplémentaire pour les développeurs
Posté par nodens . En réponse à la dépêche Debian adopte une nouvelle stratégie pour les "freeze". Évalué à 4.
Je serais assez de cet avis. Mais l'expérience me prouve le contraire. Même des mises à jour de version mineures posent parfois des problèmes majeurs. Le souci, c'est que le client qui a payé pour le développement d'un site ne voit pas pourquoi il devrait payer à nouveau un développement pour prendre en compte la mise à jour (souvent avec un autre prestataire), alors que ça « juste marche ». Du point de vue du client, ça se comprend, on n'a qu'à se démerder. Les marchés publics notamment ont une grande inertie. Bizarrement, la maintenance pour fonctionner avec un système plus récent n'est jamais comprise dans le marché :-)
Quant à dire que php5 est sorti il y a 5 ans, c'est vrai, mais je constate qu'il n'est pas répandu en entreprise depuis si longtemps que ça.
Par contre, personne ne m'a jamais demandé de faire tourner quelque chose en php3 depuis au moins 2001. Comme quoi c'est variable.
Les changements de la distribution de base ne me posent pas de problème. La libc, openssl, le noyau, ce genre de chose, sauf cas très particulier, c'est le problème de l'admin, l'applicatif n'a aucun impact : résultat on se débrouille. Les développements d'un client en php et mysql effectués avec un vieux « php pour les nuls » sous les yeux, c'est une autre paire de manche.
A la limite, les développements internes me posent moins de souci. On peut toujours, effectivement, faire la part des choses entre le coût d'administration d'un système obsolète et le coût d'une évolution du code. Mais le client ne veut pas avoir ce type de problèmes, sinon il ne prendrait pas de prestation d'infogérance.
Je n'ai jamais dit que ce type de support prolongé devait nécessairement être fourni par Debian, ni gratuit. Je pense que ça pourrait aussi se faire via une équipe de volontaires. Les entreprises intéressées contribueraient probablement du temps et des moyens.
N'empêche que ça m'arrangerait bien ! :-)
[^] # Re: Pas de réponse aux demande de ping
Posté par nodens . En réponse au journal Script Iptables. Évalué à 2.
Pour l'exemple de découverte du réseau, l'icmp c'est quand même le plus vieux protocole pour ça :-)
Sinon, un exemple typique de découverte du réseau et de fingerprinting en une passe : envoyer un paquet icmp echo request sur l'adresse broadcast, et regarder qui répond quoi. Ou encore sur l'adresse du réseau, même principe. Les fonctionnement par défaut des os sont assez disparates (y'a ceux qui répondent normalement, ceux qui l'ignorent, ceux qui répondent un truc spécifique...).
Quand aux dangers du fingerprinting, je suis assez d'accord à la base, mais au final c'est, plus qu'une véritable mesure de sécurisation (assimilable à une porte blindée ou une serrure), un truc qui permet de ralentir ou de décourager le pirate de passage. Ca ne fera que ralentir un peu le vrai gars déterminé, mais déjà si on s'est débarrassé des attaques automatiques et des Jean-Kévin c'est toujours ça de pris. On peut comparer ça au fait de mettre sa maison sur une colline un peu escarpée :-)
Bon, après, le défaut c'est que ça peut avoir l'effet inverse chez le hacker - le vrai - curieux : « tiens ça m'a l'air bien protégé par ici... Est-ce que je vais réussir à passer, et qu'est-ce que ça cache ? » ;-)
En plus on parle théorie, là, dans la vraie vie on n'a pas toujours le loisir de mettre autant de protections de manières systématique. Encore une fois, c'est une question de gestion du risque, il faut faire le rapport entre le risque qu'on prend quand on ne le fait pas et ce que ça coûte (en argent, temps, énergie...).
[^] # Re: Pas de réponse aux demande de ping
Posté par nodens . En réponse au journal Script Iptables. Évalué à 2.
Toujours est-il que ce n'est pas forcément une question de confiance, c'est une question de contrat.
Quand on parle de réseau, ce n'est pas forcément un réseau d'utilisateurs... Ca peut être des serveurs, le tunnel icmp peut être une manière furtive de sortir des données, et ça peut poser un problème aux utilisateurs du dit serveur. Il y a peut-être des données confidentielles et personnelles dessus. Si quelqu'un parvient à s'introduire sur le serveur (mettons par une faille php, classique), l'idée est qu'il ne puisse pas sortir d'information sans que ça se voie... En plus j'ai déjà vu un gros truc bien évident (type reverse backdoor bloquée par le firewall, tentatives maladroite d'escalade de privilège) qui servait surtout à dissimuler une fuite d'information via un tunnel icmp ou DNS...
Et puis bon, pour les réseaux interne, la question n'est pas de savoir si c'est bien ou pas, c'est de savoir si tu veux avoir la maîtrise de ton réseau. Si on bloque le ssh à l'extérieur, c'est pas pour laisser passer un truc aussi vieux qu'un tunnel icmp. Si on ne le bloque pas, on loggue au moins les accès externe pour savoir qui se connecte où, et faire la différence entre le gars qui se connecte de temps en temps chez lui pour faire de l'irc (inoffensif et pas gênant a priori) et celui qui uploade une énorme quantité de données en ukraine... Personnellement je n'ai aucun problème à laisser sortir un utilisateur en ssh pour se connecter à un serveur perso entre midi et deux, mais le jour où ça sert à sortir des infos confidentielles, c'est que je n'ai pas joué mon rôle. Sans parler du jour où ça sert à lancer des attaques dictionnaire un peu partout... ;-)
La sécurité, c'est pas simple, ce n'est pas les gentils utilisateurs contre les vilains admins, ni l'inverse ; et surtout ça ne peut se faire que si tout le monde y met du sien. Il ne s'agit pas de s'aliéner les utilisateurs (même si parfois il y a des têtes de c**), mais de se protéger contre les indélicats (le gars qui passe plus de temps à bosser sur des trucs perso que pour l'entreprise, celui qui joue double jeu et tente de récupérer des clients à son compte avant de démissionner...), et contre les maladresses (j'ai cliqué sur le mauvais lien, ça m'a installé un troyen et maintenant on est attaqués en justice parce que notre ip de sortie a servi à pirater un ordinateur du minefi).
Bien sûr qu'un type déterminé y arrivera. Ce n'est qu'une question de savoir faire, de motivation et de temps. Mais moi je suis payé pour lui compliquer la vie ! ;-)
[^] # Re: dépot tuxfamily
Posté par nodens . En réponse au message installer Fusion. Évalué à 2.
De préférence, utilise un gestionnaire de paquets qui sait repérer les paquets installés localement (aptitude fait ça très bien) pour les supprimer et les remplacer par la version debian le cas échéant.
# dépot tuxfamily
Posté par nodens . En réponse au message installer Fusion. Évalué à 2.
En ce qui me concerne je n'utilise plus fusion-icon depuis un bon moment, mais je peux te dire que fusion est bien là, dans les dépots officiels, sous le nom compiz-fusion.
... Et en cherchant un peu (http://packages.debian.org/fusion-icon) je m'aperçois que fusion-icon est là aussi.
Quand ils existent, il faut toujours utiliser les paquets officiels. (Corrolaire : quand ils n'existent pas il faut les faire soi-même et tenter de les faire inclure, comme ça au moins tu sais qu'ils sont fait proprements> à ta convenance ;-) )
# driver carte graphique
Posté par nodens . En réponse au message choix Debian stable / unstable pour avoir un KDE 4 en multi ecran avec les effets 3D. Évalué à 2.
Avec une (vieille) nvidia et twinview je n'ai aucun souci pour faire tourner compiz, et le choix d'un cube sur les deux écrans ou de deux cubes (qui tournent en simultané) se fait dans la configuration des effets du cube.
J'ai lu qu'il y a pas mal de problème avec les drivers ATI propriétaires (même que c'est ce qui me freine pour acheter une ATI), mais que ça marche assez bien avec les drivers libre (si ta carte fait de la 3D avec les drivers libres).
Pour les jeux, quoi qu'il arrive, il vaut mieux lancer un serveur X dédié quand tu veux en lancer un. Sinon ça a tendance à tout faire planter avec compiz... Enfin, si le jeu se lance en plein écran (généralement il se lance sur un seul, à condition que la résolution choisie soit supportée par un seul écran).
Dans tous les cas, avec twinview, tu as en fait un seul bureau, avec peut-être quelques pseudos éléments de xinerama (peut-être que tout ça est géré par freedesktop maintenant) qui sont en fait surtout des hints pour les gestionnaires de fenêtres.
Sinon si tu veux vraiment deux bureaux séparés, alors il te faut vraiment du xinerama (avec deux cartes, ou alors j'ai cru comprendre qu'un mode des drivers ATI propriétaires permettaient de faire ça aussi). La tu pourra passer le pointeur d'un écran à l'autre, faire des copier/coller, mais pas déplacer de fenêtres de l'un à l'autre.
[^] # Re: 802.3ad, stp, tout ça...
Posté par nodens . En réponse au message Keepalived / VRRP et question réseau. Évalué à 2.
Je voulais évidemment dire : « chère à heartbeat ». Ma langue a fourché. (et ici, il ne s'agit donc pas d'autosatisfaction récursive mais de contrôle qualité ;-) )
[^] # Re: 802.3ad, stp, tout ça...
Posté par nodens . En réponse au message Keepalived / VRRP et question réseau. Évalué à 2.
[^] # Re: Une pression supplémentaire pour les développeurs
Posté par nodens . En réponse à la dépêche Debian adopte une nouvelle stratégie pour les "freeze". Évalué à 7.
Pour les serveurs (ou même les stations de travail) ça serait le pied. Le choix des paquets pourrait se faire à l'avance (le popularity contest ou les mainteneurs qui inscrivent leur paquet dans la liste par exemple), avec une équipe moins fermée que security (comme l'équipe qui s'occupe de la sécurité de testing).
Steve Langasek évoquait quelque chose comme ça il y a un an ou deux il me semble.
En ce qui me concerne, j'ai quelques réticences à basculer sur Ubuntu pour les serveurs, mais la LTS me fait de l'oeil depuis un moment, avec le cycle de support de Debian qui se raccourcit de fait. Ce qui m'embête c'est que la LTS ne sort pas quand elle est prête, mais quand sa date de sortie arrive...
Je proposerai bien cette idée sur debian-project mais j'ai un peu peur de déclencher une flamewar, on va la tester un peu ici d'abord ;-)
# Relation d'approbation
Posté par nodens . En réponse au message Configuration avec Active directory. Évalué à 2.
Après ton vrai souci est que ton PDC samba c'est du NTLM, et le contrôleur de domaine (pas primaire, ça n'existe plus avec AD) c'est de l'AD... Et que ça ne marche pas pareil.
Mais tu dois pouvoir inscrire ton PDC samba (TOTO) sur l'AD (TITI) pour que les utilisateurs de titi soient valides. Par contre il va falloir faire ça soigneusement au niveau nss pour que les utilisateurs de titi et les utilisateurs locaux soient considérés comme valides. Par contre avec une fedora 4 j'ai peur que la compatibilité AD soit pas terrible... Cela dit tu n'y coupera pas si tu veux pouvoir y accéder à partir du domaine TITI.
Tu devrais aller voir les docs Technet de microsoft sur la migration NTLM -> Active directory, il y a sûrement des méthodes que tu pourras adapter.
# 802.3ad, stp, tout ça...
Posté par nodens . En réponse au message Keepalived / VRRP et question réseau. Évalué à 2.
Avec une communauté lacp entre les switches, et un peu de spanning tree, ça évite les boucles, et ça devrait résoudre ton souci : avoir à la fois le trunk (2 liens) et l'interface connectée à l'autre switch qui tombe, ça devient vraiment improbable. Tu as plus de chance de voir les deux switches ou les deux firewall cramer en même temps.
Tu peux utiliser utiliser la méthode STONITH (Shoot The Other Node In The Head), chère à keepalived pour t'assurer de n'avoir qu'un master à la fois : tu fais un script qui tombe les interfaces frontales de l'autre firewall (ou désactive les ports du switch...) quand tu passe master si tu arrive toujours à le joindre par une autre interface, et tu l'appelles quand tu passe en état "master".
Il y a sûrement d'autres méthodes, et je suis sûr qu'on peut imaginer d'autres scénarios catastrophe, c'est toujours la m*** quand on mélange L2 / L3 et qu'on veut être redondant.
[^] # Re: Pile à combustible ?
Posté par nodens . En réponse au journal Un nouvel espoir pour la voiture électrique?. Évalué à 3.
# Validation de formulaires
Posté par nodens . En réponse à la dépêche Sortie de LemonLDAP::NG 0.9.4. Évalué à 2.
Par contre je ne trouve pas comment faire dans la doc, ni dans le manager (que ça soit la démo ou la version que j'ai installée vite fait)... Quelqu'un sait ?
[^] # Re: NX est…
Posté par nodens . En réponse à la dépêche Google sort un serveur NX libre. Évalué à 3.
Rien à faire, on installe les paquets et ça tourne... Il y a même le shadowing de session locale qui marche (mais c'est pas aussi rapide et pratique que les sessions NX classique, surtout si on a des résolutions différentes entre les deux postes, ou si on utilise plusieurs écrans).
[^] # Re: Le retour du jedi Wikipédia
Posté par nodens . En réponse au journal piratage de logiciels libres. Évalué à 3.
C'est une connaissance dont découle une chose dont on peut jouir, et il y a traditionnellement une notion de « secret de fabrication ».
Comme toutes les analogies ça a ses limites, mais ça a l'avantage d'être compréhensible par le commun des mortels (tout le monde connaît une oeuvre de fiction dans laquelle il faut récupérer les plans de tel truc ultra-secret, et tout le monde s'est déjà demandé « mais comment font-ils » au restaurant).
# pfiou
Posté par nodens . En réponse à la dépêche Grand quizz des 11 ans : connaissez-vous bien LinuxFr.org ? (jour 5). Évalué à 3.
Je crois que c'est celui sur lequel j'aurais passé le plus de temps. Maintenant on va attendre minuit pour voir ce que ça donne ;-).
# là j'ai un doute.
Posté par nodens . En réponse à la dépêche Grand quizz des 11 ans : connaissez-vous bien LinuxFr.org ? (jour 4). Évalué à 2.
Combien y-a-t-il de messages de refus automatiques pour un refus de dépêche ?
réponse : 12 (28 bonnes réponses, dont « douze »)
En ce qui me concerne j'ai mis 11, considérant que le message "dépêche déjà proposée" n'était pas un message automatique de refus. Bon ça peut l'être, une change sur le nombre de dépêche proposée que ça n'en soit pas un. Mais je pensais qu'il y avait un autre message envoyé quand la dépêche était finalement refusée.
J'ai hésité, j'aurais dû suivre mon propre conseil et la jouer bête et méchant : le challenge était de trouver les directives de modérations, pas de les interpréter...
[^] # Re: Ça marche en binaire!
Posté par nodens . En réponse à la dépêche Grand quizz des 11 ans : connaissez-vous bien LinuxFr.org ? (jour 3). Évalué à 2.
Comme quoi c'est utile ces entretiens.
Je soupçonne qu'inventer des question en s'assurant que la réponse est trouvable est encore plus drôle que répondre (mais que tant que le concours n'a pas lieu c'est comme répondre aux questions sans participer au concours, il manque un truc)...
[^] # Re: Tomboy ?
Posté par nodens . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 1.
En tout cas, en ce qui me concerne, sans synchronisation, je ne suis pas prêt d'utiliser gnote, c'est la killer feature de tomboy.
En même temps je n'ai pas peur de mono plus que ça : le jour où il y a un problème, les forks type gnote se feront très actif. C'est pas plus mal que certains prennent de l'avance au cas où, même si à mon avis ils perdent leur temps : qui sait, ils développeront peut-être des features qui feront basculer les utilisateur ?
Ce qui fait changer les utilisateurs de produit, c'est soit les distributions (xorg...), soit les features. Pas les vitupérations de barbus. On a - malheureusement ou heureusement c'est pas la question - dépassé le stade où seuls des barbus et leurs zélotes utilisaient des logiciels libres.
En ce qui me concerne, je suis rarement pleinement d'accord avec RMS ces derniers temps. Soit je vieillis, soit il se radicalise. Paradoxalement j'étais aussi un peu sceptique par rapport à mono, l'utilisant parce que des applis dont je me sers en avaient besoin et le considérant comme un mal nécessaire. Maintenant que je me suis penché sur le problème, je suis beaucoup plus serein sur la question, merci RMS ;-)
[^] # Re: Commentaires
Posté par nodens . En réponse à la dépêche Grand quizz des 11 ans : connaissez-vous bien LinuxFr.org ? (jour 3). Évalué à 2.
Après peut-être que la suite me donnera tort... Jusqu'ici ça marche ;-)
# ah ben voilà !
Posté par nodens . En réponse à la dépêche Grand quizz des 11 ans : connaissez-vous bien LinuxFr.org ? (jour 3). Évalué à 4.
Reste à être tiré au sort maintenant, mais bon, le plus fun c'est quand même de participer, et la vraie récompense, de voir qu'on ne s'est pas trompé ! [1]
Merci aux organisateurs, en ce qui me concerne je m'amuse comme un petit fou avec vos questions.
[1] La preuve, c'est que je me suis jeté sur les réponses avant même de penser à regarder le nom du gagnant. Comme quoi, hein...
[^] # Re: Ça mérite deux dépêches
Posté par nodens . En réponse au journal En vrac : Python 3.1, Netbeans 6.7. Évalué à 2.
En ce qui concerne kuro5hin je ne saurais dire, vu que je ne me suis jamais intéressé à son système de dépêche, j'en ai juste lu de temps en temps. Cela dit ça m'intéresse ce que tu dis je vais y faire un tour :-)
[^] # Re: Soit dit en passant.
Posté par nodens . En réponse au journal Script Iptables. Évalué à 2.
Je prends note sur set require-order. J'ai passé pas mal de temps sur cette problématique et la seule réponse que j'avais trouvé c'était que j'étais obligé de respecter l'ordre, et ça me gênait énormément (le pire étant les ancres). Il faut que je regarde ce que ça implique pour les ancres, justement, mais au pire je me passerait d'ancres quitte à générer le pf.conf à la volée pour séparer en plusieurs fichiers.
Moralité, il vaut mieux se plaindre sur DLFP que sur un chan irc, fut-il consacré à *BSD. On a plus de réponses utiles ;-P
[^] # Re: Soit dit en passant.
Posté par nodens . En réponse au journal Script Iptables. Évalué à 3.
Exemple de cas gênant : si ma machine c'est une passerelle dont le rôle est de tagguer des vlan (disons 500 interfaces) et de les filtrer, et qui n'est pas « connectée à internet » mais fait partie d'un backbone, in/out ça devient complètement arbitraire comme appellation... Et du coup vachement moins lisible.
D'ailleurs je ne vois pas comment on filtre entre deux vlans à ce compte là, il faudrait que je recreuse.
Le set require-order à no c'est une bonne nouvelle. Je ne savais pas que ça existait. C'est un paramètre noyau ou pf ? Ca existe (même à yes par défaut) dans des versions antérieure ? Faut que j'attende son apparition dans une version stable de FreeBSD pour pouvoir en profiter sur l'existant :-).
(Ben oui les nouveaux trucs, sauf pour la gestion de la QoS, j'ai tendance à les mettre sous linux du coup).