So I’m going through a bit of a Linux kick lately and one of the things I ended up doing was installing Ubuntu 16.04LTS on my Dell 7370 laptop. Afterwards, I started to get sick of the scrolling with two fingers on the touch pad – I was pretty used to the “natural scrolling” function on the laptops.

All of the guides were pointing me towards opening the Mouse/Touchpad settings, but there was no checkbox for Natural scroll anywhere to be found.

User “goetzc” from askubuntu.com pointed me in the right direction:
nano /usr/share/X11/xorg.conf.d/50-synaptics.conf
Find the section that says “Identifier ‘touchpad catchall’
Mine now says:

Section “InputClass”
Identifier “touchpad catchall”
Driver “synaptics”
MatchIsTouchpad “on”
MatchDevicePath “/dev/input/event*”
Option “NaturalScrolling” “on”
Option “MiddleEmulation” “on”
Option “Tapping” “on”
Option “DisableWhileTyping” “on”
EndSection

**EDIT**
I just realized that I couldn’t see the option in my Mouse settings panel because I had a non-compatible theme running that ruined the visuals of many options. Oh well, live and learn I guess.

I had reformatted one of my hypervisor boxes (prox) and completely forgot about changing my SSH keys on other systems. I have a jumpbox that allows me to remotely access and admin the environment, but I couldn’t SSH into my prox system:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
2a:35:00:00:c7:e8:f3:fe:f7:6e:cf:00:00:db:e9:d8.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:33
RSA host key for prox1 has changed and you have requested strict checking.
Host key verification failed.

Opening up my /root/.ssh/known_hosts file I see a bunch of giberish. Answer found from c0rp.

Fast and easy fix
sed -i '33d' ~/.ssh/known_hosts
Obviously change the ’33d’ to reflect your line number. e.g line 12 wouild be ’12d’
Then SSH to your machine again and you’ll be asked if you want to store the new RSA fingerprint.

Or you can use SSH Keygen
ssh-keygen -R yourmachinenamehere

After my engineers gave me a test vmware system full of the requested guest VM’s, I noticed that the CentOS system did not have any vmware tools installed. I attempted to run through the standard mount the CD and run the rpm’s, but I was greeted with a message saying I should run the open-vm-tools suite instead.

Install Open VM Tools
yum -y install open-vm-tools

Start the VM Tools Daemon
systemctl start vmtoolsd.service

Enable Startup on Reboot
systemctl enable vmstoolsd.service

service vmtoolsd start
also works

Recently upgraded the Rancid server from 12.04.3 to 14.04 (and it started as 10.04 from my rancid on ubuntu 10 install page).

Not everything went flawlessly: the upgraded killed the configuration file that said drancid is to be used for my dell switches. Not a big deal, just calling it out. I just following my “drancid” post somewhere else on this blog.

Then I noticed that some of the switches were EOF prematurely; turned out it was due to the fact that the exec and login banners on these cisco devices had the character “#” in them and the new version of having an issue parsing those out. Another easy fix.

Final problem was an error 500 on the web interface. In my brief research this was due to the fact that perl was upgraded to 5.18.x from 5.14.x
It should be noted that I learned about the rmadison packagenamehere command (installed with devscripts) which was fairly helpful. It should also be noted that there was not a lot of information on this error which leads me to believe that not many are using rancid on a 14.x or above system.

Troubleshooting this issue I ran (change depending on the user you’re running rancid under)
sudo login -f root
source /etc/rancid/rancid.conf
NOPIPE=yes;export NOPIPE
rancid -d switchname
nano *.new
nano *.raw
The full logs are the *.new and the *.raw files in the directory you ran the commands in.

So someone (a netbsd op) pointed out that there is a fix for this issue. In my case I’m running debian/ubuntu, so I actually found this article by Mark Kamichoff.

nano /usr/lib/cgi-bin/cvsweb
I searched for “legend” to get to the following:

 <legend>General options</legend>
 <input type="hidden" name="copt" value="1" />
 EOF
-    for my $v qw(hidecvsroot hidenonreadable) {
+    for my $v (qw(hidecvsroot hidenonreadable)) {
       printf(qq{<input type="hidden" name="%s" value="%s" />\n},

Searched again for “mytz”:

   print '<i>';
-  if (defined @mytz) {
+  if (@mytz) {
     my ($est) = $mytz[(localtime($date{$_}))[8]];
     print scalar localtime($date{$_}), " $est</i> (";
   } else {

Running 9.2.0.1 – Shigawire (revision 972) on some supermicro server with an Intel Xeon.

Noticed that I wasn’t receiving my weekly status emails so I finally got around to checking it out (system is running as a backup of a backup for my personal files, so not the end of the world if it doesn’t work right).

Logged in via the web interface and didn’t notice anything really going on except that out of the 4 available cores on the processor 2 were maxing out at 100%. Process listing showed smartctl was the culprit. Went into the ZFS settings (forgot no smart settings in there), and then tried to load up the Disk > Management area. No go – spinning and spinning.

Logged in using SSH to restart the web services
/etc/rc.d/lighttpd restart

Back in business, but then the Disk > Management area was once again crashing it out.

Issued a kill -s HUP thePIDhere. They came right back.

Rebooted the server. Smartctl was still coming up eating all of my available CPU time for reports.

I ended up renaming the smartctl bin file and then killing the processes.
It’s located /usr/local/sbin, then mv smartctl to smartctl.old or something

From there I could load the Disk > Management page again and disable smart monitoring.

And yes, the disks have all checked OK.