Lock and unlock the KDE desktop with a bluetooth device

Standard

Today my mouse right button stopped working, so I searched on my desk drawer and I have found a bluetooh mouse… I don’t usually like bluetooth devices, but if there is no more option… so, after install some basic bluetooth packages like bluez and the bluez-utils and start some daemons like bluetooth like this

sudo pacman -S bluez bluez-utils
sudo systemctl enable bluetooth
sudo systemctl start bluetooth

I finally could open System Settings and pair my new old mouse and continue working🙂

But, some years ago, I played with a piece of software, called BlueProximity that can lock and unlock your computer based on a bluetooth device proximity you previously paired with the application.

I have taken a look into AUR and someone has prepared a package which works flawlessly. So first we can install it with

yaourt -S blueproximity –noconfirm

And then whe can start it right from the menu

Once started, first we must pair a bluetooth device. It’s supposed to work with any bluetooth device, when this application was developed, back in the ’00s, only PDA and phones were the only bluetooth powered devices, nowadays perhaps we can prefer to pair with a smartwatch or another IoT bluetooth enabled device😉

The use is pretty straight forward

  • Make visible your desired device on its settings
  • Click on “Scan for devices”: your device should be shown on the list.
  • Select your device and click on “Use selected device”: its MAC now its copied to a text field below the former buttons.
  • Click on “Scan channels on device” to let the application scan for usable communication channels.

Now the device is paired with the BlueProximity. BlueProximity is a GNOME application, and if like me are using KDE, the lock and unlock commands will not work for you, so lets configure the right commands.

On “Locking” tab, we put this

The fields are

Locking:

dbus-send –type=method_call –dest=org.freedesktop.ScreenSaver /ScreenSaver org.freedesktop.ScreenSaver.Lock; xset dpms force off

Unlocking:

qdbus | perl -ne ‘qx/kquitapp $1/ if /(kscreenlocker_greet-\d+)/’; xset dpms force on

Proximity:
If you want to unlock the computer as you come near:

qdbus | perl -ne ‘qx/kquitapp $1/ if /(kscreenlocker_greet-\d+)/’; xset dpms force on

If you want only to wake up the screen

qdbus org.freedesktop.ScreenSaver /ScreenSaver SimulateUserActivity

If your version of KDE is below 4.13, perhaps you must use those other commands.

Locking:

qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock

Unlocking:

killall -9 kscreenlocker

‘authentication key already exists’ error when adding a proxmox node to a cluster

Standard

Today I shall not write about Arch linux but about Proxmox VE, since I faced a problem after rebooting one of the cluster’s nodes and see it had lost all network configuration due the horrible and broken Debian’s apt autoremove feature… one is used to pacman and apt needs a major rewrite to avoid those dependency hell which it cannot leave.

Returning to the topic, if you need to add or readd a node to a existing cluster you should do it with this command from the node you want to add:

# pvecm add clustered_node_IP_or_name

Then, the usual behavior if you add the node for the first time, is to copy the keys from the cluster node to the new node, and modify cluster.conf to add an entry for the new node, and the start all related daemons, like cman or rgmanager.

But if you are adding again this node, you probably end with this error:

# pvecm add clustered_node_IP_or_name
authentication key already exists

I’d searched on Internet for this message and many people ended reinstalling the conflicting node, not a good solution at all, so I tried to get a better one.

Obviously, somwhere on the current cluster configuration is the key for that node, and after some time searching for it everywhere on the system, I decided to do some trick, taking the advantage that the key is already on the configuration.

So, the first thing we need to do is to modify cluster.conf manually and add this node, in proxmox, we need to copy /etc/pve/cluster.conf into a file called /etc/pve/cluster.conf.new and edit that copied file

# cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new
# nano /etc/pve/cluster.conf.new

<?xml version=”1.0″?>
<cluster name=”pvecluster” config_version=”5“>

<cman keyfile=”/var/lib/pve-cluster/corosync.authkey”>
</cman>

<clusternodes>
<clusternode name=”pve01″ votes=”1″ nodeid=”1″/>
<clusternode name=”pve02″ votes=”1″ nodeid=”2″/>
<clusternode name=”quormox” votes=”1″ nodeid=”3″/>  
</clusternodes>

</cluster>

We need to increase the config_version value in one, and then we will add the line <clusternode name=”quormox” votes=”1″ nodeid=”3″/>  giving the desired name and ID.

Then, on the proxmox GUI, under the HA tab, we’ll press “Activate” as shown down here

And we will see the changes with the new node.

Now, we need to copy all needed files on the node we want to add. So first we will delete (do a backup first just in case) the folders on that node, but for that, we need to do it in this order, following the red lines commands. In my example, the node I want to add is called quormox and the node with the working configuration is pve01. I also removed all references to quormox on .ssh/known_hosts in all nodes on the cluster.

root@quormox:~# /etc/init.d/pve-cluster stop
Stopping pve cluster filesystem: pve-cluster.
root@quormox:~# umount /etc/pve
umount: /etc/pve: not mounted
root@quormox:~# /etc/init.d/cman stop
Stopping cluster:
Stopping dlm_controld… [  OK  ]
Stopping fenced… [  OK  ]
Stopping cman… [  OK  ]
Unloading kernel modules… [  OK  ]
Unmounting configfs… [  OK  ]
root@quormox:~# rm /etc/cluster/cluster.conf
root@quormox:~# rm -rf /var/lib/pve-cluster/*
root@quormox:~# scp pve01:/etc/cluster/cluster.conf /etc/cluster/
The authenticity of host ‘pve01 (192.168.96.11)’ can’t be established.
ECDSA key fingerprint is 89:02:2e:79:f3:2a:54:30:2d:78:a8:9c:2c:55:03:e5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘pve01,192.168.96.11’ (ECDSA) to the list of known hosts.
root@pve01’s password:
cluster.conf                                                100%  340     0.3KB/s   00:00
root@quormox:~# mkdir -p /var/lib/pve-cluster
root@quormox:~# scp pve01:/var/lib/pve-cluster/* /var/lib/pve-cluster/
root@pve01’s password:
config.db                                                   100%   64KB  64.0KB/s   00:00
config.db-shm                                               100%   32KB  32.0KB/s   00:00
config.db-wal                                               100% 1028KB   1.0MB/s   00:00
corosync.authkey                                            100%  128     0.1KB/s   00:00
root@quormox:~# /etc/init.d/pve-cluster start
Starting pve cluster filesystem : pve-cluster

After that, a reboot is needed to start all the daemons in the right order. Once rebooted the node is correclty added to the cluster!😀

 

Steam error on launch: OpenGL GLX context is not using direct rendering

Standard

If you are having this error when launching steam, and follow the steps on the link provided by the dialog, most probably you have a 64bit system and some problem with your 32bit drivers.

In my case, I had this problem with my Intel 4000HD card. First of all, you need to know what’s happening, for know that, you must run glxinfo:

glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.2.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.2.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0
OpenGL ES profile extensions:

It seems so far so good… but wait, I’ve just run 64bit version of glxinfo, so the information could be wrong. First thing I did was install glxinfo32, located on lib32-mesa-demos

$ yaourt -S lib32-mesa-demos

Once installed, I executed the right command

glxinfo32 | grep OpenGL
libGL error: dlopen /usr/lib32/xorg/modules/dri/i965_dri.so failed (/usr/lib32/xorg/modules/dri/i965_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: i965_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: i965
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.4, 256 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.2.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.2.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0
OpenGL ES profile extensions:

Well, VMWare? No idea why it’s saying this! But anyway, I’ve just find the problem, I need to install the needed intel 32bit drivers, lib32-intel-dri

$ yaourt -S lib32-intel-dri

Let’s try once again to see the results

glxinfo32 | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile x86/MMX/SSE2
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.2.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.2.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0
OpenGL ES profile extensions:

Yay! Let’s play something!!🙂

 

qtDesigner does not start

Standard

I’m starting to playing with desktop interfaces, I use KDE and I like a lot Qt controls. Furthermore, are multiplatform, so combined with python I can do beautilful programs in a easy way.

So I’d installed Qt4 Designer on my work’s laptop. But when I clicked on the Qt4 Designet icon, nothing happened.

I opened a terminal and run designer-qt in order to see what happened. This is what I saw:

$ designer-qt4
designer-qt4: symbol lookup error: /usr/lib/qt4/plugins/designer/libqscintillaplugin.so: undefined symbol: _ZN13QsciScintillaC1EP7QWidget

Pretty weird, it seems something wrong with scintilla. So after reinstalling qscintilla and see that not solved my issue, I tried to recompile from sources instead of reinstalled

$ yaourt -S qscintilla –build

(please note that there are two hyphen (-) before the buid parameter)

Once finished, designer-qt started smoothly🙂

sudo command ask for a password even with the NOPASSWD condition

Standard

After a hardware problems with my hard disk, I decided to get rid of it and install arch o a new hard disk.

After setting up the graphical environment, one of the configuration I like for my personal computer, discouraged for servers, is to configure sudo for not to ask for my password in each bash session. As said, it’s not recommended to do this, but I’m too lazy to put my password again and again.

So, as you may already know, in order to say to sudo command do not ask for the user password, it execute as root the visudo command and let the user or the group to execute all commands without password.

If you want to your user (malevolent in my case) to execute all sudo command withou password, you must type this when visudo opens.

malevolent ALL=(ALL) NOPASSWD: ALL

Perhaps your user belongs to the wheel group, so you can give to the entire group those rights, but this is even less recommended.

%wheel ALL=(ALL) NOPASSWD: ALL

In both cases, today I faced a new problem. The system continued asking me for my password. Ignoring those entries.

Looking the visudo documentation, it says:

When multiple entries match for a user, they are applied in order.  Where there are multiple matches, the last match is used (which is not  necessarily the most specific match).

So I look my entries with the following command

$ sudo -l
User malevolent may run the following commands on malevolo:
(ALL) NOPASSWD: ALL
(ALL) ALL

An it seems that the nopasswd entry is ignored by the all entry. So including my user just below the root user inside sudoers, did not make the job. After placing the line

malevolent ALL=(ALL) NOPASSWD: ALL

At the very end of the file, executing the last command now it returns:

$ sudo -l
User malevolent may run the following commands on malevolo:
(ALL) ALL
(ALL) NOPASSWD: ALL

And now my system does not ask for my password.