RE: [PATCH]: 64-bit porting issue in apr_sdbm.h
Please review and commit the following patch. Thanks, Mohan -Original Message- From: GUMMALAM,MOHAN (HP-Cupertino,ex2) [mailto:[EMAIL PROTECTED]] Sent: Friday, April 05, 2002 3:26 PM To: '[EMAIL PROTECTED]' Subject: [PATCH]: 64-bit porting issue in apr_sdbm.h There is a 64-bit issue with the apr_dbm.h sources -- this results in a WeDAV failure on a 64-bit OS. The problem is in the CONVERT_DATUM macro, which coverts a apr_datum_t* to apr_sdbm_datum_t*, through casting. I am sending a patch for fixing the apr_sdbm_datum_t structure. Can somebody evaluate this and commit it? Thanks, Mohan Index: apr_sdbm.h === RCS file: /home/cvspublic/apr-util/include/apr_sdbm.h,v retrieving revision 1.10 diff -u -r1.10 apr_sdbm.h --- apr_sdbm.h 13 Mar 2002 20:40:48 - 1.10 +++ apr_sdbm.h 5 Apr 2002 23:10:28 - @@ -88,7 +88,7 @@ /** pointer to the data stored/retrieved */ char *dptr; /** size of data */ -int dsize; +apr_size_t dsize; } apr_sdbm_datum_t; /* The extensions used for the database files */
Apache and SOCKS
In Apache1.3 I remember seeing support for SOCKS in mod_proxy. I do not see any such support in Apache2.0. I have looked through the email archives, and have not come across any email thread yet which contains a discussion on it. So, was it a conscious decision to not have Socks support in Apache2.0? If so, what were the reasons behind it? Thanks, Mohan.
RE: cvs commit: httpd-2.0 STATUS
Hi Cliff/Others: Whenever you're ready, do let us know, and we'll make the machines available to you folks. Also, do count on us, if you need any help to build binaries on HP-UX on behalf of ASF. As I did not see any binaries posted for 2.0.35 in the HP-UX directory (neither for 11.0 nor for 11i version 1.5), I was wondering if you needed any help from our side. I am pretty keen on getting the Apache binaries posted for HP-UX. Thanks, Mohan -Original Message- From: Cliff Woolley [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 07, 2002 11:47 PM To: '[EMAIL PROTECTED]' Subject: RE: cvs commit: httpd-2.0 STATUS On Sun, 7 Apr 2002, GUMMALAM,MOHAN (HP-Cupertino,ex2) wrote: > So does it mean that you (as in apache.org) have access to a 11i version > 1.5 (IA64) box? If so, thats good news. Otherwise, I could arrange an > access to an IPF box for one of the apache.org folks. Please do let me > know! If no one else steps up in the next day saying they already have access to one, then sure, I'll take you up on that. Thanks! --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
RE: cvs commit: httpd-2.0 STATUS
So does it mean that you (as in apache.org) have access to a 11i version 1.5 (IA64) box? If so, thats good news. Otherwise, I could arrange an access to an IPF box for one of the apache.org folks. Please do let me know! Thanks, Mohan -Original Message- From: Cliff Woolley [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 07, 2002 11:09 PM To: '[EMAIL PROTECTED]' Subject: RE: cvs commit: httpd-2.0 STATUS On Sun, 7 Apr 2002, GUMMALAM,MOHAN (HP-Cupertino,ex2) wrote: > I do not see HP-UX in the list. So, has anyone signed up for releasing > Apache binaries on HP-UX already? If not, I would like to sign up for > building apache on HP-UX 11.00 (PA-RISC) and HP-UX 11i version 1.5 > (IA64/IPF). While we appreciate the offer, we have a policy of only accepting binaries from committers. :( Thanks though... --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
RE: cvs commit: httpd-2.0 STATUS
I do not see HP-UX in the list. So, has anyone signed up for releasing Apache binaries on HP-UX already? If not, I would like to sign up for building apache on HP-UX 11.00 (PA-RISC) and HP-UX 11i version 1.5 (IA64/IPF). Thanks, Mohan -Original Message- From: Aaron Bannert [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 07, 2002 11:16 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: httpd-2.0 STATUS On Sun, Apr 07, 2002 at 04:58:31PM -, [EMAIL PROTECTED] wrote: > +Binaries needed: > + > + Mandrake 8.1: rbb volunteers > + FreeBSD 4.1: rbb volunteers > + OS X 10.1.3: jimjag volunteers > + Solaris 8.x: jimjag volunteers > + RedHat 7.2:jimjag volunteers Hmmm...we should specify the architecture too. Also, lets not differenciate each and every linux distro, but just major linux version. I've got a 2.2.19-based (redhat) system that I can build on, and a Solaris 8 Intel machine too. -aaron
[PATCH]: 64-bit porting issue in apr_sdbm.h
There is a 64-bit issue with the apr_dbm.h sources -- this results in a WeDAV failure on 64-bit HP-UX. We ran into the problem while trying to support it on IA64. The problem is in the CONVERT_DATUM macro, which coverts a apr_datum_t* to apr_sdbm_datum_t*, through casting. I am sending a patch for fixing the apr_sdbm_datum_t structure. Can somebody evaluate this and commit it? Thanks, Mohan Index: apr_sdbm.h === RCS file: /home/cvspublic/apr-util/include/apr_sdbm.h,v retrieving revision 1.10 diff -u -r1.10 apr_sdbm.h --- apr_sdbm.h 13 Mar 2002 20:40:48 - 1.10 +++ apr_sdbm.h 5 Apr 2002 23:10:28 - @@ -88,7 +88,7 @@ /** pointer to the data stored/retrieved */ char *dptr; /** size of data */ -int dsize; +apr_size_t dsize; } apr_sdbm_datum_t; /* The extensions used for the database files */
suexec and apache2.0
Currently suexec does not seem to work with apache2.0.. well atleast not completely. The problem I seem to run into is with ~user situations. Looks like the suexec code (suexec.c) expects to make a distinction between ~user calls from others by inspecting for the "~" character. However, in os/unix/unixd.c, the userid passed to suexec program is a numerical string (string of numbers, corresponding to uid_t of the ~user). As a result, suexec always bails out for every ~user calls with the following error message in suexec_log file: command (/home/user/public_html/showuser.cgi) not in docroot (/usr/local/apache2) I have made some fix and it works. I could post the patch(es) if required. The files changed for this are: os/unix/unixd.c os/unix/unixd.h modules/generators/mod_suexec.c modules/generators/mod_suexec.h 1. Change the return type of get_suexec_id_doer to unixd_config_rec (originally ap_unix_identity_t). 2. Modify get_suexec_id_doer to return "user" string in the cfg->ugid.user_name structure, if the URI contains ~. 3. Call the suexec program with "~user" string if required, otherwise call it with uid_t of the user specified in the SuexecUserGroup directive in httpd.conf (the original behaviour). If someone has a better solution, please post it. Thanks, M
