It looks like ACL permissions are still wrong. They are propagating to "Subfolders and files only" but should be "This folder, subfolders and files".

Dont forget to update the protos as well.

Restarting the Nomad client doesn't seem to recover the old task but creating a new one instead.

At the moment you can define an https-binding, but theres no way to specify a certificate.

At the moment, schema and deserialization of task and agent config is hardcoded.
There's also a lot of duplicate code. We should move to a declarative approach.

Websites in IIS need a unique numeric id. Currently, we're using max+1 as the next id.
Therefore you may run out of ids some time.
We should use the smallest available id.

Get the plugin listed on the official HashiCorp Documentation as a community plugin.

Try to implement the exec functionality if it is possible to do that under the AppPool identity.

At the moment the website path is relative to the allocation directory but when using an artifact block, content is being put into the task-directory.
Maybe we should make the website path relative to the task-directory?

At the moment we cannot specify "NoManagedRuntime" for the RuntimeVersion.
This is needed when hosting ASP.NET Core Applications inside IIS.

IIS worker processes don't log to stdout which is pretty bad.
But maybe we can provide a named pipe to the application so the app developer can configure logging to it manually.

Nomad is already creating a named pipe for logging, but only the Administrator account is permitted to access it.
So we should try to wrap it into a new one and permit the AppPool user.

Allow to specify file size limits on the alloc directory and maybe stop the app on an overusage.

Remove the hardcoded HTTP port 5003 from Program.cs.
It should be dynamic and already gets exposed by the HandshakeService.

If i have an empty IIS with no existing website and schedule the first one via Nomad, it doesn't start throwing a HTTP 500.
The problem is that we start at an Id 0 instead of 1 when numbering websites. A 0 doesn't get written to the applicationHost.config which seems to corrupt it.

Implement an optional management API for administrative tasks. The API could be called by a higher order management service, sitting on top of nomad.

Examples would be:

• Creating a memory dump of a w3wp process
• Download some internal IIS logs
• Clean up orphan websites if any #14
• Allow patching of files in a running website
• etc

The web app fails to load the web.config, if someone specifies a path using a slash (Linux stlye) instead of a backslash.

Eg.

application {
   path = "local/app"
}

We should normalize all paths.

Recovering a task fails sometimes, because the driver state cannot be deserialized.

Looks line nomad sometimes sends a kill signal, so we should implement this.

https://developer.hashicorp.com/nomad/docs/job-specification/service

Although it is very unlikely, but it may happen, that sometimes an AppPool and/or website is not getting removed.
We should implement a task for finding and destroying them periodically.
This should be a driver-option with default = false.

Because the plugin needs admin permissions to manage IIS, we should check this on startup.

CPU Utilization always shows a value of 0%.

Currently, deploying an IIS job will always create a new website and application.
I need a way to deploy a new application into an existing website which is managed outside of nomad.
This is needed especially in situations where you have an existing server where you only want to manage "some" applications by nomad.

I'am thinking about something like:

config {
  target_website = "Default Web Site"

  application {
    path = "..."
  }
}

This will only manage the application inside the specified website but never touch the website itself.

There're a few restrictions:

• Defining bindings or other website-related settings must be prohibited
• All applications need to use an alias and they must be unique on the target node
  • It would be a good idea to define some client-metadata to ensure jobs are only scheduled on the right nodes containing the website
• There can be no nomad-managed root-application because changing it's path would require to re-create it

Update to .NET 8 because it's LTS.
Update all dependencies.
Dont forget to update the readme.

We also need to remove folder permissions on the alloc and private folders as already stated in the Readme.

Add support for loading the user profile of an AppPool.
Because this creates a new directory in C:\Users, we also need to clean this up when purging the job.

It would be a cool idea to allow to define some REST-API calls which can then be invoked by a signal.
Something like:

signal {
  name = "SIGUSR1"
  path = "/api/signals/sigusr1"
  method = "GET"
  headers = {
    X-Api-Key = "Some API Key"
  }
}

May be usefull to execute some management tasks.
The API may listen to localhost only.

According to the official docs we shouldn't use a custom interval to report task statistics. Instead, we should use the provided interval by nomad.

We need to make sure that folder permissions are correct, so that only a single AppPool can access it. Especially on the secrets folders.