Skip to content
GitLab
Commit 19883d7f authored by Quanah Gibson-Mount's avatar Quanah Gibson-Mount
Browse files

*** empty log message ***

parent 182dacfa
Expand all Hide whitespace changes
Inline Side-by-side
contrib/slapd-modules/nssov/Makefile
View file @ 19883d7f
......@@ -24,7 +24,7 @@ OPT=-g -O2
CC=gcc
LDAP_INC=-I$(LDAPOBJ)/include -I$(LDAPSRC)/include -I$(LDAPSRC)/servers/slapd
NLDAPD_INC=-Inss-ldapd
NLDAPD_INC=-Inss-pam-ldapd
INCS=$(LDAP_INC) $(NLDAPD_INC)
LDAP_LIB=-lldap_r -llber
......@@ -40,7 +40,7 @@ moduledir = $(libexecdir)$(ldap_subdir)
sysconfdir = $(prefix)/etc$(ldap_subdir)
schemadir = $(sysconfdir)/schema
all: install
all: nssov.la
XOBJS = tio.lo
......@@ -52,8 +52,8 @@ OBJS = alias.lo ether.lo group.lo host.lo netgroup.lo network.lo \
.c.lo:
$(LIBTOOL) --mode=compile $(CC) $(OPT) $(DEFS) $(INCS) -c $<
tio.lo: nss-ldapd/common/tio.c
$(LIBTOOL) --mode=compile $(CC) $(OPT) $(DEFS) $(NLDAPD_INC) -c $?
tio.lo: nss-pam-ldapd/tio.c
$(LIBTOOL) --mode=compile $(CC) $(OPT) $(DEFS) $(INCS) -c $?
$(OBJS): nssov.h
......@@ -68,3 +68,4 @@ install: nssov.la
clean:
rm -f *.*o *.la .libs/*
rm -rf .libs
contrib/slapd-modules/nssov/README
View file @ 19883d7f
......@@ -4,12 +4,15 @@ same IPC protocol as Arthur de Jong's nss-ldapd, and a complete
copy of the nss-ldapd source is included here. It also handles
PAM requests.
To use this code, you will need the client-side stub library from
nss-ldapd (which resides in nss-ldapd/nss). You will not need the
nslcd daemon; this overlay replaces that part. You should already
be familiar with the RFC2307 and RFC2307bis schema to use this
overlay. See the nss-ldapd/README for more information on the
schema and which features are supported.
To use this code, you will need the client-side stuf library from
nss-pam-ldapd. You can get it from:
http://arthurdejong.org/nss-pam-ldapd
You will not need the nslcd daemon; this overlay replaces that part.
To disable building of the nslcd daemon in nss-pam-ldapd, add the
--disable-nslcd option to the nss-pam-ldapd configure script. You
should already be familiar with the RFC2307 and RFC2307bis schema
to use this overlay. See the nss-pam-ldapd README for more information
on the schema and which features are supported.
To use the overlay, add:
......
contrib/slapd-modules/nssov/alias.c
View file @ 19883d7f
......@@ -83,7 +83,7 @@ static int write_alias(nssov_alias_cbp *cbp,Entry *entry)
/* for each name, write an entry */
for (i=0;!BER_BVISNULL(&names[i]);i++)
{
WRITE_INT32(cbp->fp,NSLCD_RESULT_SUCCESS);
WRITE_INT32(cbp->fp,NSLCD_RESULT_BEGIN);
WRITE_BERVAL(cbp->fp,&names[i]);
WRITE_BVARRAY(cbp->fp,members);
}
......@@ -97,7 +97,7 @@ NSSOV_HANDLE(
char fbuf[1024];
struct berval filter = {sizeof(fbuf)};
filter.bv_val = fbuf;
READ_STRING_BUF2(fp,cbp.buf,sizeof(cbp.buf));
READ_STRING(fp,cbp.buf);
cbp.name.bv_len = tmpint32;
cbp.name.bv_val = cbp.buf;,
Debug(LDAP_DEBUG_TRACE,"nssov_alias_byname(%s)\n",cbp.name.bv_val,0,0);,
......
contrib/slapd-modules/nssov/ether.c
View file @ 19883d7f
......@@ -111,7 +111,7 @@ static int write_ether(nssov_ether_cbp *cbp,Entry *entry)
for (i=0;!BER_BVISNULL(&names[i]);i++)
for (j=0;!BER_BVISNULL(&ethers[j]);j++)
{
WRITE_INT32(cbp->fp,NSLCD_RESULT_SUCCESS);
WRITE_INT32(cbp->fp,NSLCD_RESULT_BEGIN);
WRITE_BERVAL(cbp->fp,&names[i]);
WRITE_ETHER(cbp->fp,ethers[j]);
}
......@@ -126,7 +126,7 @@ NSSOV_HANDLE(
struct berval filter = {sizeof(fbuf)};
filter.bv_val = fbuf;
BER_BVZERO(&cbp.addr);
READ_STRING_BUF2(fp,cbp.buf,sizeof(cbp.buf));
READ_STRING(fp,cbp.buf);
cbp.name.bv_len = tmpint32;
cbp.name.bv_val = cbp.buf;,
Debug(LDAP_DEBUG_TRACE,"nssov_ether_byname(%s)\n",cbp.name.bv_val,0,0);,
......
contrib/slapd-modules/nssov/group.c
View file @ 19883d7f
......@@ -248,7 +248,7 @@ static int write_group(nssov_group_cbp *cbp,Entry *entry)
names[i].bv_val);
continue;
}
WRITE_INT32(cbp->fp,NSLCD_RESULT_SUCCESS);
WRITE_INT32(cbp->fp,NSLCD_RESULT_BEGIN);
WRITE_BERVAL(cbp->fp,&names[i]);
WRITE_BERVAL(cbp->fp,&passwd);
WRITE_TYPE(cbp->fp,gid,gid_t);
......@@ -277,7 +277,7 @@ NSSOV_HANDLE(
char fbuf[1024];
struct berval filter = {sizeof(fbuf)};
filter.bv_val = fbuf;
READ_STRING_BUF2(fp,cbp.buf,sizeof(cbp.buf));
READ_STRING(fp,cbp.buf);
cbp.name.bv_len = tmpint32;
cbp.name.bv_val = cbp.buf;
if (!isvalidgroupname(&cbp.name)) {
......@@ -316,7 +316,7 @@ NSSOV_HANDLE(
char fbuf[1024];
struct berval filter = {sizeof(fbuf)};
filter.bv_val = fbuf;
READ_STRING_BUF2(fp,cbp.buf,sizeof(cbp.buf));
READ_STRING(fp,cbp.buf);
cbp.user.bv_len = tmpint32;
cbp.user.bv_val = cbp.buf;
if (!isvalidusername(&cbp.user)) {
......
contrib/slapd-modules/nssov/host.c
View file @ 19883d7f
......@@ -91,7 +91,7 @@ static int write_host(nssov_host_cbp *cbp,Entry *entry)
addrs = a->a_vals;
numaddr = a->a_numvals;
/* write the entry */
WRITE_INT32(cbp->fp,NSLCD_RESULT_SUCCESS);
WRITE_INT32(cbp->fp,NSLCD_RESULT_BEGIN);
WRITE_BERVAL(cbp->fp,&name);
if ( dupname >= 0 ) {
WRITE_INT32(cbp->fp,numname-1);
......@@ -118,7 +118,7 @@ NSSOV_HANDLE(
struct berval filter = {sizeof(fbuf)};
filter.bv_val = fbuf;
BER_BVZERO(&cbp.addr);
READ_STRING_BUF2(fp,cbp.buf,sizeof(cbp.buf));
READ_STRING(fp,cbp.buf);
cbp.name.bv_len = tmpint32;
cbp.name.bv_val = cbp.buf;,
Debug(LDAP_DEBUG_TRACE,"nssov_host_byname(%s)\n",cbp.name.bv_val,0,0);,
......
contrib/slapd-modules/nssov/netgroup.c
View file @ 19883d7f
......@@ -140,8 +140,8 @@ static int write_netgroup_triple(TFILE *fp,const char *triple)
return 0;
}
/* write strings */
WRITE_INT32(fp,NSLCD_RESULT_SUCCESS);
WRITE_INT32(fp,NETGROUP_TYPE_TRIPLE);
WRITE_INT32(fp,NSLCD_RESULT_BEGIN);
WRITE_INT32(fp,NSLCD_NETGROUP_TYPE_TRIPLE);
WRITE_STRING_STRIPSPACE_LEN(fp,triple+hostb,hoste-hostb)
WRITE_STRING_STRIPSPACE_LEN(fp,triple+userb,usere-userb)
WRITE_STRING_STRIPSPACE_LEN(fp,triple+domainb,domaine-domainb)
......@@ -171,9 +171,9 @@ static int write_netgroup(nssov_netgroup_cbp *cbp,Entry *entry)
for (i=0;i<a->a_numvals;i++)
{
/* write the result code */
WRITE_INT32(cbp->fp,NSLCD_RESULT_SUCCESS);
WRITE_INT32(cbp->fp,NSLCD_RESULT_BEGIN);
/* write triple indicator */
WRITE_INT32(cbp->fp,NETGROUP_TYPE_NETGROUP);
WRITE_INT32(cbp->fp,NSLCD_NETGROUP_TYPE_NETGROUP);
/* write netgroup name */
if (write_string_stripspace_len(cbp->fp,a->a_vals[i].bv_val,a->a_vals[i].bv_len))
return -1;
......@@ -190,7 +190,7 @@ NSSOV_HANDLE(
char fbuf[1024];
struct berval filter = {sizeof(fbuf)};
filter.bv_val = fbuf;
READ_STRING_BUF2(fp,cbp.buf,sizeof(cbp.buf));,
READ_STRING(fp,cbp.buf);,
cbp.name.bv_len = tmpint32;
cbp.name.bv_val = cbp.buf;
Debug(LDAP_DEBUG_TRACE,"nssov_netgroup_byname(%s)\n",cbp.name.bv_val,0,0);,
......
contrib/slapd-modules/nssov/nss-ldapd/AUTHORS deleted 100644 → 0
View file @ 182dacfa
The original nss_ldap library was written by Luke Howard of PADL Software Pty
Ltd. In 2006 Arthur de Jong of West Consuling forked the library to split it
into a thin NSS part and a server part. The copyright holders of most of the
code are:
Luke Howard <lukeh@padl.com>
West Consulting <info@west.nl>
Arthur de Jong <arthur@ch.tudelft.nl>
The following people (in no particular order) have also volunteered their
time, effort, and ideas to make this software available. If you feel you are
unjustly left out of this list, please send an email.
Steven Barrus <sbarrus@eng.utah.edu>
David Begley <david@avarice.nepean.uws.edu.au>
Maxim Batourine <Batourine_M@ald.utoronto.ca>
Michael Brownea <mbrown@fensystems.co.uk>
Max Caines <Max.Caines@wlv.ac.uk>
Carlos Celso <carlos.celso@embraer.com.br>
Peter Cherny <peterc@luddite.com.au>
Howard Chu <hyc@symas.com>
Ben Collins <bcollins@debian.org>
Stephan Cremer <scremer@dohle.com>
Alejandro Forero Cuervo <azul@freaks-unidos.net>
Guenther Deschner <gd@samba.org>
Luca Filipozzi <lucaf+nssldap@ece.ubc.ca>
Andrew Findlay <Andrew.Findlay@skills-1st.co.uk>
Cristian Gafton <gafton@redhat.com>
Gabor Gombas <gombasg@inf.elte.hu>
DJ Gregor <dj@gregor.com>
Bob Guo <bob@mail.ied.ac.cn>
Daniel Hanks <hanksdc@plug.org>
Leif Hedstrom <leif@ogre.com>
Emile Heitor <eheitor@isdnet.net>
Geert Jansen <undisclosed>
Szymon Juraszczyk <szymon@ssk.pl>
Anselm Kruis <kruis@till-photonics.com>
Thorsten Kukuk <kukuk@suse.de>
Steve Langasek <vorlon@netexpress.net>
Joe Little <jlittle@open-it.org>
Phillip Liu <phillip@loudcloud.com>
Larry Lile <llile@dreamworks.com>
Jeff Mandel <jeff.mandel@probes.com>
Peter Marschall <peter@adpm.de>
Michael Mattice <mike@bmisystems.com>
Dejan Muhamedagic <dejan.muhamedagic@at.ibm.com>
Doug Nazar <nazard@dragoninc.on.ca>
Frode Nordahl <frode@nordahl.net>
Lars Oergel <lars.oergel@innominate.de>
Fredrik Ohrn <ohrn@chl.chalmers.se>
Rakesh Patel <rpatel@globix.com>
Nathan Hawkins <Nathan.Hawkins@FMR.COM>
Andrew Rechenberg <ARechenberg@shermanfinancialgroup.com>
Greg Retowski <greg@rage.net>
Alain Richard <alain.richard@equation.fr>
Michael Shuey <shuey@ecn.purdue.edu>
Oliver Schulze L. <oliver@samera.com.py>
Alexander Spannagel <spannagel@jobpilot.com>
Scott M. Stone <sstone@foo3.com>
Gero Treuner <gero@faveve.uni-stuttgart.de>
Jarkko Turkulainen <jt@wapit.com>
Stein Vrale <stein@terminator.net>
Simon Wilkinson <sxw@sxw.org.uk>
Davide Puricelli <evo@debian.org>
Sami Haahtinen <ressu@debian.org>
Stephen Frost <sfrost@debian.org>
Américo Monteiro <a_monteiro@netcabo.pt>
Cyril Brulebois <cyril.brulebois@enst-bretagne.fr>
Kenshi Muto <kmuto@debian.org>
Andreas Schneider <anschneider@suse.de>
Ralf Haferkamp <rhafer@suse.de>
Michael Calmer <mc@suse.de>
Erik Schanze <eriks@debian.org>
Bart Cornelis <cobaco@skolelinux.no>
Rudy Godoy Guillén <rudy@debian.org>
Petter Reinholdtsen <pere@hungry.com>
contrib/slapd-modules/nssov/nss-ldapd/COPYING deleted 100644 → 0
View file @ 182dacfa
This diff is collapsed.
contrib/slapd-modules/nssov/nss-ldapd/ChangeLog deleted 100644 → 0
View file @ 182dacfa
This diff is collapsed.
contrib/slapd-modules/nssov/nss-ldapd/HACKING deleted 100644 → 0
View file @ 182dacfa
This document tries to describe the software layout and design of the library.
It should provide some help for contributing code to this package.
CONTRIBUTING TO NSS-LDAPD
=========================
Contributions to nss-ldapd are most welcome. However not all contributions
will be automatically integrated. Some notes:
* for large changes it is a good idea to send an email first
* send your patches in unified diff (diff -u) format
* try to use the svn version of the software to develop the patch
* clearly state which problem you're trying to solve and how this is
accomplished
* please follow the existing coding conventions
* patches will be integrated on a best-effort bases
* please test the patch and include information on testing with the patch
(platforms tested, etc)
* contributions will be acknowledged in the AUTHORS file
* include a copyright statement in the patched code if you feel the
contribution is significant enough (e.g. more than a few lines)
* when including third-party code, retain copyright information (copyright
holder and license) and ensure that the license is LGPL compatible
Please contact Arthur de Jong <arthur@ch.tudelft.nl> if you want to
contribute or use the Debian BTS if you're using the Debian package.
BUILD DEPENDENCIES
==================
For building svn snapshots the following tools are needed:
* autoconf (2.61 is used but 2.59 is minimal)
* automake (1.10 is used)
* check (0.9.5 is used)
and of course the usual build tools (gcc/make/etc). Also see debian/control
(Build-Depends field) for libraries you need.
To build the svn snapshot run the autogen.sh shell script to build the
configure script. When developing patches please use --enable-warnings with
configure and don't introduce too many new warnings. For building the manual
pages docbook2x is used.
RELEASE VERSIONING
==================
A new versioning scheme was chosen over the nss_ldap release scheme. The
scheme is a simple major.minor numbering starting with 0.1. Until a 1.0
release is made the code will be considered work in progress. The interfaces
may change and features may be added and removed.
GENERAL DESIGN
==============
The basic design splits the functionality in two parts. The NSS part
interfaces with libc and translates the NSS requests into simple generic
requests (e.g. "get user with name test", "get group with gid 101" or "get all
shadow entries"). Translating these requests into LDAP requests is then the
job of the daemon (nslcd) so that the NSS part won't have to know anything
about LDAP (in fact replacing it with another lookup method is very simple).
nslcd -> OpenLDAP -> LDAP server
^
libc NSS -> libnss_ldap.so
design goals
------------
* make it as simple as possible
* design as specified above
* simpler configuration and semantics
* simpler, clearer and completer documentation
* split source code into directories (src, src/hacks, src/aix, src/irs, etc)
* get rid of unneeded code and complexity
* split complexity in two parts (LDAP interface in server, NSS interface in
library)
* have a stable, easily maintainable piece of quality software
NSS PART
========
The NSS part is implemented in files in the nss directory. The functions are
split into files according to the database they support. All functions look
like:
_nss_ldap_FUNCTION_r(...)
This function opens the connection to the nslcd (with a time-out) builds the
correct data structures and does a request (write()) to the nslcd waiting
for an answer (again with a time-out)
Currently a number of macros are used to build most of the function bodies for
these functions. A more elegant solution is welcome.
Some handy links:
http://mirrors.usc.edu/pub/gnu/Manuals/glibc-2.2.3/html_chapter/libc_28.html#SEC596
http://www.gnu.org/software/libc/manual/html_node/index.html
THE COMMUNICATIONS PROTOCOL
===========================
The protocol used for communicating between the NSS library and the nslcd
daemon is very simple and almost fully described in the nslcd.h header file.
The nslcd-common.h header file defines some macros that are used for reading
and writing protocol entities (strings, 32-bit integers, etc).
Some of the protocol handling code is automatically generated from the macros
defined in nslcd.h. This cannot be done automatically in every case though so
changing the protocol requires manual checking in the relevant source files in
both the nss and the nslcd directories.
If the protocol is changed in an incompatible way the protocol version should
be incremented in nslcd.h. There is currently no versioning scheme available
for this.
A special module (common/tio.c) was made so we can define simpler semantics
for time-out values and buffer sizes. Both tha NSS library and nslcd use this
module which means that it includes functionality that is needed for both
(e.g. large write buffers for the server part and large resettable read
buffers for the NSS part). Maybe building two modules from the same source
with different features in them is an option (e.g. the NSS part needs the
read buffers and handling of SIGPIPE and the nslcd part needs the write
buffers and possibly flushing in the background).
SERVER PART
===========
At the server end a dispatcher picks up the request and delegates it to one of
the database specific functions.
nslcd_FUNCION(...)
This functions fills in the correct parameters from the request. This
function should write responses to the stream. Almost all these functions
are generated from a macro in common.h.
SECURITY NOTES
==============
This design does open up the system to more potential security issues as there
is now a local interface to a daemon with privileges. Before processes could
only potentially exploit bugs in the library and gain the privileges of the
process that was doing the name lookups. In this case the privileges of the
daemon are potentially exposed.
The deamon should be changed to set a specific less-privileged user and
group to minimize the riscs. Code for this is already in place. Configuration
options should be added and the Debian packaging should use this.
contrib/slapd-modules/nssov/nss-ldapd/INSTALL deleted 100644 → 0
View file @ 182dacfa
Installation Instructions
*************************
Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005,
2006, 2007 Free Software Foundation, Inc.
This file is free documentation; the Free Software Foundation gives
unlimited permission to copy, distribute and modify it.
Basic Installation
==================
Briefly, the shell commands `./configure; make; make install' should
configure, build, and install this package. The following
more-detailed instructions are generic; see the `README' file for
instructions specific to this package.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions. Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, and a
file `config.log' containing compiler output (useful mainly for
debugging `configure').
It can also use an optional file (typically called `config.cache'
and enabled with `--cache-file=config.cache' or simply `-C') that saves
the results of its tests to speed up reconfiguring. Caching is
disabled by default to prevent problems with accidental use of stale
cache files.
If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release. If you are using the cache, and at
some point `config.cache' contains results you don't want to keep, you
may remove or edit it.
The file `configure.ac' (or `configure.in') is used to create
`configure' by a program called `autoconf'. You need `configure.ac' if
you want to change it or regenerate `configure' using a newer version
of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type
`./configure' to configure the package for your system.
Running `configure' might take a while. While running, it prints
some messages telling which features it is checking for.
2. Type `make' to compile the package.
3. Optionally, type `make check' to run any self-tests that come with
the package.
4. Type `make install' to install the programs and any data files and
documentation.
5. You can remove the program binaries and object files from the
source code directory by typing `make clean'. To also remove the
files that `configure' created (so you can compile the package for
a different kind of computer), type `make distclean'. There is
also a `make maintainer-clean' target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
6. Often, you can also type `make uninstall' to remove the installed
files again.
Compilers and Options
=====================
Some systems require unusual options for compilation or linking that the
`configure' script does not know about. Run `./configure --help' for
details on some of the pertinent environment variables.
You can give `configure' initial values for configuration parameters
by setting variables in the command line or in the environment. Here
is an example:
./configure CC=c99 CFLAGS=-g LIBS=-lposix
*Note Defining Variables::, for more details.
Compiling For Multiple Architectures
====================================
You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory. To do this, you can use GNU `make'. `cd' to the
directory where you want the object files and executables to go and run
the `configure' script. `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.
With a non-GNU `make', it is safer to compile the package for one
architecture at a time in the source code directory. After you have
installed the package for one architecture, use `make distclean' before
reconfiguring for another architecture.
Installation Names
==================
By default, `make install' installs the package's commands under
`/usr/local/bin', include files under `/usr/local/include', etc. You
can specify an installation prefix other than `/usr/local' by giving
`configure' the option `--prefix=PREFIX'.
You can specify separate installation prefixes for
architecture-specific files and architecture-independent files. If you
pass the option `--exec-prefix=PREFIX' to `configure', the package uses
PREFIX as the prefix for installing programs and libraries.
Documentation and other data files still use the regular prefix.
In addition, if you use an unusual directory layout you can give
options like `--bindir=DIR' to specify different values for particular
kinds of files. Run `configure --help' for a list of the directories
you can set and what kinds of files go in them.
If the package supports it, you can cause programs to be installed
with an extra prefix or suffix on their names by giving `configure' the
option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
Optional Features
=================
Some packages pay attention to `--enable-FEATURE' options to
`configure', where FEATURE indicates an optional part of the package.
They may also pay attention to `--with-PACKAGE' options, where PACKAGE
is something like `gnu-as' or `x' (for the X Window System). The
`README' should mention any `--enable-' and `--with-' options that the
package recognizes.
For packages that use the X Window System, `configure' can usually
find the X include and library files automatically, but if it doesn't,
you can use the `configure' options `--x-includes=DIR' and
`--x-libraries=DIR' to specify their locations.
Specifying the System Type
==========================
There may be some features `configure' cannot figure out automatically,
but needs to determine by the type of machine the package will run on.
Usually, assuming the package is built to be run on the _same_
architectures, `configure' can figure that out, but if it prints a
message saying it cannot guess the machine type, give it the
`--build=TYPE' option. TYPE can either be a short name for the system
type, such as `sun4', or a canonical name which has the form:
CPU-COMPANY-SYSTEM
where SYSTEM can have one of these forms:
OS KERNEL-OS
See the file `config.sub' for the possible values of each field. If
`config.sub' isn't included in this package, then this package doesn't
need to know the machine type.
If you are _building_ compiler tools for cross-compiling, you should
use the option `--target=TYPE' to select the type of system they will
produce code for.
If you want to _use_ a cross compiler, that generates code for a
platform different from the build platform, you should specify the
"host" platform (i.e., that on which the generated programs will
eventually be run) with `--host=TYPE'.
Sharing Defaults
================
If you want to set default values for `configure' scripts to share, you
can create a site shell script called `config.site' that gives default
values for variables like `CC', `cache_file', and `prefix'.
`configure' looks for `PREFIX/share/config.site' if it exists, then
`PREFIX/etc/config.site' if it exists. Or, you can set the
`CONFIG_SITE' environment variable to the location of the site script.
A warning: not all `configure' scripts look for a site script.
Defining Variables
==================
Variables not defined in a site shell script can be set in the
environment passed to `configure'. However, some packages may run
configure again during the build, and the customized values of these
variables may be lost. In order to avoid this problem, you should set
them in the `configure' command line, using `VAR=value'. For example:
./configure CC=/usr/local2/bin/gcc
causes the specified `gcc' to be used as the C compiler (unless it is
overridden in the site shell script).
Unfortunately, this technique does not work for `CONFIG_SHELL' due to