Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - The Knew Guy

Pages: [1]
1
Is your server a 2003 or 2003 R2? The sysvol is synced by zentyal using a script which pulls the sysvol content from the server you join each 15 min.

Yes, this I can believe, but the problem is the inbound replication from zentyal to the w2k3 servers.  Since it does not work, it causes problems when users are authenticated against the zentyal box.  So what happens is this.

  • Zentyal joins domain, and all machines replicate happily
  • Shortly after joining, inbound replication from Zentyal to Windows Server fails, schema mismatch
  • Zentyal responds to Active Directory logon requests from computer and user accounts
  • Since zentyal isn't replicating inbound, user or computer accounts that authenticate against it are "untrusted" when trying to access shares or other resources on the w2k3 servers

In my eyes, the only thing that makes sense is either that Zentyal only be promoted as a RODC - something that Samba 4 does not yet support; or that Zentyal NOT be allowed to participate in domain updates or answer logon requests, unless it is the only domain controller, or unless the entire environment is Samba, (in which case we can use rsync as described here→https://wiki.samba.org/index.php/SysVol_Replication

2
disclaimer: There are many questions in this post, but the bolded ones are the main ones I need help with.

Synopsis:
In my workplace, I have implemented a Zentyal server as an additional domain controller.  Following Zental-Samba 3.5.4, joining my domain FINALLY works.  However, that being said, I am still having problems with my environment that seem to only be fixed by turning the Zentyal box off.

My only interest at this point is to use Zentyal as a Samba based file server.  I'm running ACL's unmanaged in the /etc/zentyal/samba.conf file and it's working well for me.  A day or two after installing and joining successfully to the domain, however, DC replication issues begin to surface.  This wouldn't be a problem, except Zentyal seems to INSIST on being a global catalog (logon) server, which is not something I want.  Especially if it cannot successfully replicate itself to windows based domain controllers.  My two Win2k3 boxes both have errors on inbound replication from the Zentyal server.  Error 8442 specifically on the DC=domain,DC=tld and on the CN=Configuration,DC=domain,DC=tld containers.  I also get errors about schema mismatch.

What happens after this replication failure issue surfaces, is I start getting logon failures and computer trust issues across my network.  People who ARE logged suddenly cannot access shares on the W2k3 boxes, other users get messages about "Trust account" not found for the workstation they are on.  The computer account exists, but seems to have failed to replicate to Zentyal for whatever reason, even though, the replication shows as successful.

Questions:
Eventually, I may run nothing but Zentyal servers once my 2k3 boxes are out of support, but until then, What can I do to make Zentyal not answer logon requests? or Is there a magic cron job I can create to manually fix the sysvol replication and make the logons work?

Other Thoughts:
On a side note, why would Zentyal even talk about or recommend the possibility of Zentyal as an additional domain controller is Samba 4 does not yet support replication of the sysvol share, and why not disable being a logon server or a global catalog server until the replication issue is fixed upstream by the Samba folks?  Why not incorporate options into the web interface to allow the user to check/uncheck "Make Zentyal a Global Catalog server" under AD join or LDAP options?

Or maybe I'm not fully understanding the problem?  Because on the web interface, I can see group policy objects and links.  Is it reading those locally, or from another domain controller.  Why does computer/user authentication fail when computers bind to the Zentyal DC on startup?  Is this also because of the failed replication or schema mismatch?

3
Installation and Upgrades / Re: Sysvol Replication Fails
« on: August 14, 2014, 01:09:54 am »
From what I understand, this is something that is not yet supported by Samba4.  Not sure what the official "workaround" for this built into Zentyal 3.5, but it doesn't seem to be working for me either.

4
There's a patch for this that I guess hasn't made it into the official build.

https://tracker.zentyal.org/issues/1090#note-13

5
Still breaks on reboot, I tried to manually start the processes with service zentyal samba start and it fails.  I manually started samba from the command line by simply typing samba and it started fine.  "zentyal samba" is still considered "stopped" (both from the dashboard, and from service zentyal samba status command, but I am able to access the "Manage" link on users and groups despite the service being stopped. 

Perhaps Samba isn't broken, just the initialization of it is?

6
This is still broken as of today.  Zentyal-samba 3.5~124

7
I'm having the same problem.  Samba database connection refused after setting up users, groups, shares and then rebooting the machine.  During Boot-up, a message appears on the screen that says something like "Zentyal is Setting up Core services"  After reboot, the Zentyal-samba module is broken and can only be fixed by purge/reinstall (which throws away all the configuration you just did)

Code: [Select]
some modules reported error when saving changes . More information on the logs in /var/log/zentyal/
FATAL: Could not connect to samba LDAP server: connect: Connection refused
FATAL: Could not connect to samba LDAP server: connect: Connection refused at
FATAL: Could not connect to samba LDAP server: connect: Connection refused at /usr/share/perl5/EBox/Ldap.pm line 219
EBox::Ldap::safeConnect('EBox::Ldap=HASH(0x9484be8)') called at /usr/share/perl5/EBox/Ldap.pm line 173
EBox::Ldap::connection('EBox::Ldap=HASH(0x9484be8)') called at /usr/share/perl5/EBox/LDAPBase.pm line 99
EBox::LDAPBase::search('EBox::Ldap=HASH(0x9484be8)', 'HASH(0x7928a28)') called at /usr/share/perl5/EBox/Samba.pm line 1856
EBox::Samba::securityGroups('EBox::Samba=HASH(0x7d0cdf0)') called at /usr/share/perl5/EBox/Samba.pm line 1636
EBox::Samba::realGroups('EBox::Samba=HASH(0x7d0cdf0)') called at /usr/share/perl5/EBox/Samba/Model/SambaSharePermissions.pm line 84
EBox::Samba::Model::SambaSharePermissions::populateGroup at /usr/share/perl5/EBox/Samba/Types/Select.pm line 50
EBox::Samba::Types::Select::options('EBox::Samba::Types::Select=HASH(0x9707b98)') called at /usr/share/perl5/EBox/Types/Select.pm line 179
EBox::Types::Select::printableValue('EBox::Samba::Types::Select=HASH(0x9707b98)') called at /usr/share/perl5/EBox/Types/Union.pm line 384
EBox::Types::Union::AUTOLOAD('EBox::Types::Union=HASH(0x9707958)') called at /usr/share/perl5/EBox/Types/Union.pm line 252
EBox::Types::Union::printableValue('EBox::Types::Union=HASH(0x9707958)') called at /usr/share/perl5/EBox/Model/Row.pm line 547
EBox::Model::Row::printableValueByName('EBox::Model::Row=HASH(0x9707a48)', 'user_group') called at /usr/share/perl5/EBox/Samba/Model/SambaSharePermissions.pm line 144
EBox::Samba::Model::SambaSharePermissions::syncRows('EBox::Samba::Model::SambaSharePermissions=HASH(0x9615400)', 'ARRAY(0x9687858)') called at /usr/share/perl5/EBox/Model/DataTable.pm line 1461
eval {...} at /usr/share/perl5/EBox/Model/DataTable.pm line 1457
EBox::Model::DataTable::ids('EBox::Samba::Model::SambaSharePermissions=HASH(0x9615400)') called at /usr/share/perl5/EBox/Samba.pm line 3462
EBox::Samba::shares('EBox::Samba=HASH(0x7d0cdf0)') called at /usr/share/perl5/EBox/Samba.pm line 3248
EBox::Samba::writeSambaConfig('EBox::Samba=HASH(0x7d0cdf0)') called at /usr/share/perl5/EBox/Samba.pm line 804
EBox::Samba::_setConfInternal('EBox::Samba=HASH(0x7d0cdf0)', undef) called at /usr/share/perl5/EBox/Samba.pm line 780
EBox::Samba::_setConf('EBox::Samba=HASH(0x7d0cdf0)') called at /usr/share/perl5/EBox/Module/Base.pm line 995
EBox::Module::Base::_regenConfig('EBox::Samba=HASH(0x7d0cdf0)') called at /usr/share/perl5/EBox/Module/Service.pm line 972
EBox::Module::Service::_regenConfig('EBox::Samba=HASH(0x7d0cdf0)') called at /usr/share/perl5/EBox/Samba.pm line 761
EBox::Samba::_regenConfig('EBox::Samba=HASH(0x7d0cdf0)') called at /usr/share/perl5/EBox/Module/Base.pm line 234
eval {...} at /usr/share/perl5/EBox/Module/Base.pm line 233
EBox::Module::Base::save('EBox::Samba=HASH(0x7d0cdf0)') called at /usr/share/perl5/EBox/GlobalImpl.pm line 651
eval {...} at /usr/share/perl5/EBox/GlobalImpl.pm line 650
EBox::GlobalImpl::saveAllModules('EBox::GlobalImpl=HASH(0x48ee178)', 'progress', 'EBox::ProgressIndicator=HASH(0x230b8f0)') called at /usr/share/perl5/EBox/Global.pm line 95
EBox::Global::AUTOLOAD('EBox::Global=HASH(0x48edba8)', 'progress', 'EBox::ProgressIndicator=HASH(0x230b8f0)') called at /usr/share/zentyal/global-action line 32 eval {...} at /usr/share/zentyal/global-action line 30

8
When i install the iso on a real machine will this failure also occur ? I didn´t tested it an i only use virtual machines. Because then its something for the bugtracker.
I thought it has to do with the virtio driver.

I had a problem with LVM and automatic partitioning not working at all with a physical install.  Fails to create file system or actually do any partitioning.

Pages: [1]