File Searcher By Owner Now Open Source

File Searcher by Owner, the number one utility for finding files and folders owned by a particular user or group, is now open source and available on its GitHub repo.
Ping: IT Admins
This site is a bit of a playground for me to test website hosting and play with a CMS that isn't WordPress. I use it in conjunction with my public GitHub repos and I write up solutions to tricky technical issues that either took me a while to resolve or where web searches yielded no answers (or, worse, a number of time-wasting "solutions" that had nothing to do with my particular issue). I'm sure someone must have solved the issue before but since I couldn't find it with a bit of Google-fu I figured it out on my own and documented the solution here. The website is also open for you to post your solutions for someone else (with admin moderation before they publicly appear), if you would like to contribute. |
File Searcher by Owner, the number one utility for finding files and folders owned by a particular user or group, is now open source and available on its GitHub repo.
NetBox is one of the best IP Address Management (IPAM) and data center infrastructure management (DCIM) tools available. It is an open source web-based application that will only cost you the time and resources to set up an internal server. However, while there is step-by-step upgrade documentation available, it can be ambiguous at times and also misses some important steps resulting in errors and service start failures (e.g., "Service Not Found" errors). The following guide will help you to make sure your upgrades are successful and will provide tips on how to troubleshoot problems that may arise.
Although NetBox can run on CentOS, we highly recommend Ubuntu since the CentOS Project is sadly transitioning away from their traditional solid Linux distro to their new CentOS Stream distro which tracks ahead of Red Hat Enterprise Linux (RHEL) development. Therefore, the steps in this guide will be tailored toward Ubuntu Server. However, the ideas behind this guide can be transferred to a CentOS installation of NetBox as well.
Read on for the guide...
I recently wrote a PowerShell script for Windows that will check if a program or update is installed and, if not, download it using BITS in low priority, verify the download hash, and then install it and copy the verbose log to a central repository. The example is for the current latest Microsoft Surface Pro 7 firmware, but it can be adapted for just about any installer.
Read on for the script code...
There are many different Git workflows out there. Gitflow has been one of the most popular for a decade now, especially for open source projects. It provides a standardized branching mechanism with a lot of flexibility. However, it is not recommended for projects that desire to maintain a single version in production. On the other end of the spectrum, GitHub flow is another popular branch-based workflow that simplifies the development workflow and is very friendly for continuous integration and continuous delivery (CI/CD). A major downside to Github flow is that features are merged directly into the Master/Main branch which greatly increases the probability of bugs or unstable code being released into production. It also may not be the best workflow for open source projects, which we at the The Grim Admin are full supporters of. Since all features are merged directly into the production branch, you need to really trust all of your developers and that can be hard at times when dealing with open source projects.
For our projects, most of the time we implement a simplified version of the Gitflow model. This modified workflow aims to be simpler in that it cuts out the release branches, which are unnecessary when maintaining a single version in production workflow. The Master/Main branch will always be the latest stable version released and tagged with an updated version number anytime the Develop branch is merged into it. Rebasing will occur if we need to streamline complex history.
As stated above, it's basically the Gitflow model without the release branches. There are two lifelong branches. The master branch stores the official release history, and the develop branch serves as an integration branch for features.
While these two branches are continuous branches that last for the life of the project, the next two branches are created and only exist until they are merged back into either the Master/Main or Develop branches.
This workflow is nice because contributors only need to worry about two types of branches: Hotfix & Feature. A detailed Git history is available on the Develop branch, while the Master/Main branch is always the latest production version ready for install or download AND is tagged so as to easily find previous release versions. This also works well for open source because of the extra layer of code review.
We'd love to hear your thoughts in the comments!
This popular screensaver utility has been updated! Two versions have been released:
1.6.3 (2020-06-15) - The final version that runs natively on older operating systems, requiring either .NET 2 or 3.5.
2.0.3 (2020-06-15) - Includes all the updates from version 1.6.3 and has been converted to run natively on newer operating systems.
After many years, we've released the next version of File Searcher by Owner!
File Searcher by Owner is the number one utility for finding files and folders owned by a particular user or group.
Download File Searcher by Owner 2.0
Much of the code has been rewritten and there are a number of new features in this release:
Version 2.0.2.0 (2020-05-15)
Known Issues
Upcoming Features
OK. Here is how I deployed the AlwaysOn VPN in device tunnel (rather than user tunnel) using PowerShell. Continue on for the steps...
If you're like me, you've run into the following set of errors when trying to use CMake on Windows and especially when trying to compile Python code:
-- Building for: NMake Makefiles
-- The CXX compiler identification is unknown
-- The C compiler identification is unknown
CMake Error at CMakeLists.txt:131 (project):
The CMAKE_CXX_COMPILER:
cl
is not a full path and was not found in the PATH.
To use the NMake generator with Visual C++, cmake must be run from a shell
that can use the compiler cl from the command line. This environment is
unable to invoke the cl compiler. To fix this problem, run cmake from the
Visual Studio Command Prompt (vcvarsall.bat).
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
CMake Error at CMakeLists.txt:131 (project):
The CMAKE_C_COMPILER:
cl
is not a full path and was not found in the PATH.
To use the NMake generator with Visual C++, cmake must be run from a shell
that can use the compiler cl from the command line. This environment is
unable to invoke the cl compiler. To fix this problem, run cmake from the
Visual Studio Command Prompt (vcvarsall.bat).
Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.
Read on for instructions on how to get past this error...
Once in a while, when using the built-in VPN client in Windows 10, we would be able to begin to connect and actually authenticate, but not complete the connection. We would have an error similar to the following in the Application Event Log:
Even rebooting alone wouldn't fix the issue. But, the fix for us was easy. We only needed to delete and have windows recreate some items in the Device Manager. Try the following:
That seems to clear out the necessary bit of whatever the VPN service was hung up on.
If you've been having issues with your Windows 10 machines not connecting for a minute or even at all after a boot or reboot, you may have been hit with a bug that has affected Windows 10 since version 1709 rolled out. Even if you have a network SSID set to "Connect Automatically," Windows would not connect reliably after a cold boot. This would affect users using pre-shared keys and also 802.1x policies (for example using RADIUS or Windows NPS Server) and all flavors of Windows including Home, Professional, Enterprise, & Education editions.
One way to fix this is by disabling the "Microsoft Wi-Fi Direct Virtual Adapter" in Device Manager, but this came with some side-effects such as disabling the ability to wirelessly project through Miracast (also Intel's WiDi). Those who couldn't or didn't want to do that have had limited success making the issue less likely to occur by disabling the "EnableActiveProbing" registry parameter and/or using Group Policy to enable the "Turn off Windows Network Connectivity Status Indicator Active Tests" & "Do Not Show the Local Access Only Network Icon" policies.
Fortunately, Microsoft has just released a cumulative patch for Windows 10 1803 that seems to have fixed the Wi-Fi issue introduced with the 1709 feature upgrade. It is the October 24, 2018—KB4462933 (OS Build 17134.376) update. Microsoft also recently released an update for Windows 10 1709, but we have not yet tested to see if it fixes this issue. As for the recently released Windows 10 1809, we do not recommend upgraded to that feature update quite yet due to the major issues that still need to be resolved.
Please comment below and let us know if you have had success with the KB4462933 update!