register hangs. about appwrite

[eldadfux]

Hi @macdougall, Does the server returns any status code? if yes please paste the response headers and body here.
Will also be useful if you could paste your containers status using 'docker ps' command.

[macdougall]

No status codes returned. But my containers are running in the background so I'd have to run a log off the docker command to check that. Here's my running containers:

9c95b787db07        redis:5.0                 "docker-entrypoint.s…"   2 hours ago         Up 2 hours             6379/tcp                                     appwrite-ce_redis_1
8eb287e7a922        appwrite/mariadb:1.0.0    "docker-entrypoint.s…"   2 hours ago         Up 2 hours             0.0.0.0:3306->3306/tcp                       appwrite-ce_mariadb_1
6be16643c81c        appwrite/appwrite         "/bin/bash /entrypoi…"   2 hours ago         Up 2 hours             0.0.0.0:80->80/tcp                           appwrite-ce_appwrite_1
f75962e2a972        influxdb:1.6              "/entrypoint.sh infl…"   2 hours ago         Up 2 hours             0.0.0.0:8086->8086/tcp                       appwrite-ce_influxdb_1
33c7de3da80f        appwrite/telegraf:1.0.0   "/entrypoint.sh tele…"   2 hours ago         Up 2 hours             8092/udp, 8094/tcp, 0.0.0.0:8125->8125/udp   appwrite-ce_telegraf_1
dfdd5870ef82        appwrite/clamav:1.0.4     "/bin/bash /entrypoi…"   2 hours ago         Up 2 hours (healthy)   3310/tcp                                     appwrite-ce_clamav_1
d772cdc59737        appwrite/smtp:1.0.0       "/bin/entrypoint.sh …"   2 hours ago         Up 2 hours             0.0.0.0:25->25/tcp                           appwrite-ce_smtp_1

[eldadfux]

Everything does seems to be running well, To try and figure whats going on I need more data. Can you try and paste some logs for both appwrite and mariadb conatiners?

Another thing that might help is to debug the nginx error log inside the appwrite container.
To get it, just run:
docker exec -it 6be16643c81c bash

and in the conatiner run:
cat /var/log/nginx/error.log

[macdougall]

I have nothing in those log files. In fact, they are empty.

root@6be16643c81c:/var/log/nginx# ls -alt
total 8
drwxr-xr-x 1 root root 4096 Sep 2 16:13 ..
drwxr-xr-x 1 root adm 4096 Aug 24 09:13 .
-rw-r----- 1 www-data adm 0 Aug 24 09:13 access.log
-rw-r----- 1 www-data adm 0 Aug 24 09:13 error.log
root@6be16643c81c:/var/log/nginx# cat error.log
root@6be16643c81c:/var/log/nginx#

[eldadfux]

This is becoming really hard to debug, do you still have access to http://localhost?

The server stop responding only after form submission?

Maybe try to remove all containers using 'docker-compose down' and then delete the appwrite-ce directory and run setup script again. Let me know if you have any lead.

[macdougall]

I think the SMTP server is hanging.

mtp_1 | 273 LOG: MAIN REJECT
smtp_1 | 273 H=appwrite-ce_appwrite_1.appwrite-ce_default (localhost.localdomain) [192.168.32.2] F=[email protected] rejected RCPT : relay not permitted
smtp_1 | 273 LOG: smtp_connection MAIN
smtp_1 | 273 SMTP connection from appwrite-ce_appwrite_1.appwrite-ce_default (localhost.localdomain) [192.168.32.2] closed by QUIT
influxdb_1 | [httpd] 192.168.32.6 - - [02/Sep/2019:19:22:30 +0000] "POST /write?db=telegraf HTTP/1.1" 204 0 "-" "telegraf" 01b83d15-cdb7-11e9-8003-000000000000 2891

[eldadfux]

This is a known issue where Gmail and other email providers reject messages sent from an ISP IP address. Anyway the Appwrite API ignores this type of errors and they do not cause any problem when using the stack on a dev environment.

Anyway if you have any indication that this might be the problem, you can edit the docker-compose file and change to your own 3rd party SMTP server using this vars:

    - _APP_SMTP_HOST=smtp.example.com
    - _APP_SMTP_PORT=587
    - _APP_SMTP_SECURE=tls
    - _APP_SMTP_USERNAME=your_emal
    - _APP_SMTP_PASSWORD=your_password

[macdougall]

Ok, I'll look at that but I think you should consider using something like https://mailcatcher.me/

This will catch smtp messages so you're not having to configure a dev. server for production emails.

[eldadfux]

@macdougall that might be a really good idea, I will definitely take a closer look at it.

[macdougall]

This will remove the idea of having to configure an SMTP server. I've used it in several projects and it's helpful because you'll never have to have to explain the issue -- the only thing a person will need to do is to configure the email server for production and remove mailcatcher.

[macdougall]

I did a clone on the repo, I can't get this to build locally. Is there anything I need to do?

Running a "docker-compose build", I'm getting the following error:

Step 35/38 : ADD ./vendor /usr/share/nginx/html/vendor
ERROR: Service 'appwrite' failed to build: ADD failed: stat /var/lib/docker/tmp/docker-builder903152574/vendor: no such file or directory

What are the projects requirements, maybe my local Mac doesn't have the right dependencies setup?

[eldadfux]

To run locally:

composer update --ignore-platform-reqs --optimize-autoloader --no-dev --no-plugins --no-scripts --prefer-dist

docker-compose up -d

[eldadfux]

You will need php package manager composer to set it up: https://getcomposer.org/

[eldadfux]

This will remove the idea of having to configure an SMTP server. I've used it in several projects and it's helpful because you'll never have to have to explain the issue -- the only thing a person will need to do is to configure the email server for production and remove mailcatcher.

After giving some thought to this idea, I am worried this might be an anti-pattern for a microservice and containers based architecture, can mailcatcher run as a standalone container? maybe something like a mock SMTP server?

Otherwise, It might be best to just cancel the mail sending at all when not running in production.

[macdougall]

This will remove the idea of having to configure an SMTP server. I've used it in several projects and it's helpful because you'll never have to have to explain the issue -- the only thing a person will need to do is to configure the email server for production and remove mailcatcher.

After giving some thought to this idea, I am worried this might be an anti-pattern for a microservice and containers based architecture, can mailcatcher run as a standalone container? maybe something like a mock SMTP server?

Otherwise, It might be best to just cancel the mail sending at all when not running in production.

Mailcatcher runs as a microservice. In fact, it's following the pattern of a microservice. Here's what I have in my docker-compose.yml for a project i'm working on:

mailcatcher:
image: schickling/mailcatcher
ports:
- 1080:1080
- 2025:1025

[macdougall]

You will need php package manager composer to set it up: https://getcomposer.org/

I missed that. Thanks...this seems to have solved the build issue.

Hit close by accident.

[macdougall]

I have a PR with mailcatcher added to the docker-compose.yml, if you want I can contribute to this. ;-) I've tested it and it works.

[eldadfux]

This could be a very good solution. We are still in a dilemma about how to make the installation process as easy as possible, but also allowing a smooth switch to production environment with a working mail server.

The whole SMTP thing is a big issue in the process, because we want to allow users with the options to easily use the 'appwrite native' SMTP container in production but also enabling a switch to 3rd-party provider very easily.

Anyway I will keep the mailcatcher idea in mind when we have a decision as this could be a good solution for the dev environment part.

Regarding the open issue, have you managed to overcome the problems?

[macdougall]

This could be a very good solution. We are still in a dilemma about how to make the installation process as easy as possible, but also allowing a smooth switch to production environment with a working mail server.

The whole SMTP thing is a big issue in the process, because we want to allow users with the options to easily use the 'appwrite native' SMTP container in production but also enabling a switch to 3rd-party provider very easily.

Anyway I will keep the mailcatcher idea in mind when we have a decision as this could be a good solution for the dev environment part.

Regarding the open issue, have you managed to overcome the problems?

I worked around my issues once I installed MailCatcher as a service and built from the repo.

[eldadfux]

Improving SMTP integration across env's issue has been added to the roadmap with a reference to this page. Closing this issue because problem seems to have a workaround.