Mailpiler - self hosted email archive
-
@marcusquinn I'd be interested, if I can help
-
Mailpiler app for cloudron is here, built based on the original docker configuration.
https://git.cloudron.io/vladimir.d/mailpilerComments are very welcome.
-
@jsuto You still with us? Want to give this a spin?
I have a couple of questions on the app, shall we discuss in the open here for the benefit of the community that I'm sure will enjoy championing this addition from your great work for you.
-
@marcusquinn open please
-
@vladimir-d Feedback :
I tried building the app from the git address
I got error as below=> ERROR [ 6/10] ADD config/nginx /app/data/nginx 0.0s ------ > [ 6/10] ADD config/nginx /app/data/nginx: ------ failed to compute cache key: "/config/nginx" not found: not found
I fixed this by creating a directory 'nginx' in 'mailpiler-master/conf' and copied the 'nginx.conf from its location couple layers below
Building then continued correctly.
Other errors found which I am investigating -
@vladimir-d Feedback on building :
After sorting out nginx.conf location, there is long list of building information until :#5 86.05 dpkg: error processing archive piler_1.3.11-focal-5c2ceb1_amd64.deb (--install): #5 86.05 package architecture (amd64) does not match system (arm64) #5 86.05 Errors were encountered while processing: #5 86.05 piler_1.3.11-focal-5c2ceb1_amd64.deb ------ executor failed running [/bin/sh -c apt-get update && apt-get -y --no-install-recommends install wget openssl sysstat php7.4-cli php7.4-cgi php7.4-mysql php7.4-fpm php7.4-zip php7.4-ldap php7.4-gd php7.4-curl php7.4-xml php7.4-memcached catdoc unrtf poppler-utils nginx tnef sudo libzip5 libtre5 cron libmariadb-dev mariadb-client-core-10.3 python3 python3-mysqldb ca-certificates curl crudini vim net-tools supervisor memcached && apt-get clean && rm -rf /var/lib/apt/lists/* && wget --no-check-certificate -q -O ${SPHINX_BIN_TARGZ} ${DOWNLOAD_URL}/generic-local/${SPHINX_BIN_TARGZ} && tar zxvf ${SPHINX_BIN_TARGZ} && sed -i '/session required pam_loginuid.so/c\#session required pam_loginuid.so' /etc/pam.d/cron && wget --no-check-certificate -q -O ${PACKAGE} https://bitbucket.org/jsuto/piler/downloads/${PACKAGE} && dpkg -i ${PACKAGE} && ln -sf /etc/piler/piler-nginx.conf /etc/nginx/sites-enabled/ && rm -f ${PACKAGE} ${SPHINX_BIN_TARGZ} /etc/nginx/sites-enabled/default /etc/piler/piler.key /etc/piler/piler.pem /etc/piler/config-site.php]: exit code: 1
I can't see what is wrong but will continue looking.
With such long combined commands ("&&"), it is difficult to identify on which command it is failing.Oh, BTW, I am building locally on a Mac Big Sur and using my docker registry.
But didn't get as far as pushing it there yet. -
I edited the Dockerfile to split the original multiple command line (#14) into multiple RUN lines to identify clearly where is the problem.
Seems like it is :=> ERROR [ 9/19] RUN dpkg -i piler_1.3.11-focal-5c2ceb1_amd64.deb 0.2s ------ > [ 9/19] RUN dpkg -i piler_1.3.11-focal-5c2ceb1_amd64.deb: #13 0.222 dpkg: error processing archive piler_1.3.11-focal-5c2ceb1_amd64.deb (--install): #13 0.222 package architecture (amd64) does not match system (arm64) #13 0.226 Errors were encountered while processing: #13 0.226 piler_1.3.11-focal-5c2ceb1_amd64.deb ------ executor failed running [/bin/sh -c dpkg -i ${PACKAGE}]: exit code: 1
Not sure what to do here. Will have to think.
Although I guess it has to be this on line #9PACKAGE="piler_1.3.11-focal-5c2ceb1_amd64.deb" \
-
Ah. Thinks.
Building this on Mac Big Sur running on Mac Mini with new Apple chip (not Intel)
Is that the cause of the architecture issue ? -
Using the following seems to get past the platform architecture issue :
Only needed perhaps if building on Mac with Apple chipdocker buildx build --platform linux/amd64 -f Dockerfile --no-cache . -t <reponame>/mailpiler:cloudron-<date>
-
Build process failed (for me) on this line in #nginx section
ln -sf /etc/piler/piler-nginx.conf /etc/nginx/sites-enabled/
But i noticed preceding similar command succeeded
ln -s /app/data/nginx/conf/sites-enabled /etc/nginx/sites-enabled
So I amended problem line by removing the trailing "/"
That build process now runs to completion.I hope people don't mind the segregated comments and 'running commentary'. Personally I find it easier to track problems and solutions.
-
Successfully built and pushed to repository (docker in my case).
App installed on Cloudron w/o hassle .... but hangs in 'starting' mode.
So I uninstalled and triedcloudron install --image <repo>/<image>:<tag>
without the --no-wait option.
This installs but similarly gets stuck=> Wait for health check ........................................................................................................................................................................................................................................................................................................................................................^C
Out of my depth now. What to check / amend ?
-
Blundering around in the dark, but I notice that
start.sh
has on line 53local SSL_CERT_DATA="/C=US/ST=Denial/L=Springfield/O=Dis/CN=www.example.com"
Should this not reference the Cloudron variable for location ?
-
@marcusquinn @vladimir-d what is the status of the app package?
-
@timconsidine I've updated
Dockerfile
to fix all building issues you faced with. After that everything went just fine on a fresh cloned copy.@timconsidine said in Mailpiler - self hosted email archive:
Blundering around in the dark, but I notice that
start.sh
has on line 53local SSL_CERT_DATA="/C=US/ST=Denial/L=Springfield/O=Dis/CN=www.example.com"
Should this not reference the Cloudron variable for location ?
When
tls
add-on is enabled in the manifest, the script doesn't generate a self signed certificate and uses the Cloudron certificate of the primary domain. I've amended it to use$CLOUDRON_APP_DOMAIN
variable.@timconsidine said in Mailpiler - self hosted email archive:
Successfully built and pushed to repository (docker in my case).
App installed on Cloudron w/o hassle .... but hangs in 'starting' mode.
So I uninstalled and triedcloudron install --image <repo>/<image>:<tag>
without the --no-wait option.
This installs but similarly gets stuck=> Wait for health check ............................^C
Out of my depth now. What to check / amend ?
It doesn't get stuck for me - I've tried to build&install the app with the recent changes.
I guess there is an issue with
piler
ornginx
directories in /etc/, probably a wrong path or an invalid symlink or so.
You need to look at the app logs to see the issue.
-
@vladimir-d thank you !
I will give it another go in the morning. -
@girish It needs to expose 25 port for
piler-smtp
daemon. it says 25 (and other smtp ports) are reserved.
For now I've addedtcpPorts
field toCloudronmanifest.json
and exposed it as12525
but I guess it won't properly work in most cases.
Is there a workaround to expose 25 port for the app? -
@vladimir-d Oh, interesting. Don't think an app can ever expose port 25 since the mail server requires port 25. Do you know why it requires port 25? Maybe I don't understand how the archiver works. I though it's pulling in all email via IMAP? Or is it that we should redirect all mail to mailpiler?
-
@girish According to my understanding of a mail archive solution, every incoming and outgoing mail must be forwarded to the archive solution. This is the only way to fulfil the requirements of the law. https://en.wikipedia.org/wiki/Email_archiving
The mailpiler docs tells us:
Postfix
Add the following to main.cf then issue the postfix reload command:always_bcc = uuid@smtp.example.com
For historical mails there is the import option
https://docs.google.com/document/d/15F0fyb07etMqEXRJnMZcYc016UN-WDds-6zrZNjF6aU/edit#heading=h.58uixy8guf9yhttps://docs.google.com/document/d/1YK7zVbcohFWf2w8BpYhCcsAY6Q61JKXa8pqUDrU7nn4/edit#
Both docs are for the enterprise edition. But the oss edition has similar docs.
https://www.mailpiler.org/wiki/current:installation -
@luckow this makes sense ... except I don't understand why an archive solution would need SMTP for sending. It just needs its own incoming email capability, and the
always_bcc
means it will get a copy of all inbound and outbound emails from the primary 'working' email server.
But maybe (as is often the case) I am not understanding the full picture.