From mingo at elte.hu Thu Feb 19 09:33:35 2004 From: mingo at elte.hu (Ingo Molnar) Date: Thu, 19 Feb 2004 10:33:35 +0100 Subject: [patch] tux3-2.6.3-A1 In-Reply-To: <20040109100403.GA25506@elte.hu> References: <20031230100521.GA31147@elte.hu> <20031230163942.GA12905@elte.hu> <3FF1D2B7.4050603@tmsusa.com> <20031231094856.GA7752@elte.hu> <20031231101431.GA8305@elte.hu> <20040101115729.GA11547@elte.hu> <20040109100403.GA25506@elte.hu> Message-ID: <20040219093335.GA30560@elte.hu> the latest Tux patch merged to 2.6.3 is available at: redhat.com/~mingo/TUX-patches/tux3-2.6.3-A1 this patch updates more version strings, noticed by Nick Koston. Ingo From joe at tmsusa.com Thu Feb 19 16:44:06 2004 From: joe at tmsusa.com (joe) Date: Thu, 19 Feb 2004 08:44:06 -0800 Subject: [patch] tux3-2.6.3-A1 In-Reply-To: <20040219093335.GA30560@elte.hu> References: <20031230100521.GA31147@elte.hu> <20031230163942.GA12905@elte.hu> <3FF1D2B7.4050603@tmsusa.com> <20031231094856.GA7752@elte.hu> <20031231101431.GA8305@elte.hu> <20040101115729.GA11547@elte.hu> <20040109100403.GA25506@elte.hu> <20040219093335.GA30560@elte.hu> Message-ID: <4034E7D6.1020304@tmsusa.com> Ingo Molnar wrote: >the latest Tux patch merged to 2.6.3 is available at: > > redhat.com/~mingo/TUX-patches/tux3-2.6.3-A1 > > > Thanks boss - BTW any hope of preempt compatibility yet? Joe From mingo at elte.hu Fri Feb 20 07:58:10 2004 From: mingo at elte.hu (Ingo Molnar) Date: Fri, 20 Feb 2004 08:58:10 +0100 Subject: [patch] tux3-2.6.3-A1 In-Reply-To: <20040219093335.GA30560@elte.hu> References: <20031230100521.GA31147@elte.hu> <20031230163942.GA12905@elte.hu> <3FF1D2B7.4050603@tmsusa.com> <20031231094856.GA7752@elte.hu> <20031231101431.GA8305@elte.hu> <20040101115729.GA11547@elte.hu> <20040109100403.GA25506@elte.hu> <20040219093335.GA30560@elte.hu> Message-ID: <20040220075810.GA1276@elte.hu> a new Tux drop is available at: redhat.com/~mingo/TUX-patches/tux3-2.6.3-A2 this adds ia64 support by David Mosberger. There's a new userspace package too: redhat.com/~mingo/TUX-patches/tux-3.2.16.tar.gz there's no change for non-ia64 systems. Ingo From mingo at elte.hu Fri Feb 20 07:59:21 2004 From: mingo at elte.hu (Ingo Molnar) Date: Fri, 20 Feb 2004 08:59:21 +0100 Subject: [patch] tux3-2.6.3-A1 In-Reply-To: <4034E7D6.1020304@tmsusa.com> References: <20031230100521.GA31147@elte.hu> <20031230163942.GA12905@elte.hu> <3FF1D2B7.4050603@tmsusa.com> <20031231094856.GA7752@elte.hu> <20031231101431.GA8305@elte.hu> <20040101115729.GA11547@elte.hu> <20040109100403.GA25506@elte.hu> <20040219093335.GA30560@elte.hu> <4034E7D6.1020304@tmsusa.com> Message-ID: <20040220075921.GA1383@elte.hu> * joe wrote: > Thanks boss - BTW any hope of preempt compatibility yet? there have been a number of preemption related fixes lately. I just tried Tux with preemption enabled and it seems to work (in light testing). I also checked out the code and it should have no fundamental problems with preempt. Could you try it - do you still get those 'scheduling while atomic' messages? Ingo From joe at tmsusa.com Sat Feb 21 07:15:46 2004 From: joe at tmsusa.com (joe) Date: Fri, 20 Feb 2004 23:15:46 -0800 Subject: [patch] tux3-2.6.3-A1 In-Reply-To: <20040220075921.GA1383@elte.hu> References: <20031230100521.GA31147@elte.hu> <20031230163942.GA12905@elte.hu> <3FF1D2B7.4050603@tmsusa.com> <20031231094856.GA7752@elte.hu> <20031231101431.GA8305@elte.hu> <20040101115729.GA11547@elte.hu> <20040109100403.GA25506@elte.hu> <20040219093335.GA30560@elte.hu> <4034E7D6.1020304@tmsusa.com> <20040220075921.GA1383@elte.hu> Message-ID: <403705A2.9090505@tmsusa.com> Ingo Molnar wrote: >there have been a number of preemption related fixes lately. I just >tried Tux with preemption enabled and it seems to work (in light >testing). I also checked out the code and it should have no fundamental >problems with preempt. Could you try it - do you still get those >'scheduling while atomic' messages? > > Looks good, I tested out 2.6.3 + tux patch on my system. I have preempt enabled, and even "sysctl -w net.ipv4.tcp_low_latency=1" for good measure. After giving tux a good workout with apachebench, I don't see any kernel warnings at all. Best Regards, Joe From anton at samba.org Sat Feb 21 16:40:31 2004 From: anton at samba.org (Anton Blanchard) Date: Sun, 22 Feb 2004 03:40:31 +1100 Subject: [patch] tux3-2.6.3-A1 In-Reply-To: <20040220075810.GA1276@elte.hu> References: <20031230100521.GA31147@elte.hu> <20031230163942.GA12905@elte.hu> <3FF1D2B7.4050603@tmsusa.com> <20031231094856.GA7752@elte.hu> <20031231101431.GA8305@elte.hu> <20040101115729.GA11547@elte.hu> <20040109100403.GA25506@elte.hu> <20040219093335.GA30560@elte.hu> <20040220075810.GA1276@elte.hu> Message-ID: <20040221164031.GC5801@krispykreme> Hi Ingo, > a new Tux drop is available at: > redhat.com/~mingo/TUX-patches/tux3-2.6.3-A2 Heres a patch to fix ppc64: - We call syscalls directly, not via their procedure descriptor. - Remove 32bit translation code now the API is 32/64bit safe. Anton diff -urN tux-2.6.3.orig/arch/ppc64/kernel/misc.S tux-2.6.3/arch/ppc64/kernel/misc.S --- tux-2.6.3.orig/arch/ppc64/kernel/misc.S 2004-02-22 03:33:39.225245698 +1100 +++ tux-2.6.3/arch/ppc64/kernel/misc.S 2004-02-22 03:34:30.585096862 +1100 @@ -788,7 +788,15 @@ .llong .compat_sys_sched_setaffinity .llong .compat_sys_sched_getaffinity .llong .sys_ni_syscall - .llong .sys32_tux +#ifdef CONFIG_TUX + .llong .__sys_tux +#else +# ifdef CONFIG_TUX_MODULE + .llong .sys_tux +# else + .llong .sys_ni_syscall +# endif +#endif .llong .sys32_sendfile64 .llong .compat_sys_io_setup .llong .sys_io_destroy @@ -1048,10 +1056,10 @@ .llong .sys_sched_getaffinity .llong .sys_ni_syscall #ifdef CONFIG_TUX - .quad __sys_tux + .llong .__sys_tux #else # ifdef CONFIG_TUX_MODULE - .quad sys_tux + .llong .sys_tux # else .llong .sys_ni_syscall # endif diff -urN tux-2.6.3.orig/arch/ppc64/kernel/sys_ppc32.c tux-2.6.3/arch/ppc64/kernel/sys_ppc32.c --- tux-2.6.3.orig/arch/ppc64/kernel/sys_ppc32.c 2004-02-22 03:33:39.231245241 +1100 +++ tux-2.6.3/arch/ppc64/kernel/sys_ppc32.c 2004-02-22 03:35:01.036380642 +1100 @@ -2768,65 +2768,6 @@ return sys_mmap(addr, len, prot, flags, fd, pgoff << 12); } -#include - -asmlinkage int __sys_tux (unsigned int action, user_req_t *u_info); - -asmlinkage int sys32_tux (unsigned int action, user_req32_t *u_info32) -{ - int ret = -ENOMEM; - user_req_t *u_info; - u32 tmp1, tmp2, tmp3; - mm_segment_t old_fs = get_fs(); - int err; - - if (!u_info32) - return __sys_tux(action, NULL); - - u_info = kmalloc(sizeof(*u_info), GFP_KERNEL); - - if (!u_info) - goto out; - - ret = -EFAULT; - - err = copy_from_user(u_info, u_info32, - offsetof(user_req32_t, object_addr)); - err |= __get_user(tmp1, &u_info32->object_addr); - err |= __get_user(tmp2, &u_info32->priv); - err |= __get_user(tmp3, &u_info32->id); - - if (err) - goto out_kfree; - - u_info->object_addr = (char *)A(tmp1); - u_info->priv = (void *)A(tmp2); - u_info->id = (void *)A(tmp3); - - set_fs(KERNEL_DS); - ret = __sys_tux(action, u_info); - set_fs(old_fs); - - err = copy_to_user(u_info32, u_info, - offsetof(user_req32_t, object_addr)); - - tmp1 = (u32 *)u_info->object_addr; - tmp2 = (u32 *)u_info->priv; - tmp3 = (u32 *)u_info->id; - - err |= __put_user(tmp1, &u_info32->object_addr); - err |= __put_user(tmp2, &u_info32->priv); - err |= __put_user(tmp3, &u_info32->id); - - if (err) - ret = -EFAULT; - -out_kfree: - kfree(u_info); -out: - return ret; -} - int get_compat_timeval(struct timeval *tv, struct compat_timeval *ctv) { return (verify_area(VERIFY_READ, ctv, sizeof(*ctv)) || From mingo at elte.hu Tue Feb 24 10:40:55 2004 From: mingo at elte.hu (Ingo Molnar) Date: Tue, 24 Feb 2004 11:40:55 +0100 Subject: [patch] tux3-2.6.3-A1 In-Reply-To: <20040221164031.GC5801@krispykreme> References: <20031230163942.GA12905@elte.hu> <3FF1D2B7.4050603@tmsusa.com> <20031231094856.GA7752@elte.hu> <20031231101431.GA8305@elte.hu> <20040101115729.GA11547@elte.hu> <20040109100403.GA25506@elte.hu> <20040219093335.GA30560@elte.hu> <20040220075810.GA1276@elte.hu> <20040221164031.GC5801@krispykreme> Message-ID: <20040224104055.GA24568@elte.hu> * Anton Blanchard wrote: > > a new Tux drop is available at: > > redhat.com/~mingo/TUX-patches/tux3-2.6.3-A2 > > Heres a patch to fix ppc64: > > - We call syscalls directly, not via their procedure descriptor. > - Remove 32bit translation code now the API is 32/64bit safe. thanks - new patch with these bits added is at: redhat.com/~mingo/TUX-patches/tux3-2.6.3-A3 Ingo From mingo at elte.hu Tue Feb 24 11:52:52 2004 From: mingo at elte.hu (Ingo Molnar) Date: Tue, 24 Feb 2004 12:52:52 +0100 Subject: [patch] tux3-2.6.3-A1 In-Reply-To: <20040224104055.GA24568@elte.hu> References: <3FF1D2B7.4050603@tmsusa.com> <20031231094856.GA7752@elte.hu> <20031231101431.GA8305@elte.hu> <20040101115729.GA11547@elte.hu> <20040109100403.GA25506@elte.hu> <20040219093335.GA30560@elte.hu> <20040220075810.GA1276@elte.hu> <20040221164031.GC5801@krispykreme> <20040224104055.GA24568@elte.hu> Message-ID: <20040224115252.GA26717@elte.hu> yet another iteration: redhat.com/~mingo/TUX-patches/tux3-2.6.3-A5 this has two arch fixes from Arjan and export cleanups. Ingo From jnerin at svalero.es Tue Feb 24 22:12:16 2004 From: jnerin at svalero.es (Jorge Nerin) Date: Tue, 24 Feb 2004 23:12:16 +0100 Subject: kernel BUG at gzip.c:3334! (2.4.23-ck1 etc) Message-ID: <403BCC40.6080001@svalero.es> Hello, I was testing the value of "2" in /proc/sys/net/tux/compression when I found that: feb 24 15:04:32 head tux: Tux version: 3/0/0 Feb 24 15:04:32 head kernel: TUX: logger thread started. Feb 24 15:04:32 head kernel: TUX: thread 0 listens on http://0.0.0.0:80. feb 24 15:04:32 head tux: tux startup succeeded Feb 24 15:17:56 head kernel: deflate in loop returned -5 Feb 24 15:17:56 head kernel: kernel BUG at gzip.c:3334! Feb 24 15:17:56 head kernel: invalid operand: 0000 Feb 24 15:17:56 head kernel: CPU: 0 Feb 24 15:17:57 head kernel: EIP: 0010:[lockd:nlmsvc_ops_Rc18947fa+160968/58190201] Not tainted Feb 24 15:17:57 head kernel: EFLAGS: 00010286 Feb 24 15:17:57 head kernel: eax: 0000001c ebx: c291eee0 ecx: 00000000 edx: c705e000 Feb 24 15:17:57 head kernel: esi: c1243e00 edi: c1243e04 ebp: 00000ce8 esp: c1243db8 Feb 24 15:17:57 head kernel: ds: 0018 es: 0018 ss: 0018 Feb 24 15:17:57 head kernel: Process tux (pid: 30101, stackpage=c1243000) Feb 24 15:17:57 head kernel: Stack: c89c9136 fffffffb c1242000 00004040 c6873f20 c89b452d c291eee0 c32ec000 Feb 24 15:17:57 head kernel: c368600b c1243e00 c1243e04 c32ec000 c3686000 c0eb6000 00000000 c1243e80 Feb 24 15:17:57 head kernel: c3c5e000 00000808 00000cb1 00000cdd c0eb620c 0000e000 c0d1b740 000001f0 Feb 24 15:17:57 head kernel: Call Trace: [lockd:nlmsvc_ops_Rc18947fa+173830/58177339] [lockd:nlmsvc_ops_Rc18947fa+88829/58262340] [alloc_skb+214/416] [do_generic_file_read+544/1312] [lockd:nlmsvc_ops_Rc18947fa+89644/58261525] Feb 24 15:17:57 head kernel: [lockd:nlmsvc_ops_Rc18947fa+88464/58262705] [lockd:nlmsvc_ops_Rc18947fa+188528/58162641] [lockd:nlmsvc_ops_Rc18947fa+109604/58241565] [lockd:nlmsvc_ops_Rc18947fa+83464/58267705] [lockd:nlmsvc_ops_Rc18947fa+86884/58264285] [lockd:nlmsvc_ops_Rc18947fa+188852/58162317] Feb 24 15:17:57 head kernel: [lockd:nlmsvc_ops_Rc18947fa+188528/58162641] [lockd:nlmsvc_ops_Rc18947fa+130232/58220937] [lockd:nlmsvc_ops_Rc18947fa+188528/58162641] [lockd:nlmsvc_ops_Rc18947fa+137866/58213303] [lockd:nlmsvc_ops_Rc18947fa+188528/58162641] [lockd:nlmsvc_ops_Rc18947fa+188528/58162641] Feb 24 15:17:57 head kernel: [path_release+15/48] [sys_chdir+156/176] [sys_tux+34/97] [system_call+51/64] Feb 24 15:17:57 head kernel: Feb 24 15:17:57 head kernel: Code: 0f 0b 06 0d 2f 91 9c c8 59 58 8b 43 04 89 46 00 8b 43 10 89 Feb 24 15:17:57 head kernel: <5>TUX: thread 0 stopping ... The partition type is reiserfs, just in case it does matter, the kernel is plain 2.4.23 with bits of the Con Kolivas patchset (O1 scheduler, lowlatency) a patch to disable ECN after a number of retries and a patch to correct the content-length in tux when compression is in use. It worked ok during some time, but then it stopped with this bug, I had to reboot. So far so good the value of "1" in compression works ok for me (precompressed files) with a patch (that I can't remember the autor) needed to send the correct Content-length, the compressed one instead of the original one. I resend the patch here, because the last time I sent it I did it with the wrong subject and it's needed in order to enable and use compression correctly (mozilla waits until timeout for the rest of the Content-length). --- linux-2.4.20-ck2-tux2/net/tux/proto_http.c Wed Jan 8 08:55:07 2003 +++ linux/net/tux/proto_http.c Wed Nov 20 14:34:59 2002 @@ -1958,9 +1958,25 @@ if (partial) curr += sprintf(curr, "%Ld", req->output_len); else { + /* // "%d" req->total_file_len memcpy(curr, &req->etag, req->lendigits); curr += req->lendigits; + */ + /* The ETag was generated with an uncompressed file's + * info. I've left the ETag as it is, but the size + * needs to be from req->total_file_len. In other + * words, needs to be from the compressed image if + * we're sending gzip versions. + * - miles at geekspeak.org -- 2002-11-13 + */ + if (req->content_gzipped) + curr += sprintf(curr, "%Ld", req->total_file_len); + else { + memcpy(curr, &req->etag, req->lendigits); + curr += req->lendigits; + } + } if (tux_generate_etags && (req->status != 404)) { -- Jorge Nerin From mingo at elte.hu Wed Feb 25 10:42:23 2004 From: mingo at elte.hu (Ingo Molnar) Date: Wed, 25 Feb 2004 11:42:23 +0100 Subject: kernel BUG at gzip.c:3334! (2.4.23-ck1 etc) In-Reply-To: <403BCC40.6080001@svalero.es> References: <403BCC40.6080001@svalero.es> Message-ID: <20040225104223.GA11186@elte.hu> * Jorge Nerin wrote: > Hello, I was testing the value of "2" in /proc/sys/net/tux/compression > when I found that: > > Feb 24 15:17:56 head kernel: deflate in loop returned -5 > Feb 24 15:17:56 head kernel: kernel BUG at gzip.c:3334! i've uploaded a new Tux patch to: redhat.com/~mingo/TUX-patches/tux3-2.6.3-B2 i've fixed all bugs in the gzip code i could find: made it use the 2.6 kernel's deflate library, and fixed a couple of bad assumptions. Memory consumption should be lower as well, since now deflate state is per-Tux-thread, not per-request. I've added the gzip fix from Miles Elam as well. i've done light testing with compression=2, but YMMV - does it work for you? i suspect the compression level should be configurable as well. Right now it's hardcoded to level 6 - what level would be the best? (this patch includes some more fixes as well - eg. stack footprint reduction for CGIs.). Ingo From michelegonella at libero.it Wed Feb 25 13:06:10 2004 From: michelegonella at libero.it (michelegonella at libero.it) Date: Wed, 25 Feb 2004 14:06:10 +0100 Subject: /proc and cgi Message-ID: hi all, I can't run cgi programs on tux 3.2.12-2 kernel 2.6.3 patched tux3-2.6.3-A7 documents refer to version 2.1 and some /proc keys look different. Is there some documentation handful to solve my problem? thanks in advance Michele From jnerin at svalero.es Wed Feb 25 15:50:41 2004 From: jnerin at svalero.es (Jorge Nerin) Date: Wed, 25 Feb 2004 16:50:41 +0100 Subject: kernel BUG at gzip.c:3334! (2.4.23-ck1 etc) In-Reply-To: <20040225104223.GA11186@elte.hu> References: <403BCC40.6080001@svalero.es> <20040225104223.GA11186@elte.hu> Message-ID: <403CC451.6060508@svalero.es> Ingo Molnar wrote: >* Jorge Nerin wrote: > > > >>Hello, I was testing the value of "2" in /proc/sys/net/tux/compression >>when I found that: >> >>Feb 24 15:17:56 head kernel: deflate in loop returned -5 >>Feb 24 15:17:56 head kernel: kernel BUG at gzip.c:3334! >> >> > >i've uploaded a new Tux patch to: > > redhat.com/~mingo/TUX-patches/tux3-2.6.3-B2 > >i've fixed all bugs in the gzip code i could find: made it use the 2.6 >kernel's deflate library, and fixed a couple of bad assumptions. Memory >consumption should be lower as well, since now deflate state is >per-Tux-thread, not per-request. I've added the gzip fix from Miles Elam >as well. > >i've done light testing with compression=2, but YMMV - does it work for >you? > >i suspect the compression level should be configurable as well. Right >now it's hardcoded to level 6 - what level would be the best? > >(this patch includes some more fixes as well - eg. stack footprint >reduction for CGIs.). > > Ingo > > I still can't upgrade to 2.6, this box has a beta redhat 6.9.5 heavily tweaked and I can't seem to find the time to upgrade to 2.6 (the glibc threads upgrade scares me), if you can make a patch to 2.4 I will try it. About the compression level, the easy answer is to make it a configurable value, either at compile time, or better like a proc entry, but I find that 6 is a good answer, althougth the cvs folks always recomends 3. -- Jorge Nerin From tux at mikebell.org Wed Feb 25 16:08:18 2004 From: tux at mikebell.org (tux at mikebell.org) Date: Wed, 25 Feb 2004 08:08:18 -0800 Subject: kernel BUG at gzip.c:3334! (2.4.23-ck1 etc) In-Reply-To: <403CC451.6060508@svalero.es> References: <403BCC40.6080001@svalero.es> <20040225104223.GA11186@elte.hu> <403CC451.6060508@svalero.es> Message-ID: <20040225160816.GH540@tinyvaio.nome.ca> On Wed, Feb 25, 2004 at 04:50:41PM +0100, Jorge Nerin wrote: > I still can't upgrade to 2.6, this box has a beta redhat 6.9.5 heavily > tweaked and I can't seem to find the time to upgrade to 2.6 (the glibc > threads upgrade scares me), if you can make a patch to 2.4 I will try it. AFAIK, upgrading to 2.6 doesn't force you to use NPTL, linuxthreads continue to work just fine (of course, otherwise threaded applications would stop working under 2.6 until you upgrade to an NPTL-enabled glibc). From mcd at daviesinc.com Thu Feb 26 17:02:58 2004 From: mcd at daviesinc.com (Chris Davies) Date: Thu, 26 Feb 2004 12:02:58 -0500 Subject: Strange behavior with Tux 3/2.4.23 Message-ID: <1077814977.27452.348.camel@mcdlp.pbi.daviesinc.com> I've got a machine that we're installing Tux on that runs some custom software but uses the Tux accelerator for images. With apache2, Tux passes the information to the backend properly, the pages are served as expected. With apache 1.3.29, Tux doesn't seem to pass the host header to apache in a manner that apache can read. I can telnet to port 81 and do even the most basic commands and get the proper results, both HTTP/1.0 and HTTP/1.1 But, anytime I telnet to port 80 and issue GET / HTTP/1.0 Host: site.com I get HTTP/1.1 301 Moved Permanently Location: http://xxxx.xxxxxxxx.com// Content-Length: 36 Connection: Keep-Alive Content-Type: text/html and in the apache log: [Thu Feb 26 11:17:16 2004] [error] [client 67.34.200.112] File does not exist: /var/www// if I put /var/www/index.html in there, it will serve index.html, which is specified as the DocumentRoot for apache, but, proves that apache1 is not getting/reading the Host Header properly. If I tell tux not to redirect html, it will serve the correct html. If I hit apache on port 81, it will serve the correct html. The same VirtualHost config works fine on apache2, but fails on apache 1.3. I had this problem on a machine a while back running apache 1.3.x, but didn't make the conclusion that apache wasn't decoding the host info from the backend. My guess is that apache1.3 must get confused by some info that tux is handing it whereas apache2 is able to decode that info. I am reasonably sure my config of apache1.3 is solid -- and the only change to tux is to change from port 81 to 82 for Apache1 and Apache2 respectively. Client must use Apache 1.3 in this particular instance. Any thoughts? Debian 3.0/Sid/unstable Kernel 2.4.23 Tux 3/0/0 according to the tux userland utilities apache 1.3.29 apache 2.0.47 /etc/apache/httpd.conf ServerType standalone ServerRoot /etc/apache LockFile /var/lock/apache.lock PidFile /var/run/apache.pid ScoreBoardFile /var/run/apache.scoreboard KeepAlive Off MinSpareServers 15 MaxSpareServers 30 StartServers 75 MaxClients 1000 MaxRequestsPerChild 10000 Port 81 Include /etc/apache/modules.conf User www-data Group www-data ServerAdmin webmaster at daviesinc.com ServerName fs1.colo-cation.com DocumentRoot /var/www ServerSignature Off ServerTokens Prod AddDefaultCharset on Options SymLinksIfOwnerMatch AllowOverride None Options Indexes Includes FollowSymLinks MultiViews AllowOverride None DirectoryIndex index.html index.htm index.shtml index.cgi UseCanonicalName On TypesConfig /etc/mime.types DefaultType text/plain HostnameLookups Off ErrorLog /var/log/apache/error.log LogLevel warn LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined Include /etc/apache/conf.d Include /etc/local-config/apache /etc/apache/modules.conf ClearModuleList AddModule mod_so.c AddModule mod_macro.c LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so LoadModule mime_module /usr/lib/apache/1.3/mod_mime.so LoadModule dir_module /usr/lib/apache/1.3/mod_dir.so VirtualHost Config: NameVirtualHost * DocumentRoot /var/www/1.2.3.4/xxxx.xxxxxxxx.com ServerName xxxx.xxxxxxxx.com CustomLog /var/log/apache/xxxx.xxxxxxxx.com-access.log full From diogenes at vgernet.net Fri Feb 27 22:29:26 2004 From: diogenes at vgernet.net (Ralph E. Kenyon, Jr.) Date: Fri, 27 Feb 2004 17:29:26 -0500 Subject: includes Message-ID: Hi, I'm new to linux, and I'm trying to get my website working. I've had pages working under Windoze 2000 IIS and on my ISP site. They have stuff like this in them: With Tux as the main server in Redhat 9, the includes aren't getting expanded. My reading suggests that I need to have Apache as the primary server and Tux as the secondary server. I've set Apache to listen to port 80, and Tux to listen to 8080, but I could not find out how to configure Tux to start on port 8080 at boot-up. How can this be done? -- http://www.xenodochy.org/ralph.html Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ From mcd at daviesinc.com Fri Feb 27 22:50:28 2004 From: mcd at daviesinc.com (Chris Davies) Date: Fri, 27 Feb 2004 17:50:28 -0500 Subject: includes In-Reply-To: References: Message-ID: <1077922228.27452.632.camel@mcdlp.pbi.daviesinc.com> my memory is vague, however, it was something like echo 'http://0.0.0.0:8080' >/proc/net/tux/0/listen/0 however.... I think you really want tux as the frontend, and apache as your backend on 8080 or whatever port, and in /etc/tux.mime.types, you want: TUX/Redirect shtml htm html php and all of the extensions -- that way, tux will handle everything and pass it to the backend for the extensions listed. And then it doesn't require any education on the part of the web designer as he uploads content. On Fri, 2004-02-27 at 17:29, Ralph E. Kenyon, Jr. wrote: > Hi, > I'm new to linux, and I'm trying to get my website working. > I've had pages working under Windoze 2000 IIS and on my ISP site. > They have stuff like this in them: > > > > > > With Tux as the main server in Redhat 9, the includes aren't getting > expanded. > My reading suggests that I need to have Apache as the primary server and > Tux as the secondary server. I've set Apache to listen to port 80, and > Tux to listen to 8080, but I could not find out how to configure Tux to > start on port 8080 at boot-up. > > How can this be done? -- Chris Davies E-Commerce/Colocation http://daviesinc.com/ +1.561.333.6946 Florida, USA From diogenes at vgernet.net Fri Feb 27 23:35:36 2004 From: diogenes at vgernet.net (Ralph E. Kenyon, Jr.) Date: Fri, 27 Feb 2004 18:35:36 -0500 Subject: includes In-Reply-To: <1077922228.27452.632.camel@mcdlp.pbi.daviesinc.com> References: <1077922228.27452.632.camel@mcdlp.pbi.daviesinc.com> Message-ID: On Fri, 27 Feb 2004 17:50:28 -0500, Chris Davies wrote: > my memory is vague, however, it was something like > > echo 'http://0.0.0.0:8080' >/proc/net/tux/0/listen/0 > > however.... > > I think you really want tux as the frontend, and apache as your backend > on 8080 or whatever port, and in /etc/tux.mime.types, you want: > > TUX/Redirect shtml htm html php > > and all of the extensions -- that way, tux will handle everything and > pass it to the backend for the extensions listed. > > And then it doesn't require any education on the part of the web > designer as he uploads content. > > On Fri, 2004-02-27 at 17:29, Ralph E. Kenyon, Jr. wrote: >> Hi, >> I'm new to linux, and I'm trying to get my website working. >> I've had pages working under Windoze 2000 IIS and on my ISP site. >> They have stuff like this in them: >> >> >> >> >> >> With Tux as the main server in Redhat 9, the includes aren't getting >> expanded. >> My reading suggests that I need to have Apache as the primary server and >> Tux as the secondary server. I've set Apache to listen to port 80, and >> Tux to listen to 8080, but I could not find out how to configure Tux to >> start on port 8080 at boot-up. >> >> How can this be done? Thanks! That sounds better. I'll try to get it working that way. -- http://www.xenodochy.org/ralph.html Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/