Re: [9fans] plan9 httpd/pegasus on unix?

[Russ Cox]

perhaps discussion of qmail would be more appropriate
on some other list or in private email.

russ

Re: [9fans] plan9 httpd/pegasus on unix?

[erik quanstrom]

> 
> I've got to maintain a several hundred packages for our emedded target 
> platforms. All of them MUST fit into an 100% automatic build process. 
> So it really matters if I have to develop (and maintain for a long
> time) individual build rules for each package.
> 

what is the definition of embedded these days?

- erik

Re: [9fans] plan9 httpd/pegasus on unix?

[Uriel]

Pity you are so busy, we all would love so much to hear more of what
you have to say about lunix MTAs.

And please, keep us updated with every detail of your tireless efforts
to 'create' a GPL fork of qmail, that project would be of utmost
relevance and usefulness to Plan 9.

uriel

On Fri, Feb 29, 2008 at 7:16 PM, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> * sqweek <[EMAIL PROTECTED]> wrote:
>
>
> > >  Well, this *very* unobvious and complex (instead of just passing $CC and
>  > >  $LD to make), requires me to maintain additional logic, which woulnd't
>  > >  be necessary, if DJB could write his makefiles in more standard and sane
>  > >  ways ;-P
>  >
>  >  The docs are a bit light on custom compilers, granted (probably as
>  > they're irrelevant for 95% of users), but INSTALL does point you at
>  > conf-users/conf-groups/conf-qmail. Doesn't take a genius to notice
>  > conf-cc and conf-ld from there.
>
>  It's not the point that it is written somewhere, but that it's very
>  different of the vast majority of the packages I'm using/maintaining.
>
>  I've got to maintain a several hundred packages for our emedded target
>  platforms. All of them MUST fit into an 100% automatic build process.
>  So it really matters if I have to develop (and maintain for a long
>  time) individual build rules for each package.
>
>  I would accept this if these individualities would serve an noticable
>  purpose, but I don't see that here. Not that I want to tell DJB how
>  to write makefiles (in this issue), but he must accept that doing such
>  trivial things totally different than 99% of the world isn't quite
>  user/maintainer friendly.
>
>
>  >  DJB's makefiles have the dubious honour of probably being written
>  > before such conventions existed. There is a reason he does it that way
>  > - Makefile dependencies only work with the timestamps on files. If you
>  > do it the "sane" way, then make has no information about the freshness
>  > of the information in CC.
>
>  Right, but actually I never had problems with this in recent 15 years.
>  "make clean" after changing toolchain settings should be obvoius.
>  *If* you really want to catch this, you an store the settings in some
>  file and compare it on next make run (almost trivial):
>
>  * some check rule (dependency for the other targets) compares the
>   current settings (eg coming from env) with the stored ones. If
>   they've changed, force recreate of the settings file
>  * the stored-settings file is created from the current settings
>  * all targets depend on the settings file
>
>
>  >  This is the motivation for DJB putting the commands into files
>  > instead of using the environment or make variables. That way he can
>  > have all the compilation rules depend on conf-cc so that should you
>  > change it, everything gets rebuilt properly. Similarly with the other
>  > conf- files - you don't need a make clean or anything after changing
>  > them, just make and exactly what needs to get regenerated will get
>  > regenerated. We're talking pretty marginal gains, obviously -
>  > recompilation is not expensive. It's mainly an academic achievement -
>  > having a *correct* Makefile.
>
>  Well, this approach is nice (probably useful for really large trees,
>  which BTW shouldnt exist at all ;-P), but has the drawback that you
>  have to take great care not to forget an single dependency to some
>  settings. And good chance for bugs ;-P
>
>
>  > >  >  Granted, the -include is a bitch and took me awhile to work out.
>  > >
>  > >  Actually, this is crap. Probably he just forgets the #include's.
>  >
>  >  Yes. There is history here again. If you hunt around you'll find
>  > posts from DJB complaining about unix (libc?) developers breaking
>  > existing code by making errno not work without including errno.h.
>
>  Then he probably complains that people fixed libc ? ;-O
>  Isn't this obvious that you have to include errno.h if you're using
>  stuff from it ? Seems like he just relied on someone else to
>  inlude errno.h ;-O
>
>
>  > >  >  The sysroot requirement is a little harder to meet, but really just
>  > >  > requires a mount --bind /tmp/sysroot/var/qmail /var/qmail. Or, if
>  > >  > you're running qmail on the host and really can't afford to stop it
>  > >  > for a minute or two, a custom setup rule based on hier.c (or use a
>  > >  > chroot - oh if only lunix had private namespaces...).
>  > >
>  > >  chroot != sysroot.
>  >
>  >  I'm well aware. If you were paying attention you'd notice I was
>  > suggesting a chroot as a method of putting a directory from the
>  > sysroot in the standard location without affecting the host system,
>  > not suggesting you attempt to chroot into a cross-compiled root.
>  >  And again, if lunix had learnt anything from plan9 this would be 
> *trivial*.
>
>  Still doesn't help in any ways. DJB's makefile *runs* compiled code
>  on the compiling machine. This DOES NOT work on crosscompiling.
>
>  Sometimes it *MAY* work if host

Re: [9fans] plan9 httpd/pegasus on unix?

[Enrico Weigelt]

* sqweek <[EMAIL PROTECTED]> wrote:

> >  Well, this *very* unobvious and complex (instead of just passing $CC and
> >  $LD to make), requires me to maintain additional logic, which woulnd't
> >  be necessary, if DJB could write his makefiles in more standard and sane
> >  ways ;-P
> 
>  The docs are a bit light on custom compilers, granted (probably as
> they're irrelevant for 95% of users), but INSTALL does point you at
> conf-users/conf-groups/conf-qmail. Doesn't take a genius to notice
> conf-cc and conf-ld from there.

It's not the point that it is written somewhere, but that it's very
different of the vast majority of the packages I'm using/maintaining.

I've got to maintain a several hundred packages for our emedded target 
platforms. All of them MUST fit into an 100% automatic build process. 
So it really matters if I have to develop (and maintain for a long
time) individual build rules for each package.

I would accept this if these individualities would serve an noticable
purpose, but I don't see that here. Not that I want to tell DJB how
to write makefiles (in this issue), but he must accept that doing such
trivial things totally different than 99% of the world isn't quite
user/maintainer friendly.

>  DJB's makefiles have the dubious honour of probably being written
> before such conventions existed. There is a reason he does it that way
> - Makefile dependencies only work with the timestamps on files. If you
> do it the "sane" way, then make has no information about the freshness
> of the information in CC. 

Right, but actually I never had problems with this in recent 15 years.
"make clean" after changing toolchain settings should be obvoius.
*If* you really want to catch this, you an store the settings in some
file and compare it on next make run (almost trivial):

* some check rule (dependency for the other targets) compares the 
  current settings (eg coming from env) with the stored ones. If 
  they've changed, force recreate of the settings file
* the stored-settings file is created from the current settings
* all targets depend on the settings file

>  This is the motivation for DJB putting the commands into files
> instead of using the environment or make variables. That way he can
> have all the compilation rules depend on conf-cc so that should you
> change it, everything gets rebuilt properly. Similarly with the other
> conf- files - you don't need a make clean or anything after changing
> them, just make and exactly what needs to get regenerated will get
> regenerated. We're talking pretty marginal gains, obviously -
> recompilation is not expensive. It's mainly an academic achievement -
> having a *correct* Makefile.

Well, this approach is nice (probably useful for really large trees,
which BTW shouldnt exist at all ;-P), but has the drawback that you
have to take great care not to forget an single dependency to some
settings. And good chance for bugs ;-P

> >  >  Granted, the -include is a bitch and took me awhile to work out.
> >
> >  Actually, this is crap. Probably he just forgets the #include's.
> 
>  Yes. There is history here again. If you hunt around you'll find
> posts from DJB complaining about unix (libc?) developers breaking
> existing code by making errno not work without including errno.h.

Then he probably complains that people fixed libc ? ;-O
Isn't this obvious that you have to include errno.h if you're using
stuff from it ? Seems like he just relied on someone else to 
inlude errno.h ;-O

> >  >  The sysroot requirement is a little harder to meet, but really just
> >  > requires a mount --bind /tmp/sysroot/var/qmail /var/qmail. Or, if
> >  > you're running qmail on the host and really can't afford to stop it
> >  > for a minute or two, a custom setup rule based on hier.c (or use a
> >  > chroot - oh if only lunix had private namespaces...).
> >
> >  chroot != sysroot.
> 
>  I'm well aware. If you were paying attention you'd notice I was
> suggesting a chroot as a method of putting a directory from the
> sysroot in the standard location without affecting the host system,
> not suggesting you attempt to chroot into a cross-compiled root.
>  And again, if lunix had learnt anything from plan9 this would be *trivial*.

Still doesn't help in any ways. DJB's makefile *runs* compiled code 
on the compiling machine. This DOES NOT work on crosscompiling.

Sometimes it *MAY* work if host and target are compatible, which may
happen on my site as I'm also crosscompiling to same platform+arch.
For me, crosscompiling isn't just a way for gettings something built
for another platform+arch, but a integral part of build and QM process.

To catch such mixups between host and target, even when host can 
run target's binaries, I first build the package for an incompatible
target to let it intentionally break when such mixups happen.

BTW: you didn't response to the compilied-in UID issue.
Rember: DJB takes the numeric UIDs/GIDs from the building host
and statically compiles them in.

Re: [9fans] plan9 httpd/pegasus on unix?

[Enrico Weigelt]

* Chad Dougherty <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 28, 2008 at 06:27:38PM +0100, Enrico Weigelt wrote:
> > Well, you've probably got the netqmail port, which automatically patches 
> > it's own sourcetree within the build process. (AFAIK, DJB's license
> > doesn't allow shipping an complete sourcetree, so netqmail has to
> > be shipped as patch against qmail).
> > 
> 
> qmail was placed in the public domain in November of last year:
> 
> 

Ah, great :)
I missed that. (I started working on this before the license change). 

So, if it's really public domain, I'm free to publish my own
fork under GPL.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [9fans] plan9 httpd/pegasus on unix?

[sqweek]

On Fri, Feb 29, 2008 at 2:27 AM, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> * sqweek <[EMAIL PROTECTED]> wrote:
>  > >  Did you ever try to building qmail ?
>  >
>  >  Yes. On linux and netbsd. With and without various patches. Works 
> perfectly.
>
>  Well, you've probably got the netqmail port, which automatically patches
>  it's own sourcetree within the build process.

 Nope. qmail-1.03.tar.gz. On netbsd anyway - on linux I built it from
my package manager which... yes, uses netqmail. And I get the same TLS
error here as at work with qmail-1.03 so I guess I owe centOS an
apology.

>  > $ uname -p
>  > x86_64
>  > $ echo cc -m32 -O2 -include /usr/include/errno.h >conf-cc
>  > $ echo cc -m32 >conf-ld
>  > $ make
>
>  Well, this *very* unobvious and complex (instead of just passing $CC and
>  $LD to make), requires me to maintain additional logic, which woulnd't
>  be necessary, if DJB could write his makefiles in more standard and sane
>  ways ;-P

 The docs are a bit light on custom compilers, granted (probably as
they're irrelevant for 95% of users), but INSTALL does point you at
conf-users/conf-groups/conf-qmail. Doesn't take a genius to notice
conf-cc and conf-ld from there.
 DJB's makefiles have the dubious honour of probably being written
before such conventions existed. There is a reason he does it that way
- Makefile dependencies only work with the timestamps on files. If you
do it the "sane" way, then make has no information about the freshness
of the information in CC. Are there object files sitting around that
were built with an incompatible CC invocation?
 This is the motivation for DJB putting the commands into files
instead of using the environment or make variables. That way he can
have all the compilation rules depend on conf-cc so that should you
change it, everything gets rebuilt properly. Similarly with the other
conf- files - you don't need a make clean or anything after changing
them, just make and exactly what needs to get regenerated will get
regenerated. We're talking pretty marginal gains, obviously -
recompilation is not expensive. It's mainly an academic achievement -
having a *correct* Makefile.

>  >  Granted, the -include is a bitch and took me awhile to work out.
>
>  Actually, this is crap. Probably he just forgets the #include's.

 Yes. There is history here again. If you hunt around you'll find
posts from DJB complaining about unix (libc?) developers breaking
existing code by making errno not work without including errno.h.
Which made me somewhat surprised to hit this problem, but I guess
qmail-1.03 is old enough to be affected.

>  >  The sysroot requirement is a little harder to meet, but really just
>  > requires a mount --bind /tmp/sysroot/var/qmail /var/qmail. Or, if
>  > you're running qmail on the host and really can't afford to stop it
>  > for a minute or two, a custom setup rule based on hier.c (or use a
>  > chroot - oh if only lunix had private namespaces...).
>
>  chroot != sysroot.

 I'm well aware. If you were paying attention you'd notice I was
suggesting a chroot as a method of putting a directory from the
sysroot in the standard location without affecting the host system,
not suggesting you attempt to chroot into a cross-compiled root.
 And again, if lunix had learnt anything from plan9 this would be *trivial*.
-sqweek

Re: [9fans] plan9 httpd/pegasus on unix?

[Chad Dougherty]

On Thu, Feb 28, 2008 at 06:27:38PM +0100, Enrico Weigelt wrote:
> Well, you've probably got the netqmail port, which automatically patches 
> it's own sourcetree within the build process. (AFAIK, DJB's license
> doesn't allow shipping an complete sourcetree, so netqmail has to
> be shipped as patch against qmail).
> 

qmail was placed in the public domain in November of last year:

Re: [9fans] plan9 httpd/pegasus on unix?

[Enrico Weigelt]

* sqweek <[EMAIL PROTECTED]> wrote:
> >  Did you ever try to building qmail ?
> 
>  Yes. On linux and netbsd. With and without various patches. Works perfectly.

Well, you've probably got the netqmail port, which automatically patches 
it's own sourcetree within the build process. (AFAIK, DJB's license
doesn't allow shipping an complete sourcetree, so netqmail has to
be shipped as patch against qmail).

For local/native builds it might be okay, but for my crosscompiling/
sysroot'ing needs it's totally unusable. (at least the latest version
I tried several month ago)

> >  For some customer, I had to get it built in our automated image
> >  builder (which does evrything from scratch wit an sysroot'ed
> >  cross-toolchain).
> 
> $ uname -p
> x86_64
> $ echo cc -m32 -O2 -include /usr/include/errno.h >conf-cc
> $ echo cc -m32 >conf-ld
> $ make

Well, this *very* unobvious and complex (instead of just passing $CC and 
$LD to make), requires me to maintain additional logic, which woulnd't
be necessary, if DJB could write his makefiles in more standard and sane
ways ;-P

>  Granted, the -include is a bitch and took me awhile to work out. 

Actually, this is crap. Probably he just forgets the #include's.
Having to include an absolute file is *very* bad for automated build systems. 
BTW: ANSI-C and ISO-C spec define , not /usr/include/errno.h
(it's up to the compiler to find it).

>  The sysroot requirement is a little harder to meet, but really just
> requires a mount --bind /tmp/sysroot/var/qmail /var/qmail. Or, if
> you're running qmail on the host and really can't afford to stop it
> for a minute or two, a custom setup rule based on hier.c (or use a
> chroot - oh if only lunix had private namespaces...).

chroot != sysroot. 

An sysroot is required for clean crosscompiling. Obviously you CANNOT 
run the freshly compiled binaries there.

DBJ does really a lot of executing freshly compiled stuff, also for
finding out things which are already provided by the toolchain
(eg. typesizes). And - consider this insanity - he compiles-in
numeric user id's of the building system. Obvoius that this sooner
or later will cause great headhache.

> > Required me to completely rewrite all makefiles.
> 
>  Just like you had to fork libixp and rewrite all its makefiles?

No, I forked libixp because it didn't yet suit my needs 
(makefiles were quite okay). The result of my works on this front
are libmixp, libmixpsrv and libmvfs which are totally different 
from libixp - an *complete* fork (including distinct naming) 
was an obvious move from start on.

> You can rewrite makefiles in every spare second of your time and I
> don't care. However, your apparent inability to grasp any build system
> not written by yourself is no excuse to spread FUD about other
> packages.

Your personal ranting doesn't bring any argument, neither anything
else productive, and just wastes bandwidth.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [9fans] plan9 httpd/pegasus on unix?

[sqweek]

On Thu, Feb 28, 2008 at 12:52 AM, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> * John Barham <[EMAIL PROTECTED]> wrote:
>
>  > If you just want to serve static content on Unix/FreeBSD, Dan
>  > Bernstein's HTTP server in his publicfile package
>  > (http://cr.yp.to/publicfile.html) is one option.  Considering his
>  > reputation for writing secure software it's probably as good a choice
>  > as any.
>
>  Beware: this reputation is limited to "secure" - installing and
>  maintenance of DJB-packages is really ugly ! (actally, I wouldn't
>  cause this stuff "packages", but collections of code fragments).
>
>  Did you ever try to building qmail ?

 Yes. On linux and netbsd. With and without various patches. Works perfectly.
 The only time in 2 years it has ever required "ugly maintenance" was
no fault of qmail's - about 2 weeks ago my ip-range got blacklisted by
some spam databases for consisting of dynamic ip assignments, so I had
to route outgoing mail through my ISP's mail server.

>  For some customer, I had to get it built in our automated image
>  builder (which does evrything from scratch wit an sysroot'ed
>  cross-toolchain).

$ uname -p
x86_64
$ echo cc -m32 -O2 -include /usr/include/errno.h >conf-cc
$ echo cc -m32 >conf-ld
$ make
...
$ objdump -f auto-gid
auto-gid: file format elf32-i386
architecture: i386, flags 0x0112:
...

 Granted, the -include is a bitch and took me awhile to work out. Some
TLS[1] related error which I don't have a good understanding of. Marks
my first qmail build failure - I blame centOS :P
 The sysroot requirement is a little harder to meet, but really just
requires a mount --bind /tmp/sysroot/var/qmail /var/qmail. Or, if
you're running qmail on the host and really can't afford to stop it
for a minute or two, a custom setup rule based on hier.c (or use a
chroot - oh if only lunix had private namespaces...).

[1] /usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section .tbss
mismatches non-TLS reference in substdio.a(substdo.o)

> Required me to completely rewrite all makefiles.

 Just like you had to fork libixp and rewrite all its makefiles?
 Look, if you have a penchant for reimplementing build systems, go for
it. You can rewrite makefiles in every spare second of your time and I
don't care. However, your apparent inability to grasp any build system
not written by yourself is no excuse to spread FUD about other
packages.
-sqweek

Re: [9fans] plan9 httpd/pegasus on unix?

[John Barham]

Enrico Weigelt wrote:

>  Beware: this reputation is limited to "secure" - installing and
>  maintenance of DJB-packages is really ugly !

Not in my experience, and I daresay that if you do use his servers
(qmail and djbdns in particular) it's easier than rebuilding your
systems after the BIND and sendmail exploits du jour.

  John

Re: [9fans] plan9 httpd/pegasus on unix?

[Steve Simon]

fgb pointed me to TDs web server on IRC the other day,
its really aimed at embedded devices but I would trust
his code.

http://www.iq0.com/duffgram/http.c

-Steve

Re: [9fans] plan9 httpd/pegasus on unix?

[Enrico Weigelt]

* John Barham <[EMAIL PROTECTED]> wrote:

> If you just want to serve static content on Unix/FreeBSD, Dan
> Bernstein's HTTP server in his publicfile package
> (http://cr.yp.to/publicfile.html) is one option.  Considering his
> reputation for writing secure software it's probably as good a choice
> as any.

Beware: this reputation is limited to "secure" - installing and
maintenance of DJB-packages is really ugly ! (actally, I wouldn't
cause this stuff "packages", but collections of code fragments).

Did you ever try to building qmail ? 
For some customer, I had to get it built in our automated image
builder (which does evrything from scratch wit an sysroot'ed
cross-toolchain). Required me to completely rewrite all makefiles.

If such things happen in beta versions, okay. But I never would 
call some package "stable" as long as it doesn't build cleanly
out-of-th-box ;-O


BTW: if you're looking for an lightweight httpd for *nix 
platforms, you might consider lighttpd.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [9fans] plan9 httpd/pegasus on unix?

[Uriel]

If you want to write web apps in rc, p9p is enough.
http://gsoc.cat-v.org is built with rc based templates and the 'werc'
framework (barely over a hundred lines of rc code).

If you want to do things right I would use mjl's new httpd for Inferno.

uriel

On Sat, Feb 23, 2008 at 10:22 PM,  <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>  I have a machine running FreeBSD that I want to set up as a web server
>  (among other things). It's not powered by plan9 because I also want to
>  run libtorrent/rtorrent on it, and afaik there's no bittorrent client
>  yet for plan9.
>  I used to run thttpd because I want something small, relatively secure,
>  and simple, but now I would like to set up something plan9-ish if
>  possible. One of the reasons being that I found Kenji's rc based cgi
>  thingie he showed at iwp9 quite nice, and I'd like to eventually use
>  that (especially since it would be a nice rc learning exercise for me
>  to port all my current perl cgis in rc.)
>
>  So my question is what is my best option?
>  Setting up inferno on FreeBSD and run httpd from there? Setting up plan9
>  in xen (or lguest) and set httpd inside that? Try to port plan9's httpd
>  to unix, using p9p as an example? Just stick to some unix httpd because
>  it's not worth it? (I guess it wouldn't be that hard to get thttpd to
>  run some rc cgis actually).
>
>  Please bear in my mind that this is an old box (p200, 256MB ram), so the
>  solution has to be light (for example I'm not even sure it's possible to
>  achieve the xen or inferno one). Well, I guess it can't be worse than
>  apache2, which actually used to run on that machine...
>
>  Thanks,
>  Mathieu.
>
>  --
>  GPG key on subkeys.pgp.net:
>
>  KeyID:  | Fingerprint:
>  683DE5F3 | 4324 5818 39AA 9545 95C6 09AF B0A4 DFEA 683D E5F3
>  --
>

Re: [9fans] plan9 httpd/pegasus on unix?

[Kernel Panic]

[EMAIL PROTECTED] wrote:


Yeah I wish I could. But I'm really doing a lot of torrenting and I
can't afford to have another server at home dedicated for that (would be
too noisy), so both the torrenting and the webserving have to be on the
same machine. Hence FreeBSD and not plan9... :/
 

now here is a reason for you to port/write bittorrent software for 
Plan9! ;-)


cinap

Re: [9fans] plan9 httpd/pegasus on unix?

[lejatorn]

Yeah I wish I could. But I'm really doing a lot of torrenting and I
can't afford to have another server at home dedicated for that (would be
too noisy), so both the torrenting and the webserving have to be on the
same machine. Hence FreeBSD and not plan9... :/

On Mon, Feb 25, 2008 at 07:25:57AM -0800, ron minnich wrote:
> I run my web site on plan9. After watching my friends suffer through
> all the security warnings that come with apache, php, and all the
> other little bits that go with *nix web servers, I feel like I made an
> easier choice.
> 
> Latest one for one site: "We blocked the ports to your web server, you
> were running php x.y.4 and you need to run x.y.5". And, of course,
> x.y.5 didn't bulid correctly on macos ... ah fun.
> 
> ron

-- 
GPG key on subkeys.pgp.net:

KeyID:  | Fingerprint:
683DE5F3 | 4324 5818 39AA 9545 95C6 09AF B0A4 DFEA 683D E5F3
--

Re: [9fans] plan9 httpd/pegasus on unix?

[John Barham]

ron minnich wrote:
> I run my web site on plan9. After watching my friends suffer through
>  all the security warnings that come with apache, php, and all the
>  other little bits that go with *nix web servers, I feel like I made an
>  easier choice.

If you just want to serve static content on Unix/FreeBSD, Dan
Bernstein's HTTP server in his publicfile package
(http://cr.yp.to/publicfile.html) is one option.  Considering his
reputation for writing secure software it's probably as good a choice
as any.

  John

Re: [9fans] plan9 httpd/pegasus on unix?

[ron minnich]

I run my web site on plan9. After watching my friends suffer through
all the security warnings that come with apache, php, and all the
other little bits that go with *nix web servers, I feel like I made an
easier choice.

Latest one for one site: "We blocked the ports to your web server, you
were running php x.y.4 and you need to run x.y.5". And, of course,
x.y.5 didn't bulid correctly on macos ... ah fun.

ron

Re: [9fans] plan9 httpd/pegasus on unix?

[maht]

for an unlikely value for "best"

this one will get you started, and it's pretty secure once you've
learned how to chroot it and run it from tcpserver

http://www.proweb.co.uk/~matt/rc/webserver.rc

for CGI it's a matter of adding if(test -x $file) and going from there :)

Re: [9fans] plan9 httpd/pegasus on unix?

[Skip Tavakkolian]

> Please bear in my mind that this is an old box (p200, 256MB ram), so the
> solution has to be light (for example I'm not even sure it's possible to
> achieve the xen or inferno one). Well, I guess it can't be worse than
> apache2, which actually used to run on that machine...

can't get lighter than httpd on plan9 on hardware. i think it would keep
up the with load from a dsl.

Re: [9fans] plan9 httpd/pegasus on unix?

[erik quanstrom]

> So my question is what is my best option? 
> Setting up inferno on FreeBSD and run httpd from there? Setting up plan9
> in xen (or lguest) and set httpd inside that? Try to port plan9's httpd
> to unix, using p9p as an example? Just stick to some unix httpd because
> it's not worth it? (I guess it wouldn't be that hard to get thttpd to
> run some rc cgis actually).
> 
> Please bear in my mind that this is an old box (p200, 256MB ram), so the
> solution has to be light (for example I'm not even sure it's possible to
> achieve the xen or inferno one). Well, I guess it can't be worse than
> apache2, which actually used to run on that machine...

one little point: rc doesn't run on inferno.

- erik

[9fans] plan9 httpd/pegasus on unix?

[lejatorn]

Hi all,

I have a machine running FreeBSD that I want to set up as a web server
(among other things). It's not powered by plan9 because I also want to
run libtorrent/rtorrent on it, and afaik there's no bittorrent client
yet for plan9.
I used to run thttpd because I want something small, relatively secure,
and simple, but now I would like to set up something plan9-ish if
possible. One of the reasons being that I found Kenji's rc based cgi
thingie he showed at iwp9 quite nice, and I'd like to eventually use
that (especially since it would be a nice rc learning exercise for me
to port all my current perl cgis in rc.)

So my question is what is my best option? 
Setting up inferno on FreeBSD and run httpd from there? Setting up plan9
in xen (or lguest) and set httpd inside that? Try to port plan9's httpd
to unix, using p9p as an example? Just stick to some unix httpd because
it's not worth it? (I guess it wouldn't be that hard to get thttpd to
run some rc cgis actually).

Please bear in my mind that this is an old box (p200, 256MB ram), so the
solution has to be light (for example I'm not even sure it's possible to
achieve the xen or inferno one). Well, I guess it can't be worse than
apache2, which actually used to run on that machine...

Thanks,
Mathieu.

-- 
GPG key on subkeys.pgp.net:

KeyID:  | Fingerprint:
683DE5F3 | 4324 5818 39AA 9545 95C6 09AF B0A4 DFEA 683D E5F3
--