Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: Andy on January 12, 2010, 11:45:14 am
-
Hello everybody,
I tried to set up an ebox-master and an ebox-slave.
On the master I created two groups and two users and set the status to "master".
On the slave machine I set the status to "slave" and filled in the IP of the master and the ldap.secret-password.
When activating UsersAndGroups on the slave machine I got a really nasty error, saying that something with permissions went wrong in /usr/share/perl5/EBox/UsersAndGroups.pm line 2493.
I looked after that line write_file(SSL_DIR . 'master.cert', $cert); and here's what did the trick for me:
In /var/lib/ebox/confthere are the two dirs "ssl" and "ssl-ca"
Look at the rights for the dirs and the files in "ssl".
With chmod I set them to rwxrwxrwx (for the dirs) and rw-rw-rw- for the files, then I activated UsersAndGroups again. It worked. After that I set the rights back.
I hope this helps somebody (and I hope I'll found it again when I need it the next time :-)
Kind regards,
Andreas
-
great, gonna try that!
-
I'm not so familiar with using chmod thru terminal, but here's what I did:
cd var/lib/ebox/conf/
chmod -R 0777 ssl
chmod -R 0777 ssl-ca
I figured that 777 is full read/write so it should work
this doesn't work for me tho...
still getting same error
should i be making these changes on the slave or master (or both)?
any chance you can post exact chmod commands?
-
Hello,
I did that only on the slave.
Look for the dirs, do they have the rights you set? (drwxrwxrwx)
I did that only with e.g. chmod 777 ssl but I think it's the same.
Can you post the entire error message?
-
drwxrwxrwx 2 ebox adm 4096 2010-01-05 15:48 ssl
drwxrwxrwx 2 ebox adm 4096 2010-01-12 17:51 ssl-ca
error message is as follows:
A really nasty bug has occurred
Exception
Failed to enable: Replication failed
Trace
Failed to enable: Replication failed at /usr/share/perl5/EBox/CGI/ServiceModule/ConfigureModuleController.pm line 74
EBox::CGI::ServiceModule::ConfigureModuleController::_process('EBox::CGI::ServiceModule::ConfigureModuleController=HASH(0xac...') called at /usr/share/perl5/EBox/CGI/Base.pm line 262
EBox::CGI::Base::run('EBox::CGI::ServiceModule::ConfigureModuleController=HASH(0xac...') called at /usr/share/perl5/EBox/CGI/Run.pm line 120
EBox::CGI::Run::run('EBox::CGI::Run', 'ServiceModule/ConfigureModuleController', 'EBox') called at /usr/share/ebox/cgi/ebox.cgi line 19
ModPerl::ROOT::ModPerl::Registry::usr_share_ebox_cgi_ebox_2ecgi::handler('Apache2::RequestRec=SCALAR(0xac7ffe0)') called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204
eval {...} called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204
ModPerl::RegistryCooker::run('ModPerl::Registry=HASH(0xaca0db8)') called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 170
ModPerl::RegistryCooker::default_handler('ModPerl::Registry=HASH(0xaca0db8)') called at /usr/lib/perl5/ModPerl/Registry.pm line 31
ModPerl::Registry::handler('ModPerl::Registry', 'Apache2::RequestRec=SCALAR(0xac7ffe0)') called at -e line 0
eval {...} called at -e line 0
-
I looked after that line write_file(SSL_DIR . 'master.cert', $cert); and here's what did the trick for me:
In /var/lib/ebox/confthere are the two dirs "ssl" and "ssl-ca"
Look at the rights for the dirs and the files in "ssl".
With chmod I set them to rwxrwxrwx (for the dirs) and rw-rw-rw- for the files, then I activated UsersAndGroups again. It worked. After that I set the rights back.
Uhm, weird, the default rights in my system after a new installation are:
drwx------ 2 ebox adm 4096 2010-01-11 14:41 /var/lib/ebox/conf/ssl/
drwxr-xr-x 2 ebox adm 4096 2009-12-24 14:19 /var/lib/ebox/conf/ssl-ca/
which should be just fine.
-
is there any difference in that regard if installing ebox on an existing ubuntu system or installing from an ebox 1.3 iso ?
-
@philmills:
It seems you have an other error.
Look at this file:
/usr/share/perl5/EBox/CGI/ServiceModule/ConfigureModuleController.pm line 74
Maybe it helps if you deactivate Replication when activating UsersAndGroups. Perhaps Replication causes the error.
@isaac:
I think the granted rights are OK, but for activating UsersAndGroups you have to grant rw-rights for ./ssl on the slave.
In this dir this module tries to create file. But with the default rights creating the file fails.
Don't forget to write down the default rights and set them back when the module UsersAndGroups was activated.
-
as far as i understand, replication is what tells the slave to get the user accounts from ldap on the master. How would i deactivate it anyway????
-
@philmills:
I did a ps ax | grep rep on both servers and only on the slave I found the /etc/ldap/slapd-replica.d running.
You should try this, too.
I think you're right that replication is needed for the LDAP.
But note, that you've had another error so its necessary to investigate for the line with the command that fails.
Did you have a look for
/usr/share/perl5/EBox/CGI/ServiceModule/ConfigureModuleController.pm line 74?
-
Well, that would make sense that a replication service is running on the slave...
line 74 is this:
throw EBox::Exceptions::Internal("Failed to enable: " .
which appears in the else statement of the following:
sub _process
{
my ($self) = @_;
$self->_requireParam('module');
my $modName = $self->param('module');
my $manager = new EBox::ServiceManager();
my $module = EBox::Global->modInstance($modName);
$module->setConfigured(1);
$module->enableService(1);
$manager->updateModuleDigests($modName);
try {
$module->enableActions();
} otherwise {
my ($excep) = @_;
$module->setConfigured(undef);
$module->enableService(undef);
if ($excep->isa("EBox::Exceptions::External")) {
throw EBox::Exceptions::External("Failed to enable: " .
$excep->stringify());
} else {
throw EBox::Exceptions::Internal("Failed to enable: " .
$excep->stringify());
}
};
$manager->updateModuleDigests($modName);
$self->{redirect} = "ServiceModule/StatusView";
}
I'm a bit of a newb when it comes to this kinda stuff...
sorry
-
i opened a ticket for this one now:
http://trac.ebox-platform.com/ticket/1671
-
Sorry, but I'm also a newbie when it comes to that scripting stuff.
Now I'm on my next problem: activating Email on the slave...
-
I got this as well
A really nasty bug has occurred
Exception
Failed to enable: Replication failed
Trace
Failed to enable: Replication failed at /usr/share/perl5/EBox/CGI/ServiceModule/ConfigureModuleController.pm line 74
EBox::CGI::ServiceModule::ConfigureModuleController::_process('EBox::CGI::ServiceModule::ConfigureModuleController=HASH(0xa7...') called at /usr/share/perl5/EBox/CGI/Base.pm line 262
EBox::CGI::Base::run('EBox::CGI::ServiceModule::ConfigureModuleController=HASH(0xa7...') called at /usr/share/perl5/EBox/CGI/Run.pm line 120
EBox::CGI::Run::run('EBox::CGI::Run', 'ServiceModule/ConfigureModuleController', 'EBox') called at /usr/share/ebox/cgi/ebox.cgi line 19
ModPerl::ROOT::ModPerl::Registry::usr_share_ebox_cgi_ebox_2ecgi::handler('Apache2::RequestRec=SCALAR(0xa794d8c)') called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204
eval {...} called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204
ModPerl::RegistryCooker::run('ModPerl::Registry=HASH(0xa7b8aac)') called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 170
ModPerl::RegistryCooker::default_handler('ModPerl::Registry=HASH(0xa7b8aac)') called at /usr/lib/perl5/ModPerl/Registry.pm line 31
ModPerl::Registry::handler('ModPerl::Registry', 'Apache2::RequestRec=SCALAR(0xa794d8c)') called at -e line 0
eval {...} called at -e line 0
I wonder if it is because I tried to run the master with several services not just users and groups - I was guessing this restriction had long since gone as we are quite close to the release date for 1.4 but maybe I am wrong.
I was running a web server as master (so it only had usersandgroups) but the three servers all fell over, to various degrees on upgrade to 12 or 13 so I started again. I wanted my egroupware and PDC server to be master as I had been unable to use it before to authenticate linux clients (seemed slaves could not manage this)
Whatever the reason by master seems to be running ok and the slave won't play ball (even after the file permission change mentioned)
-
tried to purge usersandgroups from web server, autoremove and purge everything then updated then reinstalled usersandgroups.
Thsi failed - system remembered it was a master (so purge did not remove all config) and it does not work now
-
well - it sounds like this master/slave thing is well and truly broken, which is comforting to know i'm not the only one, but i do sympathise that your master is now broken from trying to get to the bottom of this...
-
Well it is only a development version so the more we find wrong now the better things will be when 1.4 is released - if we don't find the problems, nobody is going to fix them!
-
i was kinda hoping that it would be fixed in 1.3 stable - if not then its not stable (if you see what i mean)
-
Hi peterr. The restriction is still there and will be in 1.4. It requires a lot of changes in the LDAP code and it can't be done right before a release.
The master can only contain 'usersandgroups', and no other modules that use groups such as mail or samba.
Cheers!
-
@philmills: it's not 'well and truly' broken at all. what happened is that we upgraded to a new openldap version and it turned out to be 'quite' broken. i have a fixed openldap version that i am uploading right now. it should be available in a few hours.
cheers
-
The OpenLDAP version that we were using (different than the one we developed the master/slave with) had a bug that caused replication to not work.
I have just packaged a fixed version and things seem to work with it. It will be uploaded to the 1.3 repositories in a few hours.
-
Thanks Isaac
Pity about the u&g only feature remaining in 1.4 but that can be worked around - is it possible to authenticate a linux client on a slave though? I had not luck previously. I have just read an email on how to clear out the ldap settngs so i will try and put things back as they were then I can go back to trying linux auth.
-
Hello!
I set up the master and slave again and replication seems to work.
On the slave I can see the user & groups I created on the master.
But what do you mean with:The master can only contain 'usersandgroups', and no other modules that use groups such as mail or samba.
You can use the master only for administrate the users & groups? No file- and/or printersharing?
My idea was to use the master as a PDC with Samba for file- and printer-sharing and a slave for communication (gateway, proxy, mail). The users can fetch their mail from the slave and in the background the authentication aould be checked via LDAP on the master.
Am I wrong?
By the way:
I tried to use the UserCorner on the slave, but whe I try to log on with a user that exists in LDAP the UserCorner says "Incorrect password".
But on the master it worked...
-
your master can run anything that does not depend on userandgroups e.g web server, dchp, dns etc but the only ldap based service can be usersandgroups.
I was rather hoping to do something similar to what you want but find I can not - However I have a web server that I can use as the master for usersandgroups (though currently that is not working as I can not reinstall ebox and get the usersandgroups module to work)
-
Before I read this I activated File- and Printersharing on the master, and Email on the slave.
Now it's not possible to access Users or Groups on the slave anymore.
The same stupid error message appears:
An internal error has occurred. This is most probably a bug, relevant information can be found in the logs.It would be nice to know in WHICH log I have to look.
In /varlog/ebox/ebox.log on the slave I found some errors:
2010/01/21 10:13:26 ERROR> Ldap.pm:682 EBox::Ldap::_errorOnLdap - $VAR1 = {
'base' => 'ou=Groups,dc=ebox,dc=domain,dc=tst',
'attrs' => [
'cn',
'gidNumber',
'description'
],
'filter' => '(objectclass=*)',
'scope' => 'one'
};
2010/01/21 10:13:26 ERROR> Ldap.pm:684 EBox::Ldap::_errorOnLdap - Unknown error at EBox::UsersAndGroups::groups Referral received
2010/01/21 10:17:03 INFO> Service.pm:615 EBox::Module::Service::restartService - Skipping restart for events as it's disabled
2010/01/21 10:17:20 ERROR> Ldap.pm:682 EBox::Ldap::_errorOnLdap - $VAR1 = {
'base' => 'ou=Users,dc=ebox,dc=domain,dc=tst',
'attrs' => [
'uid',
'uidNumber'
],
'filter' => 'objectclass=*',
'scope' => 'one'
};
2010/01/21 10:17:20 ERROR> Ldap.pm:684 EBox::Ldap::_errorOnLdap - Unknown error at EBox::UsersAndGroups::uidList Referral received
2010/01/21 10:18:19 INFO> Service.pm:619 EBox::Module::Service::restartService - Restarting service for module: usercorner
2010/01/21 10:18:48 ERROR> Ldap.pm:682 EBox::Ldap::_errorOnLdap - $VAR1 = {
'base' => 'ou=Users,dc=ebox,dc=domain,dc=tst',
'attrs' => [
'uid',
'uidNumber'
],
'filter' => 'objectclass=*',
'scope' => 'one'
};
2010/01/21 10:18:48 ERROR> Ldap.pm:684 EBox::Ldap::_errorOnLdap - Unknown error at EBox::UsersAndGroups::uidList Referral received
Now I'm a little bit confused:
ebox is a user but also the name of the master machine.
Does the BaseDN (cn=) contain the machine's name or the user's name?
Is it possible to get the slave working again?
And where can I find (in the filesystem) the LDAP-server's configuration?
And where's the LDAP-client's config?
-
I looked after that line write_file(SSL_DIR . 'master.cert', $cert); and here's what did the trick for me:
In /var/lib/ebox/confthere are the two dirs "ssl" and "ssl-ca"
Look at the rights for the dirs and the files in "ssl".
With chmod I set them to rwxrwxrwx (for the dirs) and rw-rw-rw- for the files, then I activated UsersAndGroups again. It worked. After that I set the rights back.
Uhm, weird, the default rights in my system after a new installation are:
drwx------ 2 ebox adm 4096 2010-01-11 14:41 /var/lib/ebox/conf/ssl/
drwxr-xr-x 2 ebox adm 4096 2009-12-24 14:19 /var/lib/ebox/conf/ssl-ca/
which should be just fine.
I had my settings like yours, but my error says "Failed to enable: write_file '/var/lib/ebox/conf/ssl/master.cert' - sysopen: Permission denied at /usr/share/perl5/EBox/UsersAndGroups.pm line 2594." I tried setting the directory to 700 or 777, no fix. Then I got the great idea to create the file (which I've done before), no fix. Finally, I said, let me edit the permissions on that file I created and see what happens. After setting the permissions on the file itself to 777, it worked. I changed it to 660 just in case.
-
I have the same situation but a slightly different error
A really nasty bug has occurred
Exception
Failed to enable: Can't call method "get_value" on an undefined value at /usr/share/perl5/EBox/UsersAndGroups.pm line 2590.
Trace
Failed to enable: Can't call method "get_value" on an undefined value at /usr/share/perl5/EBox/UsersAndGroups.pm line 2590.
at /usr/share/perl5/EBox/CGI/ServiceModule/ConfigureModuleController.pm line 74
EBox::CGI::ServiceModule::ConfigureModuleController::_process('EBox::CGI::ServiceModule::ConfigureModuleController=HASH(0x8f...') called at /usr/share/perl5/EBox/CGI/Base.pm line 262
EBox::CGI::Base::run('EBox::CGI::ServiceModule::ConfigureModuleController=HASH(0x8f...') called at /usr/share/perl5/EBox/CGI/Run.pm line 120
EBox::CGI::Run::run('EBox::CGI::Run', 'ServiceModule/ConfigureModuleController', 'EBox') called at /usr/share/ebox/cgi/ebox.cgi line 19
ModPerl::ROOT::ModPerl::Registry::usr_share_ebox_cgi_ebox_2ecgi::handler('Apache2::RequestRec=SCALAR(0x9019f78)') called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204
eval {...} called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204
ModPerl::RegistryCooker::run('ModPerl::Registry=HASH(0x9019b28)') called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 170
ModPerl::RegistryCooker::default_handler('ModPerl::Registry=HASH(0x9019b28)') called at /usr/lib/perl5/ModPerl/Registry.pm line 31
ModPerl::Registry::handler('ModPerl::Registry', 'Apache2::RequestRec=SCALAR(0x9019f78)') called at -e line 0
eval {...} called at -e line 0
Is there any estimate on when having a PDC on the same machine as the master will be available? I recently bought a new file server and upgraded my old one to 1.4 (which currently has the PDC). Is there a way to transfer the PDC over to the new fileserver (recreating it from scratch may cause problems with things like MS project server)?
Also, will disabling the things requiring users and groups be enough to have it be the master LDAP, or will i need a complete reinstall?
BTW, eBox is by far the best thing to happen to my IT dept (which consists of me, and I'm not an IT guru) and has made life much more enjoyable. Awesome work guys ;D.