OpenSuSE 11.1 install problem !
in [Suse]
|
Prev: useradd issue
Next: ttyUSB0 and ICS
From: DenverD on 27 Sep 2009 12:30 > Yes, I do know it's certainly not a good idea but I have done it in the > past and will probably do so again sometime in the future. The > important thing to not do, if you're going to use X as root, is to > *keep* *out* *of* *the* *users* *home* *directories* or, if you > manipulate something in a users home directory, use chown to > recursively set the ownership of the users home directory to that user. > That way any changed or incorrectly owned files become owned by that > user and it prevents some of the problems of having root-owned files > cause when trying to start X as the normal user. that is exactly the prescription to cure most (maybe all, i'm not sure) of those automagical problems mentioned earlier.. the problem is, when you are working with n00bs it is often difficult to learn what they did to break their machine.. much better, in my opinion is to foot stop: don't log in as root (cause you KNOW they are gonna go direct to their home and 'try' something.).. -- DenverD (Linux Counter 282315) via Thunderbird 3.0.1-1.1, KDE 3.5.7, openSUSE Linux 10.3, 2.6.22.19-0.4-default #1 SMP i686 athlon
From: David Bolt on 27 Sep 2009 12:26 On Sunday 27 Sep 2009 16:51, Happy Oyster played with alphabet spaghetti and left this residue on the plate: > On Sun, 27 Sep 2009 13:10:57 +0100, David Bolt <blacklist-me(a)davjam.org> wrote: > >>Yes, I do know it's certainly not a good idea but I have done it in the >>past and will probably do so again sometime in the future. The >>important thing to not do, if you're going to use X as root, is to >>*keep* *out* *of* *the* *users* *home* *directories* or, if you >>manipulate something in a users home directory, use chown to >>recursively set the ownership of the users home directory to that user. >>That way any changed or incorrectly owned files become owned by that >>user and it prevents some of the problems of having root-owned files >>cause when trying to start X as the normal user. > > And THERE is a damned big bullshit of SuSE (or whoever is responsible for THIS > bug): If a directory has the rights set as you want them, the order to the > system to change the rights ALSO for the lower subdirectories and files, this > order is not obeyed. How are you changing them? From a console and using chown, the changes occur when I do them: davjam(a)moray:~> ls -l music total 684 -rw-r--r-- 1 davjam users 478744 2009-09-16 01:59 core.410 -rw-r--r-- 1 davjam users 55148 2009-08-28 04:10 knoppix.binaries.txt -rw-r--r-- 1 davjam users 4747 2009-08-28 15:24 knoppix.packages.txt -rwxr-xr-x 1 davjam users 17615 2009-09-07 04:43 test -rw-r--r-- 1 davjam users 3075 2009-09-07 04:36 test.c -rw-r--r-- 1 davjam users 126996 2009-08-28 04:41 unknown.knoppix.packages.txt davjam(a)moray:~> sudo chown root.root music -R root's password: davjam(a)moray:~> ls -l music total 684 -rw-r--r-- 1 root root 478744 2009-09-16 01:59 core.410 -rw-r--r-- 1 root root 55148 2009-08-28 04:10 knoppix.binaries.txt -rw-r--r-- 1 root root 4747 2009-08-28 15:24 knoppix.packages.txt -rwxr-xr-x 1 root root 17615 2009-09-07 04:43 test -rw-r--r-- 1 root root 3075 2009-09-07 04:36 test.c -rw-r--r-- 1 root root 126996 2009-08-28 04:41 unknown.knoppix.packages.txt davjam(a)moray:~> ls -l total 9388 .... drwxr-xr-x 2 root root 151 2009-09-18 01:49 music .... davjam(a)moray:~> sudo chown davjam.users /home/davjam -Rv|grep -i changed chown: cannot access `/home/davjam/.gvfs': Permission denied changed ownership of `/home/davjam/music/.directory' to davjam:users changed ownership of `/home/davjam/music/knoppix.binaries.txt' to davjam:users changed ownership of `/home/davjam/music/unknown.knoppix.packages.txt' to davjam:users changed ownership of `/home/davjam/music/knoppix.packages.txt' to davjam:users changed ownership of `/home/davjam/music/test.c' to davjam:users changed ownership of `/home/davjam/music/test' to davjam:users changed ownership of `/home/davjam/music/core.410' to davjam:users changed ownership of `/home/davjam/music' to davjam:users davjam(a)moray:~> Regards, David Bolt -- Team Acorn: www.distributed.net OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s openSUSE 10.3 32b | openSUSE 11.0 32b | | openSUSE 10.3 64b | openSUSE 11.0 64b | openSUSE 11.1 64b | openSUSE 11.2m6 RISC OS 3.6 | RISC OS 3.11 | openSUSE 11.1 PPC | TOS 4.02
From: David Bolt on 27 Sep 2009 12:31 On Sunday 27 Sep 2009 17:06, J G Miller played with alphabet spaghetti and left this residue on the plate: > On Sun, 27 Sep 2009 13:40:31 +0200, houghi wrote: > >> But anyway, I would like to know what you think is a "exceptionally >> special circumstance" where you would run as root > > A possible circumstance could be root needs to run an X11 program for some > reason (administration task) and /home is not available because the file > system on it is bad, so normal users are unable to login. Why would you *need* to run any GUI based program for administration tasks? YaST2 runs very nicely as an ncurses application on a text console with minimal differences between the text layout and the QT layout. And if a file system is bad, you wouldn't be running a GUI application to fix it. That's what fsck and other related tools are for. Regards, David Bolt -- Team Acorn: www.distributed.net OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s openSUSE 10.3 32b | openSUSE 11.0 32b | | openSUSE 10.3 64b | openSUSE 11.0 64b | openSUSE 11.1 64b | openSUSE 11.2m6 RISC OS 3.6 | RISC OS 3.11 | openSUSE 11.1 PPC | TOS 4.02
From: David Bolt on 27 Sep 2009 12:28 On Sunday 27 Sep 2009 15:17, houghi played with alphabet spaghetti and left this residue on the plate: > David Bolt wrote: >>>> ! Non of the terminal (alt+ctrl+Fx) works either. >> >> That's not a good sign. > > type '3' when booting. This will not start the X server. I am also > unable to go to tty 1-6 when the NVidia drivers is used. On of my systems has an on-board SIS 660 graphics chip-set and, when used directly, will very often lock up both the screen and keyboard when switching between consoles. Since I mostly use it using SSH or NX, this doesn't bother me. On my other systems where on-board nVidia chip-sets or nVidia graphics cards are used, I have no issues with swapping to or from other consoles while using the nVidia drivers. In fact I often get caught out on this system when test-driving susestudio applications under VirtualBox as I frequently press the wrong key combo to go to another console. In stead of going to one in the VM, I swap to one on the real hardware. >>> Never startx as root! Never! >> >> You don't like the pretty desktop background with those nice little >> triangular warning signs and bombs? > > The what now? ;-) More or less, yes :-) >> Yes, I do know it's certainly not a good idea but I have done it in the >> past and will probably do so again sometime in the future. > > I have done it as well, just to see if the background has changed. :-D > Otherwise I have no need for it in the last few years. I can't remember the previous time I did it, possibly back when 9.3 was newly released. It might have been even earlier, but the background there made it clear that you weren't running as a normal user. The background now looks a lot different to what I remember. The last time I saw it, the background was a bright red with the warning triangles and bombs. Now[0], just make things really "Not A Good Idea"(tm), KDE4 when started as root doesn't give a visual indication that you're running as root. Instead it displays the standard desktop background, which is "Air" on my system. The root desktop image is still there but you now have to manually select it and, while the bomb and triangle is still there, the background has changed to a pale blue. >> And if you don't, post the actual errors produced when using startx as >> a user. > > He can't get into X, he cant get into CLI (as far as I can see) so he > can't get to the errors. From what I saw, the system was booting into run-level 5 but X wasn't starting and so he was seeing the same login prompt as he'd see on any of the other consoles. > Most likely he does not even see any errors. Possibly, possibly not. [0] Just to be silly, I logged in as root on a physical console, started a second session of X, waited for the desktop to finish loading and then logged back out. Regards, David Bolt -- Team Acorn: www.distributed.net OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s openSUSE 10.3 32b | openSUSE 11.0 32b | | openSUSE 10.3 64b | openSUSE 11.0 64b | openSUSE 11.1 64b | openSUSE 11.2m6 RISC OS 3.6 | RISC OS 3.11 | openSUSE 11.1 PPC | TOS 4.02
From: Happy Oyster on 27 Sep 2009 12:55
On Sun, 27 Sep 2009 17:26:57 +0100, David Bolt <blacklist-me(a)davjam.org> wrote: >On Sunday 27 Sep 2009 16:51, Happy Oyster played with alphabet >spaghetti and left this residue on the plate: > >> On Sun, 27 Sep 2009 13:10:57 +0100, David Bolt <blacklist-me(a)davjam.org> wrote: >> >>>Yes, I do know it's certainly not a good idea but I have done it in the >>>past and will probably do so again sometime in the future. The >>>important thing to not do, if you're going to use X as root, is to >>>*keep* *out* *of* *the* *users* *home* *directories* or, if you >>>manipulate something in a users home directory, use chown to >>>recursively set the ownership of the users home directory to that user. >>>That way any changed or incorrectly owned files become owned by that >>>user and it prevents some of the problems of having root-owned files >>>cause when trying to start X as the normal user. >> >> And THERE is a damned big bullshit of SuSE (or whoever is responsible for THIS >> bug): If a directory has the rights set as you want them, the order to the >> system to change the rights ALSO for the lower subdirectories and files, this >> order is not obeyed. > >How are you changing them? From a console and using chown, the changes >occur when I do them: From the GUI: <rightclick> <properties> -- TINA LIVE ! TINA LIVE ! TINA LIVE ! TINA LIVE ! TINA LIVE ! TINA LIVE ! http://www.leipziger-montagsdemo.de/informationen/daten/daten_02_spd/TINA-There_Is_No_Alternative_I.jpg http://www.leipziger-montagsdemo.de/informationen/daten/daten_02_spd/TINA-There_Is_No_Alternative_II.jpg |