mirror of
https://github.com/docker-mailserver/docker-mailserver.git
synced 2025-08-03 09:34:33 +02:00
deploy: ddcc1dcc5c
This commit is contained in:
github-actions[bot]
parent
0eeb91b632
commit
b6afb50e7c
25 changed files with 136 additions and 136 deletions
|
|
@ -1582,7 +1582,7 @@
|
|||
<h1>LDAP Authentication</h1>
|
||||
|
||||
<h2 id="introduction"><a class="toclink" href="#introduction">Introduction</a></h2>
|
||||
<p>Getting started with ldap and <code>docker-mailserver</code> we need to take 3 parts in account:</p>
|
||||
<p>Getting started with ldap and DMS we need to take 3 parts in account:</p>
|
||||
<ul>
|
||||
<li><code>postfix</code> for incoming & outgoing email</li>
|
||||
<li><code>dovecot</code> for accessing mailboxes</li>
|
||||
|
|
|
|||
|
|
@ -1565,7 +1565,7 @@
|
|||
|
||||
<h2 id="overview"><a class="toclink" href="#overview">Overview</a></h2>
|
||||
<p>Full-text search allows all messages to be indexed, so that mail clients can quickly and efficiently search messages by their full text content. Dovecot supports a variety of community supported <a href="https://doc.dovecot.org/configuration_manual/fts/">FTS indexing backends</a>.</p>
|
||||
<p><code>docker-mailserver</code> comes pre-installed with two plugins that can be enabled with a dovecot config file.</p>
|
||||
<p>DMS comes pre-installed with two plugins that can be enabled with a dovecot config file.</p>
|
||||
<p>Please be aware that indexing consumes memory and takes up additional disk space.</p>
|
||||
<h3 id="xapian"><a class="toclink" href="#xapian">Xapian</a></h3>
|
||||
<p>The <a href="https://github.com/grosjo/fts-xapian">dovecot-fts-xapian</a> plugin makes use of <a href="https://xapian.org/">Xapian</a>. Xapian enables embedding an FTS engine without the need for additional backends.</p>
|
||||
|
|
@ -1648,7 +1648,7 @@ docker-compose up -d
|
|||
<p>Run the following command in a daily cron job:</p>
|
||||
<p><div class="highlight"><pre><span></span><code>docker-compose exec mailserver doveadm fts optimize -A
|
||||
</code></pre></div>
|
||||
Or like the <a href="../../../faq/#how-can-i-make-spamassassin-better-recognize-spam">Spamassassin example</a> shows, you can instead use <code>cron</code> from within <code>docker-mailserver</code> to avoid potential errors if the mail-server is not running:</p>
|
||||
Or like the <a href="../../../faq/#how-can-i-make-spamassassin-better-recognize-spam">Spamassassin example</a> shows, you can instead use <code>cron</code> from within DMS to avoid potential errors if the mail server is not running:</p>
|
||||
</li>
|
||||
</ol>
|
||||
<details class="example">
|
||||
|
|
|
|||
|
|
@ -1486,8 +1486,8 @@
|
|||
<h1>IPv6</h1>
|
||||
|
||||
<h2 id="background"><a class="toclink" href="#background">Background</a></h2>
|
||||
<p>If your container host supports IPv6, then <code>docker-mailserver</code> will automatically accept IPv6 connections by way of the docker host's IPv6. However, incoming mail will fail SPF checks because they will appear to come from the IPv4 gateway that docker is using to proxy the IPv6 connection (<code>172.20.0.1</code> is the gateway).</p>
|
||||
<p>This can be solved by supporting IPv6 connections all the way to the <code>docker-mailserver</code> container.</p>
|
||||
<p>If your container host supports IPv6, then DMS will automatically accept IPv6 connections by way of the docker host's IPv6. However, incoming mail will fail SPF checks because they will appear to come from the IPv4 gateway that docker is using to proxy the IPv6 connection (<code>172.20.0.1</code> is the gateway).</p>
|
||||
<p>This can be solved by supporting IPv6 connections all the way to the DMS container.</p>
|
||||
<h2 id="setup-steps"><a class="toclink" href="#setup-steps">Setup steps</a></h2>
|
||||
<div class="highlight"><pre><span></span><code><span class="gi">+++ b/serv/docker-compose.yml</span>
|
||||
<span class="gu">@@ ... @@ services:</span>
|
||||
|
|
|
|||
|
|
@ -1082,10 +1082,10 @@
|
|||
|
||||
<li class="md-nav__item">
|
||||
<a href="#exposing-your-mail-server-to-the-outside-world" class="md-nav__link">
|
||||
Exposing your Mail-Server to the Outside World
|
||||
Exposing your Mail Server to the Outside World
|
||||
</a>
|
||||
|
||||
<nav class="md-nav" aria-label="Exposing your Mail-Server to the Outside World">
|
||||
<nav class="md-nav" aria-label="Exposing your Mail Server to the Outside World">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
|
|
@ -1610,10 +1610,10 @@
|
|||
|
||||
<li class="md-nav__item">
|
||||
<a href="#exposing-your-mail-server-to-the-outside-world" class="md-nav__link">
|
||||
Exposing your Mail-Server to the Outside World
|
||||
Exposing your Mail Server to the Outside World
|
||||
</a>
|
||||
|
||||
<nav class="md-nav" aria-label="Exposing your Mail-Server to the Outside World">
|
||||
<nav class="md-nav" aria-label="Exposing your Mail Server to the Outside World">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
|
|
@ -1690,10 +1690,10 @@
|
|||
<h1>Kubernetes</h1>
|
||||
|
||||
<h2 id="introduction"><a class="toclink" href="#introduction">Introduction</a></h2>
|
||||
<p>This article describes how to deploy <code>docker-mailserver</code> to Kubernetes. Please note that there is also a <a href="https://github.com/docker-mailserver/docker-mailserver-helm">Helm chart</a> available.</p>
|
||||
<p>This article describes how to deploy DMS to Kubernetes. Please note that there is also a <a href="https://github.com/docker-mailserver/docker-mailserver-helm">Helm chart</a> available.</p>
|
||||
<div class="admonition attention">
|
||||
<p class="admonition-title">Requirements</p>
|
||||
<p>We assume basic knowledge about Kubernetes from the reader. Moreover, we assume the reader to have a basic understanding of mail servers. Ideally, the reader has deployed <code>docker-mailserver</code> before in an easier setup with Docker (Compose).</p>
|
||||
<p>We assume basic knowledge about Kubernetes from the reader. Moreover, we assume the reader to have a basic understanding of mail servers. Ideally, the reader has deployed DMS before in an easier setup with Docker (Compose).</p>
|
||||
</div>
|
||||
<div class="admonition warning">
|
||||
<p class="admonition-title">About Support for Kubernetes</p>
|
||||
|
|
@ -1737,7 +1737,7 @@
|
|||
<span class="w"> </span><span class="nt">SSL_CERT_PATH</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">/secrets/ssl/rsa/tls.crt</span>
|
||||
<span class="w"> </span><span class="nt">SSL_KEY_PATH</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">/secrets/ssl/rsa/tls.key</span>
|
||||
</code></pre></div>
|
||||
<p>We can also make use of user-provided configuration files, e.g. <code>user-patches.sh</code>, <code>postfix-accounts.cf</code> and more, to adjust <code>docker-mailserver</code> to our likings. We encourage you to have a look at <a href="https://kustomize.io/">Kustomize</a> for creating <code>ConfigMap</code>s from multiple files, but for now, we will provide a simple, hand-written example. This example is absolutely minimal and only goes to show what can be done.</p>
|
||||
<p>We can also make use of user-provided configuration files, e.g. <code>user-patches.sh</code>, <code>postfix-accounts.cf</code> and more, to adjust DMS to our likings. We encourage you to have a look at <a href="https://kustomize.io/">Kustomize</a> for creating <code>ConfigMap</code>s from multiple files, but for now, we will provide a simple, hand-written example. This example is absolutely minimal and only goes to show what can be done.</p>
|
||||
<div class="highlight"><pre><span></span><code><span class="nn">---</span>
|
||||
<span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span>
|
||||
<span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ConfigMap</span>
|
||||
|
|
@ -1813,7 +1813,7 @@
|
|||
<span class="w"> </span><span class="nt">protocol</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">TCP</span>
|
||||
</code></pre></div>
|
||||
<h3 id="deployments"><a class="toclink" href="#deployments">Deployments</a></h3>
|
||||
<p>Last but not least, the <code>Deployment</code> becomes the most complex component. It instructs Kubernetes how to run the <code>docker-mailserver</code> container and how to apply your <code>ConfigMaps</code>, persisted storage, etc. Additionally, we can set options to enforce runtime security here.</p>
|
||||
<p>Last but not least, the <code>Deployment</code> becomes the most complex component. It instructs Kubernetes how to run the DMS container and how to apply your <code>ConfigMaps</code>, persisted storage, etc. Additionally, we can set options to enforce runtime security here.</p>
|
||||
<div class="highlight"><pre><span></span><code><span class="nn">---</span>
|
||||
<span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">apps/v1</span>
|
||||
<span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Deployment</span>
|
||||
|
|
@ -1965,7 +1965,7 @@
|
|||
<span class="w"> </span><span class="nt">emptyDir</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{}</span>
|
||||
</code></pre></div>
|
||||
<h3 id="certificates-an-example"><a class="toclink" href="#certificates-an-example">Certificates - An Example</a></h3>
|
||||
<p>In this example, we use <a href="https://cert-manager.io/docs/"><code>cert-manager</code></a> to supply RSA certificates. You can also supply RSA certificates as fallback certificates, which <code>docker-mailserver</code> supports out of the box with <code>SSL_ALT_CERT_PATH</code> and <code>SSL_ALT_KEY_PATH</code>, and provide ECDSA as the proper certificates.</p>
|
||||
<p>In this example, we use <a href="https://cert-manager.io/docs/"><code>cert-manager</code></a> to supply RSA certificates. You can also supply RSA certificates as fallback certificates, which DMS supports out of the box with <code>SSL_ALT_CERT_PATH</code> and <code>SSL_ALT_KEY_PATH</code>, and provide ECDSA as the proper certificates.</p>
|
||||
<div class="highlight"><pre><span></span><code><span class="nn">---</span>
|
||||
<span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">cert-manager.io/v1</span>
|
||||
<span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Certificate</span>
|
||||
|
|
@ -1995,11 +1995,11 @@
|
|||
<p>For storing OpenDKIM keys, TLS certificates or any sort of sensitive data, you should be using <code>Secret</code>s. You can mount secrets like <code>ConfigMap</code>s and use them the same way.</p>
|
||||
</div>
|
||||
<p>The <a href="../../security/ssl/">TLS docs page</a> provides guidance when it comes to certificates and transport layer security. Always provide sensitive information vai <code>Secrets</code>.</p>
|
||||
<h2 id="exposing-your-mail-server-to-the-outside-world"><a class="toclink" href="#exposing-your-mail-server-to-the-outside-world">Exposing your Mail-Server to the Outside World</a></h2>
|
||||
<p>The more difficult part with Kubernetes is to expose a deployed <code>docker-mailserver</code> to the outside world. Kubernetes provides multiple ways for doing that; each has downsides and complexity. The major problem with exposing <code>docker-mailserver</code> to outside world in Kubernetes is to <a href="https://kubernetes.io/docs/tutorials/services/source-ip">preserve the real client IP</a>. The real client IP is required by <code>docker-mailserver</code> for performing IP-based SPF checks and spam checks. If you do not require SPF checks for incoming mails, you may disable them in your <a href="../override-defaults/postfix/">Postfix configuration</a> by dropping the line that states: <code>check_policy_service unix:private/policyd-spf</code>.</p>
|
||||
<p>The easiest approach was covered above, using <code class="highlight"><span class="nt">externalTrafficPolicy</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Local</span></code>, which disables the service proxy, but makes the service local as well (which does not scale). This approach only works when you are given the correct (that is, a public and routable) IP address by a load balancer (like MetalLB). In this sense, the approach above is similar to the next example below. We want to provide you with a few alternatives too. <strong>But</strong> we also want to communicate the idea of another simple method: you could use a load-balancer without an external IP and DNAT the network traffic to the mail-server. After all, this does not interfere with SPF checks because it keeps the origin IP address. If no dedicated external IP address is available, you could try the latter approach, if one is available, use the former.</p>
|
||||
<h2 id="exposing-your-mail-server-to-the-outside-world"><a class="toclink" href="#exposing-your-mail-server-to-the-outside-world">Exposing your Mail Server to the Outside World</a></h2>
|
||||
<p>The more difficult part with Kubernetes is to expose a deployed DMS to the outside world. Kubernetes provides multiple ways for doing that; each has downsides and complexity. The major problem with exposing DMS to outside world in Kubernetes is to <a href="https://kubernetes.io/docs/tutorials/services/source-ip">preserve the real client IP</a>. The real client IP is required by DMS for performing IP-based SPF checks and spam checks. If you do not require SPF checks for incoming mails, you may disable them in your <a href="../override-defaults/postfix/">Postfix configuration</a> by dropping the line that states: <code>check_policy_service unix:private/policyd-spf</code>.</p>
|
||||
<p>The easiest approach was covered above, using <code class="highlight"><span class="nt">externalTrafficPolicy</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Local</span></code>, which disables the service proxy, but makes the service local as well (which does not scale). This approach only works when you are given the correct (that is, a public and routable) IP address by a load balancer (like MetalLB). In this sense, the approach above is similar to the next example below. We want to provide you with a few alternatives too. <strong>But</strong> we also want to communicate the idea of another simple method: you could use a load-balancer without an external IP and DNAT the network traffic to the mail server. After all, this does not interfere with SPF checks because it keeps the origin IP address. If no dedicated external IP address is available, you could try the latter approach, if one is available, use the former.</p>
|
||||
<h3 id="external-ips-service"><a class="toclink" href="#external-ips-service">External IPs Service</a></h3>
|
||||
<p>The simplest way is to expose <code>docker-mailserver</code> as a <a href="https://kubernetes.io/docs/concepts/services-networking/service">Service</a> with <a href="https://kubernetes.io/docs/concepts/services-networking/service/#external-ips">external IPs</a>. This is very similar to the approach taken above. Here, an external IP is given to the service directly by you. With the approach above, you tell your load-balancer to do this.</p>
|
||||
<p>The simplest way is to expose DMS as a <a href="https://kubernetes.io/docs/concepts/services-networking/service">Service</a> with <a href="https://kubernetes.io/docs/concepts/services-networking/service/#external-ips">external IPs</a>. This is very similar to the approach taken above. Here, an external IP is given to the service directly by you. With the approach above, you tell your load-balancer to do this.</p>
|
||||
<div class="highlight"><pre><span></span><code><span class="nn">---</span>
|
||||
<span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span>
|
||||
<span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Service</span>
|
||||
|
|
@ -2027,13 +2027,13 @@
|
|||
<li>requires you to specify the exposed IPs explicitly.</li>
|
||||
</ul>
|
||||
<h3 id="proxy-port-to-service"><a class="toclink" href="#proxy-port-to-service">Proxy port to Service</a></h3>
|
||||
<p>The <a href="https://github.com/kubernetes/contrib/tree/master/for-demos/proxy-to-service">proxy pod</a> helps to avoid the necessity of specifying external IPs explicitly. This comes at the cost of complexity; you must deploy a proxy pod on each <a href="https://kubernetes.io/docs/concepts/architecture/nodes">Node</a> you want to expose <code>docker-mailserver</code> on.</p>
|
||||
<p>The <a href="https://github.com/kubernetes/contrib/tree/master/for-demos/proxy-to-service">proxy pod</a> helps to avoid the necessity of specifying external IPs explicitly. This comes at the cost of complexity; you must deploy a proxy pod on each <a href="https://kubernetes.io/docs/concepts/architecture/nodes">Node</a> you want to expose DMS on.</p>
|
||||
<p>This approach</p>
|
||||
<ul>
|
||||
<li>does not preserve the real client IP, so SPF check of incoming mail will fail.</li>
|
||||
</ul>
|
||||
<h3 id="bind-to-concrete-node-and-use-host-network"><a class="toclink" href="#bind-to-concrete-node-and-use-host-network">Bind to concrete Node and use host network</a></h3>
|
||||
<p>One way to preserve the real client IP is to use <code>hostPort</code> and <code>hostNetwork: true</code>. This comes at the cost of availability; you can reach <code>docker-mailserver</code> from the outside world only via IPs of <a href="https://kubernetes.io/docs/concepts/architecture/nodes">Node</a> where <code>docker-mailserver</code> is deployed.</p>
|
||||
<p>One way to preserve the real client IP is to use <code>hostPort</code> and <code>hostNetwork: true</code>. This comes at the cost of availability; you can reach DMS from the outside world only via IPs of <a href="https://kubernetes.io/docs/concepts/architecture/nodes">Node</a> where DMS is deployed.</p>
|
||||
<div class="highlight"><pre><span></span><code><span class="nn">---</span>
|
||||
<span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">extensions/v1beta1</span>
|
||||
<span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Deployment</span>
|
||||
|
|
@ -2062,11 +2062,11 @@
|
|||
</code></pre></div>
|
||||
<p>With this approach,</p>
|
||||
<ul>
|
||||
<li>it is not possible to access <code>docker-mailserver</code> via other cluster Nodes, only via the Node <code>docker-mailserver</code> was deployed at.</li>
|
||||
<li>it is not possible to access DMS via other cluster Nodes, only via the Node DMS was deployed at.</li>
|
||||
<li>every Port within the Container is exposed on the Host side.</li>
|
||||
</ul>
|
||||
<h3 id="proxy-port-to-service-via-proxy-protocol"><a class="toclink" href="#proxy-port-to-service-via-proxy-protocol">Proxy Port to Service via PROXY Protocol</a></h3>
|
||||
<p>This way is ideologically the same as <a href="#proxy-port-to-service">using a proxy pod</a>, but instead of a separate proxy pod, you configure your ingress to proxy TCP traffic to the <code>docker-mailserver</code> pod using the PROXY protocol, which preserves the real client IP.</p>
|
||||
<p>This way is ideologically the same as <a href="#proxy-port-to-service">using a proxy pod</a>, but instead of a separate proxy pod, you configure your ingress to proxy TCP traffic to the DMS pod using the PROXY protocol, which preserves the real client IP.</p>
|
||||
<h4 id="configure-your-ingress"><a class="toclink" href="#configure-your-ingress">Configure your Ingress</a></h4>
|
||||
<p>With an <a href="https://kubernetes.github.io/ingress-nginx">NGINX ingress controller</a>, set <code>externalTrafficPolicy: Local</code> for its service, and add the following to the TCP services config map (as described <a href="https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services">here</a>):</p>
|
||||
<div class="highlight"><pre><span></span><code><span class="nt">25</span><span class="p">:</span><span class="w"> </span><span class="s">"mailserver/mailserver:25::PROXY"</span>
|
||||
|
|
@ -2135,7 +2135,7 @@
|
|||
</details>
|
||||
<p>With this approach,</p>
|
||||
<ul>
|
||||
<li>it is not possible to access <code>docker-mailserver</code> via cluster-DNS, as the PROXY protocol is required for incoming connections.</li>
|
||||
<li>it is not possible to access DMS via cluster-DNS, as the PROXY protocol is required for incoming connections.</li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1530,7 +1530,7 @@
|
|||
<span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ENABLE_FETCHMAIL=1</span>
|
||||
<span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">FETCHMAIL_POLL=300</span>
|
||||
</code></pre></div>
|
||||
<p>Generate a file called <code>fetchmail.cf</code> and place it in the <code>docker-data/dms/config/</code> folder. Your <code>docker-mailserver</code> folder should look like this example:</p>
|
||||
<p>Generate a file called <code>fetchmail.cf</code> and place it in the <code>docker-data/dms/config/</code> folder. Your DMS folder should look like this example:</p>
|
||||
<div class="highlight"><pre><span></span><code>├── docker-data/dms/config
|
||||
│ ├── dovecot.cf
|
||||
│ ├── fetchmail.cf
|
||||
|
|
|
|||
|
|
@ -1488,7 +1488,7 @@
|
|||
<h2 id="add-configuration"><a class="toclink" href="#add-configuration">Add Configuration</a></h2>
|
||||
<p>The Dovecot default configuration can easily be extended providing a <code>docker-data/dms/config/dovecot.cf</code> file.
|
||||
<a href="https://doc.dovecot.org/configuration_manual/">Dovecot documentation</a> remains the best place to find configuration options.</p>
|
||||
<p>Your <code>docker-mailserver</code> folder should look like this example:</p>
|
||||
<p>Your DMS folder structure should look like this example:</p>
|
||||
<div class="highlight"><pre><span></span><code>├── docker-data/dms/config
|
||||
│ ├── dovecot.cf
|
||||
│ ├── postfix-accounts.cf
|
||||
|
|
@ -1500,7 +1500,7 @@
|
|||
<div class="highlight"><pre><span></span><code><span class="na">mail_max_userip_connections</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">100</span>
|
||||
</code></pre></div>
|
||||
<p>Another important option is the <code>default_process_limit</code> (defaults to <code>100</code>). If high-security mode is enabled you'll need to make sure this count is higher than the maximum number of users that can be logged in simultaneously.</p>
|
||||
<p>This limit is quickly reached if users connect to the <code>docker-mailserver</code> with multiple end devices.</p>
|
||||
<p>This limit is quickly reached if users connect to DMS with multiple end devices.</p>
|
||||
<h2 id="override-configuration"><a class="toclink" href="#override-configuration">Override Configuration</a></h2>
|
||||
<p>For major configuration changes it’s best to override the dovecot configuration files. For each configuration file you want to override, add a list entry under the <code>volumes</code> key.</p>
|
||||
<div class="highlight"><pre><span></span><code><span class="nt">services</span><span class="p">:</span>
|
||||
|
|
@ -1521,7 +1521,7 @@ docker<span class="w"> </span>cp<span class="w"> </span>mailserver:/etc/dovecot/
|
|||
</ul>
|
||||
<div class="admonition note">
|
||||
<p class="admonition-title">Note</p>
|
||||
<p><a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/setup.sh"><code>setup.sh</code></a> is included in the <code>docker-mailserver</code> repository. Make sure to use the one matching your image version release.</p>
|
||||
<p><a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/setup.sh"><code>setup.sh</code></a> is included in the DMS repository. Make sure to use the one matching your image version release.</p>
|
||||
</div>
|
||||
<p>The file <code>docker-data/dms/config/dovecot.cf</code> is copied internally to <code>/etc/dovecot/local.conf</code>. To verify the file content, run:</p>
|
||||
<div class="highlight"><pre><span></span><code>docker<span class="w"> </span><span class="nb">exec</span><span class="w"> </span>-it<span class="w"> </span>mailserver<span class="w"> </span>cat<span class="w"> </span>/etc/dovecot/local.conf
|
||||
|
|
|
|||
|
|
@ -1408,7 +1408,7 @@
|
|||
|
||||
<h1>Modifications via Script</h1>
|
||||
|
||||
<p>If you'd like to change, patch or alter files or behavior of <code>docker-mailserver</code>, you can use a script.</p>
|
||||
<p>If you'd like to change, patch or alter files or behavior of DMS, you can use a script.</p>
|
||||
<p>In case you cloned this repository, you can copy the file <a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/config-examples/user-patches.sh"><code>user-patches.sh.dist</code> (<em>under <code>config/</code></em>)</a> with <code class="highlight">cp<span class="w"> </span>config/user-patches.sh.dist<span class="w"> </span>docker-data/dms/config/user-patches.sh</code> in order to create the <code>user-patches.sh</code> script.</p>
|
||||
<p>If you are managing your directory structure yourself, create a <code>docker-data/dms/config/</code> directory and add the <code>user-patches.sh</code> file yourself.</p>
|
||||
<div class="highlight"><pre><span></span><code><span class="c1"># 1. Either create the docker-data/dms/config/ directory yourself</span>
|
||||
|
|
|
|||
|
|
@ -1609,7 +1609,7 @@
|
|||
<p>Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux System.</p>
|
||||
<div class="admonition warning">
|
||||
<p class="admonition-title">About Support for Podman</p>
|
||||
<p>Please note that Podman <strong>is not</strong> officially supported as <code>docker-mailserver</code> is built and verified on top of the <em>Docker Engine</em>. This content is entirely community supported. If you find errors, please open an issue and provide a PR.</p>
|
||||
<p>Please note that Podman <strong>is not</strong> officially supported as DMS is built and verified on top of the <em>Docker Engine</em>. This content is entirely community supported. If you find errors, please open an issue and provide a PR.</p>
|
||||
</div>
|
||||
<div class="admonition warning">
|
||||
<p class="admonition-title">About this Guide</p>
|
||||
|
|
@ -1650,7 +1650,7 @@ systemctl<span class="w"> </span><span class="nb">enable</span><span class="w">
|
|||
<p>Also notice that Podman's rootless mode is not about running as a non-root user inside the container, but about the mapping of (normal, non-root) host users to root inside the container.</p>
|
||||
<div class="admonition warning">
|
||||
<p class="admonition-title">Warning</p>
|
||||
<p>In order to make rootless <code>docker-mailserver</code> work we must modify some settings in the Linux system, it requires some basic linux server knowledge so don't follow this guide if you not sure what this guide is talking about. Podman rootfull mode and Docker are still good and security enough for normal daily usage.</p>
|
||||
<p>In order to make rootless DMS work we must modify some settings in the Linux system, it requires some basic linux server knowledge so don't follow this guide if you not sure what this guide is talking about. Podman rootfull mode and Docker are still good and security enough for normal daily usage.</p>
|
||||
</div>
|
||||
<p>First, enable <code>podman.socket</code> in systemd's userspace with a non-root user.</p>
|
||||
<div class="highlight"><pre><span></span><code>systemctl<span class="w"> </span><span class="nb">enable</span><span class="w"> </span>--now<span class="w"> </span>--user<span class="w"> </span>podman.socket
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue