For all those of you who have been trying to clear Putty’s cache of host fingerprints (Windows) for development or testing, here is the answer:
Open the registry (regedit) Go to HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys Delete the rows that you need and presto! Nice, TIL.
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 -ql to list the files installed by a particular binary; e.g.
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 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.
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 References https://techtalk.gfi.com/copy-paste-working-remote-desktop-connection-whats-wrong/
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.