something is wrong with setup #85
Comments
|
|
Hmm, don't you consider that the API version issue might be the cause for these kind of problems? If not: check the logs of the stopped containers. Edit: I just moved from travis-ci to github actions. All integration tests are still running fine. |
|
Thank you. Ok, never did travis, something to learn. How could the API version interfere here? I noticed you updated the images a week ago. So I work with new images now. How can I test with the old images? Will check the logs ASAP. |
|
Travis is nothing you need to learn for now, but it runs docker-mailserver on a clean system on every code change and tests it in various ways. |
|
downgrading
|
|
Hello, maybe I found something. To begin with, I made sure that no container is running. Then I started mailserver with
When all containers were running, error messages were produced abundantly. There are 3 containers producing these error messages: They keep repeating over and over until the corresponding container gives up. Now what does this mean? I interpret these error messages as protocols of attempting to spawn a contact between this container and another one. For example, If I remember correctly, this was the way to talk to containers in the stone age of docker. Since several years now, containers talk to each other by their name. Why do we have this problem in the first place? Who is trying to contact another container the old way? In order to understand this error message better, I wrote a little shell script. One question here is, for example, which container runs on IP The next question is, can
For the record:
If I call this script soon enough, all containers are still running. The result is: After installing This shows that all containers can see each other, assuming the Please tell me if I am right in my analysis and what I can do to fix these things. |
|
Each service is checking the availablility of other services before starting, thats right. This is done via the application Dockerize. Can you explain why the names of db, mda, mta and filter resolve to the same public ip address in the above example? -> 217.160.241.84 I think that this is not the right place to solve your Kubernetes/Docker Swam/... issues and I would kindly ask you to try this in a different place. |
|
.. but to say something useful and just to be complete: Sorry for acting angrily, but it makes me crazy to see your whole environment changing everytime you post here ;P |
|
I've improved the startup time of the virus service. This should make your tests easier, so make sure that you have the latest image version. |
|
First I'd like to state that I appreciate your work very much, the more so as in the meantime I studied quite a number of other systems and didn't succeed with them either. Furthermore I learned that any complete mail system is quite complicated and definitely nothing to be done easily. Also I appreciate your time and effort trying to help me very much. Nevertheless, if you don't care anymore, it's okay with me. For the record and for others tapping into this problem, I will continue, though, until I find a solution or give up. Talking to myself does help, too. I'd like to see the first success I had when I installed your system the first time without problems, but I can't. I don't understand why this is so. A docker system should work out-of-the-box every time. Now it looks like it works on |
|
On
Why? Obviously I have to change the A record of I was surprised I could add a domain -- so I will see in a while if I can skip setting up a separate mailserver on Still the question remains why I'm sorry that I confused you with my reports. Let me explain. I started out with a server named As I ran into problems when struggling with POP3 and SMTP and as the overall setup of On this machine, I experienced the same problems, however.
Good catch. This is the IP of my 2nd virtual server At the time when I posted this I wasn't aware of this problem, however. As I did the same with
This is probably due to different experimental series. Docker picks random ranges (192.-, 172.-). Thank you for the advice. I had a look at this address. If it only took 2 minutes, it wouldn't be a problem, but it keeps on trying until the system gives up. So I thought it might a good idea to present you the whole output of the startup procedure. Please tell me if that is okay with you. I'd like to debug this, but I don't know where to begin. As I proved to you, all the containers can ping each other, but still connection problems are reported. I found something interesting at timeout and wait-retry-interval not working
Unfortunately, I don't know what to do with this. In the other thread, I told you that I was struggling with the proxy to handle TLS and the client IP to be passed through to the docker zoo. In the meantime I have understood the problem and found a solution, so both machines work flawlessly except they need a mail system.
Actually the nginx proxy runs alone as a single container on both macheines (and not in swarm mode) and communicates with the rest of the band via external network. In this scenario, docker-mailserver would constitute another group of containers to be connected to from the proxy. I'll have to study your instructions for a proxy server. I think that once I get docker-mailserver to run on one system, I will be able to do it on the other as well. For the record: On Different picture at There is an obvious difference in the startup sequence, Both
Both are fresh cloned. There is enough space on both:
|
|
|
I begin to understand what's happening on On both machines, Also, I'm told, browsers should be instructed to never use a connection without TLS, which is preventing to use docker-mailserver on port 81 without TLS. My first workaround was to introduce a separate FQDN running without TLS which would be served by docker-mailserver, and it works, but that doesn't feel right. Next I tried I already do have an NGINX proxy This works, but in order for the proxy to be able to see the container web, this container must be exposed to that network. And here we have it (from
Mind you, this is the IP of the machine the whole stuff runs on, Of course, How come? How could a simple have this consequence? I introduced a second external network Then I removed What makes Actually, I made protocols to be able to inspect later and found 2 entries with the host IP from the workaround with the additional FQDN: This did not lead to problems, though. So even in regular use, this call to port For POP and SMTP, I suspect that the configuration of
|
|
So, in retrospect, the problems started when I introduced a network on |
|
I was in the process of describing the error conditions on Imagine my surprise! I took this system down with I could reproduce this twice, then no more for half a dozen trials, then again ok. How can I debug this? Next I opened port 81 on Now there was something dubious with my setup. I used the same FQDN on both accounts, I deleted the domain for the duplicate domain and added the new FQDN, added users, sent emails, worked. Great. So far so good. If it works, it works. If it doesn't -- I don't know why. How can I find out? Looking at the logs, we have the same error messages of type Checking all those containers with Do you have an idea what could be causing this? To me, this looks like a timing error. If I understood correctly, you added waiting states using dockerize. Where would I manipulate these? I guess I should enlarge the wait interval. As far as I can see it the retrial interval is pretty short, the log is filled with error messages. It looks like every second it is firing. Would it be promising to enlarge this interval? I don't think that this interval is given by dockerize, rather by the logic of the container. Where to look for? Are there any parameters to be set? By the way, I got my testing FQDNs via Thinking about it, I could live with this workaround forever. On the other hand, I'd really like to know why adding a network to Interesting: I tried to get a letsenscrypt certificate for the |
|
I think, I managed to develop an acceptable workaround. IONOS_1On this machine, I can bring up the system, although most of the time it would take a lot of retries. I don't know why this is so, but as I found out that I can serve all my FQDNs from In order to ease this tedious procedure, I finally wrote two shell scripts,
to see the result and then repeatedly call I put these to On
And if I try often enough, it works. Really enigmatic.
I changed IONOS_2The situation is different on this machine. As a rule, the system will start. But sometimes
This trick worked every time. So finally I was confident that I could bring up docker-mailserver on On the mail manager system, I installed 2 domains and appropriate users. I could send e-mails from those domains to other e-mail addresses I own, but I could not receive e-mails to these addresses. Also, I wanted to use Thunderbird, which was the begin of all the trouble. I couldn't understand why I was able to do so the day before, as I documented here. The solution to this enigma was quite simple, but I had a hard time to find out. The successful tests I had performed were e-mails sent from the webmail interface to both of the domains. I obviously didn't test to send e-mails from other, foreign addresses like Google Mail. In one of my tests the days before, I received an error message from GMX with instructions of how to get more information about the rejection. One of the services to ask was https://mxtoolbox.com/SuperTool.aspx?action=smtp%3avoxx.biz&run=toolpage I luckily remembered this and found that something was not as it should be: I had a This was really enigmatic. Googling told me that the Finally I called the support of IONOS and they told me that I not only could set up the My intuition told me that the Okay, I had already set up an A record And then came the surprise: all the e-mails which couldn't have been delivered during the last 2 days all came in in a rush for both domains. ThunderbirdThe problem with Thunderbird was solved yesterday, but because of the delivery problem, I couldn't really appreciate it. I noticed during my testing, that one of the foreign addresses reacted immediately in Thunderbird, whereas others took their time unless I manually downloaded new e-mails. Inspecting the differences, I noticed that the latter were So I learned that it is not easy to transform a Setting up a new account in Thunderbird, you can choose between That completes the whole setup. Calling the hostThe error of form reported above can be produced in 2 ways, adding a network being one. Looking at
How come that I guess the problem lies here, But this definitely does not fall into the realm of |
|
There is one more remark: Thunderbird does not accept the security certificate.
Therefore I have to store an exception. As I have a letsencrypt certificate for the main domain, maybe I somehow could manage that Thunderbird would get and accept this, but I don't know yet if I will take the pain to research this. |
|
Another addendum to make things clear for anybody who runs into the same situation as I did: Where to put which domain name?In my humble attempt to mediate between the need for In the admin interface of Now the question arises which information has been put where to make things work. So far I was experimenting and found out that the following seems to work well:
The last mistake I made was to change This kind of error happened to lots of people (e.g. postfix virtualdomain - message bouncing - unknown user error in maillog), so I quickly found the reason and changed the line Duplicate Thunderbird accountsInterestingly, I now have duplicated accounts for those 2 domains on Thunderbird, each of The reason must be that One of those accounts is very old and has lots of data, the other is new and has very few data. So this one is the perfect candidate to find out how to get rid of a Thunderbird account without losing data. With drag-and-drop I moved the inbox messages from the For the other one I have to think about another method. As far as I know Thunderbird manages data simply in directories, so that might be easier to do. Last thoughtMaybe my attempt to get rid of the security complaint was flawed. There may be a configuration which does the right thing like it should, but at the moment I am exhausted and satisfied so far. It works as it should and those quirks don't really annoying me. |
Describe the bug
A clear and concise description of what the bug is.
After hours of trial and error I decided to refresh my system and start fresh once more. But there it is, the error I see for days now, so it can be reproduced.
To Reproduce
Steps to reproduce the behavior:
see above
Expected behavior
A clear and concise description of what you expected to happen.
I witnessed a successful installation before, so I know what to expect.
Screenshots
If applicable, add screenshots to help explain your problem.
Docker environment (please complete the following information):
docker infosee below...
docker-compose versionNo way to find an explanation for this "Error response from daemon". I had this before when I did my first refresh, and had then found a simple downgrade instruction, but could not find it today.
Instead I found kubernetes-sigs/kubespray#6160 with a trick:
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: