Re: 1.0.0 RC5
At 04:04 PM 8/2/2004, Graham Leggett wrote: David Reid wrote: The main fooness is in apr_ldap_url.c. Can we not mark this code as deprecated in v1.0, which should hopefully warn alert coders that the code should not be used, and can be pointed out to coders who are asleep otherwise if they moan. How much work is needed to fix it? What exactly is broken about it? It needs an overhaul as it does some wrong things. Fixing it can wait till APR v1.1. In the meantime we can mark what's there as deprecated so as to not cause confusion. If they need the broken implementation, they can keep using 0.9 - in the meantime let's design the right interface by 1.1 and completely REMOVE, not 'deprecate' the existing flavor. Deprecation isn't getting rid of a feature until the next release. This IS the next release, so just branch 1.1-dev, and remove the ldap files on the 1.0 branch, knock out the config.m4 magic, and we have a valid 1.0 release. Let's take the course of least action shall we? Is this release creating a record for being the longest in history? I'm away for most of the rest of the week. I had hoped to have RC5 rolled today, but guess that isn't going to happen now. *sigh* I have added a note that the two offending LDAP source files (apr_ldap_compat and apr_ldap_url) are deprecated subject to an overhaul. Quick - roll RC5! I'll vote -1 on this sheist - however that's just a vote. Shall see if anyone else is this disgusted. David, if we are at 1.0, shall we branch 1.1 right now and I'll do the dirty deed myself tomorrow night at the hotel? Bill
Re: 1.0.0 RC5
At 12:53 PM 8/2/2004, David Reid wrote: Graham Leggett wrote: William A. Rowe, Jr. wrote: I would be +1 to simply remove auth_ldap from APR 1.0, and reintroduce the entire feature in the new APR 1.1 (which we can start development on immediately.) And that presumes httpd 2.1/2.2 will depend on the 1.1 release of apr-util. I hate to hold up 1.0 any further. I would hate to release apr-util as-in even more. Thoughts or comments about my solution above? Why (I feel I have to ask) is this ONLY just coming to light now? Well, it isn't. Several APR contributors have griped that apr-util would become nothing more than a garbage pit of hacks-upon-hacks around broken/inconsistent APIs. My only ldap hacks to date were on win32. Now I'm deeply immersed in config and build issues for many more unix platforms, and was hacking in Sun LDAP SDK support. It's when I discovered apr-util's implementation of ldap was valueless for writing portable code. If our code doesn't facilitate portable code, it doesn't belong in APR. So I threw it to the list, drop the existing implementation? I'm NOT suggesting we put it back in before APR 1.0 release. How much work is needed to fix it? What exactly is broken about it? Right now it does little. Graham and I agree on the right solution, to abstract out the logic to do SSL connections in a portable way. There will be no need for the 'application developer' to know which toolkit they are using. We will make that transparent. Ripping it out is a whole lot of work best avoided IMHO. Let's take the course of least action shall we? Least action is fork 1.1, cvs rm the offensive files, and change about 10 lines of the makefiles and rip out the ldap detection. Pretty trivial. Deprecating means we support this junk till 2.0 releases. Bill
Re: 1.0.0 RC5
On Mon, 2 Aug 2004, William A. Rowe, Jr. wrote: Least action is fork 1.1, cvs rm the offensive files, and change about 10 lines of the makefiles and rip out the ldap detection. Pretty trivial. Deprecating means we support this junk till 2.0 releases. +1. If the API is really that broken, it's better to remove it completely and add something better later.
Re: 1.0.0 RC5
--On Tuesday, August 3, 2004 12:16 AM -0400 Cliff Woolley [EMAIL PROTECTED] wrote: +1. If the API is really that broken, it's better to remove it completely and add something better later. Under our compatibility rules, we can remove apr_ldap_* in APR 1.0 and add it back in APR 1.1. That's my recommendation here. -- justin
RC5 is available
Well, after what seems an eternity, RC5 is finally available. I have changed the version files for HEAD in all 3 repositories to be 1.0.1-dev and the version files are tagged to give us 1.0.0. APR has a lot of bumps and now includes the kpoll code (managing the versions to include the other changes without it was going to be too hard!). The changes to the apr-find macro have NOT been picked up in apr-util and apr-iconv, so hopefully these tarballs will encourage people to fix that? APR-Util has had the ldap code removed entirely from the tarball. This will need checked as it may break builds. APR-iconv has been included and has had the relevant files bumped. Please test/report/vote. I'm away (connection is uncertain) but will be home Friday so will review all comments then :-) david
[PATCH] apr-util apu-config update (was: RC5 is available)
David Reid wrote:
The changes to the apr-find macro have NOT been picked up in apr-util
and apr-iconv, so hopefully these tarballs will encourage people to fix
that?
Here is the apr-util part of that. (apr-iconv part will follow later)
In addition to applying the equivalent changes from apr to apr-util, this
patch also brings across some forgotten comment updates and OS/2 compat code
from apr.
In particular, please could people look at the two dnl Note: paragraphs
in find_apu.m4 which this patch does _not_ touch. Copied here:
dnl Note: At this time, we cannot find *both* a source dir and a build dir.
dnl If both are available, the build directory should be passed to
dnl the --with-apr-util switch.
The fact that you can pass a build directory to the --with-apr(-util)
options seems to be one of those occasionally useful but not very tested
features. Perhaps we don't want to advertise it (yet?).
dnl Note: the installation layout is presumed to follow the standard
dnl PREFIX/lib and PREFIX/include pattern. If the APU config file
dnl is available (and can be found), then non-standard layouts are
dnl possible, since it will be described in the config file.
Is plain wrong, I think. The macro *requires* that a config file be found.
Max.
Index: .cvsignore
===
RCS file: /home/mirror/cvsmirror/misc-cvs/apr-util/.cvsignore,v
retrieving revision 1.24
diff -u -p -r1.24 .cvsignore
--- .cvsignore 30 Jul 2004 19:37:22 - 1.24
+++ .cvsignore 1 Aug 2004 17:08:26 -
@@ -14,6 +14,7 @@ exports.c
export_vars.[ch]
export_vars.sh
apu-config
+apu-*-config
apu-config.out
Debug
Release
Index: CHANGES
===
RCS file: /home/mirror/cvsmirror/misc-cvs/apr-util/CHANGES,v
retrieving revision 1.134
diff -u -p -r1.134 CHANGES
--- CHANGES 1 Aug 2004 16:55:14 - 1.134
+++ CHANGES 1 Aug 2004 17:08:50 -
@@ -1,5 +1,8 @@
Changes with APR-util 1.0
+ *) Only install apu-$MAJOR-config and add appropriate detection code to
+ find_apu.m4 (APU_FIND_APU). [Max Bowsher maxb ukf.net]
+
*) Add an apr_ldap_err_t structure to handle the return of LDAP
specific error codes. [Graham Leggett, Brad Nicholes]
Index: Makefile.in
===
RCS file: /home/mirror/cvsmirror/misc-cvs/apr-util/Makefile.in,v
retrieving revision 1.95
diff -u -p -r1.95 Makefile.in
--- Makefile.in 1 Jul 2004 14:37:45 - 1.95
+++ Makefile.in 1 Aug 2004 16:57:05 -
@@ -33,7 +33,7 @@ CLEAN_TARGETS = exports.c export_vars.c
DISTCLEAN_TARGETS = config.cache config.log config.status libtool \
include/private/apu_config.h include/private/apu_private.h \
include/private/apu_select_dbm.h include/apr_ldap.h include/apu.h \
- export_vars.sh apu-config build/rules.mk include/apu_want.h \
+ export_vars.sh $(APU_CONFIG) build/rules.mk include/apu_want.h \
apr-util.pc
EXTRACLEAN_TARGETS = configure aclocal.m4 include/private/apu_config.h.in \
exports.c build-outputs.mk \
@@ -49,8 +49,8 @@ [EMAIL PROTECTED]@
[EMAIL PROTECTED]@
# Create apu-config script suitable for the install tree
-apu-config.out: apu-config
- sed 's,^\(location=\).*$$,\1installed,' apu-config $@
+apu-config.out: $(APU_CONFIG)
+ sed 's,^\(location=\).*$$,\1installed,' $(APU_CONFIG) $@
install: $(TARGET_LIB) apu-config.out
if [ ! -d $(DESTDIR)$(includedir) ]; then \
@@ -76,9 +76,8 @@ install: $(TARGET_LIB) apu-config.out
if [ ! -d $(DESTDIR)$(bindir) ]; then \
$(APR_MKDIR) $(DESTDIR)$(bindir); \
fi;
- $(LIBTOOL) --mode=install cp apu-config.out
$(DESTDIR)$(bindir)/apu-config
$(LIBTOOL) --mode=install cp apu-config.out
$(DESTDIR)$(bindir)/$(APU_CONFIG)
- chmod 755 $(DESTDIR)$(bindir)/apu-config
$(DESTDIR)$(bindir)/$(APU_CONFIG)
+ chmod 755 $(DESTDIR)$(bindir)/$(APU_CONFIG)
$(TARGET_LIB): $(OBJECTS)
$(LINK) @lib_target@ $(ALL_LIBS) $(EXTRA_OS_LINK)
Index: apu-config.in
===
RCS file: /home/mirror/cvsmirror/misc-cvs/apr-util/apu-config.in,v
retrieving revision 1.36
diff -u -p -r1.36 apu-config.in
--- apu-config.in 14 Jun 2004 15:43:40 - 1.36
+++ apu-config.in 1 Aug 2004 16:58:12 -
@@ -43,7 +43,7 @@ [EMAIL PROTECTED]@
show_usage()
{
cat EOF
-Usage: apu-config [OPTION]
+Usage: apu-$APRUTIL_MAJOR_VERSION-config [OPTION]
Known values for OPTION are:
--prefix[=DIR]change prefix to DIR
@@ -62,9 +62,9 @@ Known values for OPTION are:
--helpprint this help
When linking with libtool, an application should do something like:
- APU_LIBS=\`apu-config --link-libtool --libs\`
+ APU_LIBS=\`apu-$APRUTIL_MAJOR_VERSION-config --link-libtool --libs\`
or when linking directly:
-
Re: 1.0.0 RC5
William A. Rowe, Jr. wrote: Right now it does little. Graham and I agree on the right solution, to abstract out the logic to do SSL connections in a portable way. There will be no need for the 'application developer' to know which toolkit they are using. We will make that transparent. This has already been done, and is already checked into apr_util. Least action is fork 1.1, cvs rm the offensive files, and change about 10 lines of the makefiles and rip out the ldap detection. Pretty trivial. That's overkill. The two most important bits of the LDAP support are ./configure magic to find the right toolkit, and the newly overhauled apr_ldap_init.c, which replaces the LDAP SDK's inconsistent ldap_init() function. These should work fine. Deprecating means we support this junk till 2.0 releases. Then cvs rm apr_ldap_url.c, which seems to be the main issue. We can fix it and put it back in the next release. What issues are there with apr_ldap_compat.c? This code is very short, and any issues are probably easily fixed. Regards, Graham --
Re: 1.0.0 RC5
Justin Erenkrantz wrote: Under our compatibility rules, we can remove apr_ldap_* in APR 1.0 and add it back in APR 1.1. That's my recommendation here. -- justin As I have just overhauled apr_ldap, I would ask that people check first which parts of apr_ldap need to be removed and/or fixed. I don't want to see code chopped out because a whole lot of different code is broken. :( Regards, Graham --
Re: RC5 is available
David Reid wrote: APR-Util has had the ldap code removed entirely from the tarball. This will need checked as it may break builds. So having just fixed most of apr_ldap, somebody says it needs to be fixed and chops the entire thing out. Sigh. Regards, Graham --
Re: 1.0.0 RC5
At 06:08 AM 8/3/2004, Graham Leggett wrote: William A. Rowe, Jr. wrote: Right now it does little. Graham and I agree on the right solution, to abstract out the logic to do SSL connections in a portable way. There will be no need for the 'application developer' to know which toolkit they are using. We will make that transparent. This has already been done, and is already checked into apr_util. Very cool! I am traveling non-stop so haven't dug into the code, and probably can't till Tuesday. That 40% of the 80%... Least action is fork 1.1, cvs rm the offensive files, and change about 10 lines of the makefiles and rip out the ldap detection. Pretty trivial. That's overkill. The two most important bits of the LDAP support are ./configure magic to find the right toolkit, and the newly overhauled apr_ldap_init.c, which replaces the LDAP SDK's inconsistent ldap_init() function. These should work fine. No - the most important bit is to start hiding the details in apu_private.h and quit publicizing the sdk versions, define mapping wrappers, etc. Once everything that aprutil-1 elects to do is hidden inside aprutil-1.so, and the interface is always the same (no matter which linkage), then we have 1. defined binary compatibility, and 2. stuck to it :) Deprecating means we support this junk till 2.0 releases. Then cvs rm apr_ldap_url.c, which seems to be the main issue. We can fix it and put it back in the next release. Actually, isn't that the most trivial to fix? #if HAVE_ldap_parse_url return ldap_parse_url(...); #else [all the code] #endif What issues are there with apr_ldap_compat.c? This code is very short, and any issues are probably easily fixed. iirc this is a bunch of macros. Any code linked against one flavor of aprutil-1.so can't be expected to load under another. This is problematic, no? Bill
Re: RC5 is available
--On Tuesday, August 3, 2004 11:31 AM +0100 David Reid [EMAIL PROTECTED] wrote: Well, after what seems an eternity, RC5 is finally available. I have changed the version files for HEAD in all 3 repositories to be 1.0.1-dev and the version files are tagged to give us 1.0.0. That should be 1.1-dev. No API changes in any form can be in 1.0.x if we follow our versioning rules. I'd suggest branching APR_1_0_BRANCH now and have HEAD report itself as 1.1.0-dev. BTW, thanks. ;-) -- justin
apr_ldap macro fooness is gone
Hi all, The macro fooness in apr_ldap.h* and apr_ldap_compat.c is gone. Please can someone review whether I've missed anything. Next is to decide the fate of apr_ldap_url.c. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: 1.0.0 RC5
Therefore I ask: How important is LDAP v2? Can we just chop LDAP v2 support for APR 1.0 - we get rid of the macros and the spare functions. We can do LDAP v2.0 support (as opposed to v3.0 support we do by default) in the proper APR way later. +1, V3 has been around for a while. Let's support V2 later if needed. My bet is that it won't be needed. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com Graham Leggett [EMAIL PROTECTED] Tuesday, August 03, 2004 1:07:47 PM William A. Rowe, Jr. wrote: The two most important bits of the LDAP support are ./configure magic to find the right toolkit, and the newly overhauled apr_ldap_init.c, which replaces the LDAP SDK's inconsistent ldap_init() function. These should work fine. No - the most important bit is to start hiding the details in apu_private.h and quit publicizing the sdk versions, define mapping wrappers, etc. Once everything that aprutil-1 elects to do is hidden inside aprutil-1.so, and the interface is always the same (no matter which linkage), then we have 1. defined binary compatibility, and 2. stuck to it :) I was referring to the most important bit of the functionality - you're referring to the most serious bit of the fooness :) I think the code with the most fooness is also the code with the least impact - so chopping it shouldn't cause too many problems, and certainly not problems that can't be fixed in v1.0.1. Then cvs rm apr_ldap_url.c, which seems to be the main issue. We can fix it and put it back in the next release. Actually, isn't that the most trivial to fix? #if HAVE_ldap_parse_url return ldap_parse_url(...); #else [all the code] #endif What it does now is this: #if !APR_HAS_LDAP_URL_PARSE [all the code] #endif Inside the code it then defines apr_ldap_is_ldap_url() - but only if APR_HAS_LDAP_URL_PARSE is false, which makes no sense. This is definitely bogus - let me see if I can fix it. What issues are there with apr_ldap_compat.c? This code is very short, and any issues are probably easily fixed. iirc this is a bunch of macros. Any code linked against one flavor of aprutil-1.so can't be expected to load under another. This is problematic, no? Looking at this further, the apr_ldap_compat is a fill in function for LDAP v2 servers. It defines ldap_search_ext_s() and ldap_memfree() for LDAP v2 servers, where these functions were missing from the C SDK. In the header file, the macro defines handling a difference between the v2 LDAP SDK and the v3 one. Therefore I ask: How important is LDAP v2? Can we just chop LDAP v2 support for APR 1.0 - we get rid of the macros and the spare functions. We can do LDAP v2.0 support (as opposed to v3.0 support we do by default) in the proper APR way later. Regards, Graham --
Re: apr_ldap macro fooness is gone
Looks good except now mod_auth_ldap is messed up because it is still using the V2 macros Calling NWGNUauthldap Generating Debug\authldap_cc.opt Compiling mod_auth_ldap.c ### mwccnlm Compiler: #File: mod_auth_ldap.c # # 707: case LDAP_URL_ERR_NOTLDAP: # Error: # undefined identifier 'LDAP_URL_ERR_NOTLDAP' ### mwccnlm Compiler: # 709: case LDAP_URL_ERR_NODN: # Error: ^ # undefined identifier 'LDAP_URL_ERR_NODN' Errors caused tool to abort. gmake[3]: *** [Debug/mod_auth_ldap.o] Error 1 gmake[2]: *** [Debug/authldap.nlm] Error 2 gmake[1]: *** [experimental] Error 2 gmake: *** [modules] Error 2 Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com Graham Leggett [EMAIL PROTECTED] Tuesday, August 03, 2004 1:33:53 PM Hi all, The macro fooness in apr_ldap.h* and apr_ldap_compat.c is gone. Please can someone review whether I've missed anything. Next is to decide the fate of apr_ldap_url.c. Regards, Graham --
Re: apr_ldap macro fooness is gone
Brad Nicholes wrote: Looks good except now mod_auth_ldap is messed up because it is still using the V2 macros # 707: case LDAP_URL_ERR_NOTLDAP: # Error: # undefined identifier 'LDAP_URL_ERR_NOTLDAP' ### mwccnlm Compiler: # 709: case LDAP_URL_ERR_NODN: # Error: ^ # undefined identifier 'LDAP_URL_ERR_NODN' Already found this - the cause is apr_ldap_url.c, which has more macro fooness :( I'm busy giving apr_ldap_url the full APR treatment - allocate memory from pools, etc. There'll be no need to use the native ldap URL parse routines any more. Should have something in the next hour or so. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Fwd: [PROOF-OF-CONCEPT?] logging memory used by an allocator
-- Forwarded message -- From: Jeff Trawick [EMAIL PROTECTED] Date: Tue, 3 Aug 2004 14:45:16 -0400 Subject: Re: [PROOF-OF-CONCEPT?] logging memory used by an allocator To: Sander Striker [EMAIL PROTECTED] On Sun, 1 Aug 2004 19:46:14 +0200, Sander Striker [EMAIL PROTECTED] wrote: From: Jeff Trawick [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 1:33 PM To: dev@apr.apache.org; dev@httpd.apache.org Subject: [PROOF-OF-CONCEPT?] logging memory used by an allocator A couple of questions come up from an application perspective: am I leaking memory? if so, on what operation? how much memory does it take to perform a certain operation? If the application can find out how much heap memory is presently owned by a certain allocator, it can be easier to address such questions. Wouldn't you want to know the memory currently being held by the allocator as well as all the memory the allocator dished out to it's pools? I'm sure that could be useful to some folks; I can't think of a use at the present with Apache unless some logging of the allocator shows that some request uses a bunch of memory, and we know that there are various pools in use on that request so we add some temporary debug code to add pool granularity to the measurement The attached apr.patch adds apr_allocator_memsize_get() to find the amount of heap memory presently owned by the allocator. (debug pool flavor not implemented; what is implemented isn't tested much ;) ) Given that memory management is on the critical path we need to be careful what we add. But this patch seems pretty harmless in that respect. but doesn't memsize_get suck as a name? any better ideas? The attached httpd.patch adds %Z log format to mod_log_config to log the memory size of the allocator used by the request pool. (I would lean towards implementing this feature in a debug module instead of in mod_log_config.) I assume you implemented this because of an itch? :) biggest itch was, in the context of a suspected storage leak, wanting to draw a line between Apache memory use and some potential third-party module or library issue; hard without some such measurements to even understand the normal Apache storage growth in a threaded server as more and more threads in the process eventually handle expensive requests more specifically: good for a *rough* idea of memory requirements; I haven't a clue how much heap memory it takes to process some request; 10K? 100K? good for determining when it is useful to use MaxMemFree by identifying situations where an infrequent request takes a lot more pool memory than normal to process; in such case, it is practical to set MaxMemFree to approximately the normal amount of memory required, since malloc()/free() overhead won't be a killer
[RESEND] [PATCH] Add apr_uid_shell_get
I'm trying to improve httpd's mod_userdir so that it knows it
shouldn't serve ~fool when user 'fool' has an administratively
prohibited shell, so:
UserDir DisableShell /bin/badlad
To this end, I need a function to query the user's shell. It seems
sensible to me (though I am new to apr) that it should go into apr.
I've written a patch that does this; it's attached.
What do you think?
--
HEBRIDES
VARIABLE 3 OR LESS BECOMING SOUTHEASTERLY 4 OR 5. RAIN OR DRIZZLE.
MODERATE OR GOOD
--- srclib/apr/include/apr_user.h.orig 2004-02-13 09:33:45.0 +
+++ srclib/apr/include/apr_user.h 2004-07-26 09:45:49.0 +0100
@@ -99,6 +99,18 @@
const char *username, apr_pool_t *p);
/**
+ * Get the shell of the specified username
+ * @param shell Returns the shell filename
+ * @param username The username to lookup
+ * @param p The pool from which to allocate the string
+ * @remark This function is available only if APR_HAS_USER is defined.
+ */
+APR_DECLARE(apr_status_t) apr_uid_shell_get(char **shell,
+const char *username,
+apr_pool_t *p);
+
+
+/**
* Get the home directory for the named user
* @param dirname Pointer to new string containing directory name (on output)
* @param username The named user
--- srclib/apr/user/unix/userinfo.c.orig2004-02-13 09:33:55.0
+
+++ srclib/apr/user/unix/userinfo.c 2004-07-27 11:08:27.0 +0100
@@ -76,6 +76,21 @@
}
+APR_DECLARE(apr_status_t) apr_uid_shell_get(char **shell,
+ const char *username,
+ apr_pool_t *p)
+{
+struct passwd pw;
+char pwbuf[PWBUF_SIZE];
+apr_status_t rv;
+
+if ((rv = getpwnam_safe(username, pw, pwbuf)) != APR_SUCCESS)
+return rv;
+
+*shell = apr_pstrdup(p, pw.pw_shell);
+return APR_SUCCESS;
+}
+
APR_DECLARE(apr_status_t) apr_uid_current(apr_uid_t *uid,
apr_gid_t *gid,
--- srclib/apr/user/win32/userinfo.c.orig 2004-02-13 09:33:55.0
+
+++ srclib/apr/user/win32/userinfo.c2004-07-27 16:32:17.0 +0100
@@ -160,6 +160,13 @@
#endif /* _WIN32_WCE */
}
+APR_DECLARE(apr_status_t) apr_uid_shell_get(char **shell,
+ const char *username,
+ apr_pool_t *p)
+{
+return APR_ENOTIMPL;
+}
+
APR_DECLARE(apr_status_t) apr_uid_current(apr_uid_t *uid,
apr_gid_t *gid,
apr_pool_t *p)
