You’ve done some initial scans with SonarQube and see the potential to help you improve your codebase. You’ve got your builds flowing through Jenkins. There’s gotta be a way to integrate the reports from SonarQube into Jenkins.
Configuring certificates for IIS isn’t always an easy task. This is particularly true if you’re coming from say the software development side of the industry rather than the operations side.
Certificates often utilize what’s referred to as a chain of trust. Certain certificate authorities publish root certificates. Then often there will be an intermediate certificate that links to the root certificate.
Here is how to import an intermediate certificate using PowerShell
Finally a wildcard certificate will be used, in our case for a website, that is validated by the intermediate certificate which depends on the root certificate. The below PowerShell imports the wildcard pfx certificate into the proper WebHosting certificate store.
Bacula is all setup and humming along. Then you end up no longer needing and decommission a machine. The issue is that now the Bacula job to backup that machine fails since it cannot connect. That makes sense, but how do we preserve the backups that we already have until their retention period expires?
Update the configuration
Backup the file sudo cp /etc/bacula/bacula-dir.conf "/etc/bacula/bacula-dir.conf.backup.$(date +"%Y%m%d-%H%M%S")"
I had an Angular front end calling a .NET Web API backend. It would produce a JWT token for authentication. However different calls would fail to the backend with the correct token. I couldn’t always reproduce the failure with Postman either. Both the front-end and the back-end are load balanced.
By default the .NET Web API uses the machine key to produce the JWT token for authentication. The problem was that when server 2 tried to validate the token server 1 produced it failed and vice versa.
I had a need to generate a unique machine key in IIS so that I could add it to the web.config of a load balanced site. I didn’t realize that by doing it wrong, I’d bring down the other .NET sites that used that machine key.
I went into IIS and clicked on Machine Key. I clicked Generate Keys and I selected “Generate a unique key for each application. This seemed reasonable since the applications were hosted in a multi-tenant environment.
After making that change, the sites that depended on the machine key would get an error stating “ERR_TOO_MANY_REDIRECTS“. The screen would look like the one below.
As it turns out that is the only combination of Machine Key options that can cause this error. All the other options pictured below will work.
You’ve finally got your SonarQube server setup and ready to go. Now you need an automated way to proceed with scanning. If you’ve already got a Jenkins instance up and running, then this post is for you.
You need to have a better understanding of the IIS as part of a migration or you’d like to scale out your existing environment. You’ve been keeping meticulous records of all IIS features in an easily digestible format, right?!?!?! This post is for anyone that hasn’t.