Updated to 1.3.6 and changed systemd unit names to dirsrv.
@ImNtReal: since you seem to be reacting quicker than I for updated. Are you interested in taking ownership of this package?
Search Criteria
Package Details: 389-ds-base 1.4.0.7-1
Git Clone URL: | https://aur.archlinux.org/389-ds-base.git (read-only) |
---|---|
Package Base: | 389-ds-base |
Description: | 389 Directory Server (base) |
Upstream URL: | http://port389.org/ |
Licenses: | |
Conflicts: | |
Provides: | |
Submitter: | Aierk |
Maintainer: | javitonino (ImNtReal) |
Last Packager: | ImNtReal |
Votes: | 12 |
Popularity: | 0.048879 |
First Submitted: | 2009-07-28 01:02 |
Last Updated: | 2018-04-16 13:16 |
Dependencies (13)
- cyrus-sasl
- cyrus-sasl-gssapi
- icu (icu-svn)
- libevent (libevent-git, libevent-fb)
- libsystemd (eudev-git, libsystemd-eudev-standalone, libeudev-systemd, libsystemd-selinux, libsystemd-git)
- lm_sensors (lm_sensors-max_of_fctemps, lm_sensors-git)
- net-snmp (net-snmp-lmsensors)
- openldap
- perl-netaddr-ip
- perl-socket (perl)
- doxygen (doxygen-git) (make)
- python-lib389 (optional) – Python managemnt scripts
- python2-lib389 (optional) – Python2 version
Required by (5)
- 389-adminutil
- kolab
- mozldap (requires svrcore)
- pykolab (optional)
- slapi-nis
Sources (1)
Latest Comments
ImNtReal commented on 2017-03-24 20:51
javitonino commented on 2017-03-24 19:59
ImNtReal commented on 2017-03-22 16:25
Here's an updated PKGBUILD: http://pastebin.com/3ArUb5Bn
Note: You may need to clean up systemd files after upgrading to this due to changing the .target from 389-ds-base.target to the default of dirsrv.target.
javitonino commented on 2017-01-19 20:03
Updated
@ImNtReal I think that's a good idea, I'd got for dirsvr. However, I would wait until at least a minor version bump to change this, to avoid disrupting current installations as much as possible.
ImNtReal commented on 2017-01-10 18:24
I think we should consider changing the systemd group name to dirsrv.target, or similar because systemctl enable 389-server.target makes more sense than 389-ds-base.target.
r3pek commented on 2017-01-06 01:14
I made a resquest on svrcore aur package so that it get compiled with "--with-systemd" and fix the LDAPS problem @ImNtReal was/is getting.
ImNtReal commented on 2016-10-17 13:12
I've updated my main instance and 1.3.5.13 seems to work fine with no patches, and no tcp_wrappers.
ImNtReal commented on 2016-10-11 13:12
1.3.5.13 builds fine for me without tcp_wrappers, or the pkg-config patch. Haven't had a chance to test it, yet, though.
ImNtReal commented on 2016-06-03 19:20
I'm not sure what caused it, but LDAPS has stopped working on my system. During startup of dirsrv, I get: SSL alert: Security Initialization: Unable to create PinObj (Netscape Portable Runtime error -5977 - Failure to load dynamic library.
Does anyone know if it uses svrcore for ssl/tls? It seems to link against libssl and libnss.
I've worked around the issue by frontending it with stunnel, for now, in case others have this issue.
javitonino commented on 2016-05-27 18:22
Updated to 1.3.5.4. Thanks @chenxiaolong for the svrcore update. I guess it makes sense to pass svrcore ownership to me, as it appears to be released simultaneously with 389-ds now, so I'll take care of it if you orphan it.
chenxiaolong commented on 2016-05-26 01:03
@javitonino: I've updated the svrcore package with your PKGBUILD. If you're interested in maintaining that package, let me know and I can disown it.
javitonino commented on 2016-05-22 10:41
Version 1.3.5 requires a newer svrcore than is currently available in the AUR. I have flagged it out of date and notified the maintainer. I will update this package as soon as svrcore is updated.
Meanwhile, you can grab both updated packages from: https://github.com/javitonino/pkgbuilds
javitonino commented on 2015-08-19 11:17
Should be fixed. New installs will place files in /var instead of /usr/var. Old install should keep working with files in /usr/var. Thanks!
grawity commented on 2015-08-16 19:52
After setup-ds.pl, the generated configuration (dse.ldif) seems to contain weird paths:
nsslapd-schemadir: /etc/dirsrv/slapd-rain/schema
nsslapd-lockdir: /usr/var/lock/dirsrv/slapd-rain
nsslapd-tmpdir: /tmp
nsslapd-certdir: /etc/dirsrv/slapd-rain
nsslapd-ldifdir: /usr/var/lib/dirsrv/slapd-rain/ldif
nsslapd-bakdir: /usr/var/lib/dirsrv/slapd-rain/bak
nsslapd-rundir: /usr/var/run/dirsrv
nsslapd-accesslog: /usr/var/log/dirsrv/slapd-rain/access
Pretty sure that should be just "(/var)/run/dirsrv"...
javitonino commented on 2015-05-17 09:54
Updated to latest version and fixed compilation problems.
javitonino commented on 2015-02-19 14:52
Package creates /etc/systemd/system/389-ds-base.wants but it should be 389-ds-base.target.wants.
As of now, starting 389-ds-base.target does not run anything, as it executes units inside /etc/systemd/system/389-ds-base.target.wants.
It is a simple fix in the install command of package()
chetwisniewski commented on 2015-01-18 21:51
Broken after pacman update to 4.2. Line 38 of PKGBUILD needs to reference /run instead of /var.
Aierk commented on 2012-01-09 18:32
I ask about db5 and Rick Megginson replied me:
"Yes. There is some porting work required to support db5. We currently
only support db4."
@javitonino, I wouldn't mind. Isn't there a way to have co-maintainers, now?