lprng-devel Mailing List for LPRng

Bernhard R. Link schrieb:
> Attached three patches for discussion. The first two
> make the work of the third a bit easier by removing kerberos4
> and pgp support.
> 
> Kerberos5 exists now a very long time, so I guess kerberos4 will no
> longer be needed. It's also relatively complicated by having more
> than one way to be reached by code (and I do not know what is needed
> to make it even compile).
> 
> using pgp for printing is also quite outdated (Does anyone even know
> someone that uses pgp and not gpg?), calling external programs and
> needing termporary files it might also make things more problematic
> in a future clean design of plugins. So I suggest removing it.
> 
> The third patch actually adds plugins:
> 
> The advantage of dynamic loadable plugins is that all their libraries
> are no longer needed when not using them and when using one only its
> own libraries need to be loaded. As a side effect that allows
> distributions to make packages that support all those methods without
> the package needing to depend on all the libraries (a simple Suggests
> instead of an Depend in Debian), so people can install lprng without
> needing to install kerberos libraries and the libraries kerberos
> libraries depend upon.
> 
> The current implementation is quite low-tech and not very nice but
> functional:
> 
> 1) It's not using libtool but just tries some compiler flags and if
> they do not work falls back to do without plugins. As there is a
> easy fallback (just compile in as done previously), having all the
> horrors of libtool (config.guess/sub files, all those libtool scripts,
> checking for fortran in configure) are avoided, as none of the features
> are needed.
> 
> 2) The generated plugins just use all functions and global variables
> from the binary itself. This has the disadvantage that the binary has
> to be compiled with -export-dynamic and the plugins cannot be compiled
> when -Wl,-z,defs is in the LDFLAGS and that it looks a bit dirty.
> But changing that means to rewrite most of LPRngs file handling
> (which is a good idea anyway, but definitly nothing possible
>  middle- or even short-term).
> 
> It's quite experimental and definitly needs a lot of testing, but
> it mostly seems to work (I tested the "test" and "md5" authenticators).
> 
> The patch in its current state (modulo possible mistakes still hidden),
> should not change behaviour except in one case: It currently does no
> longer output a list of all authentication possibilites. That could
> be readded, but would most likely mean to load all authentication
> plugins to get that information. perhaps just listing in which
> directly to look would be a more sensible solution.
> 
> Hochachtungsvoll,
> 	Bernhard R. Link
> 

Hi BRL,
thanks for your afford to remove dead cruft. I think we can go with that until some one
will complain loudly.

Why do you want to use plug-ins at all ? i see you struggle to make them work in the current
environment. perhaps we can live with a compiled version first like the scheduler ?
It is not pretty either :(

re,
 wh

Attached three patches for discussion. The first two
make the work of the third a bit easier by removing kerberos4
and pgp support.

Kerberos5 exists now a very long time, so I guess kerberos4 will no
longer be needed. It's also relatively complicated by having more
than one way to be reached by code (and I do not know what is needed
to make it even compile).

using pgp for printing is also quite outdated (Does anyone even know
someone that uses pgp and not gpg?), calling external programs and
needing termporary files it might also make things more problematic
in a future clean design of plugins. So I suggest removing it.

The third patch actually adds plugins:

The advantage of dynamic loadable plugins is that all their libraries
are no longer needed when not using them and when using one only its
own libraries need to be loaded. As a side effect that allows
distributions to make packages that support all those methods without
the package needing to depend on all the libraries (a simple Suggests
instead of an Depend in Debian), so people can install lprng without
needing to install kerberos libraries and the libraries kerberos
libraries depend upon.

The current implementation is quite low-tech and not very nice but
functional:

1) It's not using libtool but just tries some compiler flags and if
they do not work falls back to do without plugins. As there is a
easy fallback (just compile in as done previously), having all the
horrors of libtool (config.guess/sub files, all those libtool scripts,
checking for fortran in configure) are avoided, as none of the features
are needed.

2) The generated plugins just use all functions and global variables
from the binary itself. This has the disadvantage that the binary has
to be compiled with -export-dynamic and the plugins cannot be compiled
when -Wl,-z,defs is in the LDFLAGS and that it looks a bit dirty.
But changing that means to rewrite most of LPRngs file handling
(which is a good idea anyway, but definitly nothing possible
 middle- or even short-term).

It's quite experimental and definitly needs a lot of testing, but
it mostly seems to work (I tested the "test" and "md5" authenticators).

The patch in its current state (modulo possible mistakes still hidden),
should not change behaviour except in one case: It currently does no
longer output a list of all authentication possibilites. That could
be readded, but would most likely mean to load all authentication
plugins to get that information. perhaps just listing in which
directly to look would be a more sensible solution.

Hochachtungsvoll,
	Bernhard R. Link

diffstat remove_krb4.diff:
 INSTALL                   |    3 
 configure.ac              |   41 -----
 src/auth/krb5_auth.c      |  366 ----------------------------------------------
 src/common/copyright.c    |    3 
 src/common/lpd_dispatch.c |    5 
 src/common/user_auth.c    |    3 
 src/include/krb5_auth.h   |    3 
 7 files changed, 424 deletions(-)

diffstat removepgp.diff
 INSTALL                |    2 
 README                 |    2 
 configure.ac           |    3 
 man/lpd.n              |   18 -
 man/lpd.perms.n        |    2 
 man/printcap.n         |    6 
 src/common/user_auth.c |  770 -------------------------------------------------
 src/include/getqueue.h |    1 
 src/include/lp.h       |    1 
 src/vars.c             |    2 
 10 files changed, 7 insertions(+), 800 deletions(-)

diffstat plugins.diff
 acinclude.m4            |   68 +++++++++++++++++++++++++
 configure.ac            |    8 +++
 src/Makefile.am         |   58 ++++++++++++++++++++-
 src/auth/krb5_auth.c    |   12 ++++
 src/auth/md5_auth.c     |    9 +++
 src/auth/ssl_auth.c     |    8 +++
 src/auth/test_auth.c    |    9 +++
 src/common/user_auth.c  |  128 +++++++++++++++++++++++++++++++++++++++++++++++-
 src/include/krb5_auth.h |    3 -
 src/include/lp.h        |    1 
 src/include/ssl_auth.h  |    2 
 src/include/user_auth.h |    9 +++
 src/vars.c              |    7 ++
 13 files changed, 316 insertions(+), 6 deletions(-)

* Bernhard R. Link <br...@de...> [090809 16:31]:
> I've applied the following patch which reduces what gets linked into
> checkpc and into monitor. That especially makes it unnecessary to link
> them with the libraries.

This time really attached...

Hochachtungsvoll,
	Bernhard R. Link

I've applied the following patch which reduces what gets linked into
checkpc and into monitor. That especially makes it unnecessary to link
them with the libraries.

Hochachtungsvoll,
	Bernhard R. Link

I've applied to attached two patches.

The first moves the md5 and test authentication
modules to their own files in src/auth/ and moving the kerberos and ssl
modules there, too. This cleans up the code layout and makes it much
easier for me to experiment with moving that code into loadable plugins.
(It does not move pgp because depending how to implement plugins it will
have to vanish before that as it very different to the rest).

The second patch moves the "struct security" structs defining the
different authenticators into the modules, so that in plugin-like
code they are at the same place in both cases.

Both only move code around, no behaviour should change.

Hochachtungsvoll,
	Bernhard R. Link

I've applied the attached patch which is supposed to make
it build under GNU/kFreeBSD.

Hochachtungsvoll,
	Bernhard R. Link