Google’s verification annoyance

Google’s verification annoyance is nightmarish on Evolution 3.26.6 (3.26.6-1.fc27) that I still want to use, because it works like a charm with an Exchange server I was recently pushed into, with GPG, and with almost anything else you throw at it. Evolution is great, and has been for a long time now.

Yet a recent “feature” in GMail has been dramatic at first, preventing me to add my GMail accounts at all, until I had figured out I should turn off Google’s OAuth2 login in Account Settings, and set it to password and login for imaps and ssmtp respectively.

This leaves me with usable Evolution for GMail accounts, albeit I have to turn the annoying pop-up “feature” off every time I start the client.

  
     

The lost case of Viber support

Time for commercials: two years ago, lured into by a very influential person in my life 🙂 I installed Viber app on my phone; soon after the installation, I started buying those stickers for the app, only to end up with more than 100 EUR worth of them nowadays. On my Android phone those stickers would work more-or-less OK all of the time. Also, synchronising those stickers on an Android tablet worked just fine. Synchronising and using those stickers worked just fine for any linux (Ubuntu, Debian, Fedora) I had been using meanwhile, as well as for a Mac OS Sierra on a MacBook Pro 2017. Until one day in December that I could get no synchronisation at the laptops any more. At first, I thought that is a general problem, and I waited a week or two to see if that will be resolved with one of the updates, but then it become clear it will not be sorted without an action from my side – so I opened a ticket.

Continue reading

JMX at JBoss 6/7

Lost quite a few hours on allowing a JMX console for a JBoss 6.4.13 (tested on series 7, too) until I figured out a winning combination of JAVA_OPTS and other settings that allow JMX to be remotely accessible. Here’s a bin/standalone.conf recipe for insecure access, once you have this sorted, move on to secure JMX access:

  • somewhere at the top of the file add this:

    JBOSS_MODULES_SYSTEM_PKGS=”org.jboss.logmanager”

  • at the end of the file, set the rest

    JAVA_OPTS=”$JAVA_OPTS -Dcom.sun.management.jmxremote”
    JAVA_OPTS=”$JAVA_OPTS -Dcom.sun.management.jmxremote.port=9934″ <!– pick a port, you can use the same for jmxremote.rmi.port –>
    JAVA_OPTS=”$JAVA_OPTS -Dcom.sun.management.jmxremote.rmi.port=9934″ JAVA_OPTS=”$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false” JAVA_OPTS=”$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false” JAVA_OPTS=”$JAVA_OPTS -Dcom.sun.management.jmxremote.local.only=false” JAVA_OPTS=”$JAVA_OPTS -Djava.rmi.server.hostname=123.123.123.123″ <!– put your IP here, not your hostname –>

Rocket.Chat at Simulakrum

Users in the appropriate group in Simulakrum directory can use Rocket.Chat now. Rocket.Chat works from within a browser, and allows for very fast and quality multi-user video-conferences, desktop display, and many other useful functions. It is using a jitsi-based server in the background.

Rocket.Chat is the second multi-user video-conferencing tool available for Simulakrum – HipChat, the Atlassian’s proprietary commercial solution that integrates well Jira and Confluence, is also currently available at Simulakrum’s. Ask for the access to those tools if you don’t have the access already.

docker-registry at simulakrum

If docker on a systemd-infected system complains that it cannot log into docker-registry at simulakrum.org, add the following into docker.service file:

:~# grep simulakrum /etc/systemd/system/multi-user.target.wants/docker.service
ExecStart=/usr/bin/dockerd –insecure-registry docker-registry.simulakrum.org -H fd://

and then reload the systemd and restart docker daemon:

systemctl daemon-reload
systemctl restart docker.service

If the same things happens in a FreeBSD, add the same switch into the following file:

root@beastie:~ # grep simulakrum /usr/local/etc/rc.d/docker
daemon -p /var/run/docker.pid ${command} -d -e jail –insecure-registry docker-registry.simulakrum.org -s zfs -g ${docker_dir} -D >/var/log/docker.log 2>/var/log/docker.log

and then restart the docker daemon:

root@beastie:~ # /usr/local/etc/rc.d/docker restart
Stopping docker…
Starting docker…
root@beastie:~ #

More changes at simulakrum.org

Simulakrum moved from OpenBSD’s OpenLDAP 2.3 to a fancy CentOS’ 389 DirectoryServer. Let me know if your account is not working.

Password manager is upgraded to a recent snapshot of 1.8, and there is no more a possibility of self-served adding to the LDAP.

Owncloud moved from ownCloud 8 on Fedora 22 to Owncloud 9 on CentOS 7. Let me know if there are things missing.

Enjoy

Change check_docker Nagios’ plugin over NRPE to list all of the Docker containers

Due to the way that NRPE/Nagios reads output from this fine plugin, it will show only the first running container in the Web-interface if asked for check_docker –status running. Python solves “printf” functionality by adding a suffix, so here’s a quick diff for the plugin so it can display all of the running containers when asked by check_docker plugin:

 

--- check_docker 2016-09-06 13:16:50.396425436 +0200
+++ /opt/nagios-plugins/check_docker/check_docker-master/check_docker.py 2016-05-16 03:20:13.000000000 +0200
@@ -1,5 +1,4 @@
 #!/usr/bin/env python3
-from __future__ import print_function
 __author__ = 'Tim Laurence'
 __copyright__ = "Copyright 2016"
 __credits__ = ['Tim Laurence']
@@ -15,6 +14,7 @@
 Note: I really would have preferred to have used requests for all the network connections but that would have added a
 dependency.
 '''
+
 from sys import argv
 from http.client import HTTPConnection
 from urllib.request import AbstractHTTPHandler, HTTPHandler, HTTPSHandler, OpenerDirector
@@ -25,6 +25,7 @@
 
 
 
+
 DEFAULT_SOCKET = '/var/run/docker.sock'
 DEFAULT_TIMEOUT = 10.0
 DEFAULT_PORT = 2375
@@ -273,15 +274,15 @@
 def print_results():
 if len(messages) > 0:
 if len(performance_data) > 0:
- print(messages[0] + '|' + performance_data[0], end=' ')
+ print(messages[0] + '|' + performance_data[0])
 else:
- print(messages[0], end=' ')
+ print(messages[0])
 for message in messages[1:]:
- print(message, end=' ')
+ print(message)
 if len(performance_data) > 1:
 print('|', end='')
 for data in performance_data[1:]:
- print(data, end=' ')
+ print(data)
 
 if __name__ == '__main__':

Docker “connectivity on endpoint” issue

I had a rough time with Docker’s messages saying “connectivity on endpoint” (AKA “your port is already used by something else”) messages a few hours ago. The log on the upgraded Ubuntu looked somewhat like:

...
 Aug 2 00:28:30 continuum rc.local[6885]: /usr/bin/docker: Error response from daemon: driver failed programming external connectivity on endpoint apache (0d941233cf3651b560252498b3be9cdf8fe0e5c89ab2c6443a44ece3a3ee27d1): Error starting userland proxy: listen tcp 192.168.43.31:9000: bind: cannot assign requested address.
 Aug 2 00:40:10 continuum dockerd[6719]: time="2016-08-02T00:40:10.227947585+02:00" level=error msg="Handler for POST /v1.24/containers/6e818fdc7e048321b0afd1b5e2355772a3bc488deb95bc26d94e25b3ca7a867e/start returned error: driver failed programming external connectivity on endpoint confluence (ee8261d117a81f8ad1af2214f693c04eb3ec3749bb91ff339f11c9366eb38c69): Error starting userland proxy: listen tcp 192.168.43.114:9909: bind: cannot assign requested address"
 Aug 2 00:40:10 continuum rc.local[6731]: /usr/bin/docker: Error response from daemon: driver failed programming external connectivity on endpoint confluence (ee8261d117a81f8ad1af2214f693c04eb3ec3749bb91ff339f11c9366eb38c69): Error starting userland proxy: listen tcp 192.168.43.114:9909: bind: cannot assign requested address.
 Aug 2 00:40:12 continuum dockerd[6719]: time="2016-08-02T00:40:12.211933605+02:00" level=error msg="Handler for POST /v1.24/containers/26d7d02a14fe0b037dd9099edf49f4365432023b03af1e7bb68994185a36976b/start returned error: driver failed programming external connectivity on endpoint jira (4651cf8fca76c6c3ce3a0eee28877bc9d996250918127a41ffbe95222c74684c): Error starting userland proxy: listen tcp...

I thought the upgrade from 14.04 LTS to 16.04 LTS did it, because it was a hell of its own kind, but apparently everything was there, and the forums weren’t clear enough.

It ended up to be my tainted /etc/networks/interfaces file, where my aliased IPs wouldn’t start normally for a reason still unknown to me. I did rewrite those aliases in order to make sure it was tidy, but it wouldn’t start normally until I moved those aliases of an interface directly beneath the “auto p4p3…” directive for the parent interface.

As soon as I cleared those, the next reboot again took only 20-ish seconds, and the docker containers started as expected.