Category: application

Random application stuff.

Guide: Installing Windows using WDS and MDT

Guide: Installing Windows using WDS and MDT

Who is this for?

This guide will target more lab oriented users. Some basic skills are assumed like installing an operating system will be assumed. Unlike other guides on the forum this specifically may interest those in or wanting a job in IT. Regardless of if you use these technologies in a corporate environment playing with them on your own can help you get familiar with technologies and concepts people use everyday to get paid. With the added bonus of doing something fun on a Saturday. Overall this guide is not about if you should. It is about if you can do something and try to have a little fun in the process. It may look complex at first because I am really verbose sometimes, but this is all free and wont cost you a dime to learn something new.

Read about it in the Forums.

Bacula blah

Bacula blah

Gave RHEL a test now that they allow 16 licenses with a free developer account and decided to install Bacula. After which I installed Baculum. I received a ton of php errors complaining about authentication and wasted about an hour looking at various guides.

I found in some obscure documentation that the API Baculum uses to talk to the Bacula console has its own GUI setup on port :9096. Sure enough the page loaded. I configured that and was finally able to get communication working from the main Baculum GUI on :9095.

The interface is meh at best, but it’s worth learning I guess. I like the fact that it doesn’t rely on headers to backup systems, but I haven’t figured out how to process a BMR yet. Soon.

ScreenConnect Woes

ScreenConnect Woes

Oh, where to begin? Like most of the IT industry and home lab enthusiasts I was drawn in by ScreenConnect the now defunct remote software company that was bought out by ConnectWise and renamed Control. When I first came across this server it was initially configured on a Ubuntu 14 desktop environment.

I wanted this to become a production system and with the delicate Mono config decided to try my luck converting it. This caused me some grief but I did not know what I know now about Ubuntu or even Linux in general in 2014. After removing the gnome desktop environment it lived like this for a few years with problem after problem that was slowly patched and fixed.

Enter connectwise. Connectwise bought SC and turned it into Control. This was of no moment at the time, using NGINX as a reverse proxy I had SSL and a manageable interface as Mono; Screenconnects built in web engine slowly faded into EOL status and no longer supported modern browsers.

It was time for 19.04 LTS and after attempting upgrade it failed. Not only was I stuck on a Gen1 VM I could no longer update the core OS from 18.04 without destroying SC. So with Connectwise predatory pricing scheme, and my lifetime SC license no longer activating on their servers I could do nothing but wait.

So I did, With 20.04 coming out I wanted to try again. I was finished the migration to encrypted and protected VMs with a slew of other security related modifications the only server out was Screenconnect.

I did the upgrade from 18.04 to 20.04 and as anticipated it broke. This time however I wanted to fix it. First and foremost I saw that the service was starting, but only After I was able to console into the server. SSH was not working. I figured if SSH did not fuction it stood to reason this may be firewall related. After a quick check:

Sudo ufw status

I was confused to find it disabled. After enabling the firewall

sudo ufw start
sudo ufw enable

This completed without issue, and a check of my rules showed they were still in place. I decided at this point to reboot, hoping that maybe this was always the problem. After however, I was greeted with the same problem. This needed to be fixed first for me to proceed. I need the firewall to start with the system. What was odd was that all of the enable commands via systemctl or otherwise did not report an error.
After some digging I managed to find my issue.

sudo nano /lib/systemd/system/ufw.service

Had a line in it regarding firewall start metrics.

This made no sense, we need the firewall to start AFTER the network comes up so it does not fail and stop.

Done. After yet another reboot the firewall service was working correctly. Now it was time to check on Screenconnect. While installed and intact after the upgrade still was not starting. Thankfully SC is configured to log its own errors.

at ScreenConnect.Program.Main (System.String[] args) [0x00000] in :0
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: An exception was thrown by the type initializer for libc ---> System.DllNotFoundException:
at (wrapper managed-to-native) ScreenConnect.MonoNative+libdlProxy:dlopenPlatformInvoke (void,int) at ScreenConnect.MonoNative+libdlProxy.dlopen (System.Void , Int32 ) [0x00000] in :0
at ScreenConnect.MonoToolkit+MonoDiskNativeLibrary.TryLoadNativeLibrary (System.String libraryPath) [0x00000] in :0
at ScreenConnect.DiskNativeLibrary..ctor (System.String libraryPath) [0x00000] in :0
at ScreenConnect.MonoToolkit+MonoDiskNativeLibrary..ctor (System.String libraryPath) [0x00000] in :0
at ScreenConnect.MonoToolkit.LoadNativeLibraryFromDisk (System.String libraryPath) [0x00000] in :0
at ScreenConnect.NativeLibrary.LoadLibrary (System.String libraryName, System.Type lookInAssemblyWithType) [0x00000] in :0
at ScreenConnect.NativeLibrary.LoadLibrary (System.Type type, System.Type lookInAssemblyWithType) [0x00000] in :0
at ScreenConnect.NativeLibrary.LoadProxy (System.Type type, System.Type lookInAssemblyWithType) [0x00000] in :0
at ScreenConnect.NativeLibrary.LoadProxy[libc] (System.Type lookInAssemblyWithType) [0x00000] in :0
at ScreenConnect.MonoNative+libc..cctor () [0x00000] in :0
--- End of inner exception stack trace ---

Rough. IT looks like it was having some issues with libc, libdl after a quick look around using find I came across broken symlinks in /lib/x86_64-linux-gnu where the files resided. It looked like glibc was updated and the existing links were broken.

SSH made this easy because the broken links showed up as bright red. Time to fix them.

sudo ln -s
sudo ln -s
sudo ln -s

After the re-link a reboot for good measure and WE WERE BACK!

20.04 running well and screenconnect letting me touch my machines.

Life is good.

BONUS: If you want colors in your sessions

sudo nano ~/.bashrc

Then uncomment the line