FAMP with Apache 'authnz_ldap' module?

S

sean137

Hi all. I'm a FreeBSD newbie and trying to set up FAMP to run some web services. I've successfully set up WordPress already for example.

But now (for a different service), I need these two apache modules: 'ldap' & 'authnz_ldap' and it seems they are not there after I install using 'pkg install'.

Some searching suggests I need to use 'ports' instead of 'packages', is that the only way? It seems quite a bit harder...

Thanks.
 
OK, thanks, I'll give it a shot. On ubuntu these apache modules are available by default when doing 'apt install apache24', any idea why they are not on FreeBSD?
 
Well, the ports system was pretty easy to use! Nice.

But alas, it seems it failed, and this is on a fresh VM:

Code: 
checking whether to enable mod_authnz_ldap... checking dependencies
checking for ldap support in apr/apr-util... no
configure: WARNING: apr/apr-util is compiled without ldap support
checking whether to enable mod_authnz_ldap... configure: error: mod_authnz_ldap has been requested but can not be built due to prerequisite failures
===>  Script "configure" failed unexpectedly.
Please report the problem to apache@FreeBSD.org [maintainer] and attach the
"/usr/ports/www/apache24/work/httpd-2.4.43/config.log" including the output
of the failure of your make command. Also, it might be a good idea to provide
an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.
make: stopped in /usr/ports/www/apache24
 
Ah, seems it's because I did `make install clean BATCH=yes`. Without the `BATCH=yes` part, I get the opportunity to build APR with LDAP support.

Is it a bug that it didn't work with BATCH=yes? Or am I expecting it to be too smart?
 
No, it's working as designed. BATCH skips any user interaction, therefore just builds ports with options already selected (e.g. from having them in your /etc/make.conf or from running make config earlier).

There's also the convention that similar options should have the same name in all ports. If you add
Code: 
OPTIONS_SET+=    LDAP
any port that has an LDAP option will have it set automatically. To enable it for apache24 only, the syntax would be
Code: 
www_apache24_SET+=    LDAP

If you want to make good use of the BATCH option, you can configure everything upfront with make config-recursive or configure all your options from /etc/make.conf as shown above. If you find yourself building a lot of ports regularly, I'd recommend to build your own package repository from source using ports-mgmt/poudriere.
 
The problem there is that apr is a different port than apache24, and in order to enable LDAP in apache, you also have to enable it in apr. If you didn't have apr already installed via pkg, it would have worked when it was installed via ports.

Once again, it's the mixing pkg and ports problem. ?

Remove apr and then use the above recommendation with make.conf
 
Thanks all for your replies. Very helpful!

msplsh: I *didn't* have apr from pkg before hand. The issue was that if one turns on the authnz_ldap build option for apache, there's no magic that automatically enables required options in the built dependencies. It would be cool, but it does happen.
 
The question is: how? There's no mechanism to test for options of another port in a port's Makefile. And that would be what you'd need to at least catch the error and give a meaningful error message instead of a failing build.

Allowing a port to force options onto another port would be a pandora's box. No, that's not "a touch more automation", it's an idea bringing so many complexities, you better not touch it. Just think about what should happen if the other port is already installed without the option? And what should happen if enabling the option would break yet other dependent ports?

Even the "simpler" idea to have a way to specify a dependency on a port with certain options, so you can fail with a meaningful error message, is not all that simple: There's no guarantee your currently configured options reflect the state of the package already installed. So you'd have to introspect installed ports. This can be done with pkg query, but integrating that in the existing dependencies framework wouldn't be simple and it's somewhat questionable it's worth the effort and complexity.

The only sane thing is already done: make sure semantically identical options of different ports have the same name.
 
Zirias said:
how?
Click to expand...

IDK

Zirias said:
it's an idea bringing so many complexities, you better not touch it
Click to expand...
Yeah, well, that's FreeBSD's current M.O. ? Too hard, don't try, why bother, just don't do that then.

Zirias said:
what should happen if the other port is already installed without the option?
Click to expand...

Throw a message that it doesn't have the option and stop?

Zirias said:
And what should happen if enabling the option would break yet other dependent ports?
Click to expand...

The same thing that happens when you try and enable it in make.conf?
 
Before anyone gives me stink-eye: I'm not saying that Freebsd should be more like Gentoo. I myself have migrated to Freebsd and away from Gentoo.

Zirias said:
The question is: how?
Click to expand...
The way Gentoo handles this is by adding the option (use flag in Gentoo parlance) to the dependency. In other words if port foo depends on port bar and port foo with LDAP needs port bar with LDAP the dependency cannot be satisfied by bar without LDAP, whether it's installed or not.

Zirias said:
Allowing a port to force options onto another port would be a pandora's box. No, that's not "a touch more automation", it's an idea bringing so many complexities, you better not touch it. Just think about what should happen if the other port is already installed without the option? And what should happen if enabling the option would break yet other dependent ports?
Click to expand...
The way Gentoo handles it is by prompting you to (re)build and (re)install any dependent ports with missing options.

So why am I not using Gentoo anymore? The reasons are many, and one of them is that package management was becoming increasingly unstable and unpredictable, but that was not the biggest pain point.
 
Jose said:
package management was becoming increasingly unstable and unpredictable
Click to expand...
So, you don't see any relation to the issue discussed here?

Yes, dependencies including options could probably be done, although one should be aware of the consequences. Trying to automatically satisfy them definitely is pandora's box.
 
Zirias said:
So, you don't see any relation to the issue discussed here?
Click to expand...
The use flags system seemed to work pretty well, TBH. It wasn't without problems, but the last big problem I had was with updating Python from 3.6 to 3.7. I can't lay that one at the feet of the Gentoo devs. I personally think the Python Steering Committee has lost the plot, but we're wandering quite a bit off the topic now.

Zirias said:
Yes, dependencies including options could probably be done, although one should be aware of the consequences. Trying to automatically satisfy them definitely is pandora's box.
Click to expand...
Gentoo did have an option to automate this process, but I never enabled it. I thought it unlikely that it would solve more problems than it would cause.
 
The FreeBSD way let all the control in the user. The error is readable :
sean137 said:
checking for ldap support in apr/apr-util... no configure: WARNING: apr/apr-util is compiled without ldap support
Click to expand...
Maybe the solution can be shown here ('please enable LDAP in make.conf and reinstall apr').
 
Hakaba said:
The error is readable :
Click to expand...
In this case, yes. But it's coming from the upstream build system, so you can't rely on a readable error message here in other cases. That's why explicit dependencies on the options of other ports would indeed be an improvement, I just wrote above why even that is not simple, you can't just check options currently configured but have to examine the actual installed package to make it reliable. Still, I'm pretty sure this could be done and would be another improvement to the ports system. So volunteering bmake wizards, take your next project please ;)

But, what I'd strongly discourage would be attempting to satisfy such dependencies automatically, for the reasons I already gave examples. I forgot to mention another important one: Just adding an option to e.g. /var/db/ports could also lead to an inconsistent configuration, e.g. because it can't be combined with another option the user already set. For this case, the ports system just bails out at check-sanity, which is the only sane thing to do, as only the user could know how to "fix" his options (e.g. which one of a set of conflicting ones he really needs to keep).
 
So it's been a few weeks, but I got `apr1` and `apache24` built from ports with the LDAP options enabled. Everything worked, yay!

But now when trying to start apache I see in the error log: "Module mod_ldap missing".

I suspect that updating/installing some other packages may have broken this. Is there any problem with having things like PHP from packages but apache from ports?
 
Feels like there's a bit missing in the middle of the story?

1) You got it all working - "yay!"
2) Something happened? What?
3) Apache now says "mod_ldap missing"

What is number 2? Apologies if I've got the wrong end of the stick.

But generally speaking it's difficult to mix ports and packages unless you know what you are doing - so I think the advice is to stick to one or the other (and generally speaking the one is packages) - or you'll have issues. Obviously in this case you started with packages but needed some extra non-packaged option.
 
You must log in or register to reply here.
Back
Top