|
In Michael Jiang's RHCE Study Guide, it says: "... you can redirect the output from X Clients running on remote systems back to the X Server running on your desktop....Using the Secure Shell (ssh)..., you can log into the remote client computer. You can then start X Clients such as xterm or even a Red Hat GUI tool such as the Security Level Configuration tool with the system-config-securitylevel command.... The GUI application opens automatically on the local computer."
I found the simple xclient works, such as xclock, but the advanced one fails, such as system-config-securitylevel.
NOTE: those steps are from Michael Jiang's RHCE Study Guide:
1. On the Enterprise computer, start the X Window. If it isn’t already open,
use the startx command.
2. When the Linux GUI is open, right-click on the desktop. In the pop-up
menu that appears, click New Terminal.
3. Authorize access from the local computer with an appropriate
xhost command.
4. Log into the remote computer using the Secure Shell. To log in as root, use
the following command. Enter the root password on the remote computer
when prompted. If you’re asked if you want to set up a encryption key, type
yes. This should log you into the remote computer.
# ssh root@cosmicc
root@cosmicc's password:
5. Now you can start the GUI applications of your choice. Start with some easy
X Clients, such as xterm, xclock, and xeyes.
6. You should be able to run most of the Red Hat GUI utilities from the
remote computer. Try some with commands such as system-config-network,
system-config-samba, and system-config-securitylevel.
The last step will not open any gui. Here is the error messages:
The program 'system-config-securitylevel.py' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 64 error_code 3 request_code 38 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Anyone encounter this problem? |
|