Change Details

People skip through the "preparing your system" part of the "installation guide" like crazy, and end up hitting severe and fatal errors in **setup-kolab**. I had originally posted a [[ https://web.archive.org/web/20130910044616/http://kolab.org/blog/vanmeeuwen/2013/03/19/why-your-system-should-have-proper-fqdn | blog article ]] on kolab.org but that has now vanished. I propose I give in to my temptation and make the checks and balances work out in favour of less fatal failures with no path to recovery; When **setup-kolab** is launched, instead of issuing a warning, cause a fatal error and quit the program with an explanatory message.

People skip through the "preparing your system" part of the "installation guide" like crazy, and end up hitting severe and fatal errors in **setup-kolab**. I had originally posted a [[ https://web.archive.org/web/20130910044616/http://kolab.org/blog/vanmeeuwen/2013/03/19/why-your-system-should-have-proper-fqdn | blog article ]] on kolab.org but that has now vanished. I propose I give in to my temptation and make the checks and balances work out in favour of less fatal failures with no path to recovery; When **setup-kolab** is launched, instead of issuing a warning, cause a fatal error and quit the program with an explanatory message. ## Implementation Design Considerations * A proper FQDN is used for self-reference in 389, and nowadays is necessary for successful integration between #Manticore, #chwala and #roundcube_kolab_plugins's `kolab_files` plugin -- it's an iframe vs. browser security thing. * To check whether the system has a proper FQDN, we currently just look at the configured hostname and the ip address on the socket with the default route. We now need to also check whether the client (desktop) can use the same address to get to the server. We should take in to account that a system may be called `demo01.example.org` whereas the address to use to reach it may be `demo.kolab.io`, or even `webmail.kolab.io` or `kolab.io/apps`. For this reason I would bump the number of hours estimated from 1 to 8.

People skip through the "preparing your system" part of the "installation guide" like crazy, and end up hitting severe and fatal errors in **setup-kolab**. I had originally posted a [[ https://web.archive.org/web/20130910044616/http://kolab.org/blog/vanmeeuwen/2013/03/19/why-your-system-should-have-proper-fqdn | blog article ]] on kolab.org but that has now vanished. I propose I give in to my temptation and make the checks and balances work out in favour of less fatal failures with no path to recovery; When **setup-kolab** is launched, instead of issuing a warning, cause a fatal error and quit the program with an explanatory message. ## Implementation Design Considerations * A proper FQDN is used for self-reference in 389, and nowadays is necessary for successful integration between #Manticore, #chwala and #roundcube_kolab_plugins's `kolab_files` plugin -- it's an iframe vs. browser security thing. * To check whether the system has a proper FQDN, we currently just look at the configured hostname and the ip address on the socket with the default route. We now need to also check whether the client (desktop) can use the same address to get to the server. We should take in to account that a system may be called `demo01.example.org` whereas the address to use to reach it may be `demo.kolab.io`, or even `webmail.kolab.io` or `kolab.io/apps`. For this reason I would bump the number of hours estimated from 1 to 8.