I am using Synergy Client in CentOs 7.
This is the problem that CentOs doesn't show mouse pointer when there is no mouse connected to the system.
Every time that I turn on my CentOs machine , I should connect the mouse to the machine otherwise CentOs doesn't show the mouse pointed for Synergy.
Everything is working with Synergy Client (click -right click , ...) but there is no mouse pointed!!!
How can I fix this problem? Synergy Client is running on CentOs 7 (64 bit)
Found the answer in this post: http://synergy-foss.org/osqa/questions/3148/ubuntu-1310-no-cursor-visable-with-synergyc
Fix:
Move the mouse to the system where the mouse pointer is not visible, open the terminal and paste the following command:
gsettings set org.gnome.settings-daemon.plugins.cursor active false
This should resolve the problem for the current session and future sessions.
I used the solution Michael Richmond presented.
Logging in, and with a terminal within that account executing
gsettings set org.gnome.settings-daemon.plugins.cursor active false
however I also wanted the mouse visible at the login window as well. I used this link to figure it out
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/desktop_migration_and_administration_guide/customizing-login-screen
it says to create or edit the gdm profile at /etc/dconf/profile/gdm with the following contents
user-db:user
system-db:gdm
file-db:/usr/share/gdm/greeter-dconf-defaults
I then created a file /etc/dconf/db/gdm.d/01-Cursor
and put the following contents
[org/gnome/settings-daemon/plugins/cursor]
active=false
This essentially sets the same value in config file, but for the gdm login window.
After adding those files, I then executed dconf update to update the current running instance with the config setting.
At this point, I now have the synergy cursor available before and after login.
For some reason, all my LFS VM's defaulted to "USB Tablet" but CentOS VM's defaulted to "PS/2 Mouse". So my guess is the built-in templates (or whatever they are called) have that wrong. When creating a new VM, if I type in "LFS", I get Type "Linux" and Version "Linux 2.6/3.x (64-bit)" but if I type in "CentOS", I get Type "Linux" and Version "Red Hat (64 bit)". So, in my opinion, the "Red Hat (64 bit)" template should be changed to set Pointing Device to "USB Tablet".
some was unexpected at this time.
Related
I have followed all the instructions on Minikube carefully (I thought). I installed it on Windows 10 (ver 1.7.2), started a Powershell console under Administrator, set the 3 PROXY variables (I am behind a proxy), enabled the Microsoft-Hyper-V, and ran the cmd: minikube start --vm-driver=hyperv
It downloads the VM boot images, then I get the following line output:
* Creating hyperv VM (CPUs=2,....etc) ....
AND THAT'S IT!
Nothing else!! If I start the Hyper-V Manager I don't see any VMs there. The .minikube directory is populated with several dirs and files. But for the rest I am completely blind!
I have left it to run for half an hour or more. Still nothing.
I have tried terminating the process, stopping, deleting (in this case I get the output 'Deleting Kubenetes cluster' but whether this means anything I don't know) and flushing the .minikube directory ... then running it all again off a clean base. NADA! NOTHING! same thing!
Could someone please tell me what I am doing wrong? I thought this was supposed to work out of the box! Why don't I see my VM in Microsoft-Hyper-V manager for a start? I don't even get as far as seeing starting Kubenets cluster, yet I get no errors!
Try to follow this guide. It has a step by step instructions bout how to setup Docker and Minikube on windows 10 with Chocolatey.
Also here you will find an analogical issue with possible solutions.
Before you start again, remember to delete the .minikube folder after executing minikube delete to avoid any leftover configuration to persist.
Please let me know if that helped.
For the record, I flushed everything .. and tried several things from the above page, the K8 site and elsewhere. In a nutshell Docker for Desktop works and Minikube doesn't (not 100% anyway)! I was just curious back in February as to whether I could set up a local Kubenetes environment quickly and easily and I am afraid for me the answer is No: Minikube is not quick and easy. Also, you can enable Kubenetes on Docker Desktop now of course and it works out of the box as software should, so no more need for Minikube.
The following are the instructions for setting up and installing Minikube and its dependencies for use on Windows Pro or Enterprise with Docker Desktop and HyperV.
Install Kubectl
Create a new directory that you will move your kubectl binaries into. A good place would be C:\bin
Download the latest kubectl executable from the link on the Kubernetes doc page:
https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
Move this downloaded .exe file into the bin directory you created.
Use Windows search to type “env” then select “Edit the system environment variables”
In the System Properties dialog box, click “Environment Variables”.
In System Variables click on the “Path” Variable and then click “Edit”
Click “New” and then type C:\bin
Drag the newly created path so that it is higher in order than Docker's binaries. This is very important and will ensure that you will not have an out of date kubectl client.
Click "OK"
Restart your terminal and test by typing kubectl into it. You should get the basic commands and help menu printed back to your screen. If this doesn't work try restarting your machine.
Run kubectl version to verify that you are using the newest version and not the out of date v1.10 version.
Install Minikube
Download the Windows installer here:
https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe
Double click the .exe file that was downloaded and run the installer. All default selections are appropriate.
Open up your terminal and test the installation by typing minikube. You should get the basic commands and help menu printed back to your screen. If this doesn't work try restarting your machine.
Configure HyperV
In Windows Search type "HyperV" and select "HyperV Manager"
In the right sidebar click "Virtual Switch Manager"
Leave selected "New Virtual network Switch" and "External" and click "Create Virtual Switch"
Name the switch "Minikube Switch" (or whatever you would like to name it)
Click Apply and acknowledge the "Pending changes" dialog box by clicking "yes"
Once the switch has been created, click "Ok"
Starting Up Minikube
Since by default Minikube expects VirtualBox to be used, you need to tell it to use the hyperv driver instead, as well as the Virtual Switch created earlier.
Start up a terminal as an Administrator. Then, in your terminal run:
minikube start --vm-driver hyperv --hyperv-virtual-switch "Minikube Switch"
NOTE: all minikube commands must be run in the context of an elevated Administrator.
This question is a port of this one applied to a similar but distinct issue:
Problem:
The Cinnamon panel (my system: Linux Mint 19.1) became "invisible", that is, it still responded to mouse-clicks but became completely transparent.
Cause:
Having plugged in an external HDMI monitor and having switched to tty1 with CTRL+ALT+F1 and back to tty7 with CTRL+ALT+F7 (where Cinnamon runs) in order to have the external monitor recognized by the system.
This answer is a port of this one applied to a similar but distinct issue:
To restart the Cinnamon Panel
type ALT+F2 to open the command box
and then type r and enter.
There are many questions similar to mine (e.g. xdg-open not open default browser or xdgutils - xdg-settings not setting default-web-browser in gentoo, but none of the answers helped in my case. Therefor I ask for my particular situation:
On Centos 7 I have no free desktop manager running, I just run some X11 applications (like VS Code) from the command line where the DISPLAY variable is set to the X server on the (Windows) machine I connect from.
On the Centos machine I have two browsers installed, firefox and google-chrome. I can start both browsers just by typing firefox resp. google-chrome in the bash terminal.
xdg-open is available and it opens links in google-chrome - as does VS Code. However I want to change this to firefox.
I tried:
Ticking "Default browser" in Firefox's GUI preferences.
Using xdg-settings, but
xdg-settings get default-web-browser
returns "xdg-settings: unknown desktop environment"
Setting $BROWSER. In bash I issued
export BROWSER=firefox
but still google-chrome is started by xdg-open
How can I set in this environment the default browser to firefox?
Note: Strangely on another machine with Centos 6 (and "no desktop environment" either) the export BROWSER method works!
The desired behavior can be set in the mimeapps.list configuration files described in the XDG MIME Applications specification.
TLDR:
In order to configure firefox as the default browser for your user create ~/.config/mimeapps.list containing the following lines:
[Default Applications]
x-scheme-handler/http=firefox.desktop
x-scheme-handler/https=firefox.desktop
x-scheme-handler/ftp=firefox.desktop
x-scheme-handler/chrome=firefox.desktop
text/html=firefox.desktop
application/x-extension-htm=firefox.desktop
application/x-extension-html=firefox.desktop
application/x-extension-shtml=firefox.desktop
application/xhtml+xml=firefox.desktop
application/x-extension-xhtml=firefox.desktop
application/x-extension-xht=firefox.desktop
Details:
xdg-utils like xdg-open(1) and xdg-mime(1) look for this file in the locations listed under the File name and location section of this specification:
$XDG_CONFIG_HOME/$desktop-mimeapps.list user overrides, desktop-specific (for advanced users)
$XDG_CONFIG_HOME/mimeapps.list user overrides (recommended location for user configuration GUIs)
$XDG_CONFIG_DIRS/$desktop-mimeapps.list sysadmin and ISV overrides, desktop-specific
$XDG_CONFIG_DIRS/mimeapps.list sysadmin and ISV overrides
$XDG_DATA_HOME/applications/$desktop-mimeapps.list for completeness, deprecated, desktop-specific
$XDG_DATA_HOME/applications/mimeapps.list for compatibility, deprecated
$XDG_DATA_DIRS/applications/$desktop-mimeapps.list distribution-provided defaults, desktop-specific
$XDG_DATA_DIRS/applications/mimeapps.list distribution-provided defaults
The locations for the $XDG variables are governed by the XDG Base Directory specification. If you want to figure out where xdg-utils are looking for configuration in your particular case, run them with the XDG_UTILS_DEBUG_LEVEL environment variable like so:
$ XDG_UTILS_DEBUG_LEVEL=10 xdg-open 'https://www.example.com'
...
Checking /home/USERNAME/.config/mimeapps.list
...
I got this when I try to open nco_event in RHEL 6.3
[netcool#noi bin64]$ nco_event&
[1] 19962
[netcool#noi bin64]$ No protocol specified
Fatal Error: /opt/IBM/tivoli/netcool/omnibus/platform/linux2x86/bin64/nco_event: can't open display
Any idea to solved that?
When executing the command xhost, you are probably receiving
No protocol specified
xhost: unable to open display ":0"
Issue is your user is not allowed to access the X server.
You can use xhost to limit access for X server for security reasons.
Switch back to default user and execute xhost again. You should see something like
SI:localuser:nuwan
The solution is to add the oracle to access control list
xhost +SI:localuser:youruser
Now switch back to original user "youruser". It should be working now.
Do you use Putty & Xming to connect to this machine?
If not, check the Xorg server on your client.
You can also check the $DISPLAY variable
Follow this while while launching Xming :
Launch Xming and select the style you wish to display the X server output.
Hint:
Select Multiple Windows and your X applications will look like they were launched from Windows.
Leave Display number set to 0 Click Next.
Select Start No Client and click Next.
On Server Options, check the box title Disable Server Control. Leaving the box unchecked can give you an "unspecified protocol error" later down the road.
Click Next and save your configuration.
This will create a quick way to launch Xming later.
This will solve "No protocol specified" error .
Thanks.
I'm setting up some new VNC servers. I already have this setup working with CentOS 6.3, although I'm not certain that this difference is the real problem.
One of the window managers I'm making available is fluxbox, but when I start it, I always get the following: Error: Couldn't connect to XServer. Here's my setup:
fluxbox: fluxbox-1.1.1-5.el6.x86_64
vnc : tigervnc-server-1.1.0-5.el6_4.1.x86_64
OS : CentOS 6.4
Note that I can start other window managers: Gnome, KDE, openbox, xfce4, etc.
I gutted my ~/.vnc/xstartup script so it only loads an xterm. Then, I tried running startfluxbox &, but still got the error. Obviously, VNC is working, since my xterm opened up OK. I can start firefox, another xterm or other app requiring X, and even fluxbox comes up, but it is worthless in its current state, since it is not connected to the X session.
What is fluxbox looking for? Are there some log files I can look at to give me some clues?
Thanks,
David
CentOS/RHEL 6.4 and up have upgraded libX11 and Xorg.
The $DISPLAY var handling has changed in libX11.
This one in particular is described in this git commit:
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=f92e754297ec5fdb81068b56a4435026666224fa
we run our fluxbox with this script in our vnc configs now:
/usr/bin/fluxbox -display "$DISPLAY.0"
OK, I think I've figured out the problem, so I'm answering my own question.
In VNC, I usually specify a display number. (Note, however, that the problem occurs even if vncserver uses the first available display number.) So, I start the vncserver as:
vncserver :17
This should create an X session where my $DISPLAY is set to :17.0, but in CentOS 6.4, the $DISPLAY is set to :17 instead. Apparently, unlike other window managers, fluxbox is unable to handle this inaccuracy. The problem, then, was that fluxbox was trying to connect to :17 and was unable to do so.
My solution, as suggested by someone answering a different problem, was to set $DISPLAY as part of the invocation of fluxbox. So, in my ~/.vnc/xstartup file, I have:
DISPLAY=$DISPLAY.0 startfluxbox &
Note that this may not work for other releases of CentOS, so you might wish to test the release of the box you are using before adding the DISPLAY=... setting to the command.