Description of problem: When installing through urpmi, I get the following message at the end of the installation: Stopping ldap (via systemctl): [ OK ] awk: ligne de commande:1: avertissement : le composant d'expression rationnelle « [:space:] » devrait probablement être « [[:space:]] » Starting ldap (via systemctl): Failed to issue method call: Unit ldap.service failed to load: No such file or directory. See system logs and 'systemctl status ldap.service' for details. [ÃCHEC ] [root@localhost ~]# service ldap start Starting ldap (via systemctl): Failed to issue method call: Unit ldap.service failed to load: No such file or directory. See system logs and 'systemctl status ldap.service' for details. [ÃCHEC ] [root@localhost ~]# systemctl status ldap.service ldap.service Loaded: error (Reason: No such file or directory) Active: inactive (dead) Version-Release number of selected component (if applicable): How reproducible: Always. (I tried "urpme openldap-servers; urpmi openldap-servers", but I get the same error) Steps to Reproduce: 1. In a console as root: urpmi openldap-servers
I forgot, the Version-Release number of selected component: openldap-servers-2.4.29-2.1.mga2.x86_64.rpm Also I don't know whether it should, but these give no result: - find /lib/systemd/ -name '*ldap*' - find /etc/systemd/ -name '*ldap*'
Assignee: bugsquad => bgmilneSource RPM: openldap-servers-2.4.29-2.1.mga2.x86_64.rpm => openldap-2.4.29-2.1.mga2.src.rpm
Missing /var/ldap/ directory. We edit file: / // etc/rc.d/init.d/ldap and we add lines : Line 111 : mkdir /run/ldap/ | chown ldap:ldap /run/ldap/ Line 170 : rm -r --interactive=never /run/ldap After you restart the LDAP server see : Starting ldap (via systemctl): [ OK ]
CC: (none) => ingvar45
(In reply to comment #2) > Missing /var/ldap/ directory. > I edited file: / // etc/rc.d/init.d/ldap and I added lines : > Line 111 : > mkdir /run/ldap/ | chown ldap:ldap /run/ldap/ > Line 170 : > rm -r --interactive=never /run/ldap > > After you restart the LDAP server see : > Starting ldap (via systemctl): [ OK ]
Thanks. Now the service still fails to start, but I can get the following message: [root@myhost ~]# systemctl status ldap.service ldap.service - LSB: LDAP servers (slapd) Loaded: loaded (/etc/rc.d/init.d/ldap) Active: failed (Result: exit-code) since Fri, 23 Nov 2012 12:13:24 +0100; 40s ago Process: 31123 ExecStart=/etc/rc.d/init.d/ldap start (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/ldap.service Nov 23 12:13:24 myhost.localdomain ldap[31123]: [79B blob data] Nov 23 12:13:24 myhost.localdomain slapd[31142]: could not open config file "/etc/openldap/slapd.conf": Permissi...(13) Nov 23 12:13:24 myhost.localdomain slapd[31142]: slapd destroy: freeing system resources. [root@myhost ~]# ls -l /etc/openldap/slapd.conf -rw-r----- 1 root root 6283 nov 14 17:24 /etc/openldap/slapd.conf Any other solution than chmod o+r slapd.conf ?
Your slapd.conf permissions don't match those in the package: # rpm -qlv openldap-servers|grep slapd.conf$ -rw-r----- 1 root ldap 6317 Oct 14 21:52 /etc/openldap/slapd.conf Just reverting them (e.g. check 'rpm -V openldap-servers') should allow slapd to start. I will look at fixing the init script or systemd unit in the package, but so far I have been unable to find a reference to what changed, and why, I can't see why the changes you made are required, possibly this works although the intention was to actually require systemd units? For systemd support, I will need to re-work some scripts and apply some patches to retain some existing features of the current init script.
Thanks, now it works. The wrong group is very probably my fault: I made a few tests with slapd.conf, then reverted back to a backup I made at the beginning. But apparently the backup was created with the wrong group... I installed Mageia 2 from the Network Install 64bits CD (with nonfree firmwares). So maybe it doesn't have the same list of packages (or the same versions ?) to install than the Mageia CD or DVD ?
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD