briaeros007 a écrit 9441 commentaires

c'est un firewall qui se met derrière chaque équipement (d'un point de vue conceptuel, en réalité c'est un seul équipement), et vérifie que ledit équipement est autorisé à acceder a un certains réseau;

Pour la vérification, il peut se reposer sur un certain nombre de crtières, dont pour certains : mise à jour de l'AV, etc…

L'un des trucs intéressants des NAC c'est la possibilité d'avoir un réseau de quarantaine pour permettre de mettre à jour juste l'AV et l'OS par exemple.

Un NAC permet aussi d'avoir des règles un peu plus évolué qu'un simple firewall. Je me souviens lors d'un teste d'une solution, qu'il empêchait les updates de ma debian au début : apt-get faisait une tonne de requête http, et donc une règle anti dos se mettait en place (j'étais en tant le sous réseau "poste bureautique" ). Une fois analysé, c'est facile à changer la conf, mais encore fallait y penser :)

(KDE était en 4.8 dans Ubuntu 12.04 avant qu'il ne soit dans Debian unstable)

Kde 4 était aussi dans ubuntu avant debian … et a généré 50% des bug report de kde … dut à la mauvaise qualité des paquets kde dans ubuntu.

Il faut arrêter le mythe du "c'est avant donc c'est mieux". Et parler de ça en comparant à deban (ca sortira quand ça sera prêt), même pour l'unstable, c'est bizarre.

et pour les madame michu, ce qui existait avant et marchait très bien.

Alors il faut m'indiquer quel est l'avantage du bouzin, par rapport au risque de voir ce truc débarquer sur les machines a adminstrer (parce qu'il va débarquer, la seule question est "quand") est

(et je te fait grace de trouver ce qui ne marche pas quand il y a une merde, déjà avec des services simples et un fichier de conf c'est pas toujour évident, alors là, avec des outils qui s'amusent à relancer sur modif d'un fichier de conf (hein network manager) ou autre …)

oui mais non :P

Le problème de gnome/dbus/systemd/… c'est que c'est un nouveau vecteur d'entré, utilisé par défaut.
Nouveau vecteur inutile, vu que l'ancien marche très bien …
De plus c'est vecteur qui vas centraliser tous les changements, donc beaucoup plus difficile a tracer et a controler.

puppet, tu l'installe, tu le configure. Si tu ne fais rien, par défaut il n'autoriseras pas quelqu'un de lambda a modifier ton fichier.

Là, tu ne fais rien, il autorise tout utilisateur loggé a modifier sa conf.

De plus, comme c'est poussé dans gnome, a terme ça sera sur les OS serveurs (network manager est installé par défaut sur les redhat maintenant , alors que c'est prévu pour les madame michu).

bref,
-> ca rajoute de la complexité
-> ca n'apporte rien a l'existant (les confs de modif de fichiers de conf ca existait déà)
-> ca centralise des droits étendus
-> ca augmente de la surface d'attaque
-> ce n'est pas scalable
-> ce n'est que difficilement maintenable pour un parc de machine.

alors le coup du logiciel a part, mais dans le même dépot que systemd, c'est comme si tu me disais que la branche staging du noyau ça n'a rien à voir avec le noyau…

Ps : et ça ne répond pas aux problème soulevé …

Un des intérêt de la fonctionnalité, c'est qu'elle permet de paramétrer le fuseau horaire pour le système (ou uniquement pour l'utilisateur), mais aussi de paramétrer le hostname pour tout le système.

J'avais compris.

Non, justement tu n'as rien compris au problème en fait.

C'est aimable, mais peut être est ce toi qui n'a point compris mes interventions.

-> Tout ce qui appartient à l'utilisateur : on peut déjà le modifier sans utiliser des trucs usines a gaz.
-> Tout ce qui est système. L'utilisateur n'a pas à le modifier, c'est aux admins de le faire.
-> Il n'est pas interdit de faire des gui qui modifient des confs systèmes, la preuve ca existent depuis des dizaines d'années. Et inutile dans ce cas d'utiliser des usines à gaz (toute nouvelles).

En 1999, sous mandriva, on avait déjà des gui, que l'on pouvait lancer à partir d'une session utilisateur, et dans laquelle on pouvait modifier les utilisateurs système (ceci n'est qu'un exemple).
Est ce qu'il y avait besoin de policy kit ou autre ? non!

Donc la question quel est le problème nouveau auxquel répond vos usines à gaz ?
Pas a modifier des confs utilisateurs
Pas a modifier des confs systèmes
Pas a gérer finement et facilement les droits (elle est ou la doc pour indiquer l'ensemble des droits, les groupes de droits existant, sur des utilisateur spécifiques, et surtout en quoi l'utilisation de groupes système classique ne pouvaient pas répondre à cette problématique)

Pourquoi l'admin devrait le faire avec Gnome ?

Si je dois modifier la conf de 120 postes bureautiques, je vais m'amuser à me connecter dans chacun des postes un par un ?

C'est sur qu'un système qui remplace inetd, qui fait init et qui gère sa conf par dbus, il va être vachement manipulable et controllable (qui fait quoi, comment, avec quel autorisation) par un fichier de conf.

Je vais arrêter d'être cassant (parce que quand on propose de péter ton outil de travail, tu as tendance a moyennement apprécier) et vais répondre un truc simple :
- Surface d'attaque
- principe KISS
- DAC linux
- Debug

C'est assez clair comme réponse ?

explique moi le lien entre le hostname (l'utilisateur doit le modifier pour sa session uniquement ? mais dans quel monde vivez vous ???) et le fait de mettre la variable LANG etc… sur le fuseau horaire pour la session de l'utilisateur ?

Je ne vois pas où tu veux en venir,

Le monsieur nous parle de portabilité, je lui répond portabilité -et pas pseudo n'importe quoi de quelqu'un qui n'a jamais fait autre chose que du linux 2.6 sur la même distrib et qui se plaint de la portabilité d'ifconfig et propose dbus à la place-

Gnome n'est pas disponible sous ces Unix là

Non du tout… Pourtant y'a un paquet gnome pour solaris … 8 (et 10) qui remplace le desktop initial CDE …

Comme quoi des fois …

et j'ai vérifié, il est présent sur aix aussi.

Alors oui, c'est pas gnome3 sur compiz avec les effets kikoolol, mais sisi c'est du gnome.

Ça répond au besoin de plein d'utilisateurs de vouloir faire des changements du système comme le nom d'hôte sans modifier un fichier de configuration à la main.

Modifier le nom d'hote, Une demande de plein d'utilisateurs ?
Tu y crois vraiment ?

Et nonobstant le coup de "modifier le fichier de conf à la main", il y a une tonne de façon de faire qui ne nécessite certainement pas une usine à gaz pareil et qui fonctionne avec les système actuels/précédents.

Sauf que ce n'est pas vraiment pour les sysadmins que cette fonctionnalité est prévu.

Peut être, mais elle les fait ch**r quand même, vu que ce genre de chose va être déployé partout, et ca va venir foutre la grouille.
Tout comme NetworkManager, déployé partout par défaut, même sur les OS serveur (par exemple redhat …)
Alors foutre des services partout parce que tu comprend "il ne faut pas que l'utilisateur ait à connaitre un mot de passe système en plus quand même. Il ne faut surtout pas le sensibiliser ce pauvre petit bout de chou".

Si le prochain botnet sera sous linux, ça sera pas faute vous avoir prévenu.

Demande ça à ta distribution, ce n'est pas le but de la fonctionnalité dont on parle.

Cette réaction, amha, ne parle pas d'expérience. (voir commentaire au dessus).

Et si le sysadmin doit administrer la machine, il est ravi qu'un service (encore un) se permette de modifier sa conf "parce qu'il ne faut pas perturber l'utilisateur" ?

Il doit apprendre 15 modes de fonctionnenement différents tous les ans le sysadmin, il va passer plus de temps en veille techno et en formation qu'en travail!

on doit pas avoir commencé linux au même moment alors. Parce que moi si tu veux le jour 0 y'avait même pas ude qui est me semble t'il précédent à dbus.
Enfin de toute façon y'avait pas dbus (qui est mine de rien relativement nouveau sur l'échelle unixienne).

A parce qu'il va rentrer les paramètres dbus l'utilisateur ?

wikipedia peut le dire. Je ne l'ai jamais vu sur aucun autre os en prod. Alors peut être qu'il existe, mais il est pas forcément utilisé (et encore moins supporté).

Et si tu reposes sur le comportement de ifconfig Linux tout le monde va gueuler par ce que c'est pas portable. C'est sans fin.

Pas portable, pas portable faut le dire vite hein.

parce que si tu veux, j'ai toucher à des os que j'avais jamais vu, des trucs comme des HP-Ux ou d'autres bestioles exotiques. ben ne t'en déplaise, ifconfig je l'avais (pas avec les mêmes options) et man aussi. Ce qui m'a permis de faire des migrations réseaux avec des bestioles que j'avais vu il y'a à peine une heure. (et oui man très utile pour trouver quel fichier éditer, ifconfig pour avoir les interface réseau déjà configuré et commencer des recherches dans les fichiers de conf, etc…)

Ton dbus portable ?
On lance quel commande en cli ? qdbus ? sous hpux ? sous aix ? sous solaris 8 ? je continue ou tu as compris le niveau de ton argument sur la "portabilité" ?

Maintenant qu'on a eu la démonstration que c'était débile on propose quoi ?

D'arrêter de vouloir tout changer en vitesse, surtout quand ça répond à aucun besoin ?
Un peu de prise de recul et d'humilité (de se dire que si ça se fait comme ça depuis 40 ans, c'est pas forcément que tous les autres sysadmins sont des gros cons et que lennart est un génie précurseur) ?
De faire de vrai doc potables, expliquant tout ?
D'avoir des outils utilisables, facilement scriptable (parce que dbus c'est gentil, mais c'est pas ce que j'apelle utilisable.
Tu veux des exemples de commandes "récentes" utilisables ? Regarde zfs et zpool
C'est un bonheur d'utiliser ces commandes).

Le but c'est quand même que le changement soit sauvegardé et persistant au reboot.

Depuis 40 ans sous unix ont peut modifier sa conf en modifiant des fichiers cachés dans son répertoire (tu sais les .profile, .bashrc .vimrc etc…)

Mais visiblement, pour certains desktop c'est ultra compliqué d'écrire dans un fichier, il faut bien mieux s'interfacer avec une tonne de service et d'api dans tous les sens, c'est tellement plus portable et simple …

En même temps, venant du desktop qui veut refaire une base de registre, plus rien ne m'étonne (oui c'est bas, et alors ?)

ça c'est le boulot de l'admin, pas de l'user dans ce cas.

On peut pas vouloir tout et son contraire.

Tu veux dire que les dev d'OpenSSH ou de Postfix sont des abrutis d'avoir fait exactement la même chose ?

Les fichiers de conf de postfix ou d'openssh je les pigent sans problèmes, et ils reposent sur les DAC linux.

Le coup du policy kit désolé c'est beaucoup beaucoup plus abscon pour moi.

Alors peut être que les dev openssh/postfix savent coder en pensant aux utilisateurs eux dans ce cas ?

Ou alors de pouvoir permettre à des utilisateurs de régler la configuration de son système sans devoir le faire se déloger, ouvrir une session graphique en root, et se reloger ?

Tu faiis tout ça pour tes actes d'admin toi ? Tu m'étonnes qu'on ait besoin d'usine a gaz pour faire fonctionner le système derrière…

Je présume que tu reboot la machine pour lancer un service aussi non ?

Le commentaire initiale de ce thread est un tissu de conneries

Ah, ça ne te plait pas, c'est donc un tissu de connerie ?
Intéressante définition de la connerie.

Tu veux dire que quand il dis que gnome3 dépend de systemd dans tel distrib c'est faux ? Ben non il dépend bien de system (même si c'est une sous partie).
Tu veux dire que le fait d'avoir un desktop qui demande unn système d'iniit particulier (même s'il n'utilise qu'une sous partie dudit système) ca va conduire à un système monolithique (qui v'a s'emmerder à utiliser des sous parties complètement différentes qui communiquent pas entre eux. C'est typique de la stratégie "embrace & extend" de ms cette façon de faire), c'est encore une connerie ?

Par contre tes posts, qui disent juste que c'est une connerie, ou alors, lorsqu'il y a un semblant d'argument, répondent comme si tu parlais à ton chien (et j'aimerais pas être ton chien) c'est quoi ?

de la bonne intelligence ?
Du respect ?

J'ai remarqué que dès qu'on osait dire du mal de systemd il y en avait toujours pour défendre le bousin (même chose au temps de ooxml …)
Et que malgré tous les argument que l'on puisse leur apporter, c'est forcément de la faute des admins "qui refusent les changements" plutôt que du truc pousser au forceps, et qui répond à des besoin plus que non nécessaire pour une grande partie des sysadmins.

On constate juste une autre façon de pousser un peu plus au forceps systemd (embrace & extend comme je disais), et ça, ne t'en déplaise, c'est un fait.

(Bientot kde va demander à utiliser un rc.conf ?)

et on se foutait de la gueule de ms avec ses sytème "je fais tout bien caché et si tu as une mrde, ben pas de chance, modifie unne valeur binaire dans la base de registre"…

je suis pas d'accord. Mes parent ont eu un gros problème au niveau de leur ligne, et même si ce fut long, le sav a été efficace et le problème fut réglé sans trop de soucis.

Mais bon l'intervention du techos de free qui constate le problème (obligatoire visiblement pour dépêcher orange), puis de free+orange (où le gars d'orange visiblement n'en a mais rien a foutre), puis encore une inter free+orange pour retirer le cable …

le plus gros des problèmes semble plus provenir de faire bouger orange…

Si je me souviens bien, les questions sous deb ne dépend pas de l'installateur (aptitude, synaptic, …) mais des scripts de pre/post_install.

Une syntaxe particulière est utilisé pour que ce soit cohérent entre les != paquets (même commande utilisé partout).
La présentation dépend des options ensuites (mode X par exemple, ou mode texte uniquement).

voilou, le petit script est dispo
http://pastebin.com/rcxMgPmP

C'est du WTFPL car je ne voulais pas me prendre la tête avec la licence etc…
(j'aurais peut être du mettre l'option "carte postale" quand même ;))
Et vu la qualité dudit code (oh les if ($DEBUG) rajouté à l'arrache derrière les print pour la publication ^).

Avant de lancer le script, il faut mettre à jour l'ip de son imprimante (dans la variable $PRINTERIP)
on lance le script suivi du nom de fichier.
Le script refuse de se lancer si le nom de fichier n'existe pas, ou pointe vers un fichier existant.

on peut spécifique la résolution après. Vous pouvez donner n'importe quel résolution, le script s'occupe pour arrondir a la résolution qui l'arrange (de tête, celle inférieur).

On ne peut pas encore spécifier le secteur à scanner, ça viendra peut être.

Le scanner sort du jpeg, donc je sauve en jpeg.
De plus il fait plein de petit jpeg donc j'utilise imagemagick pour postraiter l'ensemble des jpegs.
Attention : J'utilise normalize car je trouve qu'on ne voit rien avec ce scanner sur des dessins. Si vous souhaitez rester sur l'original, remplacez "-normalize" par "-append"

Si vous avez une capture réseau d'une session avec un truc spécifique , n'hésitez pas à me l'envoyer (mp) en spécifiuant les paramètres classiques (dpi,…) et le spécifique, pour que je puisse faire la soustraction de ce que je connais déjà et ce que je ne connais pas.

Si vous souhiatez plus d'info sur le proto, même punition. J'ai deux feuille montrant un peu les champs, mais un peu galère a présenter proprement, donc je ne le ferais pas sans raison :)

Si pb a utiliser: msg ici (mais c'est pas un forum), ou mp. (je n'ai aucune offre de support donc si ca prend du temps ou si j'ai pas envie/les compétences de trouver le problème, tant pis:P)

J'ai un peu regardé vite fait, mais le protocole utilisé ne semble pas le même.
(pas la même taille de header, un enregistrement spécifique, …)

Faudrait que je fasse une ou deux capture réseaux pour m'en assurer mais je suis pas sur que faire un patch serait intéressant.

Par contre pourquoi pas un programme englobant les deux.

Je l'avais pas trouvé.
Faut que je le lise/test un peu pour voir si je peux faire qqch avec :)