users October 2006

users@lists.fedoraproject.org

664 participants
1011 discussions

Re: Re: Re: VNC problem - now more understood - but a solution?
by Mike C 03 Oct '06

03 Oct '06

Mike Cohler wrote: >Hopefully more information can be obtained and a solution found. I have been playing with this during the evening - I found that I can work around this by vnc'ing in to the remote machine - and then going into the kde control centre - Under peripherals by going to the display section and then switching power management off, doing "Apply" and then selecting power management on again then I can work with the vnc session until I have finished and then disconnect. The screensaver will eventually come on and the remote system will return to its powersave mode after the set time. However it would be nicer to see a cleaner solution. I wonder if this will still be the same under FC6 ? -- mike cohler

1 0

Selinux - iptables and other errors
by Claude Jones 03 Oct '06

03 Oct '06

Here's some Selinux messages from my system log just after a system reboot about half an hour ago: Oct 2 22:24:13 tehogee kernel: audit(1159842231.053:4): avc: denied { create } for pid=2038 comm="iptables" scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:dhcpc_t:s0 tclass=rawip_socket Oct 2 22:24:14 tehogee kernel: audit(1159842231.053:5): avc: denied { read } for pid=2038 comm="iptables" name="modprobe" dev=proc ino=-268435399 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:sysctl_modprobe_t:s0 tclass=file Oct 2 22:24:14 tehogee kernel: audit(1159842231.053:6): avc: denied { create } for pid=2039 comm="iptables" scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:dhcpc_t:s0 tclass=rawip_socket Oct 2 22:24:14 tehogee kernel: audit(1159842231.053:7): avc: denied { read } for pid=2039 comm="iptables" name="modprobe" dev=proc ino=-268435399 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:sysctl_modprobe_t:s0 tclass=file Oct 2 22:24:14 tehogee kernel: audit(1159842231.057:8): avc: denied { create } for pid=2041 comm="iptables" scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:dhcpc_t:s0 tclass=rawip_socket Oct 2 22:24:15 tehogee kernel: audit(1159842231.057:9): avc: denied { read } for pid=2041 comm="iptables" name="modprobe" dev=proc ino=-268435399 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:sysctl_modprobe_t:s0 tclass=file In a different thread today, I'm reporting some smartd errors - I wonder if there's any connection. I'm wondering what those "dev=proc ino=########## etc..." mean. Can anyone make any sense of this? Also, during startup, I get: eth0 is not ready touch: cannot touch "/var/lock/firestarter" : Permission denied fatal error: your kernel does not support iptables Firewall ### not started rm: cannot remove "/var/lock/firestarter" : Permission denied Moments later, Firestarter starts up seemingly normally, and when I boot up to the desktop, eth0 is working just fine Theories anyone? -- Claude Jones Brunswick, MD, USA

3 4

Re: VNC problem - now more understood - but a solution?
by David G. Miller (aka DaveAtFraud) 03 Oct '06

03 Oct '06

"Mike Cohler" <mike.cohler(a)gmail.com> wrote: >This behaviour does not kick in when the screensaver starts up but >only when the screensaver goes off the screen when the power save >kicks in later -(in my systems). > >I would be interested to know if you still get normal behaviour if you >wait until the screen is in powersave (not just with the screensaver >running visibly) with the operating system different from Fedora and >with gnome - this would certainly point at kde/vnc interaction of some >kind. > >Hopefully more information can be obtained and a solution found. > I just fired up vncserver on my test box (currently running FC5) and then started a vnc session to it from my FC4 box. Both systems have a default gnome desktop with all updates applied. The monitor on the FC5 box is still in power save mode but the vnc session is behaving normally. My expectation is that, if I wait a little while, the graphical screensaver will "blank" (power on but hidden by the screensaver) the remote desktop within the vnc window. Funny thing is, when I was using vnc for remote access to my home network I was looking for a way to turn even this off. I didn't want the screensaver for the vnc desktop chewing up bandwidth by drawing pretty pictures. The vnc installation is completely "default." My user vnc configuration is pretty trivial: # cat ~dave/.vnc/xstartup #!/bin/sh # Uncomment the following two lines for normal desktop: unset SESSION_MANAGER exec /etc/X11/xinit/xinitrc [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources gnome-session Cheers, Dave -- Politics, n. Strife of interests masquerading as a contest of principles. -- Ambrose Bierce

1 0

FC5 -- "yum -y upgrade" forever
by robert alan bowman 03 Oct '06

03 Oct '06

3 2

Re: VNC problem - now more understood - but a solution?
by David G. Miller (aka DaveAtFraud) 03 Oct '06

03 Oct '06

"Mike Cohler" <mike.cohler(a)gmail.com> wrote: >So the questions are: > >1) Can I do something to wake up the power on the remote monitor once >I have ssh'ed in? >2) If not then can I still run VNC to look at the remote screen but >not have the constant irritation of the local screen display >attempting to put the screensaver back? > >By the way both machines are running fully up to date FC5 with KDE desktop. > >I hope someone knows the answer(s)? > Not to be funny and definitely not to start any kind of a gnome vs. KDE flame war but I don't see VNC behaving like this with gnome. This includes even having the "screensaver" kick-in after the set inactivity period on the VNC desktop. I think both systems were running CentOS 4 (gnome, x.org) at the time. Just pointing out that this behavior *may* be peculiar to VNC interacting with KDE. Cheers, Dave -- Politics, n. Strife of interests masquerading as a contest of principles. -- Ambrose Bierce

2 1

Re: Re: VNC problem - now more understood - but a solution?
by Mike C 03 Oct '06

03 Oct '06

"David G. Miller" wrote: >Not to be funny and definitely not to start any kind of a gnome vs. KDE >flame war but I don't see VNC behaving like this with gnome. This >includes even having the "screensaver" kick-in after the set inactivity >period on the VNC desktop. I think both systems were running CentOS 4 >(gnome, x.org) at the time. Just pointing out that this behavior *may* >be peculiar to VNC interacting with KDE. This behaviour does not kick in when the screensaver starts up but only when the screensaver goes off the screen when the power save kicks in later -(in my systems). I would be interested to know if you still get normal behaviour if you wait until the screen is in powersave (not just with the screensaver running visibly) with the operating system different from Fedora and with gnome - this would certainly point at kde/vnc interaction of some kind. Hopefully more information can be obtained and a solution found. -- mike cohler

1 0

Re: Re: VNC problem - now more understood - but a solution?
by Mike C 03 Oct '06

03 Oct '06

Raman Gupta wrote: >have a work-around that works for me. Before starting up x11vnc, I run > >DISPLAY=:0 xset -dpms > >After my VNC session, I restore dpms > >DISPLAY=:0 xset +dpms > >Unfortunately, this wakes up the remote monitor, and disables sleep >mode, but it works. YMMV. Thanks - though I have seen postings elsewhere saying that it is possible to use vbetool dpms on or vbetool dpms off See "man vbetool" Apparently xset sometimes does not use the dpms system even though X is supposed to - maybe this is why the unexpected behaviour occurs after you have used those commands? I understand that vbetool runs bios commands so might not have the unexpected behaviour - it will be interesting to see any further replies on this - and maybe other suggestions for workarounds? -- mike cohler

2 1

NVIDIA GeForce FX5200 Linux Driver
by Erich Carlson 03 Oct '06

03 Oct '06

I put a new NVIDIA GeForce FX5200 128meg AGP 8X video card in one of my systems running Fedora Core 5. I use the NVIDIA drivers that come with Fedora. Occasionally the screen will freeze, not very often, maybe once a week, but am thinking it's the driver. Does anyone have any knowledge of this condition with NVIDIA? Is there a better NVIDIA repository that is compatible with Fedora Core 5? I've done extensive debugging on all the other hardware components and can't find the problem. erich http://ComputerPerceptions.com

7 15

VNC problem - now more understood - but a solution?
by Mike C 03 Oct '06

03 Oct '06

Some time ago I noticed (in fact pre-FC4 !) that when I used VNC to connect via an ssh tunnel into a remote computer that sometimes the screen on my local machine was constantly repainting, and the screensaver from the remote machine was loading up almost before I could enter any mouse movements. This has continued to happen but not every time, and since this was an intermittent behaviour, I was puzzled by this mis-behaviour until now. A short time ago I was testing vnc from this computer to one on the other side of this same room, and noticed that this constant screen re-painting was happening.... but then I also noticed that the other computer was in fact in monitor power saving mode - and its screen was blank. So I walked across and waggled the mouse on the remote computer so that its screen came alive - and lo and behold vnc started working normally again!! The screen was not repainting and just as if the remote machine was on my local desktop - exactly as vnc should behave. So now I know ! VNC works fine when both computers have their monitor in normal mode.... but once the remote monitor goes into powersave then VNC misbehaves! So the questions are: 1) Can I do something to wake up the power on the remote monitor once I have ssh'ed in? 2) If not then can I still run VNC to look at the remote screen but not have the constant irritation of the local screen display attempting to put the screensaver back? By the way both machines are running fully up to date FC5 with KDE desktop. I hope someone knows the answer(s)? Thanks -- mike cohler

2 1

postix, cyrus imap and online backup
by Boris Glawe 03 Oct '06

03 Oct '06

Hello, we're using postfix and cyrus imap on the same machine for internal mail. Mail delivered by smtp to the machine is locally forwarded to the imap server. Currently all mail is handled by a domain provider. We fetch our (external) mails via POP3 from the provider's server. We'd like to extend the usage of this mailsystem in a way, that it will 1.) send all external mail, 2.) receive all external mail *and* 3.) do an online backup of all mails that have been transferred. 1.) is easy to solve. 2.) What's the best solution here? - we could forward mails from our domain provider to our postfix machine. What happens if that machine isn't online for a few days? Is there a solution that the mail is regularly being fetched (every 5 minutes) from the provider's server? - what else do you suggest? 3.) The backup can of course be done by syncing the imapd's directory regularly to another machine. Problem is that the backuped data structure is an cyrus specific data stucture that can hardly be used to restore lost mails. We'd like to have a solution that makes it easy to restore lost mails and - if possible - is an online backup solution. That means each mail the is delivered or received will automatically be backuped while it's being handled. Thanks for any suggestions. If you have suggestions to use a different software environment for mail delivery, please tell me. Thanks and greets Boris

2 2

Jump to page: