I have AWS instance with mailinabox installed, running without any issues for past 3 years. CloudFlare is used for name servers and contains glue (A) records.
Had to do instance reboot from AWS, and after reboot it has new IP assigned.
I have updated glue records.
I can access box.domainname.com/admin without any issues, can send and receive emails using both webmail and mail apps.
However, admin status check still shows old IP, saying SSH is running but not accessible at ip:22.
I’ve waited for more than 24h now, SSH into server, ran ‘sudo mailinabox’ multiple times but it still gets the old IP address.
Now, aside from annoying message in admin status check, I don’t see any real issues. But would still prefer not to see all that ‘red’ in the status.
Anyone has any experience what to do if mailinabox does not get updated IP at all? Not sure what can cause this though, never had such issue with IP change before as I’ve setup multiple mailinabox servers for my clients in the past.
I kept lower cost, as Elastic IP is an additional $. I’d expect though I can reboot, update glue records and should be able to function further properly, without much additional work. I’m still trying to figure out from where old IP address reading comes from…
If you have it attached to a running instance you won’t be charged. It only charges when an instance is stopped/terminated, or the elastic IP is unattached.
Something worth looking in to if you need to restart or migrate again.
NIce find! I was not aware of /etc/mailinabofx.conf!
This contains old IP address, and old private IP address. I’ve just updated it to new ones and now when I re-run sudo mailinabox it does the update properly! No more errors reported in /admin!
There should be a notice somewhere to manually update IP addresses in this .conf file - I haven’t seen this in any online documentation.
True but also generates additional cost. @KiekerJan tip on the /etc/mailinabox.conf file solved the problem. I just manually updated IP in the config file, ran sudo mailinabox and it updated itself correctly, removing all errors in admin caused by new IP / old IP issue.
No, there should not be as this file normally updates perfectly well automatically … except when sub-prime providers such as AWS are being used. To be honest though, this is the first time I have encountered anyone having this issue.
It may generate extra cost – that is the price to be paid for using that particular provider as there are literally 100’s of providers in the world to choose from. But then again … it does not generate extra cost - only when it is idle do you pay extra for it.
This project is not designed for scenario’s where the IP address constantly changes. Why create such an extra hassle for yourself?
Well, having a notice “those who use AWS, in case you experience …” would suffice. No need to develop anything further. It’s not for “constant IP changes”, just when IP does change, in this case with AWS, to give your users a notice that they can manually update IP info in mailinabox.conf file, if they encounter issue with it.
Sure this would be nice, but then we’d need a notice for
Contabo
MS Azure
Bradler & Krantz
Time4VPS
…
Surely you can see where this is going … that is an unreasonable request, which is why Mail-in-a-Box is so dead set on not supporting “Unsupported Modifications”, as you support one, you need to support the next to be fair, and it snowballs from there. I hope you can appreciate what I mean?
I guess then your users will be searching discourse for solution to find this discussion for information about /etc/mailinabox.conf and how to manually update IP address if it fails to fetches new one automatically.
Seems to me there’s a potential bug in mailinabox setup, rather than being issue with AWS. If it is an issue with AWS, many different platforms, and application frameworks, that depend on the IP address, would have issues as well. I think it is worth looking into the issue to see what went wrong for real, and not just automatically blaming it on AWS.
In my opinion, if IP changes, but mailinabox still sees the old IP and fails to update config with new one, that is an issue. Not a major one, as users can manually update .conf file after IP changes.
Using Elastic IP should not be mandatory in my opinion. Can be mentioned in docs as “recommended”, but it does not seem to me as something a must-have. I wonder how then it would work with multiple server instances behind load balancer, which is in my opinion an important feature for a software to be used for larger corporations.
It should be in MailInABox interest to be able to work in such environments, in order to ensure larger businesses will consider using it - this will ensure longevity of this project, which has, for small biz like my own, became essential for both my own company needs as well as my clients.
The one thing that I do not see mentioned anywhere in this thread is that you ran the mailinabox command, which is the command to be run to update the box when the server IP changes, among other things. Did you ever execute this?
Users are not to be expected to update this conf file manually. This is the job of running the mailinabox command as mentioned above.
@sinisa: Mentioning that boxes should have static IP addresses is something that makes sense in our setup guide. I agree with @alento that intentionally changing IP addresses is likely to cause a lot of headaches in general, but it can happen, and some documentation about how to resolve it would also be fine in the appropriate place. That said, you’ll have to be the one to open a pull request on the project’s github repository to make those changes.
