Update après relecture : ce n'est pas un troll Java/C++, même si ça en a l'air. Je voulais dire dans ma dernière phrase qu'il valait mieux essayer de vaincre dès le départ les difficultés d'un langage plutôt que d'appliquer les modèles d'un autre. Ce n'est pas un plaidoyer en faveur d'un langage plus que de l'autre ...
En fait c'est logique, même si cette méthode est déclarée virtuelle et donc redéfinissable dans B, cela n'implique pas qu'elle doive nécessairement être redéfinie vu qu'elle n'est pas virtuelle pure.
Pas tout-à-fait : une méthode, quelle qu'elle soit, n'a pas besoin d'être virtuelle (pure ou non) pour pouvoir être redéfinie. En fait, tu n'as même pas besoin de la déclarer dans les classes dérivées dès lors que celles-ci en héritent de la classe supérieure. Ca veut dire notamment que tu n'as pas besoin de déclarer une méthode virtuelle (pure) à la racine de ton graphe simplement parce que tu comptes la faire apparaître un peu plus loin. C'est même fondamentalement le contraire : le procédé est fait pour t'éviter d'avoir à y penser à l'avance.
D'autre part, être confronté à des héritages en diamant est une chose relativement fréquente en C++, mais ils sont généralement dus à une erreur de conception dans le modèle et pas à une limitation technique. Au pire, ils traduisent un conflit, au mieux, ils mettent généralement en évidence des notions jusque là implicites.
Mais ton erreur d'analyse, dans ce cas précis, est de considérer chaque classe dérivée comme un sous-ensemble d'une classe plus générale (ce que N est à R, par exemple), alors qu'il s'agit au contraire d'une extension de la classe précédente (comme Z par rapport à N). Chaque classe contient implicitement la classe mère en entier, plus d'autres choses.
Il est humainement facile de trancher entre une classe qui définit property1() et une autre qui ne se prononce pas, mais c'est plus dur de le faire si elles ont des opinions antagonistes : tu pourrais très bien définir une classe D qui, héritant de deux classes, soit à la fois un anneau intègre et un anneau non-intègre, ce qui n'a pas de sens.
Si ce problème se résout parce qu'on sait qu'il y a prédominance ou récessivité, alors celles-ci doivent être définies. Mais ici, on voit que c'est le modèle objet même qui doit être revu. Le Java ne permettant pas d'hériter de plusieurs classes à la fois, c'est un problème qui est automatiquement contourné (donc jamais rencontré), mais pas résolu.
, auriez-vous des conseils pour l'exemple que je donnais à la fin ?
J'en ai un : Contrairement à Java, le C++ n'impose pas que tu définisses tes méthodes à l'intérieur de ta classe. C'est même mieux si tu sépares tes déclarations et définitions dans des fichiers .h et .c distincts. Ainsi, le .h peut être directement utilisé par les programmes sources externes qui utiliseront ta classe.
D'autre part, toute fonction membre définie dans la déclaration de la classe est automatiquement considérée inline, et c'est rarement souhaitable.
Par contre, d'un point de vue conception de soft, c'est une pure horreur. Tu ferais mieux de rester dans le cas de classe virtuelle qui représentent des "interfaces" comme en Java.
En même temps, si l'on passe au C++, c'est un peu pour profiter de sa puissance. Gérer les différentes branches n'est pas si compliqué. Le problème du Java, c'est que des pans entier du paradigme objet implémenté dans le C++ ont été sacrifiés pour que ce soit plus simple et parce que ça couvre toujours 90% des besoins habituels. En soi, ce n'était pas une mauvaise idée mais à présent, tous les étudiants se précipitent d'emblée sur le Java parce que c'est plus facile et ils ont ensuite un mal fou à remonter la pente.
La bonne attitude à avoir, à mon avis, c'est essayer de s'entraîner tout-de-suite à maîtriser le C++ en entier, avant d'entamer de gros projets.
Peut on devenir programmeur sans faire d'étude? C'est a dire est ce que les compétences seulent suffisent ?
Oui ! D'ailleurs, les programmeurs autodidactes sont généralement les plus passionnés, et ont tendance à plus aller au fond des choses que ceux qui apprennent un langage sur le banc de l'école.
Maintenant, j'ai envie de dire qu'apprendre la programmation en école d'ingé ou par soi même, c'est un peu comme apprendre la musique au conservatoire ou dans un club de jazz. Idéalement, il faudrait faire les deux pour être accompli. Les musiciens issus du conservatoire sont généralement éminents, mais ça n'a jamais empêché quelqu'un de prendre une guitare et de jouer, au bout de quelques temps, de la très bonne musique.
Il faut retenir que la manière d'aborder les technologies de l'informatique est très différente de celles des sciences dures classiques. Il y a beaucoup moins de "dogmes" (des formules statique à connaître parce que la Nature est telle qu'elle est) car pratiquement tout a été inventé par l'homme il y a moins de 50 ans, donc tout a une raison d'être. En revanche, il y a aujourd'hui beaucoup trop de concepts pour pouvoir tous les connaître et comme ils deviennent caducs assez rapidement, il faut réfléchir avant de s'investir à corps perdu dans une technologie. Il faut donc faire beaucoup plus appel au raisonnement et au bon sens pour manipuler des fonctions généralement inconnues, qu'au simple bachotage.
Sache aussi que c'était probablement beaucoup plus facile pour les gens de mon époque (ceux qui ont la trentaine passée) car à ton âge, nous utilisions les huit bits. Beaucoup plus limités, ils obligeaient le programmeur à faire preuve de beaucoup d'astuce. En revanche, les machines étaient beaucoup plus diversifiées qu'à notre époque, où le PC est tellement omniprésent que les gens ne savent même plus qu'il ne s'agit qu'un type d'architecture parmi d'autre (et pas le meilleur, loin de là !). D'autre part, les ressources de ces machines étaient également beaucoup restreintes et il était facile d'en faire le tour. On avait une maîtrise absolue de sa machine, ce qui est beaucoup moins fréquent aujourd'hui.
N'hésite pas à fréquenter les clubs et choisis bien tes forums (on trouve le meilleur comme le pire). En général, dans une coding party, on assimile en une journée ce que l'on aurait fait en trois mois, par ailleurs.
Souviens-toi enfin que c'est extrêmement chronophage et tu peux y passer ton adolescence entière si tu n'y prends pas garde. Bref, si tu as envie de conserver tes amis, ta copine et de profiter de la vie, c'est possible, mais à condition d'y faire activement attention.
Et peut trouver un métier de programmeur (plutôt pour les jeux vidéos) "facilement" ?
Oui !
Si c'est pour être coder conventionnel, tu peux trouver très facilement.
Maintenant, pour les jeux vidéos en particulier, c'est un peu différent. A l'époque, un bon programmeur pouvait coder un casse-brique à lui tout seul et ravir tous ses camarades. Aujourd'hui, le jeu vidéo est comparable à l'industrie du cinéma et surtout, sans 3D, point de salut. Et le jeu vidéo est souvent le domaine où l'on va avoir besoin de hautes performances, et des programmeurs capables de les apporter.
Cela signifie qu'il faut non seulement être très bon programmeur, mais également avoir un solide bagage mathématique, ce qui, contrairement à ce que le profane pourrait croire, va rarement ensemble. Ceci dit, si tu finis une première S et que tu te diriges vers les sciences de l'ingénieur, cela devrait se passer sans trop de difficulté ...
Plus précisément, 192.168.0.10, c'est la machine sous XP, et elle n'est pas sur la white list de PostgreSQL En clair :
# IPv4 local connections:
host all all 10.0.2.15/32 trust
Je ne sais pas comment tu l'as pris, mais cette entrée spécifie l'adresse distante du client qui essaie d'accéder à ton serveur, pas l'adresse locale d'écoute.
C'est très probable, en effet, mais s'il n'y a qu'une seule base à migrer, le SQL reste "suffisamment" le même pour que l'on puisse se permettre d'adapter le résultat du dump à la main pour les cas particuliers (gestion des rôles, etc.).
Je pense que dans ce cas précis, ça reste la solution la plus facile et la plus rapide.
Un ls de /proc me donne tout les répertoires à la date d'aujourd'hui ...
C'est bizarre, ça marche bien chez moi (avec un 2.6.24.2). quelle est la version du noyau que tu utilises ?
Je lutte au quotidien pour garder mes machines sous linux. Et encore je n'ai pas le choix de la distrib, c'est Redhat, car support etc ... J'ai installé une Debian en cachette ...
Pfff. L'esprit "grandes boîtes" : si ce n'est pas rébarbatif, ce n'est pas du boulot. C'est désolant de voir le potentiel gaché par un tel esprit. C'est comme ça que l'on arrive à avoir mauvaise réputation auprès du reste du monde.
Jusque là, j'ai bon sauf que monsieur ps nous donne l'heure pour un processus lancé dans la journée, le jour pour un processus lancé dans le mois, le mois pour un processus lancé entre le début de l'année et le mois dernier et l'année pour les processus lancés avant le 1er janvier ...
Autant que je sache, Solaris fait la même chose, et le ps de chez GNU est compatible avec celui de Sun. Sinon, sous GNU/Linux, tu peux aussi essayer :
$ ls -dl --time-style=full-iso /proc/[0-9]*
Voila. C'est assez précis pour lui ? :-)
Le manque de précision m'a valut un bon pic sur les LL comme il sait bien les faire ...
Ben, bravo. Troller entre deux Unices SysV. C'est vraiment pour le plaisir de se plaindre ...
Je dois acheter un ordinateur et je suis très tenté de passer à Linux, rejoignant ainsi une communauté dont l’esprit, la philosophie m’intéressent.
C'est parce que tu n'as pas encore découvert la Tribune ! :-)
Sachant que j’habite Paris 11ème, pouvez-vous m’orienter vers l’aide (si possible de proximité) dont j’ai besoin ?
Je plaisante. Tu as exactement l'attitude à avoir et tu devrais très vite trouver tes marques. Les LUGs (Linux User Groups) sont faits pour toi. Celui de Paris est Parinux :
Il ne s'agit pas de passer toutes les commandes root en un équivalent utilisateur ordinaire, mais les plus fréquentes, de façon à ce que passer root devienne exceptionnel (ou, au moins, rare).
Pour password, encore une fois, il y a une différence entre utiliser le SetUID d'une manière générale, et l'utiliser pour passer root. De toutes façons, pour gagner le droit d'écriture sur un fichier donné, un SetGID suffit. Pas besoin de changer en plus d'identité.
Quand a la difference entre ssh root et su -, je t'invite a faire taper "screen" dans les deux cas pour voir la diff ;)) (ssh cree un PTS alors que su ne le fait pas, tu est pas TOTALEMENT root en su pour de rare cas particuliers)
Un logiciel setuid qui fait des choses aussi complexes, ca a de quoi faire peur
Encore une fois, il faut distinguer sudo et les setuids du compte root. On peut prendre l'identité de n'importe quel (pseudo-)utilisateur.
Un logiciel setuid qui fait des choses aussi complexes, ca a de quoi faire peur
Oui, mais cela reste toujours plus facile de les faire directement en root dès lors que les privilèges sont acquis. C'est pour cette raison qu'il ne faut pas prendre l'habitude de passer root à tout bout de champ.
Un truc style gksudo, par exemple, accorde un délai de grâce à une console inconnue (normal si directement lancée depuis X), ce qui permet à n'importe quel processus X-Window ou se détachant de lui-même de sa console d'en profiter ( https://linuxfr.org//comments/860291.html#860291 ).
Une console root ouverte sous X peut éventuellement recevoir des événements clavier d'une autre application connectée au serveur graphique ...
(et je vois mal la différence entre un su - et être loggué en root).
C'est-à-dire que su permet de changer d'identité, et pas forcément pour prendre celle du root. C'est ce dernier point qui est important, parce que ce n'est pas utilisé assez fréquement, à mon goût, pour les tâches d'administration.
Quand à utiliser su et se logger de façon ordinaire, c'est aussi, à mon avis, l'origine d'une faiblesse courante sur de nombreux système :lorsque su ou un dispositif similaire sont indisponibles, les gens préfèrent souvent s'accorder directement tous les pouvoirs, parce qu'il est difficile de changer temporairement d'identité. C'est même très génant quand on est obligés de le faire au milieu d'une session de travail.
De toutes façons, sudo, c'est un moindre mal. On en avait déjà discuté il y a quelque temps. Evidemment, qu'un administrateur Unix va avoir besoin d'ouvrir un shell root de temps en temps, mais cela ne doit pas être un comportement ordinaire.
qui est censé balancé 15 commandes à la minute nécessitant la plupart du temps les droits root
C'est surtout cela qu'il faut identifier. Quand tu en es à balancer, en temps normal, 15 commandes root à la minute, c'est que ta machine n'est pas configurée correctement. Il y a des dizaines de petits trucs à régler pour t'éviter de passer systématiquement root chaque fois que tu as besoin de faire une action un peu originale. L'une des plus importantes, à mon avis, est l'accès aux logs. Un sudo pour aller lire un log Apache ou autre, par exemple, est une hérésie. A la place, il faut créer un groupe dédié spécialisé et lui donner les droits de lecture seule.
En identifiant toutes les tâches privilégiées répétitives, tu peux réduire considérablement tes 15 commandes par minute. Evidemment, cela demande un minimum de bon sens. On peux donner les droits read-only sur des logs à un groupe, on sera beaucoup plus circonspects s'il faut donner les droits d'écriture.
Dans l'absolu, même des trucs comme passwd n'ont pas besoin d'être setuid root s'il ne s'agit que d'aller mettre à jour le fichier /etc/passwd. Un SetGID sur un groupe ordinaire suffit largement. Evidemment, aujourd'hui, ce n'est plus tout-à-fait vrai car le tout passe par PAM et qu'il y a différentes méthodes d'authentification. Mais l'esprit reste le même ...
Ils font la majorité de leur travail sous leur propre compte, utilisent des comptes dédiés pour les daemons (dont les privilèges peuvent être plus restreints encore que ceux des utilisateurs de base), configurent les groupes correctement, changent d'identité uniquement sur besoin avec su et pensent à refermer le shell concerné derrière (le tout, donc, sans avoir besoin de changer de session), font un usage modéré de sudo, et n'utilisent le mot de passe root et le prompt # qu'en tout dernier ressort.
Je suis assez d'accord dans le principe, sauf sur :
Privilèges administrateur. C'est trop vague (et trop proche de Windows). Un administrateur en informatique, c'est quelqu'un qui fait des tâches d'administration sur les machines et qui, à ce titre, doit bénéficier de pouvoirs particulier. Le root UNIX, c'est quand même beaucoup plus précis que cela. Et de toutes façons, le bon administrateur UNIX ne travaille jamais sous root.
Rétropropagé. Pourquoi pas, mais ça reste un piège classique du traducteur. C'est un mot français qui n'a de sens que lorsque l'on connaît déjà l'original. Hors contexte, ça devient beaucoup plus flou.
[^] # Re: Only two remote holes in the default install, in more than 10 years!
Posté par Obsidian . En réponse au journal Microsoft pire qu'ubuntu dans ses updates. Évalué à 6.
Subtil ! :-)
[^] # Re: héritage multiple en diamant
Posté par Obsidian . En réponse au message Autour de l'héritage multiple et des méthodes virtuelles.. Évalué à 3.
[^] # Re: Tes "virtual" sont mals placés
Posté par Obsidian . En réponse au message Autour de l'héritage multiple et des méthodes virtuelles.. Évalué à 3.
Pas tout-à-fait : une méthode, quelle qu'elle soit, n'a pas besoin d'être virtuelle (pure ou non) pour pouvoir être redéfinie. En fait, tu n'as même pas besoin de la déclarer dans les classes dérivées dès lors que celles-ci en héritent de la classe supérieure. Ca veut dire notamment que tu n'as pas besoin de déclarer une méthode virtuelle (pure) à la racine de ton graphe simplement parce que tu comptes la faire apparaître un peu plus loin. C'est même fondamentalement le contraire : le procédé est fait pour t'éviter d'avoir à y penser à l'avance.
D'autre part, être confronté à des héritages en diamant est une chose relativement fréquente en C++, mais ils sont généralement dus à une erreur de conception dans le modèle et pas à une limitation technique. Au pire, ils traduisent un conflit, au mieux, ils mettent généralement en évidence des notions jusque là implicites.
Mais ton erreur d'analyse, dans ce cas précis, est de considérer chaque classe dérivée comme un sous-ensemble d'une classe plus générale (ce que N est à R, par exemple), alors qu'il s'agit au contraire d'une extension de la classe précédente (comme Z par rapport à N). Chaque classe contient implicitement la classe mère en entier, plus d'autres choses.
Il est humainement facile de trancher entre une classe qui définit property1() et une autre qui ne se prononce pas, mais c'est plus dur de le faire si elles ont des opinions antagonistes : tu pourrais très bien définir une classe D qui, héritant de deux classes, soit à la fois un anneau intègre et un anneau non-intègre, ce qui n'a pas de sens.
Si ce problème se résout parce qu'on sait qu'il y a prédominance ou récessivité, alors celles-ci doivent être définies. Mais ici, on voit que c'est le modèle objet même qui doit être revu. Le Java ne permettant pas d'hériter de plusieurs classes à la fois, c'est un problème qui est automatiquement contourné (donc jamais rencontré), mais pas résolu.
J'en ai un : Contrairement à Java, le C++ n'impose pas que tu définisses tes méthodes à l'intérieur de ta classe. C'est même mieux si tu sépares tes déclarations et définitions dans des fichiers .h et .c distincts. Ainsi, le .h peut être directement utilisé par les programmes sources externes qui utiliseront ta classe.
D'autre part, toute fonction membre définie dans la déclaration de la classe est automatiquement considérée inline, et c'est rarement souhaitable.
[^] # Re: héritage multiple en diamant
Posté par Obsidian . En réponse au message Autour de l'héritage multiple et des méthodes virtuelles.. Évalué à 1.
En même temps, si l'on passe au C++, c'est un peu pour profiter de sa puissance. Gérer les différentes branches n'est pas si compliqué. Le problème du Java, c'est que des pans entier du paradigme objet implémenté dans le C++ ont été sacrifiés pour que ce soit plus simple et parce que ça couvre toujours 90% des besoins habituels. En soi, ce n'était pas une mauvaise idée mais à présent, tous les étudiants se précipitent d'emblée sur le Java parce que c'est plus facile et ils ont ensuite un mal fou à remonter la pente.
La bonne attitude à avoir, à mon avis, c'est essayer de s'entraîner tout-de-suite à maîtriser le C++ en entier, avant d'entamer de gros projets.
# Fonce !
Posté par Obsidian . En réponse au message comment devenir programmeur ? Et quelles études ?. Évalué à 6.
Oui ! D'ailleurs, les programmeurs autodidactes sont généralement les plus passionnés, et ont tendance à plus aller au fond des choses que ceux qui apprennent un langage sur le banc de l'école.
Maintenant, j'ai envie de dire qu'apprendre la programmation en école d'ingé ou par soi même, c'est un peu comme apprendre la musique au conservatoire ou dans un club de jazz. Idéalement, il faudrait faire les deux pour être accompli. Les musiciens issus du conservatoire sont généralement éminents, mais ça n'a jamais empêché quelqu'un de prendre une guitare et de jouer, au bout de quelques temps, de la très bonne musique.
Il faut retenir que la manière d'aborder les technologies de l'informatique est très différente de celles des sciences dures classiques. Il y a beaucoup moins de "dogmes" (des formules statique à connaître parce que la Nature est telle qu'elle est) car pratiquement tout a été inventé par l'homme il y a moins de 50 ans, donc tout a une raison d'être. En revanche, il y a aujourd'hui beaucoup trop de concepts pour pouvoir tous les connaître et comme ils deviennent caducs assez rapidement, il faut réfléchir avant de s'investir à corps perdu dans une technologie. Il faut donc faire beaucoup plus appel au raisonnement et au bon sens pour manipuler des fonctions généralement inconnues, qu'au simple bachotage.
Sache aussi que c'était probablement beaucoup plus facile pour les gens de mon époque (ceux qui ont la trentaine passée) car à ton âge, nous utilisions les huit bits. Beaucoup plus limités, ils obligeaient le programmeur à faire preuve de beaucoup d'astuce. En revanche, les machines étaient beaucoup plus diversifiées qu'à notre époque, où le PC est tellement omniprésent que les gens ne savent même plus qu'il ne s'agit qu'un type d'architecture parmi d'autre (et pas le meilleur, loin de là !). D'autre part, les ressources de ces machines étaient également beaucoup restreintes et il était facile d'en faire le tour. On avait une maîtrise absolue de sa machine, ce qui est beaucoup moins fréquent aujourd'hui.
N'hésite pas à fréquenter les clubs et choisis bien tes forums (on trouve le meilleur comme le pire). En général, dans une coding party, on assimile en une journée ce que l'on aurait fait en trois mois, par ailleurs.
Souviens-toi enfin que c'est extrêmement chronophage et tu peux y passer ton adolescence entière si tu n'y prends pas garde. Bref, si tu as envie de conserver tes amis, ta copine et de profiter de la vie, c'est possible, mais à condition d'y faire activement attention.
Oui !
Si c'est pour être coder conventionnel, tu peux trouver très facilement.
Maintenant, pour les jeux vidéos en particulier, c'est un peu différent. A l'époque, un bon programmeur pouvait coder un casse-brique à lui tout seul et ravir tous ses camarades. Aujourd'hui, le jeu vidéo est comparable à l'industrie du cinéma et surtout, sans 3D, point de salut. Et le jeu vidéo est souvent le domaine où l'on va avoir besoin de hautes performances, et des programmeurs capables de les apporter.
Cela signifie qu'il faut non seulement être très bon programmeur, mais également avoir un solide bagage mathématique, ce qui, contrairement à ce que le profane pourrait croire, va rarement ensemble. Ceci dit, si tu finis une première S et que tu te diriges vers les sciences de l'ingénieur, cela devrait se passer sans trop de difficulté ...
Bonne chance.
[^] # Re: blague quantique
Posté par Obsidian . En réponse au journal Calcul quantique. Évalué à 2.
Mais tu ne peux pas en être certain avant de l'avoir relue :-)
[^] # Re: blague quantique
Posté par Obsidian . En réponse au journal Calcul quantique. Évalué à 3.
Surtout qu'en l'occurence, en répondant "Non, mais je sais où je suis", le premier mot répond quand même à la question ...
[^] # Re: blague quantique
Posté par Obsidian . En réponse au journal Calcul quantique. Évalué à 7.
[^] # Re: IPs ?
Posté par Obsidian . En réponse au message Mise en place d'un serveur postgresql. Évalué à 3.
# IPv4 local connections:
host all all 10.0.2.15/32 trust
Je ne sais pas comment tu l'as pris, mais cette entrée spécifie l'adresse distante du client qui essaie d'accéder à ton serveur, pas l'adresse locale d'écoute.
[^] # Re: Pirates de Brevets...
Posté par Obsidian . En réponse au journal SCO : Le retour. Évalué à 1.
Aïe ! :-(
Elle est sévèvre, celle-là ...
[^] # Re: lstart est ton ami
Posté par Obsidian . En réponse au message Date de lancement d'un processus. Évalué à 2.
Merci pour l'info.
[^] # Re: Utilise les dumps
Posté par Obsidian . En réponse au message Migrer de MySQL vers Prostgre. Évalué à 2.
Je pense que dans ce cas précis, ça reste la solution la plus facile et la plus rapide.
[^] # Re: Comme sur son foutu Solaris.
Posté par Obsidian . En réponse au message Date de lancement d'un processus. Évalué à 4.
C'est bizarre, ça marche bien chez moi (avec un 2.6.24.2). quelle est la version du noyau que tu utilises ?
Pfff. L'esprit "grandes boîtes" : si ce n'est pas rébarbatif, ce n'est pas du boulot. C'est désolant de voir le potentiel gaché par un tel esprit. C'est comme ça que l'on arrive à avoir mauvaise réputation auprès du reste du monde.
# Comme sur son foutu Solaris.
Posté par Obsidian . En réponse au message Date de lancement d'un processus. Évalué à 6.
Autant que je sache, Solaris fait la même chose, et le ps de chez GNU est compatible avec celui de Sun. Sinon, sous GNU/Linux, tu peux aussi essayer :
$ ls -dl --time-style=full-iso /proc/[0-9]*
Voila. C'est assez précis pour lui ? :-)
Ben, bravo. Troller entre deux Unices SysV. C'est vraiment pour le plaisir de se plaindre ...
# Utilise les dumps
Posté par Obsidian . En réponse au message Migrer de MySQL vers Prostgre. Évalué à 2.
$ psql mabase < monfichier.sql
A peu de choses près, ça devrait suffire (bon, je connais pg_dump, mais j'ai jamais essayé mysqldump, encore).
[^] # Re: autres gestionnaires ?
Posté par Obsidian . En réponse au message synaptic. Évalué à 3.
# Lug, Parinux
Posté par Obsidian . En réponse au message Initiation, formation pour débutant. Évalué à 2.
C'est parce que tu n'as pas encore découvert la Tribune ! :-)
Sachant que j’habite Paris 11ème, pouvez-vous m’orienter vers l’aide (si possible de proximité) dont j’ai besoin ?
Je plaisante. Tu as exactement l'attitude à avoir et tu devrais très vite trouver tes marques. Les LUGs (Linux User Groups) sont faits pour toi. Celui de Paris est Parinux :
http://www.google.fr/search?hl=fr&q=LUG+Paris&btnG=R(...)
http://www.parinux.org/
Bon courage et bienvenue.
[^] # Re: Lemme n°0 de Debian
Posté par Obsidian . En réponse au journal Le logo debian sur une pièce de deux euro.... Évalué à 2.
Je sors.
[^] # Re: Je vais faire mon chieur...
Posté par Obsidian . En réponse à la dépêche Important bug de sécurité sur noyau 2.6.17 à 2.6.24. Évalué à 2.
Je crois que cette phrase résume à elle-seule tout le sujet.
L'idée générale était bel et bien que le recours à root doit demeurer occasionnel.
[^] # Re: Je vais faire mon chieur...
Posté par Obsidian . En réponse à la dépêche Important bug de sécurité sur noyau 2.6.17 à 2.6.24. Évalué à 3.
Il ne s'agit pas de passer toutes les commandes root en un équivalent utilisateur ordinaire, mais les plus fréquentes, de façon à ce que passer root devienne exceptionnel (ou, au moins, rare).
Pour password, encore une fois, il y a une différence entre utiliser le SetUID d'une manière générale, et l'utiliser pour passer root. De toutes façons, pour gagner le droit d'écriture sur un fichier donné, un SetGID suffit. Pas besoin de changer en plus d'identité.
Quand a la difference entre ssh root et su -, je t'invite a faire taper "screen" dans les deux cas pour voir la diff ;)) (ssh cree un PTS alors que su ne le fait pas, tu est pas TOTALEMENT root en su pour de rare cas particuliers)
Déjà repondu juste au-dessus.
[^] # Re: Je vais faire mon chieur...
Posté par Obsidian . En réponse à la dépêche Important bug de sécurité sur noyau 2.6.17 à 2.6.24. Évalué à 3.
Encore une fois, il faut distinguer sudo et les setuids du compte root. On peut prendre l'identité de n'importe quel (pseudo-)utilisateur.
Un logiciel setuid qui fait des choses aussi complexes, ca a de quoi faire peur
Oui, mais cela reste toujours plus facile de les faire directement en root dès lors que les privilèges sont acquis. C'est pour cette raison qu'il ne faut pas prendre l'habitude de passer root à tout bout de champ.
Un truc style gksudo, par exemple, accorde un délai de grâce à une console inconnue (normal si directement lancée depuis X), ce qui permet à n'importe quel processus X-Window ou se détachant de lui-même de sa console d'en profiter ( https://linuxfr.org//comments/860291.html#860291 ).
Une console root ouverte sous X peut éventuellement recevoir des événements clavier d'une autre application connectée au serveur graphique ...
(et je vois mal la différence entre un su - et être loggué en root).
C'est-à-dire que su permet de changer d'identité, et pas forcément pour prendre celle du root. C'est ce dernier point qui est important, parce que ce n'est pas utilisé assez fréquement, à mon goût, pour les tâches d'administration.
Quand à utiliser su et se logger de façon ordinaire, c'est aussi, à mon avis, l'origine d'une faiblesse courante sur de nombreux système :lorsque su ou un dispositif similaire sont indisponibles, les gens préfèrent souvent s'accorder directement tous les pouvoirs, parce qu'il est difficile de changer temporairement d'identité. C'est même très génant quand on est obligés de le faire au milieu d'une session de travail.
[^] # Re: Je vais faire mon chieur...
Posté par Obsidian . En réponse à la dépêche Important bug de sécurité sur noyau 2.6.17 à 2.6.24. Évalué à 4.
qui est censé balancé 15 commandes à la minute nécessitant la plupart du temps les droits root
C'est surtout cela qu'il faut identifier. Quand tu en es à balancer, en temps normal, 15 commandes root à la minute, c'est que ta machine n'est pas configurée correctement. Il y a des dizaines de petits trucs à régler pour t'éviter de passer systématiquement root chaque fois que tu as besoin de faire une action un peu originale. L'une des plus importantes, à mon avis, est l'accès aux logs. Un sudo pour aller lire un log Apache ou autre, par exemple, est une hérésie. A la place, il faut créer un groupe dédié spécialisé et lui donner les droits de lecture seule.
En identifiant toutes les tâches privilégiées répétitives, tu peux réduire considérablement tes 15 commandes par minute. Evidemment, cela demande un minimum de bon sens. On peux donner les droits read-only sur des logs à un groupe, on sera beaucoup plus circonspects s'il faut donner les droits d'écriture.
Dans l'absolu, même des trucs comme passwd n'ont pas besoin d'être setuid root s'il ne s'agit que d'aller mettre à jour le fichier /etc/passwd. Un SetGID sur un groupe ordinaire suffit largement. Evidemment, aujourd'hui, ce n'est plus tout-à-fait vrai car le tout passe par PAM et qu'il y a différentes méthodes d'authentification. Mais l'esprit reste le même ...
[^] # Re: Je vais faire mon chieur...
Posté par Obsidian . En réponse à la dépêche Important bug de sécurité sur noyau 2.6.17 à 2.6.24. Évalué à 2.
[^] # Re: Je vais faire mon chieur...
Posté par Obsidian . En réponse à la dépêche Important bug de sécurité sur noyau 2.6.17 à 2.6.24. Évalué à 3.
[^] # Re: Je vais faire mon chieur...
Posté par Obsidian . En réponse à la dépêche Important bug de sécurité sur noyau 2.6.17 à 2.6.24. Évalué à 4.
Privilèges administrateur. C'est trop vague (et trop proche de Windows). Un administrateur en informatique, c'est quelqu'un qui fait des tâches d'administration sur les machines et qui, à ce titre, doit bénéficier de pouvoirs particulier. Le root UNIX, c'est quand même beaucoup plus précis que cela. Et de toutes façons, le bon administrateur UNIX ne travaille jamais sous root.
Rétropropagé. Pourquoi pas, mais ça reste un piège classique du traducteur. C'est un mot français qui n'a de sens que lorsque l'on connaît déjà l'original. Hors contexte, ça devient beaucoup plus flou.