Problems with FC3 - any ideas?

General Computing *nix and other operating systems
1

I have a small problem with FC3 which is not apparent on my FC2 boxes.

I have configured FC3 with a VNC server, in exactly the same way as FC2. VNC will let me access my normal desktop no problems, but if I try to run anything which requires root access e.g. up2date, I am prompted for the password and then … nothing. The same applies to 99% of the items on the “System Settings” menu. I can, from terminal, “su” to root just nothing in the X desktop.

Putting a head on the box and doing exactly the same thing works fine.
FC2 works fine either way.

This is a pain because to do, say, a kernel update I need to pull the box, put a screen and keyboard on it, run the update, and then put it back in the “farm”. I’m seriously tempted to reinstall FC2 on these boxes - there are only two headless.

Firewall is off, SELinux is off.

Any ideas?

2

It could be very well the X forwarding. I am not sure how VNC handles the displays but with some other apps on LINUX a xforwarder is set up and and drives the display through the user interface vo security reasons.

Personally I use ssh and export my display to the local X server and just run xapps that way, I keep the headless boxes in runlevel 3 as to not waste any resources on a Xserver for a box with no head. One can always start the xserver for the console if a head is attached. The /etc/initab line to change to run level 3 looks like this.
[b]

Default runlevel. The runlevels used by RHS are:

0 - halt (Do NOT set initdefault to this)

1 - Single user mode

2 - Multiuser, without NFS (The same as 3, if you do not have networking)

3 - Full multiuser mode

4 - unused

5 - X11

6 - reboot (Do NOT set initdefault to this)

id:3:initdefault:
[/b]

For instance
xhost +
ssh otherbox ----- do all the login stuff
export DISPLAY=localbox:0.0
up2date

Actually for updating the system I just ssh in and run
yum -y update

the update.conf can altered to point at the fastest servers and the updates run flawlessly.

Then I put a cron entry in to fire yum and the updates take place on the frequency of the cronjob.

3

Still not sussed this - it’s X which is causing the problem for sure.

However a cron job to run

up2date -u -v -f -i --nox >up2date.log

works just as well :nod:

4

Up2date uses yum under the covers. :wink:

Check out ssh and X forwarding. I will have a look at the stuff at work today.

5

Hi there…

I too would also be interested in the resolution to this. Or even finding out what is causing it to break would be helpful.

I am running FC3 and this was initially working fine for me up until about a month ago. I am accessing a server in my home country while oversees and I like to use a GUI for doing iptables work (not to mention I am still learning linux and need the GUI everynow and again).

The previous senario was this: I would log in with a user account (vnc tunnelled thru ssh) and for things like launching u2date or other system services as you describe, it would prompt me for the root pwrd and then voila. Now it just prompts me for the password and nothing. I have tried with both the xserver settings method and now the built in vnc.so with the xorg.conf settings.

Must have been an update that has caused this to break. I guess if I can’t get it to work it will help my linux knowledge but man is it frustrating. The main problem is iptables is a pain to administer for me… I much rather use a GUI for that.

6

Ok well I was able to get this working. Here is what I did.

while rooted:

I unclude this first part incase it did something to a backend file that I am not aware of but it did not work 100% for me. The second part did. Jump to that if you like.

  1. uninstall my current vnc-server (rpm -e vnc-server-4.0-8.i386.rpm)
  2. download and install this (vnc-server-4.1.1-2.0.3.i386.rpm from rpm.pbone.net)
  3. rebooted and set new password ala vncpasswd

This worked but it kept coughing up a fur ball (sesson terminated). I had a similar issue with an old version of vnc before but… whatever… not important.

Second part:

  1. uninstalled my new furry vnc-server-4.1.1-2.0.3.i386.rpm
  2. deleted my hidden .vnc folders for my user and root (/home/user/.vnc and /root/.vnc)
  3. downloaded and installed vnc-server-4.0-8.i386.rpm
  4. rebooted and set new password (yes reboot… I am still new at this :slight_smile: )

That’s it. Works even better then I had before. I now see a login screen when I connect to vnc which was never there before. It would always leave my user account logged in and I would have to lock the screen. So now I can log in as root if needed to the GUI.
I have only a .vnc folder in my root account and it only has the passwd file in it.

I am using this http://www.realvnc.com/products/free/4.1/x0.html xorg.conf method to connect which was not the case before… I was using the xserver setups in the .vnc folder as most webpages show how to do.

Finally, I added only the Load “vnc” to the module section and the Option “PasswordFile” “/root/.vnc/passwd” to the Screen section (I don’t know what this means in a security context and will check it out later as I am not too concerned at the moment since I am using SSH to tunnel in).

Hope this helps someone out there get their VNC back to normal.

7

Mojo,

As a simple workaround, how about just ssh in to the remote box, su to root and launch any app you want that requires root previledges as root from the command line (so you’re not asked for the root password by the X app).

For example, to run up2date:

ssh 192.168.0.1
password xxxx
su
password xxxx
up2date

And now you have up2date running on the remote box, but displayed on your current box :slight_smile:

Ned