I was trying to compile collectd on a old CentOS 6 host, and ./configure complained that rrdtool couldn’t be found; e.g.
rrdtool . . . . . . . no (rrd.h not found)
I’d intended to use rrdtool to collect instance-level metrics and then graph ’em out with CGP, so it was pretty annoying. TIL that you can use the “-ql” to list the files installed by a particular binary; e.g.
$ rpm -ql rrdtool-devel
package rrdtool-devel is not installed
I installed rrdtool-devel, and then lo and behold:
rrdtool . . . . . . . yes
A keylogger records when a key is pressed, when it is released, and whether any shift or special keys have been pressed. It is also recorded if, for example, a password is entered even if it is not displayed on the screen.
There is no evidence that this keylogger has been intentionally implemented. Obviously, it is a negligence of the developers – which makes the software no less harmful. If the developer would just disable all logging, using debug-logs only in the development environment, there wouldn’t be problems with the confidentiality of the data of any user.
I found the file MicTray64.exe in my HP EliteBook 840 G3. It’s barely 2 months old, running an up-to-date version of Windows 10 Pro. The prudent measure was to remove this file, as neither Conexant nor Hewlett-Packard hasn’t deigned to respond. I was unable to find the log file C:\Users\Public\MicTray.log, though.
I quickly pressed Windows Key + q to open the Search box and typed in: turn windows features on or off Turn windows features on or off I scanned a few options but one in particular was salient: Hyper-V was enabled.
So I installed the 64-bit version of Docker for Windows after configuring a shiny new VirtualBox CentOS 7 guest. The latter’d ran just fine previously, but was now causing a BSOD, and I wasn’t even able to create new 64-bit guests.
As it turns out, installing Docker enables Hyper-V, but uninstalling Docker doesn’t disable Hyper-V; i.e. these virtualization technologies are incompatible. The fix to this is quoted above: disable Hyper-V.
Fixing this issue is pretty straightforward and involves a few simple steps.
- Load up task manager (right click taskbar and select Task Manager)
- Go to the Processes Tab
- Select rdpclip.exe
- Click End Process
- Go to the Application Tab
- Click New Process
- Type rdpclip
- Click Ok
Today, I was trying out the new release, and then I ran into a wall: logging in to mysql didn’t work, even though I was sure that I’d configured it correctly; i.e. root with an empty password.
I’d done this hundreds of times already, so I was sure it’d work, but then again, it just didn’t. So I tried to reset the root password by killing mysql and then starting mysql_safe with a new password. In the past, this process has worked successfully, but then I kept getting the message that mysql_safe has ended; i.e. not good.
I left things as-is for awhile, before thinking to read the manual (RTM):-
Password behaviour when the MySQL root password is empty has changed. Packaging now enables socket authentication when the MySQL root password is empty. This means that a non-root user can’t log in as the MySQL root user with an empty password. For details, see the NEWS file.
Tldr: Non-root *nix users can no longer login as MySQL root, so just use sudo root.
p.s. Sudo is not the answer to everything. The trick here is knowing why: an upstream change.
Previously I wrote about configuring a Microtik for RDP. Well, that router died, so I’d to do it all over again. (Here are the Terminal commands, except I’ve changed my public IP address to x.x.x.x.):-
/ip firewall nat>> add chain=dstnat action=dst-nat to-addresses=192.168.1.243 to-ports=3389 protocol=tcp dst-address=x.x.x.x dst-port=3389 log=no log-prefix=""
/ip firewall nat>> add chain=srcnat action=src-nat to-addresses=192.168.1.254 to-ports=3389 protocol=tcp dst-address=192.168.1.243 dst-port=3389 log=no log-prefix=""