Observium installation on Debian 9 – adding devices fails

Installing fresh Observium (18.9.9420) (community version) on Debian 9 does not end up with a working installation.  (See Observium documentation)

Only one device is added, that cannot be viewed afterwards.

Possible solution: modify the database structure after installation and before adding your devices.

Start checking if the devices_id field has an auto-increment value set and is the primary key.

One can do so by issuing following commands:

mysql>show columns from devices from observium;

or alternatively:

mysql>show create table devices;

If the auto-increment value is missing, please add it:

mysql> use observium;

mysql> alter table devices change column device_id device_id int(11) not null auto_increment;

Easy fix, but takes some time to find out.

Some background information from the logs:

##### Software versions #####

o OS Linux 4.9.0-8-amd64 [amd64] (Debian 9.6)
o Apache 2.4.25
o PHP 7.0.33-0+deb9u1 (OPcache: DISABLED)
o Python 2.7.13
o MySQL 10.1.37-MariaDB-0+deb9u1 (extension: mysqli 5.0.12-dev)
o RRDtool 1.6.0
o Fping 3.15 (IPv4 and IPv6)

##### Memory Limit #####

o PHP Unlimited

##### MySQL mode #####


##### Charset info #####

o MySQL utf8

##### Timezones info #####

o Date Wednesday, 15-May-19 13:35:30 CAT
o PHP +02:00
o MySQL +02:00

After making the change, please check the auto_increment value is there.

show columns from devices from observium;

Mint upgrading from 18.3 to 19 – Netbeans broke

Seems netbeans cannot work with OpenJDK 10/11 and stops silently shortly after start.


uninstall 8.1 from software list and/or remove manual installation from /usr/local

Install OpenJDK 1.8

Download latest 8.2 from netbeans.org.

Install Netbeans 8.2 in current user (aka path /home/youruser). Also install Glassfish/Tomcat in current user. For some reason, installation in /usr/local does fail.

During installation, point your java jdk to /usr/lib/jvm/openjdk-1.8.

Please note that editing the /etc/netbeans.conf file as indicated by some sites is not resolving the issue.

Mint update from 18.3 to 19 – Wine broke

After updating from Linux Mint 18.3 to 19, wine stopped working. This is what was required to correct.

sudo all below commands if required

dpkg --add-architecture i386
apt-add-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ bionic main'
wget -nc https://dl.winehq.org/wine-builds/Release.key
apt-key add Release.key

Check if you do not have duplicate lines from an earlier install.

vi /etc/apt/sources.list.d/additional-repositories.list

Then the final step.

apt-get update

apt-get install --install-recommends winehq-stable

Source: Ubuntu – WineHQ Wiki

Unknown media type in type Fix

If Linux Mint 19 (Tara) shows error during update fril 18.3.

Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'

To fix run following with sudo user:

cd /usr/share/mime
grep -R all/all *

in kde xml, remove the sections containing:
<mime-type type="all/allfiles">
<mime-type type="all/all">

sudo vi packages/kde.xml

the other files showing these sections can remain untouched.

Then run following, no errors should occur

sudo update-mime-database /usr/share/mime

Source: Unknown media type in type Fix

Problem with mounting NFS on Mac OS X

Recently, I got a problem mounting my NFS shares. A shortcut to the /Volumes/Public placed on the desktop would mount the volume in read-only mode. A go to /Volumes and selecting the Public link would mount it in read-write.

Things I tried first:
-chgrp to guest, admin, 20 (group where my user is)
-chown to guest, myself, admin
-chmod to 777

Once a volume was mounted in read-only mode, it would only come back on read-write mode after a reboot of the NFS client and following the manual process. It must have been a while like this but it went unnoticed as when mounting from an application (not Finder), it would mount correctly.

I tried rebooting the QNAP (shame on me) but it would not change the mounts without rebooting the client.

So what did I learn so far. All NFS mounts are cached on the client. If you know how to clear the cache without rebooting, it would help me.

I also run nfsstat to find a lot of problems. Compared to some production systems, the number of nfs problems is abnormally high. (I will include some statistics to prove my point.)