Solaris / OpenSolarisThis forum is for the discussion of Solaris and OpenSolaris.
General Sun, SunOS and Sparc related questions also go here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I have been trying installing CentOS on BrandZ. It works, I can have xclock showing in a window on Solaris. X11 forwarding, that is. To get it working, I do "su". If I do "su -" it doesnt work, as I have messed my root acc up. I have tinkered with xauth, xhost + and lots of other stuff in the global Solaris zone. Now my Solaris root account is acting weird. Before, Solaris root account could show "gvim" as a window, but not anymore, only cli.
Xlib: connection to "localhost:0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
E233: cannot open display
Using authority file /root/.Xauthority
frasse:0 MIT-MAGIC-COOKIE-1 f1f1f9f4cfe8dad4c7d7fbd5c4c9f2cf
frasse/unix:0 MIT-MAGIC-COOKIE-1 f1f1f9f4cfe8dad4c7d7fbd5c4c9f2cf
The DISPLAY is empty string, "".
How do I get Solaris global zone root account working correctly again? I want to be able to type "gvim" without getting error msgs.
And, my .bash_profile exists but it doesnt execute? My root PATH is just /usr/sbin:/usr/bin
despite me having a long path in .bash_profile. Why is my PATH short? I think it was when I made a user "cbe" for compiling wine, that this happened? Before that, the PATH in .bash_profile was valid.
I don't understand the requirement for doing su to be able to use the BrandZ zone. Anyway, I'm afraid you are messing too much with the root account. My advice would be to leave its home directory as /, its shell as /sbin/sh and never log in as it again outside exceptional situations like singleuser mode.
Another point: you don't need to run gvim as root.
If you want to edit system files, either grant you the rights to write them through ACLs (1), or simply give your non root personal account full administrative rights (2). In the latter case, logout and login again for the change to take effect. Then you can run any command with root privileges by prefixing it with pfexec (eg: pfexec gvim file)
When I create install programs, zones, format the drive, mount file systems, zpool, ifconfig, ass users, etc you mean that root acc is not necessary to do all this stuff? Ive read that you recommend against logging in as root ever, but I didn't thought you meant it literally? Or did you? O_o
If you did, never ever log in as root, then approach (2) seems neatest to me. If I do ansatz (2), I practically have root rights? Then I can do all those things I do as root?
And then I dont never ever log in as root again? As my root acc is acting a bit weird, I dont have to try to correct the problem because I will never ever log in as root again?
But... what is the point of this arrangement? Now we have just moved the root rights to another user. This would be equivalent to if a user "su -" as soon as he needs to do something administrative? Writing "su -" corresponds to "pfexec bash"?
However, locking the root account still prevents a root login shell to be run, either under a graphic environment or through a remote or local login prompt.
Solaris allows finer grain privileges but there is no real incentive in using them in your case as you are the only administrator of your machine. You are right granting you the full set of privileges is not that much different than using "su -" but at least removes the annoyance of asking you for root's password. By entering the pfexec prefix, you are also knowing you are about to execute a sensitive command, while if you have a root's login shell, you are tempted to run casual commands like a browser or other foreign untrusted applications with the risk for the system to be compromised. A mistake in a rm or similar command would be more damaging as root too.