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 - andrew_seacap

Pages: [1]
1
This is how I fixed it:

1. Open /usr/share/zentyal/stubs/dns/named.conf.local.mas
2. Insert your PPTP subnet in the trusted ACL below the localnets line:

Code: [Select]
acl "trusted" {
% foreach my $intnet (@intnets) {
    <% $intnet %>;
% }
    localhost;
    localnets;
    # PPTP Subnet
    192.168.210.0/24;
};

3. Restart DNS in Zentyal Dashboard
4. Reconnect PPTP client and test with nslookup somedomain.com yourzentyalip

The problem seems to be specific to PPTP clients. OpenVPN clients are automatically considered by Zentyal to be local clients and therefore do not have this problem.

2
Hi,

I have just performed a clean installation of Zentyal 3. I changed the 'Administration interface TCP port'. Now when I login to the server, it still opens Firefox automatically to https://localhost instead of https://localhost:port. I have changed the homepage in Firefox settings, but that does not affect the script that fires upon login.

Please can someone tell me where this script is so I can change it.

Regards

Andrew

3
Installation and Upgrades / Problems when restoring backup
« on: November 21, 2012, 01:53:05 pm »
When I restore a backup I took two months ago it says success, but when I then click on 'Save changes', I am shown the following error:

Saving changes

Some modules reported error when saving changes . More information on the logs in /var/log/zentyal/

Service Zentyal Administration Web Server already exists. Service Zentyal Administration Web Server already exists. at /usr/share/perl5/EBox/Model/DataTable.pm line 3315 EBox::Model::DataTable::_checkFieldIsUnique('EBox::CA::Model::Certificates=HASH(0x7923698)', 'EBox::Types::Text=HASH(0x79d5520)') called at /usr/share/perl5/EBox/Model/DataTable.pm line 873 EBox::Model::DataTable::addTypedRow('EBox::CA::Model::Certificates=HASH(0x7923698)', 'HASH(0x79413f0)') called at /usr/share/perl5/EBox/Model/DataTable.pm line 3722 EBox::Model::DataTable::_autoloadAdd('EBox::CA::Model::Certificates=HASH(0x7923698)', 'add', 'ARRAY(0x41abfe8)') called at /usr/share/perl5/EBox/Model/DataTable.pm line 2560 EBox::Model::DataTable::AUTOLOAD('EBox::CA::Model::Certificates=HASH(0x7923698)', 'module', 'apache', 'serviceId', 'Zentyal Administration Web Server', 'service', 'Zentyal Administration Web Server', 'cn', 'Zentyal', ...) called at /usr/share/perl5/EBox/CA/Model/Certificates.pm line 121 EBox::CA::Model::Certificates::syncRows('EBox::CA::Model::Certificates=HASH(0x7923698)', 'ARRAY(0x7940808)') called at /usr/share/perl5/EBox/Model/DataTable.pm line 1526 EBox::Model::DataTable::ids('EBox::CA::Model::Certificates=HASH(0x7923698)') called at /usr/share/perl5/EBox/Model/DataTable.pm line 3278 EBox::Model::DataTable::_find('EBox::CA::Model::Certificates=HASH(0x7923698)', 'serviceId', 'Zentyal Administration Web Server', undef, 'printableValue') called at /usr/share/perl5/EBox/Model/DataTable.pm line 2206 EBox::Model::DataTable::find('EBox::CA::Model::Certificates=HASH(0x7923698)', 'serviceId', 'Zentyal Administration Web Server') called at /usr/share/perl5/EBox/CA/Model/Certificates.pm line 242 EBox::CA::Model::Certificates::isEnabledService('EBox::CA::Model::Certificates=HASH(0x7923698)', 'Zentyal Administration Web Server') called at /usr/share/perl5/EBox/CA/Certificates.pm line 180 EBox::CA::Certificates::_genCert('EBox::CA::Certificates', 'HASH(0x798bf20)') called at /usr/share/perl5/EBox/CA/Certificates.pm line 57 EBox::CA::Certificates::genCerts('EBox::CA::Certificates') called at /usr/share/perl5/EBox/CA.pm line 1950 EBox::CA::_setConf('EBox::CA=HASH(0x4848290)') called at /usr/share/perl5/EBox/Module/Base.pm line 985 EBox::Module::Base::_regenConfig('EBox::CA=HASH(0x4848290)') called at /usr/share/perl5/EBox/Module/Service.pm line 746 EBox::Module::Service::_regenConfig('EBox::CA=HASH(0x4848290)') called at /usr/share/perl5/EBox/Module/Base.pm line 232 EBox::Module::Base::save('EBox::CA=HASH(0x4848290)') called at /usr/share/perl5/EBox/GlobalImpl.pm line 636 EBox::GlobalImpl::saveAllModules('EBox::GlobalImpl=HASH(0x3c2ded8)', 'progress', 'EBox::ProgressIndicator=HASH(0x3c24028)') called at /usr/share/perl5/EBox/Global.pm line 95 EBox::Global::AUTOLOAD('EBox::Global=HASH(0x3c2db00)', 'progress', 'EBox::ProgressIndicator=HASH(0x3c24028)') called at /usr/share/zentyal/global-action line 39

Any ideas?

Regards

Andrew

4
Hi Jase,

Yes that seems to help with the error. I wish I had know before I tried to force-uninstall Zentyal!

Regards

Andrew

5
Hi,

I came in today and ran an upgrade of zentyal-core to 3.0.7 via the browser. It resulted in an error message. I rebooted, checked to see if the upgrade run successfully, which it hadn't. I then tried via the command line and saw the following:

Code: [Select]
root@zentyal:~# apt-get install zentyal-core
Reading package lists... Done
Building dependency tree       
Reading state information... Done
zentyal-core is already the newest version.
zentyal-core set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? y
Setting up zentyal-core (3.0.7) ...
Processing triggers for zentyal-core ...
Deep recursion on subroutine "Error::subs::try" at /usr/share/perl5/EBox/GlobalImpl.pm line 96.
Deep recursion on subroutine "Error::subs::try" at /usr/share/perl5/EBox/GlobalImpl.pm line 96.
Deep recursion on subroutine "Error::subs::try" at /usr/share/perl5/EBox/Monitor.pm line 527.
Deep recursion on subroutine "EBox::Global::AUTOLOAD" at /usr/share/perl5/EBox/Monitor/Measure/Base.pm line 104.
Deep recursion on subroutine "EBox::GlobalImpl::modInstance" at /usr/share/perl5/EBox/Global.pm line 93.
Deep recursion on subroutine "EBox::Monitor::_create" at /usr/share/perl5/EBox/GlobalImpl.pm line 876.
Deep recursion on subroutine "EBox::Monitor::_setupMeasures" at /usr/share/perl5/EBox/Monitor.pm line 81.
Deep recursion on subroutine "EBox::Monitor::Measure::Manager::register" at /usr/share/perl5/EBox/Monitor.pm line 518.
Deep recursion on subroutine "EBox::Monitor::Measure::Manager::register" at /usr/share/perl5/EBox/Monitor.pm line 519.
Deep recursion on subroutine "EBox::Monitor::Measure::Manager::register" at /usr/share/perl5/EBox/Monitor.pm line 520.
Deep recursion on subroutine "EBox::Monitor::Measure::Manager::register" at /usr/share/perl5/EBox/Monitor.pm line 521.
Deep recursion on subroutine "EBox::Monitor::Measure::Manager::register" at /usr/share/perl5/EBox/Monitor.pm line 522.
Deep recursion on subroutine "EBox::Monitor::Measure::Thermal::new" at /usr/share/perl5/EBox/Monitor/Measure/Manager.pm line 99.
Deep recursion on subroutine "EBox::Monitor::Measure::Base::new" at /usr/share/perl5/EBox/Monitor/Measure/Thermal.pm line 38.
Deep recursion on subroutine "EBox::Monitor::Measure::Thermal::_description" at /usr/share/perl5/EBox/Monitor/Measure/Base.pm line 48.
Deep recursion on subroutine "EBox::Monitor::Measure::Base::baseDir" at /usr/share/perl5/EBox/Monitor/Measure/Thermal.pm line 116.

I see another post which looks similar:

http://forum.zentyal.org/index.php?topic=7003.0

But as it is related to an older version of Zentyal I decided to open a new thread.

I have attached today's output in zentyal.log. error.log just contains the same "Deep recursion" entries as are displayed above.

At the moment our server is unusable as a gateway so any help would be greatly appreciated.

Regards

Andrew

6
Yes, you're right. I checked this morning and I have no logs from today. They stopped yesterday at 23:59:07. Seems like something is happening around midnight that is interfering with the logger daemon. I checked the syslog and there is no mention of loggerd around that time. I also checked the process and it is still running, having been started some time yesterday.

7
Interesting, I just rebooted after upgrading to Zentyal 3 and now I have firewall logs...

Oh well, looks like the stable version works!


8
Hmm,

So I enabled the query log in MySQL, and I can see the queries generating the inserts to the squid_access table, but there are none for for the firewall table. What could cause this? The last entry in the firewall table has the timestamp '2012-09-18 23:58:16'. Was there some update this week that could have broken something?

9
Aha, looking in the syslog I see lots of the following:

Code: [Select]
Sep 20 14:49:13 zentyal kernel: [171376.751775] init: ebox.loggerd main process (52828) terminated with status 9
Sep 20 14:49:13 zentyal kernel: [171376.751795] init: ebox.loggerd main process ended, respawning
Sep 20 14:49:25 zentyal kernel: [171389.199573] init: ebox.loggerd main process (52846) terminated with status 9
Sep 20 14:49:25 zentyal kernel: [171389.199593] init: ebox.loggerd main process ended, respawning
Sep 20 14:49:38 zentyal kernel: [171401.677225] init: ebox.loggerd main process (52954) terminated with status 9
Sep 20 14:49:38 zentyal kernel: [171401.677246] init: ebox.loggerd main process ended, respawning
Sep 20 14:49:50 zentyal kernel: [171414.103164] init: ebox.loggerd main process (52987) terminated with status 9
Sep 20 14:49:50 zentyal kernel: [171414.103189] init: ebox.loggerd main process ended, respawning
Sep 20 14:50:03 zentyal kernel: [171426.587614] init: ebox.loggerd main process (53008) terminated with status 9
Sep 20 14:50:03 zentyal kernel: [171426.587637] init: ebox.loggerd main process ended, respawning
Sep 20 14:50:15 zentyal kernel: [171439.099930] init: ebox.loggerd main process (53118) terminated with status 9
Sep 20 14:50:15 zentyal kernel: [171439.099958] init: ebox.loggerd main process ended, respawning
Sep 20 14:50:28 zentyal kernel: [171451.576796] init: ebox.loggerd main process (53372) terminated with status 9
Sep 20 14:50:28 zentyal kernel: [171451.576825] init: ebox.loggerd main process ended, respawning
Sep 20 14:50:40 zentyal kernel: [171464.030033] init: ebox.loggerd main process (53454) terminated with status 9
Sep 20 14:50:40 zentyal kernel: [171464.030054] init: ebox.loggerd main process ended, respawning
Sep 20 14:50:53 zentyal kernel: [171476.522623] init: ebox.loggerd main process (53499) terminated with status 9
Sep 20 14:50:53 zentyal kernel: [171476.522643] init: ebox.loggerd main process ended, respawning
Sep 20 14:51:05 zentyal kernel: [171488.980299] init: ebox.loggerd main process (53516) terminated with status 9
Sep 20 14:51:05 zentyal kernel: [171488.980321] init: ebox.loggerd main process ended, respawning
Sep 20 14:51:18 zentyal kernel: [171501.407468] init: ebox.loggerd main process (53597) terminated with status 9
Sep 20 14:51:18 zentyal kernel: [171501.407489] init: ebox.loggerd main process ended, respawning
Sep 20 14:51:30 zentyal kernel: [171513.916003] init: ebox.loggerd main process (53616) terminated with status 9
Sep 20 14:51:30 zentyal kernel: [171513.916024] init: ebox.loggerd main process ended, respawning
Sep 20 14:51:43 zentyal kernel: [171526.343189] init: ebox.loggerd main process (53702) terminated with status 9
Sep 20 14:51:43 zentyal kernel: [171526.343210] init: ebox.loggerd main process ended, respawning
Sep 20 14:51:55 zentyal kernel: [171538.805120] init: ebox.loggerd main process (53734) terminated with status 9
Sep 20 14:51:55 zentyal kernel: [171538.805144] init: ebox.loggerd main process ended, respawning
Sep 20 14:52:08 zentyal kernel: [171551.268769] init: ebox.loggerd main process (53758) terminated with status 9
Sep 20 14:52:08 zentyal kernel: [171551.268792] init: ebox.loggerd main process ended, respawning
Sep 20 14:52:20 zentyal kernel: [171563.730357] init: ebox.loggerd main process (53841) terminated with status 9
Sep 20 14:52:20 zentyal kernel: [171563.730378] init: ebox.loggerd main process ended, respawning
Sep 20 14:52:33 zentyal kernel: [171576.327033] init: ebox.loggerd main process (53900) terminated with status 9
Sep 20 14:52:33 zentyal kernel: [171576.327052] init: ebox.loggerd main process ended, respawning

Any clues as to what 'status 9' means?

10
I have exactly the same problem, only the message at the bottom is different. See screenshot.

I have just tested a brand new installation of Zentyal 3 in a virtual machine and the same problem does not occur there. I can see the Firewall and Proxy logs etc.

What can we do to fix the issue in existing installations? I don't want to have to reinstall Zentyal just to fix a bug like this.

Regards

11
That last line might throw you out a bit, I had been testing some workarounds that I found on Google. I removed them, went back to the Zentyal DHCP settings and double-checked that DDNS is enabled, the output now is different:

Code: [Select]
Aug 23 17:12:06 zentyal named[47482]: client 127.0.0.1#39258: updating zone 'tld.com/IN': adding an RR at 'andrew-imac.tld.com' A
Aug 23 17:12:06 zentyal named[47482]: client 127.0.0.1#39258: updating zone 'tld.com/IN': adding an RR at 'andrew-imac.tld.com' TXT
Aug 23 17:12:06 zentyal dhcpd: Added new forward map from andrew-imac.tld.com. to 192.168.1.20
Aug 23 17:12:06 zentyal dhcpd: unable to add reverse map from 20.1.168.192.in-addr.arpa. to andrew-imac.tld.com.: timed out

Regards

Andrew

12
Hi Robb,

Thanks for your quick reply!

Yes, I realised it was old, but I have [nearly] the exact same symptoms. I'm using Ubuntu 12.04 and Zentyal 2.3:

Code: [Select]
Aug 23 16:47:28 zentyal named[19327]: client 127.0.0.1#41489: updating zone 'tld.com/IN': update unsuccessful: andrew-desire-z.tld.com: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Aug 23 16:47:28 zentyal named[19327]: client 127.0.0.1#55682: updating zone 'tld.com/IN': deleting rrset at 'andrew-desire-z.tld.com' A
Aug 23 16:47:28 zentyal named[19327]: client 127.0.0.1#55682: updating zone 'tld.com/IN': adding an RR at 'andrew-desire-z.tld.com' A
Aug 23 16:47:28 zentyal dhcpd: Added new forward map from andrew-desire-z.tld.com. to 192.168.1.50
Aug 23 16:47:28 zentyal dhcpd: unable to add reverse map from 50.1.168.192.1.168.192.in-addr.arpa. to andrew-desire-z.tld.com.: timed out

I have replaced our actual domain name with tld.com

Regards

Andrew

13
Is there any workaround that be implemented to fix this, for example, by modifying the stub files.

Can you provide any technical information on why Zentyal is unable to update the reverse records?

Regards

Andrew

Pages: [1]