Domain Controller - ".local" DNS domain

[mphilippi]

Hi there!

I just set up the new Zentyal 3.0 in a virtual machine to test the new software.
I am very impressed with the new features implemented as well as the polished look and feel. The dev team has done a superb job on the new release! Please keep improving this great peace of software!

But I think I came across a bug in the DC configuration section. Surprisingly, this problem has not been mentioned here before, but I think it is a pretty huge bug because none of the options in the domain controller sections can be changed. If I try to enable the roaming profiles option, for instance, I receive the following error after trying to apply the changes:

Code: [Select]

DNS domain name cannot end in '.local'
The system is freshly installed and updated. What can be done to change DC settings in the webinterface without getting this error message all the time and have the changes applied?

Best regards from Germany,
Marc

[christian]

Perhaps this is not a bug but real "warning" message stating that ".local" TLD is not supported 

BTW and joke aside, if you search further in this forum, you will find that we have already discuss this a lot.
".local" is not supported because it doesn't work well with rezoconf, although Microsoft is promoting this approach.

[mphilippi]

Perhaps this is not a bug but real "warning" message stating that ".local" TLD is not supported 

BTW and joke aside, if you search further in this forum, you will find that we have already discuss this a lot.
".local" is not supported because it doesn't work well with rezoconf, although Microsoft is promoting this approach.

Hi Christian!

Thanks for your quick reply!
I found another thread discussing this topic. Sorry, it looks like I missed this one during my research.

If this TLD is not supported, then why does Zentyal accept it at the initial setup (this should be the place for the mentioned error warning)? Every module but the domain server seems to "support" it (or at least does not conflict with it/no implemented error in the Zentyal webgui).
On the other side, the '.local' TLD is used in many lan networks and I actually never came up any existing internal network where this was not the preferred domain ending. Altough it looks like it conflicts with another service (which by the way is not provided by zentyal!) this should not be a huge problem as of today. As already said, many admins use this TLD for their networks and have no problem doing with it.
So why should Zentyal not allow the admin to use this TLD? It already kind of allows it because you can enter it at the initial setup and use it but have to face problem that you cannot edit any DC settings.

The best solution to me would be the following:
Allow the user to use .local (=remove the blocking of changes in the dc section), but add a warning/confirmation dialogue at the initial setup page where the REALM domain is specified if the user enters a .local TLD which informs the user about the incompatibility with certain services. Then the admin who can live with this issue or has to make a compromise because of existing MS networks confirms the warning and can use Zentyal (and of course can start editing the DC settings ) without restrictions. In my view, this would be perfect because Zentyal keeps itself aligned to official standards but on the other side is also flexible and does what the admin wants it do to.

Best regards
Marc

[christian]

Marc,

I share your comment that is to have an earlier warning and believe you are mainly working with Microsoft environment because this .local TLD is clearly pushed by Microsoft (only ?) and not by Apple as .local is used, e.g. by Bonjour protocol.

[mphilippi]

Yeah but it should be considered to allow .local as well.
Zentyal is a product which, I bet, will be used in MS environments (at least I want to ). You include a domain controller for use with MS workstations and a groupware tool which (for full functionality) recommends and integrates well with MS Outlook on the client side. I do not want to promote MS or support their policies but what I want to say is that Zentyal as an open-source alternative to MS SBS or MS Server should be "compatible" to their environments. But forcing the user to not have compatibility with existing networks does not go along with the term open if you ask me. If conflicts with certain services become an urgent problem in .local networks then admins will pay attention to that fact and MS will have to start thinking again and will eventually come up with another solution. But until then, why no flexibility? If the user can live with it after the warning, then it should be fine.

And as mentioned earlier, Zentyal is already "compatible" but just allows no changes in the DC module (either way, there is a bug: Zentyal does not completely allow or deny it). So I assume that changing this behavior and adding a confirmation at the beginning of the setup should be no big deal. Even if someone does not face this problem (=aggrees to standards; uses ohter TLDs because he can and is not forced), he will not have any disadvantage with my proposed solution. There is no drawback, just additional benefit for (many?) users who have to start on existing environments.

Another idea would be letting the users of this forum decide whether such a feature should be implemented or not, like other distros do.

[christian]

I can share some aspects but strongly do not share some others, sorry for that.
How can you think that "letting users in this forum decide" is an option ?
Do not take my comment the wrong way but even if Zentyzl is based on OpenSource (and BTW, open here doesn't mean that everything and anything is permitted  ) it doesn't mean that Zentyal as a company should go in the direction promoted by community users if there is a risk to jeopardize their business with customers.
At least this is the way I perceive it, not being Zentyal client BTW

Thus, to me, if they change their mind, this will mean that they can commit to support it, not just because this us community choice.

[mphilippi]

Of course, letting the user decide about every single line of code is not an idea but as I read through the already written posts regarding this topic in those forums, it comes to my mind that there are different opinions. The idea is to implement the opinion of the majority. As already said, I agree with you when saying that you cannot let the user decide about everything.

However, I came up with a temporary fix which can be used by those who have to rely on the ".local" domain. It works but can be broken by updates of the software. You then have to do it again to let the ".local" domain pass through. But that should not be a big problem regarding the fact that changes in this section of the DC module are rarely made when the system is set up once.

The file which is to be modified is called GeneralSettings.pm and should be located under /usr/share/perl5/EBox/Samba/Model/.
Open the file in an editor:

sudo nano /usr/share/perl5/EBox/Samba/Model/GeneralSettings.pm

Next, you have to comment out (with a # at the beginning of the line) two sections:

Code: [Select]

'LOCAL',and

Code: [Select]

if ($domain =~ m/\.local$/i) {
throw EBox::......
}Save the file and after rebooting the server or restarting the services you are done. Keep in mind that this file can be overwritten by an upcoming update. Then you have to redo the steps.

[FarquahrWindsor]

Hey Zentyal the .local debate is just ridiculous as your shooting yourself in the foot.

There are tons of win installs out there with .local also its nothing to do with samba4 its just the way its been implemented.

I can't believe you would offer a AD replacement and then place restrictions on what will be a huge amount of upgrade paths.

.local add it just make a disclaimer.

[browley]

I had made an earlier post about this exact problem.  FarquahrWindsor is 100% correct in that offering a replacement to active directory and then saying ".local" alienates anyone with this previous setup, effectively alienating potential market share.  In other words, Zentyal Devs: this will cause you to loose money.  Seriously.  Honestly, if it conflicts with other services such as mDNS/bonjour (which are p2p and should probably be blocked in an enterprise environment anyway, not to mention the noise they create on networks) are very much secondary to getting Active Directory up.  Now that I am not stuck to this "limitation" I am going to try and get Zentyal 3 up with my .local domain.  mphilippi, THANK YOU for finding the exception in the code.  Can confirm it works by commenting out the '.local' and that entire if statement.  With this I am going to do a fresh VM install and I will be reporting back on the success in this thread if anyone's curious: http://forum.zentyal.org/index.php/topic,12035.0.html.  Also, if this post sounds opinionated, it's because it is!  Thanks folks!

[christian]

The point is a bit wider than Bonjour itself 
Look at this and also this.

This is like a battle between Microsoft and Apple, unfortunately Ubuntu world is implementing services (like avahi) that are based on .local

Then, if you feel you will never be impacted, you can obviously hack current code and run your own customized Zentyal version.

[FarquahrWindsor]

Its just a strange point that you seem to be enforcing it? That is what I don't understand as its a simple script change.

Thing is Zentyal is aimed at being a linux server that you don't need cli or scripting skills to get running.
Its a really superb easy out of the box solution and hacks to make it run with unfortunately the most common OS in the world is just a little strange.

Zentyal is a SBS replacement just as Zarafa is billed as an Exchange replacement it needs to do what the original can do or it isn't a replacement.

I can make the script change but for the 100's of win sysadmins who try Zentyal for the first time and it doesn't work do you not see that by saying make a custom edit sort of reduces the image of a compatible robust product.

The argument is just ridiculous and I am unsure why your sticking to your guns.

If people want to set up incorrect FQDNs let them do so but don't dictate it. You have already shown us its a simple matter of a script change.

Quality control went out with the seventies and all you can do is assure with a disclaimer in the documentation.

[christian]

.../... If people want to set up incorrect FQDNs let them do so but don't dictate it.../...

OK, let me make it clear on more time ad this is the very last time: I will not comment this further as, I agree, it becomes ridiculous 

1 - I do understand your point about the "one to one" Microsoft replacement, including the .local TLD, even if this is technically wrong
2 - I'm not Zentyal staff and can not tell you what they may accept or not but I try to explain why supporting .local TLD is perhaps not a good idea from their standpoint.
3 - Zentyal, as a company, although Zentyal product is open-source, is making business with what they develop. I do understand they may not be prone to move in a direction they may not be able to support later. Decision is up to them.
4 - Please stop with this "if people want to do something wrong, warn them but let them do"  As I said, if you want to do this yourself because Zentyal team is not prone to support it, do it but do not ask Zentyal to implement it as "officially supported solution"

Again, I'm not Zentyal team so I will not comment further something not in my hands. Better let Zentyal add their own comments.
Or try to find something more convincing than "if users want it, give it to them" 

 

[FarquahrWindsor]

Ok well last week they lost out on a subscription because the DC was a .local

They would of had a zentyal proxy on site but because of .local they haven't its that simple. They are not going to change the whole domain structure which has been running for 6 years because of a AD replacement that doesn't function in the same way AD does.

Only one thing I can say and its Quarkybeddingspot and I am not sure what that means.

Also there is something strangely amiss is Zentyal isn't going to listen to customers!

[mphilippi]

Maybe one of the Zentyal officials could make their statement here whether they implement it (which would be beneficial with absolutely no negative impact on the users) or not. Because I don't know if those two sections of code are the only ones who deal with the problem. Maybe another module has implemented such a policy as well but does not show it with a warning or anything else and just drop the configuration of the server or misconfigure it if .local is used.

[innocenti_jr]

Have a look here:
http://trac.zentyal.org/ticket/5183#comment:1

Cheers - Oliver