Le 24/12/2011 19:04, gene heskett a écrit : > On Saturday, December 24, 2011 12:56:52 PM Mark Wendt (Contractor) did > opine: > >> On 12/24/2011 12:22 PM, gene heskett wrote: >>> On Saturday, December 24, 2011 12:14:41 PM yann jautard did opine: >>>> Le 24/12/2011 15:04, gene heskett a écrit : >>>>> On Saturday, December 24, 2011 09:00:31 AM Mark Wendt (Contractor) >>>>> did >>>>> >>>>> opine: >>>>>> On 12/23/2011 2:47 PM, gene heskett wrote: >>>>>>> I sounded like a good idea, but: >>>>>>> [gene@coyote ~]$ ssh shop >>>>>>> gene@shop's password: >>>>>>> Linux shop 2.6.32-122-rtai #rtai SMP Tue Jul 27 12:44:07 CDT 2010 >>>>>>> i686 GNU/Linux >>>>>>> Ubuntu 10.04.3 LTS >>>>>>> >>>>>>> Welcome to Ubuntu! >>>>>>> >>>>>>> * Documentation: https://help.ubuntu.com/ >>>>>>> >>>>>>> 11 packages can be updated. >>>>>>> 6 updates are security updates. >>>>>>> >>>>>>> Last login: Thu Dec 22 09:38:52 2011 from coyote.coyote.den >>>>>>> gene@shop:~$ sudo useradd -u 500 gene >>>>>>> [sudo] password for gene: >>>>>>> useradd: user 'gene' already exists >>>>>>> >>>>>>> So there isn't an obvious way to make the user numbers match >>>>>>> between the *buntu's and the rest of the world. >>>>>>> >>>>>>> The last time I tried that, I wound up re-installing to fix it. >>>>>>> >>>>>>> Cheers, Gene >>>>>> Gene, >>>>>> >>>>>> What about good old vi, or gedit on the /etc/passwd and /etc/group >>>>>> files, changing the uid and gid to what ever you need, then doing a >>>>>> chown -R gene:gene on /home/gene >>>>>> >>>>>> No need to reinstall. Just a little careful editing is all you >>>>>> need. >>>>>> >>>>>> Mark >>>>> I did something like that, including the chown -R back on 8.04 and >>>>> had to reinstall. Among other things, sudo quit working so I >>>>> couldn't fix the rest of the perms problems that created. >>>>> >>>>> Cheers, Gene >>>> yeah sudo quit working due to permission problems during the >>>> operation. >>>> >>>> This is why you need to create a root password first, and login as >>>> root to make the user modification. >>>> >>>> sudo password root >>>> >>>> then you log off the graphical interface >>>> >>>> switch to terminal (ctrl-F1) >>>> >>>> login as root >>>> >>>> make the modifications >>>> >>>> >>>> go back to the graphical login (ctrl-F7 or F8) then login as your >>>> normal user, and that's all. >>> That is, IIRC, what I did to an older 6.06 LTS install. Things worked >>> passably well, but somehow the root passwords presence messed up sudo, >>> it wouldn't take either pw, so that I had to constantly su - to do >>> things that scripts use su for. So I tried to remove the root pw, >>> then that blew everything up and I had to re-install. >>> >>> AFAIAC, the buntu's do that to be a PITA, thinking it might add to the >>> many layers of security. Perhaps it does, to an ex winders user, but >>> I am used to machinery that only I have access to, and which do >>> exactly as I tell them too, even if its wrong. :) >>> >>> Cheers, Gene >> Gene, >> >> That sounds like syntax problems in the passwd, group or shadow file. >> The root account's password has nothing to do with the operation of >> sudo. sudo uses either a set uid, or set gid process to gain the >> elevated privileges to do it's work. It doesn't access the root account >> at all. >> >> Realize there's a difference between a simple "su" and "su -". An "su" >> will bring you up to superuser, however it uses the rc scripts in the >> account you are "su'ing" from to set the environment. An "su -" brings >> you up to superuser, but it does so using the rc scripts in the "root" >> account to set the environment. Unless you have a reason to use the >> regular user account's rc scripts, I'd recommend to always use "su -" >> when you are doing real superuser work. >> >> Mark > I do. But that is so all encompassing on pclos, that all paths then have > to be cd'd to from the /root account. Even when using it in a script, a cd > to do something in a subdir must be semicolon separated else the effect of > the cd expires at the end of the current line of the script, so the > operative work command must be "cd wherever;exec the subscript" in > construction. You cannot cd somewhere, and expect that cd to be effective > for the next line of the script, it is not. One can script around it, but > it took me a half an hour to grasp the concept. It will be interesting to > see if centos has a similar restriction. > > Cheers, Gene
I think here we are talking about another problem. The point is not to use root account to make all your admin stuff (even if it may be a better choice than sudo), but use it only the time needed to change your UID, or other special things like that you might need to do. Gaining acces to real root account by setting a password for it does not mean you cannot continue using sudo for everything you are using it now. And about using su, or su -, I don't think it is a good idea when making a UID change. Because using su, you are still logged in as the user you are changing the UID, and this _will_ bring problems. The initial login process or terminal might crash or something like that. Just log in a real root user on a terminal, without graphical interface, and do the stuff. I have root account acces on my EMC machine as well as the shop file server, and my laptop(wich I'm writing from), the tree of them using ubuntu 9,04 10,10 and 11,04, and I don't experience any issues while using sudo. ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
