Obsidian a écrit 5299 commentaires

Tu confonds avec Frontpage ... /o\

Je sors.

il y a peu de taches répetitives que j'ai a faire en root de facon régulière.

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.

C'est parce que tu as mal lu. :-)

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.

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 ...

Meilleur, en effet.

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.

Tu m'as fichu les boules :j'ai cru qu'Eolas était mort !

Bon, sinon, c'est triste mais 90 ans, c'est quand même une belle vie.

Salut, y aura sûrement dis micros là-haut ...

C'est intéressant mais si Picidae reste un serveur décentralisé, il se fera filtrer comme les autres. C'est déjà ce qui arrive aux anonymizers les plus populaires ...

Penser à recharger la page avant de poster, les gars !

Bonjour,

le style SMS est proscrit sur ce site, merci de faire des phrases complètes.

Les deux serveurs de bases de données les plus populaires sous Linux sont MySQL et PostgreSQL.

Installe le package correspondant de ta distribution et tout sera filé avec : serveur lancé au démarrage, moniteur client, bibliothèques et documentations .

Bon courage.

A part ça, je ne dis jamais non plus que je suis informaticien; il est plus simple de dire "je travaille sous linux dans les réseaux". Le pauvre gus qui pensait te demander de l'aide ne comprend meme pas ce que tu lui dis, donc pour pas passer pour un con, il se tait.

C'est pas faux ! :-)

en bash, tu peux aussi écrire echo {1..20} ...

man pam

... devrait être un bon point de départ. Ces pages-là également :

http://www.kernel.org/pub/linux/libs/pam/modules.html
http://sourceforge.net/projects/pam-mysql/

Sinon, si c'est en local, tu peux écrire une application qui remplace mingetty, mais tu as intérêt à savoir ce que tu fais. Dans tous les cas, garde au moins une console qui s'authentifie par les moyens traditionnels, histoire de rentrer en root quand même si jamais le serveur de base de données ne démarre pas, par exemple.

En réalité, c'est quelque chose que l'on dit souvent de l'enseignement en général. Il est extrêmement important de donner le goût de ce que l'on enseigne, mais les bons pédagogues sont assez rares. D'autre part, pédagogie, vulgarisation, et enseignement proprements dits sont des choses sensiblement différentes, qu'il faut examiner individuellement et avec soin avant de les réunir en un même cours, le piège étant de les confondre.

Concernant la compta, il existe un cas tout-à-fait similaire en informatique :la gestion des bases de données.

C'est typiquement le truc qui gave tout le monde en cours, spécialement les développeurs, alors que c'est critique en entreprise. C'est même un devenu un métier à part entière. D'expérience, même les administrateurs système ne veulent pas y mettre les doigts. Ils l'admettent généralement de façon très hypocrite devant le DBA car cela leur donne l'illusion de respecter les plate-bandes des différents acteurs du service informatique alors que les devs doivent se battre pour avoir les moyens de travailler correctement. :-)

Pourtant, dès lors que a), on sort du cliché typique "client-numéro de commande-fournisseur-annuaire-adresse du client" et que b), on soit affranchi au départ du remplissage (souvent manuel) de la base fraîchement pondue, il y a vraiment moyen de s'amuser.

Personnellement, les bases de données me poussaient à la dépression rien que d'y penser, puis j'ai eu à développer des applications qui exploitaient une base existante de 53 tables sur un serveur Sybase, déjà remplies par plusieurs millions d'entrées. Dès lors, j'ai appris le SQL sur le tas avec SQLPro puis, étant retourné en cours, j'ai assimilé les bases académiques qui y sont associées. Depuis, je suis en train de me passionner pour PostgreSQL 8.3, qui est réellement un petit bijou en soi.

Mais ... les gens du métier auront toujours la possibilité d'agir dessus dès qu'elle sera connue, comme celle de pouvoir identifier les effets de bord qu'elle implique et qui concernent le contexte dans lequel le système est exploité.

On n'est pas obligé d'attendre le patch issu selon le bon vouloir de la maison-mère ni de se contenter d'un "dormez braves gens, nous avons fait le nécessaire".

Quand il y a un départ de feu chez soi, appeler les pompiers, c'est bien, avoir un extincteur à portée de main, c'est mieux.

Essaie, lorsque l'écran devient noir, de taper Ctrl+Alt+F1 pour voir si tu peux revenir sur une console texte, puis taper Alt+F2, Alt+F3, Alt+F4, etc. pour changer de console virtuelle.

Il est possible que :
1) Il te faille recompiler le pilote nVidia (pas très difficile)
2) Il te faille bidouiller la config de X.org pour y mettre les bonnes options, spécialement si ta carte est une dual-head, a une sortie TV, ou autre goodies.

Encore une fois, en principe, ce truc ne peut pas marcher, car #! appelle l'exécutable en lui passant le nom du script en argument, et pas en balançant son contenu sur l'entrée standard, comme iptables-restore s'y attend. Extrait de man iptables-restore :

iptables-restore is used to restore IP Tables from data specified on STDIN. Use I/O redirection provided by your shell to read from a file

Il paraît que iptables-restore accepte quand même un fichier en argument mais ça reste à vérifier et c'est de toutes façons à proscrire.

PS : Hum, marche plus, blockquote ?

T'aurais pas le même problème qui lui ? (mercredi dernier).

https://www.linuxfr.org/forums/15/23937.html

Restart regularly

This tip is simple. Restart your PC at least once a week, especially if you use it a lot. Restarting a PC is a good way to clear out its memory and ensure that any errant processes and services that started running get shut down.

Tiens, d'ailleurs, cette entrée devrait répondre à une interrogation de pasBill :

https://linuxfr.org/comments/488622.html#488622

C'est donc bien l'usage, chez MS.

Restarting closes all the software running on your PC. Not only the programs you see running on the taskbar, but also dozens of services that might have been started by various programs and never stopped. Restarting can fix mysterious performance problems where the exact cause is hard to pinpoint.

If you keep so many programs, e‑mail messages, and websites open that you think restarting is a hassle, that’s probably a sign you should restart your PC. The more things you have open and the longer you keep them running, the greater the chances your PC will bog down and eventually run low on memory.

Ça, c'est quand même énorme, nom d'un chien.

Ça laisse penser que les gens qui ont écrit ce papier pensent en toute bonne foi que même sur un système très fiable, on ne peut empêcher l'entropie de progresser et que c'est vrai sur tous les O.S.

Même si c'est à destination de Mme Michu, une grande compagnie ne doit pas distiller de pareilles âneries, sinon les gens vont vraiment finir par croire qu'il faut rebooter pour l'hygiène !

Que les gens ne s'intéressent pas à la technique est une chose, confirmer de manière officielle ce qui devrait être une mauvaise habitude en est une autre.

C'est ce que je m'apprétais à dire également, pour leur donner au moins un point, jusqu'à ce que je m'aperçoive que le conseil suivant est :

Limit how many programs load at startup

Donc, c'est pour une autre raison ! :-)

Il faudrait se renseigner un peu avent de dénigrer.... #! passe stdin au programme appelé.

Relis-toi ! Tu viens de montrer qu'un scrit shell reçoit l'entrée standard, pas son propre contenu ...

ça fait longtemps que tu n'es pas aller à l'école

Ben toi non plus, visiblement ... :-)

Nan, je rigole mais d'une part, cette une erreur tellement fréquente que non seulement, elle vient probablement de l'école elle-même (même si on se refuse à le reconnaître) mais on la voit tellement souvent qu'on en arrive à douter.

L'heure de la segfault, je dirais surtout ... :-)