Airgapped installation support

[mattroot]

Is your feature request related to a problem? Please describe.
Honeypots tend to be sometimes run in airgapped installations. This includes industrial environments, like factories. The main purpose in such setups is to detect potential intrusions of the network or to identify misbehaving devices.

Describe the solution you'd like
An official way to install, run and maintain a T-Pot installation (distributed or standalone) in an airgapped environment. This mainly consists of a detailed instruction and a few helpers and cleanups in the code.
This includes adding an instruction to set up a Docker registry, a git instance and possibly a distribution repository mirror for this purpose.

Describe alternatives you've considered
Basically, in this case one might configure a T-Pot instance outside of the airgapped setup and bring it in after deploying. This however creates some challenges when it comes to upgrades in the future.

Additional context
I have been running a similar setup for quite some time in such an environment, thus I can help with implementing it. If this is accepted, expect a few pull requests in the future regarding this issue, although those PRs might be irregular.

[t3chn0m4g3]

You can run T-Pot airgapped, when setting TPOT_PULL_POLICY=never in $HOME/tpotce/.env after installation.

From experience airgapped solutions tend to lack updates as a tedious amount of work and planning is necessary to keep the machines updated. By disabling the container check, setting up an OS mirror / a private container registry in the airgapped environment and a HIVE setup to receive SENSOR logs an airgapped install including central logging is possible today.

This is one of the best examples we had in mind with the introduction for T-Pot 24.04 to keep things as open as possible so adding the building blocks as necessary for individual setups just with a basic T-Pot 24.04 install.

With the design choices made to keep T-Pot more open, adding / changing the platform for setups that are expected to be highly individual by design, would focus work / maintenance too much on the platform rather than contributing to T-Pot's core, which are the honeypots and the deception experience.

[mattroot]

There are a few places where those variables are hardcoded tho. I will try to spot them all and submit a PR.

[t3chn0m4g3]

Thanks, making this modular in that regard is a good idea.