On 12/24/2011 1:04 PM, gene heskett wrote: > 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 > Or just run the script with the entire path: /run/this/script/in/this/directory/script
Mark ------------------------------------------------------------------------------ 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
