* [9fans] plan9 httpd/pegasus on unix? @ 2008-02-23 21:22 lejatorn 2008-02-23 21:34 ` erik quanstrom ` (3 more replies) 0 siblings, 4 replies; 21+ messages in thread From: lejatorn @ 2008-02-23 21:22 UTC (permalink / raw) To: 9fans 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 -- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-23 21:22 [9fans] plan9 httpd/pegasus on unix? lejatorn @ 2008-02-23 21:34 ` erik quanstrom 2008-02-23 22:13 ` Skip Tavakkolian ` (2 subsequent siblings) 3 siblings, 0 replies; 21+ messages in thread From: erik quanstrom @ 2008-02-23 21:34 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-23 21:22 [9fans] plan9 httpd/pegasus on unix? lejatorn 2008-02-23 21:34 ` erik quanstrom @ 2008-02-23 22:13 ` Skip Tavakkolian 2008-02-25 11:00 ` maht 2008-02-25 19:03 ` Uriel 3 siblings, 0 replies; 21+ messages in thread From: Skip Tavakkolian @ 2008-02-23 22:13 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-23 21:22 [9fans] plan9 httpd/pegasus on unix? lejatorn 2008-02-23 21:34 ` erik quanstrom 2008-02-23 22:13 ` Skip Tavakkolian @ 2008-02-25 11:00 ` maht 2008-02-25 15:25 ` ron minnich 2008-02-25 19:03 ` Uriel 3 siblings, 1 reply; 21+ messages in thread From: maht @ 2008-02-25 11:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 :) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-25 11:00 ` maht @ 2008-02-25 15:25 ` ron minnich 2008-02-25 16:26 ` John Barham 2008-02-25 16:30 ` lejatorn 0 siblings, 2 replies; 21+ messages in thread From: ron minnich @ 2008-02-25 15:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-25 15:25 ` ron minnich @ 2008-02-25 16:26 ` John Barham 2008-02-27 15:52 ` Enrico Weigelt 2008-02-25 16:30 ` lejatorn 1 sibling, 1 reply; 21+ messages in thread From: John Barham @ 2008-02-25 16:26 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-25 16:26 ` John Barham @ 2008-02-27 15:52 ` Enrico Weigelt 2008-02-27 17:50 ` Steve Simon ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Enrico Weigelt @ 2008-02-27 15:52 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs * John Barham <jbarham@gmail.com> 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/ --------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-27 15:52 ` Enrico Weigelt @ 2008-02-27 17:50 ` Steve Simon 2008-02-28 5:24 ` John Barham 2008-02-28 7:23 ` sqweek 2 siblings, 0 replies; 21+ messages in thread From: Steve Simon @ 2008-02-27 17:50 UTC (permalink / raw) To: weigelt, 9fans 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-27 15:52 ` Enrico Weigelt 2008-02-27 17:50 ` Steve Simon @ 2008-02-28 5:24 ` John Barham 2008-02-28 7:23 ` sqweek 2 siblings, 0 replies; 21+ messages in thread From: John Barham @ 2008-02-28 5:24 UTC (permalink / raw) To: weigelt, Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-27 15:52 ` Enrico Weigelt 2008-02-27 17:50 ` Steve Simon 2008-02-28 5:24 ` John Barham @ 2008-02-28 7:23 ` sqweek 2008-02-28 17:27 ` Enrico Weigelt 2 siblings, 1 reply; 21+ messages in thread From: sqweek @ 2008-02-28 7:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, Feb 28, 2008 at 12:52 AM, Enrico Weigelt <weigelt@metux.de> wrote: > * John Barham <jbarham@gmail.com> 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 0x00000112: ... 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-28 7:23 ` sqweek @ 2008-02-28 17:27 ` Enrico Weigelt 2008-02-28 19:23 ` Chad Dougherty 2008-02-29 0:26 ` sqweek 0 siblings, 2 replies; 21+ messages in thread From: Enrico Weigelt @ 2008-02-28 17:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs * sqweek <sqweek@gmail.com> 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 <errno.h>, 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/ --------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-28 17:27 ` Enrico Weigelt @ 2008-02-28 19:23 ` Chad Dougherty 2008-02-29 14:43 ` Enrico Weigelt 2008-02-29 0:26 ` sqweek 1 sibling, 1 reply; 21+ messages in thread From: Chad Dougherty @ 2008-02-28 19:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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: <http://cr.yp.to/qmail/dist.html> ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-28 19:23 ` Chad Dougherty @ 2008-02-29 14:43 ` Enrico Weigelt 0 siblings, 0 replies; 21+ messages in thread From: Enrico Weigelt @ 2008-02-29 14:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs * Chad Dougherty <crd@andrew.cmu.edu> 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: > > <http://cr.yp.to/qmail/dist.html> 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/ --------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-28 17:27 ` Enrico Weigelt 2008-02-28 19:23 ` Chad Dougherty @ 2008-02-29 0:26 ` sqweek 2008-02-29 18:16 ` Enrico Weigelt 1 sibling, 1 reply; 21+ messages in thread From: sqweek @ 2008-02-29 0:26 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Feb 29, 2008 at 2:27 AM, Enrico Weigelt <weigelt@metux.de> wrote: > * sqweek <sqweek@gmail.com> 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-29 0:26 ` sqweek @ 2008-02-29 18:16 ` Enrico Weigelt 2008-02-29 18:18 ` erik quanstrom ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Enrico Weigelt @ 2008-02-29 18:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs * sqweek <sqweek@gmail.com> 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. This is very bad even for purely native builds. So everytime you change some of these IDs, you have to completely rebuild qmail. First of all, you HAVE TO BE AWARE OF THAT (I'm really interested in what percentage of (potential) qmail users really know this). As an distro maintainer you have to *ENSURE* that every individual target system has the matching IDs to your building system. A very critical design flaw in the makefile. 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/ --------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-29 18:16 ` Enrico Weigelt @ 2008-02-29 18:18 ` erik quanstrom 2008-02-29 18:37 ` Uriel 2008-02-29 18:44 ` Russ Cox 2 siblings, 0 replies; 21+ messages in thread From: erik quanstrom @ 2008-02-29 18:18 UTC (permalink / raw) To: weigelt, 9fans > > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-29 18:16 ` Enrico Weigelt 2008-02-29 18:18 ` erik quanstrom @ 2008-02-29 18:37 ` Uriel 2008-02-29 18:44 ` Russ Cox 2 siblings, 0 replies; 21+ messages in thread From: Uriel @ 2008-02-29 18:37 UTC (permalink / raw) To: weigelt, Fans of the OS Plan 9 from Bell Labs 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 <weigelt@metux.de> wrote: > * sqweek <sqweek@gmail.com> 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. > This is very bad even for purely native builds. So everytime you > change some of these IDs, you have to completely rebuild qmail. > First of all, you HAVE TO BE AWARE OF THAT (I'm really interested > in what percentage of (potential) qmail users really know this). > As an distro maintainer you have to *ENSURE* that every individual > target system has the matching IDs to your building system. > A very critical design flaw in the makefile. > > > > > 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/ > --------------------------------------------------------------------- > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-29 18:16 ` Enrico Weigelt 2008-02-29 18:18 ` erik quanstrom 2008-02-29 18:37 ` Uriel @ 2008-02-29 18:44 ` Russ Cox 2 siblings, 0 replies; 21+ messages in thread From: Russ Cox @ 2008-02-29 18:44 UTC (permalink / raw) To: weigelt, 9fans perhaps discussion of qmail would be more appropriate on some other list or in private email. russ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-25 15:25 ` ron minnich 2008-02-25 16:26 ` John Barham @ 2008-02-25 16:30 ` lejatorn 2008-02-25 16:48 ` Kernel Panic 1 sibling, 1 reply; 21+ messages in thread From: lejatorn @ 2008-02-25 16:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 -- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-25 16:30 ` lejatorn @ 2008-02-25 16:48 ` Kernel Panic 0 siblings, 0 replies; 21+ messages in thread From: Kernel Panic @ 2008-02-25 16:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs lejatorn@gmail.com 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 httpd/pegasus on unix? 2008-02-23 21:22 [9fans] plan9 httpd/pegasus on unix? lejatorn ` (2 preceding siblings ...) 2008-02-25 11:00 ` maht @ 2008-02-25 19:03 ` Uriel 3 siblings, 0 replies; 21+ messages in thread From: Uriel @ 2008-02-25 19:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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, <lejatorn@gmail.com> 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 > -- > ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2008-02-29 18:44 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-02-23 21:22 [9fans] plan9 httpd/pegasus on unix? lejatorn 2008-02-23 21:34 ` erik quanstrom 2008-02-23 22:13 ` Skip Tavakkolian 2008-02-25 11:00 ` maht 2008-02-25 15:25 ` ron minnich 2008-02-25 16:26 ` John Barham 2008-02-27 15:52 ` Enrico Weigelt 2008-02-27 17:50 ` Steve Simon 2008-02-28 5:24 ` John Barham 2008-02-28 7:23 ` sqweek 2008-02-28 17:27 ` Enrico Weigelt 2008-02-28 19:23 ` Chad Dougherty 2008-02-29 14:43 ` Enrico Weigelt 2008-02-29 0:26 ` sqweek 2008-02-29 18:16 ` Enrico Weigelt 2008-02-29 18:18 ` erik quanstrom 2008-02-29 18:37 ` Uriel 2008-02-29 18:44 ` Russ Cox 2008-02-25 16:30 ` lejatorn 2008-02-25 16:48 ` Kernel Panic 2008-02-25 19:03 ` Uriel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).