mod_imap/2025: Can a .map file return the selected point to a cgi program ?
Number: 2025 Category: mod_imap Synopsis: Can a .map file return the selected point to a cgi program ? Confidential: no Severity: non-critical Priority: medium Responsible:apache State: open Class: support Submitter-Id: apache Arrival-Date: Wed Apr 1 03:40:01 PST 1998 Last-Modified: Originator: [EMAIL PROTECTED] Organization: apache Release:1.2.4 Environment: Solaris 2.5.1 on a Sun SPARCStation-5 Description: I wish to view an OS mapsheet (GIF), click on it, and return the coordinates within the image to a cgi program so that I may work out the OS coordinates of the point clicked in order to query a database via DBI. Is there a way, via the default option to add the value of the point selected. Obviously I could create a massive .map file (500x500) for each pixel and add a ?x=1y=1 ... ?x=500y=500 to the http address desired, but I think there must be an easier way to simply pass the point on to the cgi program. How-To-Repeat: Fix: If there isn't currently a way of doing this, would it be possible to add a parameter(s) to the default option Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
Re: general/2019: Stop condition on URL parsing is incorrect
[In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] Synopsis: Stop condition on URL parsing is incorrect Comment-Added-By: dgaudet Comment-Added-When: Wed Apr 1 03:47:31 PST 1998 Comment-Added: I fixed it in 1.2.7-dev anyhow. Thanks.
Re: apache-api/2024: adding auth_why to conn_rec
[In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] Synopsis: adding auth_why to conn_rec State-Changed-From-To: open-feedback State-Changed-By: dgaudet State-Changed-When: Wed Apr 1 03:50:53 PST 1998 State-Changed-Why: Just what would AUTH_WHY contain though? The reasons for access being permitted are essentially arbitrary... Dean
Re: mod_imap/2025: Can a .map file return the selected point to a cgi program ?
[In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] Synopsis: Can a .map file return the selected point to a cgi program ? State-Changed-From-To: open-closed State-Changed-By: dgaudet State-Changed-When: Wed Apr 1 03:51:43 PST 1998 State-Changed-Why: [This is a standard response.] This is a CGI programming or basic configuration issue. As mentioned on the main bug database page, we must refer all such basic or non-Apache-related questions to the comp.infosystems.www.servers.unix and related newsgroups. Please ask your question there. Please also search the FAQ and the bug database. Thanks for using Apache! Class-Changed-From-To: support-mistaken Class-Changed-By: dgaudet Class-Changed-When: Wed Apr 1 03:51:43 PST 1998
Re: os-solaris/2016: Under some circumstances files 'break' - and remain so.
[In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] Synopsis: Under some circumstances files 'break' - and remain so. State-Changed-From-To: open-feedback State-Changed-By: dgaudet State-Changed-When: Wed Apr 1 03:53:16 PST 1998 State-Changed-Why: Yeah this really looks like a solaris 2.4 bug... you should probably start by applying any recommended 2.4 patches. You could upgrade to 2.6 ... but you shouldn't need to go that far. Tell us how it goes though, or if you get any more data. Dean
Re: apache-api/2024: adding auth_why to conn_rec
The following reply was made to PR apache-api/2024; it has been noted by GNATS. From: Marc Slemko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Apache bugs database [EMAIL PROTECTED] Subject: Re: apache-api/2024: adding auth_why to conn_rec Date: Wed, 1 Apr 1998 08:06:57 -0700 (MST) On 1 Apr 1998 [EMAIL PROTECTED] wrote: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] Synopsis: adding auth_why to conn_rec State-Changed-From-To: open-feedback State-Changed-By: dgaudet State-Changed-When: Wed Apr 1 03:50:53 PST 1998 State-Changed-Why: Just what would AUTH_WHY contain though? The reasons for access being permitted are essentially arbitrary... I'm not sure I like the idea either. It starts going a bit crazy when you look at what modules can actually do for auth... What could be useful is a group field to complement the user field. Users and groups are a reasonably generic concept in many auth modules, so setting the group they were found in could be useful and is something that people do ask for a lot.
Re: apache-api/2024: adding auth_why to conn_rec
The following reply was made to PR apache-api/2024; it has been noted by GNATS. From: Jay Soffian [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], Apache bugs database [EMAIL PROTECTED], Marc Slemko [EMAIL PROTECTED] Cc: Subject: Re: apache-api/2024: adding auth_why to conn_rec Date: Wed, 01 Apr 1998 11:19:26 -0500 +--Marc Slemko [EMAIL PROTECTED] once said: | |On 1 Apr 1998 [EMAIL PROTECTED] wrote: | | Just what would AUTH_WHY contain though? The reasons for access | being permitted are essentially arbitrary... | |I'm not sure I like the idea either. It starts going a bit crazy when you |look at what modules can actually do for auth... | |What could be useful is a group field to complement the user field. |Users and groups are a reasonably generic concept in many auth modules, so |setting the group they were found in could be useful and is something that |people do ask for a lot. I agree, reasons for access being permitted are arbitrary, but all auth modules (at least with all modules I have looked at) act on a 'require ...'. It is my suggestion then that it is up to the module to decide what AUTH_WHY is set to. For the mod_auth files that handle 'require user ...', 'require group ...', and 'require valid-user', the suggested behavior is that they set AUTH_WHY to 'user ...', 'group ...', or 'valid-user', where in the case of 'user ...', '...' is the username that matched, and in the case of 'group ...', '...' is the group the user is a member of that matched. For auth_modules that grant access based on other criteria (for example, we are using a mod_auth_sys that we modified to work with NIS and accecpt 'require netgroup ...'), it is entirely up to module author to determine what 'AUTH_WHY' should be set to. As long as their behavior is documented, users of 'AUTH_WHY' shouldn't have any trouble knowing what to do. I would argue that is it even valid for an auth_ module not to set AUTH_WHY at all, and that a user of AUTH_WHY should treat this condition as 'the reason for access is unknown', and act accordingly. j. -- Jay Soffian [EMAIL PROTECTED] UNIX Systems Administrator Cox Interactive Media
mod_log-any/2026: Max log file size is 2,147,483,616 (2^31 - 32) bytes
Number: 2026 Category: mod_log-any Synopsis: Max log file size is 2,147,483,616 (2^31 - 32) bytes Confidential: no Severity: non-critical Priority: medium Responsible:apache State: open Class: sw-bug Submitter-Id: apache Arrival-Date: Wed Apr 1 10:40:01 PST 1998 Last-Modified: Originator: [EMAIL PROTECTED] Organization: apache Release:1.2.5 Environment: Solaris 2.5.1 gcc 2.8.1 Description: After log files reach 2,147,483,616 bytes no more hits are logged. The server otherwise seems to perform normally. The server in question only getting about 5 million hits per day, so this only becomes a problem if our nightly rollover/ restart process does not run. How-To-Repeat: Fix: I know there are routines for using 64-bit file access. I'll see if these can be used and if Apache can be compiled to use them. We may hit the 2 gig limit in a few months, but terabyte limits would be the best answer. Workarounds include using the existing facility for logging to a subprocess which handles log rotation automatically. Still, I'd prefer not to introduce a second process into the system. %0 Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
Re: mod_log-any/2026: Max log file size is 2,147,483,616 (2^31 - 32) bytes
The following reply was made to PR mod_log-any/2026; it has been noted by GNATS. From: Marc Slemko [EMAIL PROTECTED] To: Robert Mela [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_log-any/2026: Max log file size is 2,147,483,616 (2^31 - 32) bytes Date: Wed, 1 Apr 1998 11:54:38 -0700 (MST) On 1 Apr 1998, Robert Mela wrote: Environment: Solaris 2.5.1 gcc 2.8.1 Description: After log files reach 2,147,483,616 bytes no more hits are logged. The server otherwise seems to perform normally. The server in question only getting about 5 million hits per day, so this only becomes a problem if our nightly rollover/ restart process does not run. AFAIK, Solaris 2.5.x can not handle regular files larger than two gigs. Things like llseek() which do 64-bit stuff are only valid for things like device files. This should work fine on Solaris 2.6 without any changes to the Apache code. Are you logging more than a standard common log format? The sizes seem big for the number of hits using CLF. I would also suggest that for this volume of logs, if you want to do anything with them, logging to a pipe and having a program automatically put them into something (eg. database, binary format, etc.) more suited to this volume. Unfortunately, I'm not sure I can recommend you try that with 1.2.x because piped logs aren't reliable. This doesn't mean they don't work fine, but if the process dies it won't get restarted, etc. Recent 1.3 betas do add that feature, to make piped logging a very attractive solution.
Re: mod_log-any/2026: Max log file size is 2,147,483,616 (2^31 - 32) bytes
The following reply was made to PR mod_log-any/2026; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Robert Mela [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_log-any/2026: Max log file size is 2,147,483,616 (2^31 - 32) bytes Date: Wed, 1 Apr 1998 12:38:35 -0800 (PST) This isn't really an apache limitation at all, or it shouldn't be. Doublecheck that you don't have your filesize limits at 2Gb -- that's what nailed me previously on a solaris box. BTW, you could also consider hourly rotation using SIGUSR1 which won't interrupt transfers. This is how I handle the load on other similarly high volume sites. Dean
Re: mod_log-any/2026: Max log file size is 2,147,483,616 (2^31 - 32) bytes
The following reply was made to PR mod_log-any/2026; it has been noted by GNATS. From: Marc Slemko [EMAIL PROTECTED] To: Rob Mela [EMAIL PROTECTED] Cc: Apache bugs database [EMAIL PROTECTED] Subject: Re: mod_log-any/2026: Max log file size is 2,147,483,616 (2^31 - 32) bytes Date: Wed, 1 Apr 1998 14:13:26 -0700 (MST) On Wed, 1 Apr 1998, Rob Mela wrote: I am using my own log format, and I'm pretty sure it is longer than the CLF. I have some options there for saving space. But, the 2 gig limit was reached after 8 or 9 million hits, which occurred only as a result of one night's log rotation and server restart not running. I'd thought about two things: - logging to a pipe to gzip or a program that does file rotations - hacking the log module to log directly to a database - hacking the log module to do automatic log rotations I'd prefer to avoid pipes or a database. I see the simplest solutions as the least error-prone and most recoverable --and a direct file write seems the simplest. My first choice is automatic rotations. Fewer moving parts, and no need to restart the server. I don't like restarting the server during the day (approx 90 hits per second), since I think a lot of people will be getting timeouts (it takes a minute or two to get up to speed again). Rotate your logs more often using SIGUSR1. See http://www.apache.org/docs/stopping.html for details. It doesn't cause the same disruption that a HUP does, but it means you have to be more careful about touching the old logs afterwards for a while since hits will still get written to them for a bit until all the old children exit. 1.2.x shouldn't take that long to get up to speed iff your StartServers is high enough; if not, then it will because it will only start a new process once every second. 1.3 does exponential spawning, so behaves much better under such situations. There is a rotatelogs in the support directory that can run from a pipe, but it looks a bit pokey for high volumes and you still have potential issues with piped logs and 1.2. In 1.3, using piped logs is really a very good solution and is very reliable and flexible.
mod_auth-any/2027: Authentication via mod_auth_dbm fails.
Number: 2027 Category: mod_auth-any Synopsis: Authentication via mod_auth_dbm fails. Confidential: no Severity: non-critical Priority: medium Responsible:apache State: open Class: sw-bug Submitter-Id: apache Arrival-Date: Wed Apr 1 13:30:01 PST 1998 Last-Modified: Originator: [EMAIL PROTECTED] Organization: apache Release:1.3b5 Environment: Debian GNU/Linux 2.0 (frozen) GCC 2.7.2.3 uname -a: Linux vertigo 2.0.33 #2 Thu Mar 19 12:44:04 EST 1998 i586 unknown LibGDBM version 1.7.3 Description: Authentication via DBM files seems to be broken for GDBM. I have seen other such problems reported on the list, so it's not just me. Pertinent files follow: .htaccess (from the /usr/local/apache/htdocs/ dir): AuthType Basic AuthName Vertigo Apache Server AuthDBMUserFile /usr/local/apache/user_db AuthDBMGroupFile /usr/local/apache/group_db Limit GET POST require valid-user /Limit ls -l from /usr/local/apache: -rw-r--r-- 1 125 root12553 Jan 13 23:03 ABOUT_APACHE -rw-r--r-- 1 125 root 1881 Feb 13 19:58 Announcement -rw-r--r-- 1 125 root 6624 Jan 13 18:10 CHANGES -rw-r--r-- 1 125 root12259 Nov 19 04:46 KEYS -rw-r--r-- 1 125 root 2671 Jan 7 11:45 LICENSE -rw-r--r-- 1 125 root 647 Sep 16 1997 Makefile -rw-r--r-- 1 125 root 4471 Nov 25 04:47 README -rw-r--r-- 1 125 root 6751 Oct 27 15:22 README.NT drwxr-xr-x 2 125 root 1024 Feb 13 20:04 cgi-bin drwxr-xr-x 2 125 root 1024 Mar 31 15:48 conf -rwxr-xr-x 1 root root 6168 Apr 1 15:34 dbmmanage -rw-r--r-- 1 root root 24 Apr 1 15:55 group_db drwxr-xr-x 5 wntrmute users1024 Apr 1 15:54 htdocs -rwxr-xr-x 1 root root 8141 Apr 1 15:54 htpasswd -rwxr-xr-x 1 root root 1362683 Apr 1 15:31 httpd drwxr-xr-x 2 125 root 2048 Feb 13 20:04 icons drwxr-xr-x 2 125 root 1024 Apr 1 15:32 logs drwxr-xr-x 11 125 root 1024 Apr 1 15:31 src -rw-r--r-- 1 root root 21 Apr 1 15:55 user_db Error snippet from Apache Error Log: [Wed Apr 1 15:53:26 1998] [error] (2)No such file or directory: could not open dbm auth file: /usr/local/apache/user_db [Wed Apr 1 15:53:26 1998] [error] DBM user gstone not found: /usr/local/apache/ htdocs How-To-Repeat: Get a copy of Debian Linux 2.0, install, then grab the source for Apache 1.3b5 and compile. Voila! Fix: I imagine this has something to do with incompatibilities between libgdbm and the mod_auth_dbm module. As dbmmanage works just fine to create, view, update, etc.. the file, I can't begin to speculate on where the exact problem is. Oh, and to answer the questions you've already asked others. I have tried both with and without AuthDBMAuthoritative, I have made sure my paths were correct, and have specified -lgdbm as the only extra library to include in the Configuration file. %0 Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
