************QUOTE FROM THE IREDMAIL WEBSITE****************************
On Debian/Ubuntu Linux, hostname is set in two files: /etc/hostname and /etc/hosts.
/etc/hostname: short hostname, not FQDN.
mx
/etc/hosts: static table lookup for hostnames. Warning: Please list the FQDN hostname as first item.
# Part of file: /etc/hosts 127.0.0.1 mx.example.com mx localhost localhost.localdomain
************************** END QUOTE **********************************************'
INSTALL ATTEMT NR 1 (with above settings in files host and hostname, of course replaced domain with my own REAL domain)
When installing Booktype (automated install), after having installed Iredmail, I wanted Booktype to use only the example.com part of the domain, so the visitors can reach it only typing http://example.com In the automated install configuration wizard I then only type in "example.com" (without the "mx" subdomain part of the url)
This gives errors during installation, and it looked to me it was some databaseengine that could not handle it, maybe something that has to do with the export book functionality (as this is where the problem shows up in the final installation) I am sorry I did not copy the consol log at this time.
INSTALL ATTEMPT NR 2:
I then started all over again, this time installing Booktype first, with the default settings in /etc/hostname and /etc/hosts. Installation went fine, Booktype working well, and the export book works without problems.
After modifying those two files and rebooting the server, I then went into Booktype installation web interface and tried to do a book export.
It did not work any longer.
This is from the booktype error log:
[23/Apr/2016 12:37:24] ERROR [booktype:43] Could not load JSON data. Traceback (most recent call last): File "/var/lib/booktype/lib/booktype/utils/download.py", line 41, in fetch_url dta = req.json() File "/var/lib/booktype/local/lib/python2.7/site-packages/requests/models.py", line 805, in json return complexjson.loads(self.text, **kwargs) File "/usr/lib/python2.7/json/__init__.py", line 338, in loads return _default_decoder.decode(s) File "/usr/lib/python2.7/json/decoder.py", line 366, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/lib/python2.7/json/decoder.py", line 384, in raw_decode raise ValueError("No JSON object could be decoded") ValueError: No JSON object could be decoded [23/Apr/2016 12:37:24] ERROR [booktype:102] Could not fetch the book from [http://example.com/_convert/]
(In the last line in the above log exerpt I have replaced my real domain with the example.com domain)
Anyone have any idea what is the problem? And how can I fix this, so IredMail can have it's wanted subdomain (mx.example.com), and Booktype and all its stuff (export book) can work using the root domain only (example.com)?
is a special line which represents the localhost, i.e. the system's loopback address for itself. There would not normally be 'example.com' or any FQDN on this line for a Debian/Ubuntu system.
This file only needs static entries for server addresses if they are not in DNS. Typically, these static entries are for a test server, either on the same machine (127.0.1.1 not 127.0.0.1 on Debian/Ubuntu, please see https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution) or a machine on the LAN (for example 192.168.1.x) like so:
As this file is only on your local server, the intended visitors cannot access it. So if you want other people to reach your Booktype instance, you need to set up a DNS record for the IP address of your Booktype instance, and then you will not need any entry for it in the server's /etc/hosts file.
Cheers!
Daniel
Post edited by Daniel James at 2016-04-25 05:30:35
The challenge comes when trying to run Booktype and iRedMail on the same computer. iRedMail seems to demand the following setup in /etc/hosts and /etc/hostname
# /etc/hosts 127.0.0.1 mx.example.com mx localhost localhost.localdomain ("mx" can be replaced by any name you chose, example "mail")
#/etc/hostname mx (you can chose whatever you want for this name, but it must be the same in hosts and hostname file)
Reason for this is: If you want to create emailadresses using the ROOT domain example.com, example admin@example.com, then you can NOT use the rootdomain during iRedMail setup. You then have to setup iRedMail with an initial address that uses a subdomain in the hostname configuraton. So if you setup iRedMail with a hostname -f that outputs mx.example.com, then you will be able to create an initial admin account using only the rootdomain e.g. postmaster@example.com. On the other hand, if you set up iRedMail with a hostname -f configuration that only outputs example.com, then you will NOT be able to coose example.com as the initial setup.
If I setup iRedMail the way it is suggested by iRedMail install HOWTO, and then install Booktype, the installation will fail. In order to be able to install Booktype, I will have to modify the /etc/hostname to include the rootdomain: 127.0.0.1 mx.example.com mx example.com localhost localhost.localdomain
Only then will Booktype complete the installation without error.
The same problem occures if the order of installation is opposite, that you have Booktype installed first, and then want to install iRedMail. If you have Booktype working on the rootdomain example.com, and want your emailaddresses to look like postmaster@example.com or admin@example.com, then you must edit your hostfiles (/etc/hostname and /etc/hosts) so that iRedMail is installed in a subdomain type of configuration.
As soon as you do this change, and do it as iRedMail install HOWTO suggest, then your existing booktype installation export book functionality will stop working.
It will work again if you then add example.com to your /etc/hostname like this: 127.0.0.1 mx.example.com mx example.com localhost localhost.localdomain
You can try this yourself. You don't even have to install iRedMail to try it. Just set up your hosts and hostname files as iRedMail install HOWTO suggest, and then try to install Booktype and configure it to use the rootdomain example.com (not mx.example.com or booktype1.example.com or booktype2.example.com, have it use rootdomain only). If you try this on a new installation the installation will fail.
If you try this on an existing Booktype installation (in order to prepear for an iRedMail installation), your existing Booktype export functionality will stop working).
BUT this is not the main reason I have given up on having Booktype and iRedMail work on the same server. The reason is, that even if I modify the /etc/hosts and /etc/hostname files so both iRedMail and Booktype configuration requirements are met, then when actually installing both on the same server will create a 500 internal server error when visiting the rootdomain example.com (which should point to the Booktype installation, while pointing to exmple.com/mail will work fine)
I have not been able to find a solution for the 500 internal server error that triggers when I visit the booktype installation, and the folks at iRedMail dont' seem interested. The main mantra at iRedMail seems to be that if you have installed iRedMail on something else than a fresh server, then you are on you own. So I have given up.
I have decided to try to solve this challenge one last time. I don't know if this is a iRedMail issue, or a Booktype issue, thus it can not hurt to ask.
As you also see from above comments, I installed both Booktype (automated install) and iRedMail. iRedMail is working as it should, but when installed together with Booktype, then the Booktype installation gives a 500 internal server error.
If I visit httpS://example.com - the apache2 virtual hostfile default-ssl.conf (port 443) kicks in and redirects to httpS://example.com/MAIL (and iRedMail is working as expected)
If I visit http://example.com (not ssl), I would expect the apache2 virtual hostfile booktype-instance1.com to kick in and serve the Booktype installation, but instead this gives the 500 internal server error.
When inspecting the /var/log/booktype-instance1-error.log I see the following:
Anyone have any idea why this type of errors are introduced when iRedMail installed. This does not happen in a Booktype server installation which has no iRedMail installed?
Could it be, that iRedMail (which also is using mod_wsgi) is doing something that blocks Booktype access to using the same mod_wsgi for its own purposes?
Hope someone can take a look at this strange issue.