Suivnt le conseil de certains grands sorciers de l'unix
je n'ai pas activé le compte Root.
Cela étant, j'aimerais savoir quelle différence existe
entre le compte Root et mon compte ou je suis administrateur ?
Le SUDO me permet-il de tout faire ?
Existe-t-il des applications qui demandent la présence d'un compte Root ?
par exemple, dans un article concernant l'installation de phpmyadmin, afin de protéger
par mot de passe les bases, il est demandé de modifier le fichier
config.inc.php....avec comme user : root et comme mot de passe celui de root
Pourtant il m'avait semble que c'etait impossible. C'etait peut-etre meme avec toi que j'en avais discute. Le serveur chais-pas-quoi refusait les connexins des autres utilisateurs que celui qui avait lance une session.
Oui, en effet. Mais j'avais sans doute précisé que root était une exception.
Voila bien une limitation stupide.
Au fait Cocoa, aqua et Carbon c'est quoi exactement? Si je fais une application graphique que vaut-il mieux utiliser (pour l'avenir)?
C'est l'API utilisée. Carbon est une évolution d'InterfaceLib qui est compatible (en partie du moins) avec Mac OS 9 et Mac OS X et qui permet donc de faire des applis qui tourne sur les deux OS. Cocoa est une évolution d'une API de NeXT et ne tourne que sur Mac OS X. C'est l'API recommandée si la compatibilité avec Classic n'est pas nécessaire.
Merci.
-- Saïd.
Patrick Stadelmann :
In article <3FB24B97.1020700@spaMquatramaran.ens.fr>,
Saïd <saidNo@spaMquatramaran.ens.fr> wrote:
Pourtant il m'avait semble que c'etait impossible. C'etait peut-etre
meme avec toi que j'en avais discute. Le serveur chais-pas-quoi refusait
les connexins des autres utilisateurs que celui qui avait lance une
session.
Oui, en effet. Mais j'avais sans doute précisé que root était une
exception.
Voila bien une limitation stupide.
Au fait Cocoa, aqua et Carbon c'est quoi exactement? Si je fais une
application graphique que vaut-il mieux utiliser (pour l'avenir)?
C'est l'API utilisée. Carbon est une évolution d'InterfaceLib qui est
compatible (en partie du moins) avec Mac OS 9 et Mac OS X et qui permet
donc de faire des applis qui tourne sur les deux OS. Cocoa est une
évolution d'une API de NeXT et ne tourne que sur Mac OS X. C'est l'API
recommandée si la compatibilité avec Classic n'est pas nécessaire.
Pourtant il m'avait semble que c'etait impossible. C'etait peut-etre meme avec toi que j'en avais discute. Le serveur chais-pas-quoi refusait les connexins des autres utilisateurs que celui qui avait lance une session.
Oui, en effet. Mais j'avais sans doute précisé que root était une exception.
Voila bien une limitation stupide.
Au fait Cocoa, aqua et Carbon c'est quoi exactement? Si je fais une application graphique que vaut-il mieux utiliser (pour l'avenir)?
C'est l'API utilisée. Carbon est une évolution d'InterfaceLib qui est compatible (en partie du moins) avec Mac OS 9 et Mac OS X et qui permet donc de faire des applis qui tourne sur les deux OS. Cocoa est une évolution d'une API de NeXT et ne tourne que sur Mac OS X. C'est l'API recommandée si la compatibilité avec Classic n'est pas nécessaire.
Merci.
-- Saïd.
jperrocheau
Ego wrote:
Pour revenir à la question initiale, il n'y aurait rien d'impossible à effectuer sans compte root ?
Un Unix ne peut pas marcher sans compte root (utilisateur qui a l'UID=0). Il faut te mettre cela dans la tête ;-)
Dans Mac OS X, il est simplement désactivé. "sudo" permet d'effectuer la plupart des actions qui demande "les droits de root".
lire:
man sudo
-- Jacques PERROCHEAU ______________________________________________________________ e-mail: mailto:
Ego <alterman@freefree.fr> wrote:
Pour revenir à la question initiale, il n'y aurait rien
d'impossible à effectuer sans compte root ?
Un Unix ne peut pas marcher sans compte root (utilisateur qui a
l'UID=0). Il faut te mettre cela dans la tête ;-)
Dans Mac OS X, il est simplement désactivé. "sudo" permet d'effectuer la
plupart des actions qui demande "les droits de root".
lire:
man sudo
--
Jacques PERROCHEAU
______________________________________________________________
e-mail: mailto:jperrocheau@mac.com
Ça peut être utile pour debuguer une application carbon avec gdb.
Pourtant il m'avait semble que c'etait impossible. C'etait peut-etre meme avec toi que j'en avais discute. Le serveur chais-pas-quoi refusait les connexins des autres utilisateurs que celui qui avait lance une session.
Au fait Cocoa, aqua et Carbon c'est quoi exactement? Si je fais une application graphique que vaut-il mieux utiliser (pour l'avenir)?
L'avenir, c'est Cocoa, mais de nombreuses API ne sont encore disponibles que Carbon. La principale différence entre Cocoa et Carbon (à part l'origine) c'est que Cocoa est orienté objet (écrit en Objective-C, mais aussi accessible en java, perl, python et applescript) alors que Carbon est pseudo-objet en C.
Aqua, c'est le nom de l'interface graphique, accesible bien évidemment de Carbon et Cocoa.
-- Schmurtz
bull shit. sudo suffit, mais tu ne pourra pas l'editer dans un
application graphique. Il faudra l'editer en mode texte.
Effectivement, sudo suffit pour tout faire en temps que root.
Si tu veux avors un shell root, il suffit de faire "sudo -s", ou même
"sudo su -" pour être aussi root qu'un login en root (dans le terminal)
On peut lancer les applis graphique Cocoa en root via sudo :
Ça peut être utile pour debuguer une application carbon avec gdb.
Pourtant il m'avait semble que c'etait impossible. C'etait peut-etre
meme avec toi que j'en avais discute. Le serveur chais-pas-quoi refusait
les connexins des autres utilisateurs que celui qui avait lance une
session.
Au fait Cocoa, aqua et Carbon c'est quoi exactement? Si je fais une
application graphique que vaut-il mieux utiliser (pour l'avenir)?
L'avenir, c'est Cocoa, mais de nombreuses API ne sont encore disponibles
que Carbon. La principale différence entre Cocoa et Carbon (à part
l'origine) c'est que Cocoa est orienté objet (écrit en Objective-C, mais
aussi accessible en java, perl, python et applescript) alors que Carbon
est pseudo-objet en C.
Aqua, c'est le nom de l'interface graphique, accesible bien évidemment
de Carbon et Cocoa.
Ça peut être utile pour debuguer une application carbon avec gdb.
Pourtant il m'avait semble que c'etait impossible. C'etait peut-etre meme avec toi que j'en avais discute. Le serveur chais-pas-quoi refusait les connexins des autres utilisateurs que celui qui avait lance une session.
Au fait Cocoa, aqua et Carbon c'est quoi exactement? Si je fais une application graphique que vaut-il mieux utiliser (pour l'avenir)?
L'avenir, c'est Cocoa, mais de nombreuses API ne sont encore disponibles que Carbon. La principale différence entre Cocoa et Carbon (à part l'origine) c'est que Cocoa est orienté objet (écrit en Objective-C, mais aussi accessible en java, perl, python et applescript) alors que Carbon est pseudo-objet en C.
Aqua, c'est le nom de l'interface graphique, accesible bien évidemment de Carbon et Cocoa.
-- Schmurtz
Ego
Jacques Perrocheau wrote:
Un Unix ne peut pas marcher sans compte root (utilisateur qui a l'UID=0). Il faut te mettre cela dans la tête ;-)
Oui je crois savoir qu'il existe un compte root sinon je n'essaierai pas de savoir s'il faut l'activer ou non :)
Dans Mac OS X, il est simplement désactivé. "sudo" permet d'effectuer la plupart des actions qui demande "les droits de root".
lire:
man sudo
Cela ne répond pas à ma question, quand il faut utiliser un sudo et bien je fais un sudo ! Ce qu j'aimerais savoir c'est ce qui se cache derrière "la plupart des actions" autrement dit : Qu'est-ce que je ne peux pas effectuer sans avoir activé un compte Root .
Merci Ego
Jacques Perrocheau <jperrocheau@mac.com.invalid> wrote:
Un Unix ne peut pas marcher sans compte root (utilisateur qui a
l'UID=0). Il faut te mettre cela dans la tête ;-)
Oui je crois savoir qu'il existe un compte root sinon je
n'essaierai pas de savoir s'il faut l'activer ou non :)
Dans Mac OS X, il est simplement désactivé. "sudo" permet d'effectuer la
plupart des actions qui demande "les droits de root".
lire:
man sudo
Cela ne répond pas à ma question, quand il faut utiliser
un sudo et bien je fais un sudo ! Ce qu j'aimerais savoir c'est ce qui
se cache derrière "la plupart des actions" autrement dit :
Qu'est-ce que je ne peux pas effectuer sans avoir activé un
compte Root .
Un Unix ne peut pas marcher sans compte root (utilisateur qui a l'UID=0). Il faut te mettre cela dans la tête ;-)
Oui je crois savoir qu'il existe un compte root sinon je n'essaierai pas de savoir s'il faut l'activer ou non :)
Dans Mac OS X, il est simplement désactivé. "sudo" permet d'effectuer la plupart des actions qui demande "les droits de root".
lire:
man sudo
Cela ne répond pas à ma question, quand il faut utiliser un sudo et bien je fais un sudo ! Ce qu j'aimerais savoir c'est ce qui se cache derrière "la plupart des actions" autrement dit : Qu'est-ce que je ne peux pas effectuer sans avoir activé un compte Root .
Merci Ego
Schmurtz
Qu'est-ce que je ne peux pas effectuer sans avoir activé un compte Root .
Rien.
cf le fichier /etc/sudoers qui décrit les droits données aux utilisateurs. Le groupe admin peut tout faire sur toutes les machines (dans un parc de machines configuré pour que ça marche) en prenant l'identité de n'importe quel utilisateur (c'est la ligne %admin ALL = (ALL) ALL)
-- Schmurtz
Qu'est-ce que je ne peux pas effectuer sans avoir activé un
compte Root .
Rien.
cf le fichier /etc/sudoers qui décrit les droits données aux
utilisateurs. Le groupe admin peut tout faire sur toutes les machines
(dans un parc de machines configuré pour que ça marche) en prenant
l'identité de n'importe quel utilisateur (c'est la ligne %admin ALL =
(ALL) ALL)
Qu'est-ce que je ne peux pas effectuer sans avoir activé un compte Root .
Rien.
cf le fichier /etc/sudoers qui décrit les droits données aux utilisateurs. Le groupe admin peut tout faire sur toutes les machines (dans un parc de machines configuré pour que ça marche) en prenant l'identité de n'importe quel utilisateur (c'est la ligne %admin ALL = (ALL) ALL)
-- Schmurtz
Ego
Schmurtz wrote:
Qu'est-ce que je ne peux pas effectuer sans avoir activé un compte Root .
Rien.
cf le fichier /etc/sudoers qui décrit les droits données aux utilisateurs. Le groupe admin peut tout faire sur toutes les machines (dans un parc de machines configuré pour que ça marche) en prenant l'identité de n'importe quel utilisateur (c'est la ligne %admin ALL = (ALL) ALL)
merci cette fois c'est très clair et je resterai donc avec mon compte root inactivé
Encore merci, j'avais mis le nez dans man sudo et man sudoers mais
1) mon anglais est un peu faiblard
2) root ALL=(ALL) ALL %admin ALL=(ALL) ALL
ce n'est pas facile à interpréter
Schmurtz <moi@ici.com> wrote:
Qu'est-ce que je ne peux pas effectuer sans avoir activé un
compte Root .
Rien.
cf le fichier /etc/sudoers qui décrit les droits données aux
utilisateurs. Le groupe admin peut tout faire sur toutes les machines
(dans un parc de machines configuré pour que ça marche) en prenant
l'identité de n'importe quel utilisateur (c'est la ligne %admin ALL =
(ALL) ALL)
merci cette fois c'est très clair et je resterai donc avec mon compte
root inactivé
Encore merci, j'avais mis le nez dans man sudo et man sudoers mais
Qu'est-ce que je ne peux pas effectuer sans avoir activé un compte Root .
Rien.
cf le fichier /etc/sudoers qui décrit les droits données aux utilisateurs. Le groupe admin peut tout faire sur toutes les machines (dans un parc de machines configuré pour que ça marche) en prenant l'identité de n'importe quel utilisateur (c'est la ligne %admin ALL = (ALL) ALL)
merci cette fois c'est très clair et je resterai donc avec mon compte root inactivé
Encore merci, j'avais mis le nez dans man sudo et man sudoers mais
1) mon anglais est un peu faiblard
2) root ALL=(ALL) ALL %admin ALL=(ALL) ALL
ce n'est pas facile à interpréter
Schmurtz
root ALL=(ALL) ALL le premier ALL : les machines sur lesquelle tu as les droits défini
après le égal le deuxième ALL : les utilisateurs dont tui peut prendre l'identité pour exécuter les commandes du troisième ALL.
%admin ALL=(ALL) ALL
idem, le % indique que c'est un groupe.
Pouir le reste, lire le man en anglais.
-- Schmurtz
root ALL=(ALL) ALL
le premier ALL : les machines sur lesquelle tu as les droits défini
après le égal
le deuxième ALL : les utilisateurs dont tui peut prendre l'identité pour
exécuter les commandes du troisième ALL.
config.inc.php....avec comme user : root et comme mot de passe celui de root
Ce n'est pas le même root :-)
Ce root là est celui de MySQL, le big boss donc, mais que de MySQL.
-- Jacques
Nicolas.MICHEL
Ego wrote:
Pour revenir à la question initiale, il n'y aurait rien d'impossible à effectuer sans compte root ?
En théorie, non.
En pratique, ça m'est arrivé de devoir ponctuellement activer root. Soit parce que le programateur l'avait décidé ainssi (NFSmanager), soit parce qu'un installateur était buggy (ARD 1.0 server) Soit parce qu'une procédure de dépannage préconisait son utilisation, et que généralement je respecte les procédures.
Mais tu pourras toujours t'en inquiéter à ce moment là si tu en as besoins, et désactiver root ensuite.
-- Je m'appelles Billy et je suis Funky
Ego <alterman@freefree.fr> wrote:
Pour revenir à la question initiale, il n'y aurait rien
d'impossible à effectuer sans compte root ?
En théorie, non.
En pratique, ça m'est arrivé de devoir ponctuellement activer root.
Soit parce que le programateur l'avait décidé ainssi (NFSmanager),
soit parce qu'un installateur était buggy (ARD 1.0 server)
Soit parce qu'une procédure de dépannage préconisait son utilisation, et
que généralement je respecte les procédures.
Mais tu pourras toujours t'en inquiéter à ce moment là si tu en as
besoins, et désactiver root ensuite.
Pour revenir à la question initiale, il n'y aurait rien d'impossible à effectuer sans compte root ?
En théorie, non.
En pratique, ça m'est arrivé de devoir ponctuellement activer root. Soit parce que le programateur l'avait décidé ainssi (NFSmanager), soit parce qu'un installateur était buggy (ARD 1.0 server) Soit parce qu'une procédure de dépannage préconisait son utilisation, et que généralement je respecte les procédures.
Mais tu pourras toujours t'en inquiéter à ce moment là si tu en as besoins, et désactiver root ensuite.