Created attachment 6031 [details]
mod_nss.patch

The attached patch will fix this problem

this bug has been fixed by applying this patch. 
At the same time, the %preun section has been fixed and in the configure section, "--with-selinux" was removed.
The daemon now starts.
The following packages are in updates_testing:
389-admin-1.1.35-1.1.mga4.src.rpm
389-admin-1.1.35-1.1.mga4.x86_64.rpm
389-admin-debuginfo-1.1.35-1.1.mga4.x86_64.rpm
and corresponding i586 packages

Assignee: thomas => qa-bugs

MGA4-64 on HP-Probook 6555b KDE.
Package 389-admin-debuginfo-1.1.35-1.1.mga4.x86_64.rpm is not present in updates testing for 64bits.
I guess that shouldn't really matter.
But at CLI I get:
#  systemctl start dirsrv-admin.service
Job for dirsrv-admin.service failed. See 'systemctl status dirsrv-admin.service' and 'journalctl -xn' for details.
# systemctl -l status dirsrv-admin.service
dirsrv-admin.service - 389 Administration Server.
   Loaded: loaded (/usr/lib/systemd/system/dirsrv-admin.service; enabled)
   Active: failed (Result: exit-code) since wo 2015-03-11 16:40:08 CET; 9s ago
  Process: 30400 ExecStart=/usr/sbin/httpd -k start -f /etc/dirsrv/admin-serv/httpd.conf (code=exited, status=1/FAILURE)

mrt 11 16:40:08 mach5.hviaene.thuis httpd[30400]: (2)No such file or directory: AH02291: Cannot access directory '/var/log/dirsrv/admin-serv/' for main error log
mrt 11 16:40:08 mach5.hviaene.thuis httpd[30400]: AH00014: Configuration check failed
mrt 11 16:40:08 mach5.hviaene.thuis systemd[1]: dirsrv-admin.service: control process exited, code=exited status=1
mrt 11 16:40:08 mach5.hviaene.thuis systemd[1]: Failed to start 389 Administration Server..
mrt 11 16:40:08 mach5.hviaene.thuis systemd[1]: Unit dirsrv-admin.service entered failed state.

I found that /var/log/dirsrv is empty, no admin-serv map present.

CC: (none) => herman.viaene

MGA4-32 on AcerD6620 Xfce.
Same remarks and outcome as Comment 3.

1. The debug packages build on a local (VM) mga4.
2. The package needs to be setup before it can be started.
The command is setup-ds-admin.pl
I haven't tried it, I am using the setup-kolab (from the kolab package) which sets up the admin server as well. I am setting up a virgin mga4 on my VM right and then try it.

(In reply to Herman Viaene from comment #3)
> MGA4-64 on HP-Probook 6555b KDE.
> Package 389-admin-debuginfo-1.1.35-1.1.mga4.x86_64.rpm is not present in
> updates testing for 64bits.
> I guess that shouldn't really matter.
> But at CLI I get:
> #  systemctl start dirsrv-admin.service
> Job for dirsrv-admin.service failed. See 'systemctl status
> dirsrv-admin.service' and 'journalctl -xn' for details.
> # systemctl -l status dirsrv-admin.service
> dirsrv-admin.service - 389 Administration Server.
>    Loaded: loaded (/usr/lib/systemd/system/dirsrv-admin.service; enabled)
>    Active: failed (Result: exit-code) since wo 2015-03-11 16:40:08 CET; 9s
> ago
>   Process: 30400 ExecStart=/usr/sbin/httpd -k start -f
> /etc/dirsrv/admin-serv/httpd.conf (code=exited, status=1/FAILURE)
> 
> mrt 11 16:40:08 mach5.hviaene.thuis httpd[30400]: (2)No such file or
> directory: AH02291: Cannot access directory '/var/log/dirsrv/admin-serv/'
> for main error log
> mrt 11 16:40:08 mach5.hviaene.thuis httpd[30400]: AH00014: Configuration
> check failed
> mrt 11 16:40:08 mach5.hviaene.thuis systemd[1]: dirsrv-admin.service:
> control process exited, code=exited status=1
> mrt 11 16:40:08 mach5.hviaene.thuis systemd[1]: Failed to start 389
> Administration Server..
> mrt 11 16:40:08 mach5.hviaene.thuis systemd[1]: Unit dirsrv-admin.service
> entered failed state.
> 
> I found that /var/log/dirsrv is empty, no admin-serv map present.

yes, the debug packages are in the updates_testing. U need to look in the debug repos?

Please use the 389-ds-base packages in updates_testing when testing 389-admin otherwise, worst they may fail but at least you would need to wayt about 10 minutes until the request for selunix times out.

Created attachment 6052 [details]
setup-ds-admin.log

this is the setup log from the command setup-ds-admin

I tested this update and it works great.
you need to add update_testing as a source and then install urpmi 389-ds-admin
It will pull in all requirements
Then as root, do setup-ds-admin.pl

See the attached log file for details

This will get the service setup and started.

Fedora has issued an advisory for 389-admin on February 5:
https://lists.fedoraproject.org/pipermail/package-announce/2015-March/151954.html

from http://lwn.net/Vulnerabilities/636944/

These kind of issues are not security issues for us since Mageia 4 due to protected_symlinks, so they are just bugs.  If you're doing an update for 389-admin anyway, if these bugs affect our version, you might want to fix them too.

I saw they fixed a lot of bugs, but normally we don't upgrade packages in released versions such as mga4, except if they are security upgrades.
I wouldn't mind to upgrade this time since it fixes over 50 bugs since we released our version.
But then I need to upgrade cauldron to, otherwise we will have a never version in mga4 than mga5.
I am skiing this week away from home and I just have my Netbook with me. So it has to wait until next week.

(And I filter out e-mails from the dev list on my home PC, so I will not get them here)

I upgraded this package in cauldron and in mga4.
These packages are now in updates_testing:
389-admin-1.1.38-1.mga4.src.rpm
389-admin-1.1.38-1.mga4.i586.rpm
389-admin-debuginfo-1.1.38-1.mga4.i586.rpm
and corresponding 64bit packages

The solve the issue in comment 10
They also resolve a ton of bugs that have been solved upstream.

MGA4-32 on AcerD6620 Xfce.
Installation: you need to enable Core Updates Testing Debug, otherwise 389-admin-debuginfo-1.1.38-1.mga4.i586.rpm isnot available.
Run into problem:
as root:
# setup-ds-admin.pl

==============================================================================
This program will set up the 389 Directory and Administration Servers.

It is recommended that you have "root" privilege to set up the software.
Tips for using this program:
  - Press "Enter" to choose the default and go to the next screen
  - Type "Control-B" then "Enter" to go back to the previous screen
  - Type "Control-C" to cancel the setup program

Would you like to continue with set up? [yes]: 

==============================================================================
Your system has been scanned for potential problems, missing patches,
etc.  The following output is a report of the items found that need to
be addressed before running this software in a production
environment.

389 Directory Server system tuning analysis version 23-FEBRUARY-2012.

NOTICE : System is i686-unknown-linux3.14.32-desktop-1.mga4 (1 processor).

WARNING: 749MB of physical memory is available on the system. 1024MB is recommended for best performance on large production system.

NOTICE : The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds
(120 minutes).  This may cause temporary server congestion from lost
client connections.

WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.  

WARNING  : The warning messages above should be reviewed before proceeding.

Would you like to continue? [no]: y

==============================================================================
Choose a setup type:

   1. Express
       Allows you to quickly set up the servers using the most
       common options and pre-defined defaults. Useful for quick
       evaluation of the products.

   2. Typical
       Allows you to specify common defaults and options.

   3. Custom
       Allows you to specify more advanced options. This is 
       recommended for experienced server administrators only.

To accept the default shown in brackets, press the Enter key.

Choose a setup type [2]: 1

==============================================================================
Server information is stored in the configuration directory server.
This information is used by the console and administration server to
configure and manage your servers.  If you have already set up a
configuration directory server, you should register any servers you
set up or create with the configuration server.  To do so, the
following information about the configuration server is required: the
fully qualified host name of the form
<hostname>.<domainname>(e.g. hostname.example.com), the port number
(default 389), the suffix, the DN and password of a user having
permission to write the configuration information, usually the
configuration directory administrator, and if you are using security
(TLS/SSL).  If you are using TLS/SSL, specify the TLS/SSL (LDAPS) port
number (default 636) instead of the regular LDAP port number, and
provide the CA certificate (in PEM/ASCII format).

If you do not yet have a configuration directory server, enter 'No' to
be prompted to set up one.

Do you want to register this software with an existing
configuration directory server? [no]: 

==============================================================================
Please enter the administrator ID for the configuration directory
server.  This is the ID typically used to log in to the console.  You
will also be prompted for the password.

Configuration directory server
administrator ID [admin]: 
Password: 
Password (confirm): 

==============================================================================
Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and typically has a
bind Distinguished Name (DN) of cn=Directory Manager.
You will also be prompted for the password for this user.  The password must
be at least 8 characters long, and contain no spaces.
Press Control-B or type the word "back", then Enter to back up and start over.

Directory Manager DN [cn=Directory Manager]: 
Password: 
Password (confirm): 

==============================================================================
The interactive phase is complete.  The script will now set up your
servers.  Enter No or go Back if you want to change something.

Are you ready to set up your servers? [yes]: 
Creating directory server . . .
Your new DS instance 'mach6' was successfully created.
Creating the configuration directory server . . .
Beginning Admin Server creation . . .
Creating Admin Server files and directories . . .
Updating adm.conf . . .
Updating admpw . . .
Registering admin server with the configuration directory server . . .
Updating adm.conf with information from configuration directory server . . .
Updating the configuration for the httpd engine . . .
Starting admin server . . .
output: Job for dirsrv-admin.service failed. See 'systemctl status dirsrv-admin.service' and 'journalctl -xn' for details.
Could not start the admin server.  Error: 256
Failed to create and configure the admin server
Exiting . . .
Log file is '/tmp/setupiEIhME.log'

and 

# systemctl -l status dirsrv-admin.service
dirsrv-admin.service - 389 Administration Server.
   Loaded: loaded (/usr/lib/systemd/system/dirsrv-admin.service; enabled)
   Active: failed (Result: exit-code) since vr 2015-03-20 12:02:44 CET; 41s ago
  Process: 27623 ExecStart=/usr/sbin/httpd -k start -f /etc/dirsrv/admin-serv/httpd.conf (code=exited, status=1/FAILURE)

mrt 20 12:02:44 mach6.hviaene.thuis httpd[27623]: httpd: Syntax error on line 136 of /etc/dirsrv/admin-serv/httpd.conf: Cannot load /usr/lib/dirsrv/modules/mod_admserv.so into server: /usr/lib/dirsrv/modules/mod_admserv.so: undefined symbol: admldapGetAuthDN
mrt 20 12:02:44 mach6.hviaene.thuis systemd[1]: dirsrv-admin.service: control process exited, code=exited status=1
mrt 20 12:02:44 mach6.hviaene.thuis systemd[1]: Failed to start 389 Administration Server..
mrt 20 12:02:44 mach6.hviaene.thuis systemd[1]: Unit dirsrv-admin.service entered failed state.

I found the same proble. I did upgrade the pacakge while I was away from home on vacation and didn't have access to test it.
It looks as if I need to upgrade 389-adminutil first. They have added this "admldapGetAuthDN" there but didn't require the updated version in the spec file of 389-admin-1.1.38

I have updated 389-adminutil to ver 1.1.21 and did a brief testing by upgrading on a vbox-mga4 389-admin to vers. 1.1.38-1mga4. I then did systemctl restart dirsrv-admin.service and got the error httpd: Syntax error on line 136 of /etc/dirsrv/admin-serv/httpd.conf: Cannot load /usr/lib/dirsrv/modules/mod_admserv.so into server: /usr/lib/dirsrv/modules/mod_admserv.so: undefined symbol: admldapGetAuthDN as described on comment 13.

I then upgraded 389-adminutil to vers. 1.1.21 and did systemctl restart dirsrv-admin.service and the service satrted w/o the problem described above.

The f9ollowing pacakges are no in updates_testing:
389-adminutil-1.1.21-1.mga4.src.rpm
389-adminutil-1.1.21-1.mga4.x86_64.rpm
389-adminutil-devel-1.1.21-1.mga4.x86_64.rpm
389-adminutil-debuginfo-1.1.21-1.mga4.x86_64.rpm
and corresponding i586 packages.
Please test them and push to updates. I then need to rebuild 389-admin because it depends on 389-adminutil-devel. It may doesn't need a rebuild, but to be save, I want to do it.

This was a little sneaky, upstream just mentioned they did upgrade 389-adminutil but didn't mention anywhere not even in the spec file that it was needed for 389-admin to work.
Please let me now when it has been pushed to updates, so I can submit 389-admin

(In reply to Thomas Spuhler from comment #15)
> I have updated 389-adminutil to ver 1.1.21 and did a brief testing by
> upgrading on a vbox-mga4 389-admin to vers. 1.1.38-1mga4. I then did
> systemctl restart dirsrv-admin.service and got the error httpd: Syntax error
> on line 136 of /etc/dirsrv/admin-serv/httpd.conf: Cannot load
> /usr/lib/dirsrv/modules/mod_admserv.so into server:
> /usr/lib/dirsrv/modules/mod_admserv.so: undefined symbol: admldapGetAuthDN
> as described on comment 13.
> 
> I then upgraded 389-adminutil to vers. 1.1.21 and did systemctl restart
> dirsrv-admin.service and the service satrted w/o the problem described above.
> 
> The f9ollowing pacakges are no in updates_testing:
> 389-adminutil-1.1.21-1.mga4.src.rpm
> 389-adminutil-1.1.21-1.mga4.x86_64.rpm
> 389-adminutil-devel-1.1.21-1.mga4.x86_64.rpm
> 389-adminutil-debuginfo-1.1.21-1.mga4.x86_64.rpm
> and corresponding i586 packages.
> Please test them and push to updates. I then need to rebuild 389-admin
> because it depends on 389-adminutil-devel. It may doesn't need a rebuild,
> but to be save, I want to do it.
> 
> This was a little sneaky, upstream just mentioned they did upgrade
> 389-adminutil but didn't mention anywhere not even in the spec file that it
> was needed for 389-admin to work.
> Please let me now when it has been pushed to updates, so I can submit
> 389-admin

Here is some additional info for testing. BTW, this was announced as a security upgrade upstream.

(In reply to Thomas Spuhler from comment #16)
> (In reply to Thomas Spuhler from comment #15)
> > I have updated 389-adminutil to ver 1.1.21 and did a brief testing by
> > upgrading on a vbox-mga4 389-admin to vers. 1.1.38-1mga4. I then did
> > systemctl restart dirsrv-admin.service and got the error httpd: Syntax error
> > on line 136 of /etc/dirsrv/admin-serv/httpd.conf: Cannot load
> > /usr/lib/dirsrv/modules/mod_admserv.so into server:
> > /usr/lib/dirsrv/modules/mod_admserv.so: undefined symbol: admldapGetAuthDN
> > as described on comment 13.
> > 
> > I then upgraded 389-adminutil to vers. 1.1.21 and did systemctl restart
> > dirsrv-admin.service and the service satrted w/o the problem described above.
> > 
> > The f9ollowing pacakges are no in updates_testing:
> > 389-adminutil-1.1.21-1.mga4.src.rpm
> > 389-adminutil-1.1.21-1.mga4.x86_64.rpm
> > 389-adminutil-devel-1.1.21-1.mga4.x86_64.rpm
> > 389-adminutil-debuginfo-1.1.21-1.mga4.x86_64.rpm
> > and corresponding i586 packages.
> > Please test them and push to updates. I then need to rebuild 389-admin
> > because it depends on 389-adminutil-devel. It may doesn't need a rebuild,
> > but to be save, I want to do it.
> > 
> > This was a little sneaky, upstream just mentioned they did upgrade
> > 389-adminutil but didn't mention anywhere not even in the spec file that it
> > was needed for 389-admin to work.
> > Please let me now when it has been pushed to updates, so I can submit
> > 389-admin
> 
> Here is some additional info for testing. BTW, this was announced as a
> security upgrade upstream.

http://directory.fedoraproject.org/docs/389ds/releases/release-console-1-1-9.html

Installed without problems on MGA4-64 HP Probook 6555b KDE
Same test and answers as per Comment 13 , except at the end:
The interactive phase is complete.  The script will now set up your
servers.  Enter No or go Back if you want to change something.

Are you ready to set up your servers? [yes]: 
Creating directory server . . .
Your new DS instance 'mach5' was successfully created.
Creating the configuration directory server . . .
Beginning Admin Server creation . . .
Creating Admin Server files and directories . . .
Updating adm.conf . . .
Updating admpw . . .
Registering admin server with the configuration directory server . . .
Updating adm.conf with information from configuration directory server . . .
Updating the configuration for the httpd engine . . .
Starting admin server . . .
The admin server was successfully started.
Admin server was successfully created, configured, and started.
Exiting . . .
Log file is '/tmp/setup0TaKmK.log'

[root@xxxx ~]# systemctl -l status dirsrv-admin.service
dirsrv-admin.service - 389 Administration Server.
   Loaded: loaded (/usr/lib/systemd/system/dirsrv-admin.service; enabled)
   Active: active (running) since wo 2015-03-25 14:00:17 CET; 2min 15s ago
  Process: 2348 ExecStart=/usr/sbin/httpd -k start -f /etc/dirsrv/admin-serv/httpd.conf (code=exited, status=0/SUCCESS)
 Main PID: 2349 (httpd)
   CGroup: /system.slice/dirsrv-admin.service
           ââ2349 /usr/sbin/httpd -k start -f /etc/dirsrv/admin-serv/httpd.conf
           ââ2350 /usr/sbin/httpd -k start -f /etc/dirsrv/admin-serv/httpd.conf
           ââ2351 /usr/sbin/httpd -k start -f /etc/dirsrv/admin-serv/httpd.conf

mrt 25 14:00:16 xxxx.yyyy.zzzz systemd[1]: Starting 389 Administration Server....
mrt 25 14:00:17 xxxx.yyyy.zzzz systemd[1]: PID file /var/run/dirsrv/admin-serv.pid not readable (yet?) after start.
mrt 25 14:00:17 xxxx.yyyy.zzzz systemd[1]: Started 389 Administration Server..

Whiteboard: (none) => MGA-4-64-OK

On MGA4-32 on AcerD620 Xfce. 
I keep running into:
Creating directory server . . .
Your new DS instance 'mach6' was successfully created.
Creating the configuration directory server . . .
Error: failed to open an LDAP connection to host 'mach6.hviaene.thuis' port '389' as user 'cn=Directory Manager'.  Error: unknown.
Failed to create the configuration directory server
Exiting . . .
This is described in Redhat bug 1155680, no real solution????

(In reply to Herman Viaene from comment #19)
> On MGA4-32 on AcerD620 Xfce. 
> I keep running into:
> Creating directory server . . .
> Your new DS instance 'mach6' was successfully created.
> Creating the configuration directory server . . .
> Error: failed to open an LDAP connection to host 'mach6.hviaene.thuis' port
> '389' as user 'cn=Directory Manager'.  Error: unknown.
> Failed to create the configuration directory server
> Exiting . . .
> This is described in Redhat bug 1155680, no real solution????

I have never tested it on a 32 bit box. In fact I haven't tested it a lot, since the current version doesn't start anyway. But according to the upstream ticket, it should have been fixed in 389-ds-base >1.3.2
https://fedorahosted.org/389/ticket/47935

We may should push this as it resolves the error it was filed for (wrong mod_nss.so file name in conf) and open a new bug. I then would report it upstream.
I think, there wouldn't be many users to run it on a 32 bit server anyway.

Thomas also posted this on the dev list, which looks like a relevant reference for this update:
http://www.port389.org/docs/389ds/releases/release-admin-1-1-38.html

Validating. 

Vague advisory uploaded with part of comment 0, srpms from comment 2 and comment 12 and refs from comment 21.

Keywords: (none) => validated_update
Whiteboard: MGA4-64-OK => advisory MGA4-64-OK
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2015-0035.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED