Implement paused-account RA handler

[pgporada]

The RA will handle receiving an unpause request from the SFE and forwarding that request to the SA for actual account unpausing. The RA should emit a metric to calculate the duration between WFE JWT issuance and when the account was unpaused.

Related to https://github.com/letsencrypt/boulder/issues/7406 Related to https://github.com/letsencrypt/boulder/issues/7499

[joakime]

Wouldn't that means we need to hook into the creation / deletion of temp files that all servlet things use? JSP temp files? JAXB temp files? AOP temp files? etc ...

[sbordet]

We don't need that much. We only need to detect if what Jetty does is deleted, i.e. primarily the war extraction because that would be fatal. A deleted JSP would just be recompiled.

[joakime]

A JSP (its actually the compiled JSP class) deleted from the temp directory can cause a classloader issue (as shown in past filed issues) The unpacked WEB-INF/lib/*.jar!META-INF/resources can also cause problems if they go missing.

Perhaps instead we "tag" the directory with something like .jetty-touch and look for that specific file occasionally, if it's gone, then we know the directory was removed out from underneath Jetty. But even that isn't a good solution, as we could accidentally have that specific file locked (like on MS Windows), but other files / directories get removed/deleted. But what do we do then?

Have to at least stop the active webapp to prevent more requests. Then hot-deploy a fresh copy? What if the user has hot-deploy disabled? stop the server with a big honking error message? Also, we can't run the destroy / de-init steps reliably, what does that mean?

[sbordet]

Perhaps instead we "tag" the directory with something like .jetty-touch and look for that specific file occasionally, if it's gone, then we know the directory was removed out from underneath Jetty.

How's that different from checking for the existence of the directory itself?

But what do we do then?

Now we do nothing, so a warning is already something better.

If hot-deploy is enabled, we can check periodically from the deployer and redeploy. If hot-deploy is disabled we can attempt a redeploy, and if that fails we try to stop the context and at least there is a warning.

[janbartel]

I suppose it would be possible for the deployer to periodically check all contexts it knows about for:

• context.getWar() isn't a directory (don't want to do checks on webapps deployed directly as dirs)
• context.isStarted() (don't want to do checks on a webapp that might be in the middle of starting, or hasn't been started yet)
• context.getBaseResource() is a directory and the directory exists

It would be easy to print a warning if the webapp has been unpacked and the unpacked dir has disappeared and the webapp is running.

It would be much more problematic to do a redeploy: it would require synchronization so that we don't try and redeploy a context that is already being redeployed (eg due to changed .xml or .war file) or deliberately stopped/removed either manually or via jmx etc etc

Also, this only handles the situation where the deployer is used. Embedded users also can have the problem that the temp directory disappears.

[joakime]

At this point in the conversation I think we are left with ...

1. Detect filesystem changes.
2. Warn if problem detected.
3. Don't even attempt to reload / redeploy / hotdeploy the webapp that now has the problem.

[stale[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sbordet]

This is so common (war deployed to a place that is periodically wiped out) that we should do something about. Either always deploy to $JETTY_BASE/tmp, or warn if the deployer can't find the wiped out wars.

[gregw]

We already have a mechanism that if $JETTY_BASE/work directory exists, then it is used for the temp directory. Note however that it has slightly different semantics as it is not cleared on a stop so things like compiled JSPs can persist.

[stale[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[joakime]

Perhaps instead we "tag" the directory with something like .jetty-touch and look for that specific file occasionally, if it's gone, then we know the directory was removed out from underneath Jetty.

How's that different from checking for the existence of the directory itself?

On windows, you can new File("directoryFoo").delete() and then do new File("directoryFoo").exists() and get true, as the filesystem locks and what not have not released that directory to Java yet, and this can take A LOOONG time to resolve itself on that running instance of Java.

A file, that is never opened by anything in Jetty, will avoid the File locks in windows that causes all of the problems we have there. That's why I proposed using a file to test for delete, vs testing for a directory is deleted.

[gregw]

I think it would be far simpler to just warn if /tmp is used and perhaps default to using the $JETTY_BASE/work directory ?

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been closed due to it having no activity.