- We don't install Dovecot from OBS anymore.
- Removed files.put() that creates
/etc/apt/keyrings/obs-home-deltachat.gpg; replaced this with a
files.file() that sets present=False to remove the file from any
existing installations where it already has been installed.
- Removed now-unused obs-home-deltachat.gpg file.
- Clarified description of sources.list operation.
- Suggested in review by missytake and hpk42.
- On an IPv4-only system, if unbound is started but not configured, it
causes subsequent steps to fail to resolve hosts.
- Revised UnboundDeployer.install_impl() to use policy-rc.d to prevent
the service from starting when installed. This is the same
mechanism used to keep nginx from starting on install.
- Revised deploy_chatmail() to use all_deployers to call the
install(), configure(), and activate() methods on all the deployers,
rather than listing them explicitly in the code.
- The previous commits that added Deployer classes mostly kept
deployment operations in the same order that they were in before.
To organize the process into separate stages for install, configure,
and activate, we need to reorder the method calls. This is the
commit that does that, and thus this is the commit that has the
largest effect on the order of operations.
- The calls for the deployer objects are all reordered here so that
the methods are called in the same sequence for each stage. This
will allow us to collect the calls into loops in the next commit.
This commit provides a way to see a diff showing exactly how the
sequence changed.
- The sequence of deployers was largely based on preserving the order
of the "activate" stage, as this seems like the place order might be
the most likely to matter. Installation of packages and
configuration of files should generally be able to run in any order.
(ChatmailDeployer handles updating the apt data, and therefore needs
to be first, however.)
- The 'curl' program is used in TurnDeployer and IrohDeployer, so it
makes more sense to install it at the beginning in ChatmailDeployer,
rather than have each thing that uses it install it separately.
- This class is a special case because it has a dependency on the
Postfix and Dovecot deployers. When deciding whether to restart the
echobot service, it needs to know whether the Postfix and Dovecot
deployers restarted their services. To support this dependency, the
PostfixDeployer and DovecotDeployer objects are passed to the
EchobotDeployer object, so it can check their was_restarted
attributes.
- Split _install_remote_venv_with_chatmaild() into three routines, to
handle the install, configure, and activate stages.
- This moves the upload of chatmail.ini later in the deployment
process, because it is a configuration file specific to the
instance, not software installation that would be uniform across all
deployments.
- Note that this moves the installation of the opendkim package
earlier in the deployment sequence. Previously, it was installed
during the _configure_opendkim() routine.
- Added a Deployer class that defines the base for objects that will
handle installation of individual components, with install,
configure, and activate stages. Subclasses will override the
implementation methods of those stages as needed, while the base
class handles all the logic of deciding which stages to execute.
- The CMDEPLOY_STAGES environment variable is used to determine what
stages to run. If this is not defined, all stages run as usual.
- Added import of Deployer to cmdeploy/__init__.py. This is not yet
used, but the next series of commits will use it.
- In deploy_chatmail(), define an empty list of deployers, and call
the create_groups() and create_users() methods for the items in the
list. This list will get filled with Deployer objects in the next
series of commits.
- Moved the "Add 9.9.9.9 to resolv.conf" step earlier, before the
creation of users or updates to any config files. This should not
affect any of those operations. Moving this step earlier makes it
easier to accommodate the restructuring of the deployment process
into separate components with separate stages for install,
configure, and activate.
We already require that outgoing connections
use STARTTLS so other servers need a valid TLS
certificate to accept messages from us.
It is then very unlikely that they cannot use TLS
to send messages to us.
Conversely, if they only can send messages to use without TLS,
it likely does not have STARTLS on its port 25
and then we don't want to accept messages from them
because we will likely not be able to reply.
