Hi the current upstream for this package is pointing to
http://www.stderr.net/apache/rpaf/ which for me at least seems to have
disappeared and from what I can tell is no longer supported.

I can see someone on github has improved this module and is actively
supporting it.
https://github.com/gnif/mod_rpaf

I propose that the upstream for this module be changed going forward to the
github repo as it seems better maintained. It also has a feature that I
think a lot of users for the module would benefit from.

In the current code base you must specify exactly which ip address
in RPAFproxy_ips which is not ideal. If your load balancer changes IP
addresses often which is the case in environments such as AWS ELB then you
never are sure what the load balancer's specific IP address is going to be.

The github repo feature allows you to set RPAFproxy_ips to a value such as "
172.0.0.0/24" which means you don't have to exactly match the IP address.
This is a must have feature at least for me if not others.

Regards,
Andrew

Control: reassign -1 libapache2-mod-rpaf 0.6-13

Is there any reason you can't use mod_remoteip?!

mod_remoteip also has this feature.

I don't see remoteip in the repository. Could you advise on the package
name in stable?

Does the remoteip package mean that this package shouldn't be changed or
removed from Debian?

Thanks,
Andrew

Sure.  Please read README.Debian of the rpaf package.

Hi,

Am 05.12.15 um 13:22 schrieb Sergey B Kirpichev:

mod_rpaf (at least https://github.com/gnif/mod_rpaf) has:

- RPAF_SetHTTPS (which can be emulated elsehow)
- RPAF_SetPort
- RPAF_ForbidIfNotProxy

anyway ... rpaf also provides the correct REMOTE_IP in the Logfiles as
far i can see.

Cheers, Jan.

Original rpaf module doesn't have such options.  So, from your
arguments - versions of rpaf <= jessie's can be replaced
with remoteip.

This is only option, I have doubts.  Others can be
emulated one way or another.

Sure, but I believe we should recommend remoteip.  Too many
people use rpaf just by accident of the history.

If just one directive seems to be important for you - new module
could be added too.

BTW, I'll ask Debian Apache maintainers, maybe they have good
suggestions about such transition.

Hi,

I stumbled on that bug, and found that MOD_RPAF here https://github.com/gnif/mod_rpaf
has a 0.8.4 version on which the apache 2.4 compatibility is assured,

I compiled it using libapache2-mod-rpaf source package, only replacing the mod_rpaf.c (and debian/rules to use mod_rpaf.c instead of 2.0.c)

The difference is important, because with current Stretch package, we have
- the right IP address (the one from X-Forwarded-For) in LOG FILES
- BUT the wrong one on CGI processes such as PHP or others, where we have the real client IP (127.0.0.1 in my case)

with rpaf 0.8.4 we have the right IP address everywhere.

Could you please package the upstream in debian ?

People advising us to use remoteip, I don't see it in debian : https://packages.debian.org/search?keywords=libapache2-mod-remoteip


thanks,
Benjamin Sonntag

Original rpaf is also broken nowadays with FPM, as detailed e.g. in
https://github.com/gnif/mod_rpaf/issues/33 .

The big downside of mod_remoteip is that it requires to change the
default LogFormat.

I think that the current situation is not helping anybody.
Some possible solutions are:
- you actually ask for mod_rpaf to be removed from Debian
- you package a modern version of mod_rpaf
- you orphan the package and let somebody else adopt it so that they can
  package a modern version

I did, long time ago.