n the oldest available and it usually works.
It *usually* works, but you can't expect it to. At least, not when your
product costs upwards of 10k and is expected to be rock-stable. You just
can't take that risk, it would be stupid. Not taking the risk costs virtually
nothing.
--
Simon Perreault -- http://nomis80.org
On Thursday 23 June 2005 19:54, James Yonan wrote:
> I was thinking more about someone who builds a binary RPM on a machine
> that has a correctly linked pam-modules set causing autoconf to sense this
> -- now that RPM can't be used on a machine with an earlier broken version
> of pam-modules.
Tha
On Thursday 23 June 2005 12:05, James Yonan wrote:
> One concern I would have is whether the PAM version test at build time is
> always predictive of what the PAM version will be at run time.
No, but then that would be going into the realm of cross-compiling.
On Wednesday 22 June 2005 15:15, Simon Perreault wrote:
> That's a bug that should be reported
> to SUSE.
...and here is the patch that should be submitted to them. I won't do so, I
don't want to help a distro which has given me so much trouble. (Much more
than only op
On Wednesday 22 June 2005 14:59, Simon Perreault wrote:
> I've also rebuilt the RPM (on a FC4 system, because I
> deleted my SUSE 9.1 vmware) and my rebuilt RPM does not have the bug!
AH! I understand now! Even though pam_unix.so is *built* in the pam RPM, it is
not *included* in t
On Wednesday 22 June 2005 14:25, Matthias Andree wrote:
> Parts of your assumption about ldd -r or linkage of the PAM modules
> against libpam don't hold. I haven't yet managed to test the whole
> setup.
I don't get it. The original 0.78 tarball from
http://www.kernel.org/pub/linux/libs/pam/pre/l
On Wednesday 22 June 2005 11:10, Matthias Andree wrote:
> Is this portable to non-GNU makes?
> If it is not, does OpenVPN require GNU make? I don't think it does.
I'm afraid it's non-portable. Damn.
> Is there a broken-out C program that fails to link at run-time if the
> workaround is required?
On Wednesday 22 June 2005 04:44, Matthias Andree wrote:
> This could be run and determined automatically by the autoconf/automake
> couple, automake supports conditional compilation (i. e. depending on
> autoconf findings, link another module into a program, or something like
> that).
Yes, that wo
On Wednesday 22 June 2005 00:22, James Yonan wrote:
> Thanks for the analysis. Because of the PAM bug, I think that
> openvpn-auth-pam will need to support the dlopen workaround for some time
> to come.
Yes, I have been thinking the same.
> Maybe the solution would be to set up an alternative Ma
On Monday 20 June 2005 22:42, James Yonan wrote:
> When I apply your patch and run on SuSE 9.1 with the default "login" PAM
> module (pam-0.77-221):
>
> plugin openvpn-auth-pam.so "login login USERNAME password PASSWORD"
>
> I get:
>
> AUTH-PAM: BACKGROUND: user 'x' failed to authenticate: Modu
On Sunday 19 June 2005 18:42, Matthias Andree wrote:
> > .so's are only included in -devel packages because their only use is when
> > linking.
>
> False.
True. Let me explain why.
> The linker, when linking a shared object, just writes a line
> "bind library libfoo.so.4.2 at run time" into the
tch.
Please take a look at the patch I sent previously, you seem to have overlooked
it. It contains all the necessary changes.
--
Simon Perreault -- http://nomis80.org
On Tuesday 14 June 2005 23:24, James Yonan wrote:
> When I was writing the auth-pam plugin, I had problems dynamically linking
> the plugin to PAM unless OpenVPN itself was also dynamically linked to PAM
> (which I didn't want to do).
What kind of problem did you encounter? It seems to work perfec
On Tuesday 14 June 2005 12:34, Simon Perreault wrote:
> I am wondering why the PAM library is dlopened by the auth-pam plugin. Why
> can't it simply be linked with it?
More specifically, why can't the attached patch be applied?
Hi,
I am wondering why the PAM library is dlopened by the auth-pam plugin. Why
can't it simply be linked with it?
Thanks for not making fun of me for asking this stupid question. ;)
On Friday 20 May 2005 12:36, James Yonan wrote:
> You can declare C function prototypes in C++ code with
>
> extern "C" {
> include "openvpn-plugin.h"
> }
>
> to maintain compatibility between the C and C++ namespaces.
For more information, check out
http://www.parashift.com/c
On Wednesday 18 May 2005 09:40, Simon Perreault wrote:
> 1) reopen stdin, stdout and stderr to /dev/null when --daemon option is
> specified (need a way to access options structure in the plugin)
Here's a patch using the first solution. Please consider applying.
Index
Hi,
The close_fds_except() function in the auth-pam plugin contains a bug, but it
seems to be by design. It doesn't close standard fds (stdin, stdout, stderr).
This means that a program that starts openvpn and reads its stdout from a
pipe will never receive EOF and will idle forever.
To reprod
18 matches
Mail list logo
