Re: Ultimate Bulletin Board? Jezuz.
On Fri, 27 Jul 2001, kyle dawkins wrote: 1. the quality of [perl] code in UBB is so phenomenally bad i can't believe people pay money for it. i can't believe it works (but it does). has anyone else ever experienced it? i guess i need a support group... it makes me cry and cuts me to the bone when i think that there are actually people out there who think that code like this is good. oh my god. it should be drop-kicked off the planet. At mp3.com, we ran UBB for the first year or so and ended up totally rewriting the bottom end to make it perform better and actually make it semi-secure. Finally we ended up getting rid of it for some other in house code. you might want to look into vBulletin, it is used on a lot of different sites is written in php with a MySQL back end and looks very similar to UBB. 2. any problems with it under mod_perl? I have it running fine under PerlRun but I am not so sure it'll behave under Registry. Our old version was written in perl 4 and definately wasn't able to be run under mod_perl. We actually fork()/exec()'d like mad for the first year, UBB looked nice, but is hell underneath. Cheers, -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ +1 (415) 536-5218 http://Sander.vanZoest.com/
Re: SAN food and entertainment
I actually live in San Diego and just send off an e-mail to a friend with similar info. A great pub in San Diego is Shakespeare's Pub on 3701 India Street. For club info you can check out: http://www.sandiegoclubs.com/ for a general list (little dated). http://www.ravelinks.com/calendars/socal.htm for Techno/Dance and http://www.sdgoth.org/local/events/ for Goth/Industrial/Fetish Let me know if you have any other interests I might be able to help with, such as (the lack of) public transportation and/or directions. -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ +1 (415) 536-5218 http://Sander.vanZoest.com/
RE: Debug perl package in Apache
On Sun, 11 Feb 2001, Wang, Pin-Chieh wrote: First I can't put the IfDefine PERLDB block at the beginning of the http.conf (I got httpd.conf syntax error when I run httpd -X -DPERLDB; Then I move the block to the end of the http.conf file re-run the command then I get % ./bin/httpd -X -DPERLDB [notice] Apache::DB initialized in child 23415 You can only call this after you have loaded modperl and such. So it might be related to that. the system is waiting for my call the request. But when I call http://localhost/server-status I still don't got the debug prompt. here I called server-status instead of perl-status. I guess I don't understand how Debuger is configured into perl-status when http://localhost/perl-status is called. can you share some light on this? This is because you can only use Apache::DB to debug perl code. mod_status.c (i.e. server-status) is written in C, so you will need to use a C debugger such as gdb or dbx. See the earlier thread on that for some useful hints. Hope that helps, -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/
Re: Debug perl package in Apache
On Thu, 8 Feb 2001, Wang, Pin-Chieh wrote: Any body has any ideals? Also How can I debug an perl package under this environment? Appreciated for any help Check out this useful article written by Dough MacEachern for PerlMonth. http://www.perlmonth.com/features/mod_perl/mod_perl.html?issue=2 Cheers, -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/
Re: mixing perl and c module on handler stack
On Fri, 12 Jan 2001, Danny Rathjens wrote: If you want to know why I just don't use Apache::SSI it is because I am dealing with a OpenAdStream from realmedia which has a modifed mod_include.so which makes calls to a 'proprietary' library. So it seems a lot easier to just be able to send the output from my handler into their mod_include. When we were using OAS we called their library call directly from our code rather then using their mod_include.c. So I do not really see a reason why you can not add the library call, via XS to Apache::SSI. (I have never looked at Apache::SSI, so I am not sure how easy that would be.) This way you can just use the slightly modified Apache::SSI and can leave out mod_include.c all together. -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/
Re: Caching search results
On Mon, 8 Jan 2001, Perrin Harkins wrote: Bill Moseley wrote: Anyway, I'd like to avoid the repeated queries in mod_perl, of course. So, in the sort term, I was thinking about caching search results (which is just a sorted list of file names) using a simple file-system db -- that is, (carefully) build file names out of the queries and writing them to some directory tree . Then I'd use cron to purge LRU files every so often. I think this approach will work fine and instead of a dbm or rdbms approach. Always start with CPAN. Try Tie::FileLRUCache or File::Cache for starters. A dbm would be fine too, but more trouble to purge old entries from. You could always have a second dbm file that can keep track of TTL issues of your data keys, so it would simply be a series of delete calls. Granted you would have another DBM file to maintain. -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/
Re: Caching search results
On Mon, 8 Jan 2001, Simon Rosenthal wrote: an RDBMS is not much more trouble to purge, if you have a time-of-last-update field. And if you're ever going to access your cache from multiple servers, you definitely don't want to deal with locking issues for DBM and filesystem based solutions ;=( RDBMS does bring replication and backup issues. The DBM and FS solutions definately have their advantages. It would not be too difficult to write a serialized daemon that makes request over the net to a DBM file. What in you experience makes you pick the overhead of an RDBMS for a simple cache in favor of DBM, FS solutions? -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/
Re: Caching search results
On Mon, 8 Jan 2001, Simon Rosenthal wrote: I couldn't see writing a daemon as you suggested offering us any benefits under those circumstances, given that RDBMS access is built into Apache::Session. No, in your case I do not see a reason behind it either. ;-) Again this shows that it all depends on the requirements and things you are willing to sacrafice. Cheers, -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/
Re: Caching search results
On Mon, 8 Jan 2001, Perrin Harkins wrote: On Mon, 8 Jan 2001, Sander van Zoest wrote: starters. A dbm would be fine too, but more trouble to purge old entries from. You could always have a second dbm file that can keep track of TTL issues of your data keys, so it would simply be a series of delete calls. Granted you would have another DBM file to maintain. I find it kind of painful to trim dbm files, because most implementations don't relinquish disk space when you delete entries. You end up having to actually make a new dbm file with the "good" contents copied over to it in order to slim it down. Yeah, this is true. Some DBMs have special routines to fix these issues. You could use the gdbm_reorganize call to clean up those issues for example (if you are using gdbm that is) Just some quick pseudo code (don't have a quick example ready here): use GDBM_File; my $gdbm = tie %hash, 'GDBM_File', 'file.gdbm' GDBM_WRCREAT|GDBM_FAST, 0640 or die "$!"; $gdbm-reorganize; That definately helps a lot. -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/
Re: Caching search results
On Mon, 8 Jan 2001, G.W. Haywood wrote: At the risk of getting shot down in flames again, do you think you could take this off-list guys? I guess this could be moved to the scalable list ([EMAIL PROTECTED]), or in private since this isn't really on the topic of modperl anymore. Cheers, -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/
Re: Proxy adding headers
On Mon, 27 Nov 2000, Dave Rolsky wrote: Actually, something is _adding_ headers and I want it to stop doing it. It may not be mod_proxy, perhaps it is mod_rewrite. I really don't know. Normally the mod_proxy code doesn't touch the headers, it simply sends the headers on from the remote server you are proxying too. I doubt it is mod_rewrite but it could be. The extra headers are probably coming from your remote server you are proxying to. -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: Proxy adding headers
On Mon, 27 Nov 2000, Dave Rolsky wrote: On Mon, 27 Nov 2000, Sander van Zoest wrote: Normally the mod_proxy code doesn't touch the headers, it simply sends the headers on from the remote server you are proxying too. I doubt it is mod_rewrite but it could be. The extra headers are probably coming from your remote server you are proxying to. I don't think so. If I do a telnet to the proxy server (port 80, no mod_perl) I get the extra headers. If I telnet to the mod_perl enabled server (port 12345), I get what I want (no extra headers). Ah, are you trying to send ICY headers or something? mod_proxy only knows of HTTP and sends the appropriate status itself rather then what it gets from the remote server. This will also require some hacks in mod_proxy to make it aware of the protocol you are trying to proxy. Cheers, -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new mailing lists archives
On Sat, 18 Nov 2000, Stas Bekman wrote: I've just updated http://perl.apache.org/#maillists and now I'm glad to announce to you that we have the online archives of modperl-dev and modperl-cvs lists thanks to Hank Leininger. Or visit http://archive.covalent.net/ if you have trouble. -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting together the TPC mod_perl track
On Wed, 1 Nov 2000, Nathan Torkington wrote: * Case studies showing how big companies use mod_perl This latter is an important part of the Perl conference. Many companies who would never 'fess up to using Perl seem quite happy to send employees to speak at conferences. Their talks end up as a big advertisement for Perl, and lets us name-drop the company as a Perl user. I see no reason why the same shouldn't happen with mod_perl. At the last US ApacheCon I did a talk on how we do XML/modperl related stuff for our publishing model at MP3.com, Inc. I have since then changed companies, so I can't really talk about that anymore (still got slides on my personal site though). The only thing I can really talk about is my current experiences in regards to i18n with the mailing list archives at http://archive.covalent.net/, but that would be pretty boring I would think. Cheers, -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/
Re: Fast DB access
On Wed, 11 Oct 2000, Matt Sergeant wrote: Most modern DBMS software should be able to handle 50 queries per second on decent hardware, provided the conditions are right. You're not going to get anything better with flat files. Hmm... I guess it all depends on what your queries look like, but you can get better results from flat files if you put them in a percise layout. Granted if you are talking about having a million lines in a single flat file, then I definately agree with you. I really think that sometimes going for a flat file layout *can* be much more reliable and scalable then RDBMS software. It all really depends on what you plan to do with the data and what you would like to get out of it. Cheers, -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/
Re: Fast DB access
On Wed, 11 Oct 2000, Matt Sergeant wrote: I really think that sometimes going for a flat file layout *can* be much more reliable and scalable then RDBMS software. It all really depends on what you plan to do with the data and what you would like to get out of it. I think you chose the wrong words there. I think a flat file layout can be more performant than an RDBMS, but I don't think its going to be more reliable or scalable than an RDBMS. There are far too many locking issues and transaction issues necessary for the terms "reliable and scalable", unless you're willing to spend a few years re-coding Oracle :-) I actually think that there are times that can be all three. Notice how I said there are times it can be all three, it definately isn't the case all the time. Neither are RDBMS. ;-) Lots of places use databases for read-only queries. Having a database that gets lots of similar queries that are read-only makes it an unnecessary single point of failure. Why not use the local disk and use rsync to replicate the data around. This way if a machine goes down, the others still have a full copy of the content and keep on running. If you have a lot of data that you need to keep in sync and needs constant updating with a random amount of different queries then you get some real use out of a RDBMS. I guess I am just saying that there are a gazillions of ways of doing things, and each tool has something it is good at. File systems are really good at serving up read-only content. So why re-invent the wheel? It all really depends on what content you are dealing with and how you expect to query it and use it. There is a reason that table optimisation and tuning databases is such a sought after skill. Most of these things require different things that all rely on the type of content and their use. These things need to be taken in consideration on a case by case basis. You can do things terribly using Oracle and you can do things well using Oracle. The same can be said about just about everything. ;-) -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/
Re: Fast DB access
On Wed, 11 Oct 2000, Matt Sergeant wrote: On Wed, 11 Oct 2000, Sander van Zoest wrote: On Wed, 11 Oct 2000, Matt Sergeant wrote: Lots of places use databases for read-only queries. Having a database that gets lots of similar queries that are read-only makes it an unnecessary single point of failure. Why not use the local disk and use rsync to replicate the data around. This way if a machine goes down, the others still have a full copy of the content and keep on running. What is the actual use of the flat files in this case? Wouldn't generating your HTML offline be better if your data is that static? The actual use of the flat files can vary. XML in some sense is a good example, generated HTML is another. Sometimes a csv or other format works best. And other times, although technically not being a flat file, a dbm file could be a good/fast alternative as well. It really depends on how flexable you need/want to be. XML is definately becoming a useful alternative here. It is just that databases can create a lot of unnecessary features/overhead that can be pre-computed ahead of time. You can do things terribly using Oracle and you can do things well using Oracle. The same can be said about just about everything. ;-) You put your point well, and my only remaining point is that I think its far far easier to screw up a flat file system by not taking into account locking issues (just look at all those perl hit-counters that did it wrong), and perhaps some reliability issues, than it is with a real database. Caveat emptor, and all that. I still have some locking issues with the mailing list archive. *grin* I totally agree that it is far easier to screw up a flat file system. It might not be as flexable as you really need it to be, because it was build for a particular query and performance on that in mind. Databases are great and I am happy to have them. It is just that it isn't that when you throw down the money to get Oracle, it will be the answer to all your problems. ;-) Sometimes an LDAP system can make more sense then an RDBMS. Other times a distributed system based on DNS. It all depends on what you value most, how much you control your environment and what you can live with and what you can't. Matt, I am not sure if you are on Dean Gaudet's scalable mailing list http://archive.covalent.net/new-httpd/2000/09/0478.xml, it is definately a great place to see how people accomplish things with their problem sets. In some odd way it reminds me of the old alt.hackers days. Cheers, -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/
Re: mod_perl on a FreeBSD 3.5-STABLE
On Tue, 8 Aug 2000, Marko van der Puil wrote: I done the installation by hand like in the guide, now my mod_perl is fine, except cgi-s dont run from the prompt anymore exiting with... ---SNIPerror_log- DynaLoader object version 1.04 does not match $DynaLoader::VERSION 1.03 at /usr/libdata/perl/5.00503/DynaLoader.pm line 80. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.005/i386-freebsd/DBI.pm line 149. BEGIN failed--compilation aborted at ./dbtest.cgi line 2. ---SNIPerror_log- If I use DBI.pm somewhere in a script. If I run the same script in RunPerl it works ok Strange that... Any Id's anyone? This means there is probably a version of perl being picked up in your apache binary versus your perl being run on the commandline. That is what I would guess. Cheers, -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net (415) 536-5218
Re: Re: redirecting a domain [OT]
On Sun, 16 Jul 2000, Barry Hoggard wrote:
No! That's a silly way to do it. You want to use mod_rewrite.
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www.investorama.com$
RewriteCond %{HTTP_HOST} !^$
RewriteRule /?(.*) http://www.investorama.com/$1 [R=permanent,L]
Too complicated. What's wrong with this:
VirtualHost ip.of.domain.org
ServerName www.domain.org
Redirect permanent / http://www.domain.net/
/VirtualHost
Nothing is wrong with that solution if you only have a few domains.
We own a lot of misspellings of our company name, so I don't want to
add each of them individually to the conf file.
The only bad thing about the mod_rewrite solution is that this is done
dynamicly on each request (including images etc.), while the VirtualHost
solution is only put into structures on initial start up time. For performance
reasons you are better off with the VirtualHost solution to decrease the
processing for each hit.
--
Sander van Zoest [EMAIL PROTECTED]
High Geekhttp://www.vanZoest.com/
Re: [mod_perl audio tutorials]
On Tue, 4 Apr 2000, Stas Bekman wrote: Consider just this once that HTML is not the preferred way to deliver this kind of content. Perhaps the tutorial could be in the form of an MP3 file, with instructions to turn to the next slide periodically. The slide could be HTML scaffolds around an image. Anyway, this has the advantage of following standards and also allowing the user the freedom to move the audio stream and slides independently. I like the idea of using MP3 but not being MP3 savy wan't sure that clients support streaming MP3. Also the encoding would have to be at less than 33kbps so it will play properly over modem lines. The slide/chapter info could be encoded into the ID3 tags and users could request any slide from the playlist. See the last TPJ article by Lincoln Stein about mp3/streaming/icecast and mod_perl. His article works, but isn't entirely accurate as I have already e-mailed Lincoln Stein about the issues. He claimed to discuss them in his follow up article. Most players support m3u's and icecast. I would suggest encoding the audio in either 24kbps. (33kbps isn't a valid bitrate, you probably meant 32kbps) I would suggest just creating a bunch of m3u files that can then be played while looking at the slides. icecast is usually used for radio like streaming, not on-demand streams. I'll have to dig a bit into Mike Oliphant's Grip or LAME to do the encoding. I am wondering if icecast software would work well for this application. Grip doesn't do the encoding it's merely a wav reader plus a nice interface to the encoding tools. Grip is an GTK interface on top of cdparanoia and lame/blade. Cheers, -- Sander van Zoest [EMAIL PROTECTED] High Geekhttp://www.vanZoest.com/
Re: mod_perl with Stronghold
On Wed, 2 Feb 2000, J. Horner wrote: I searched the archives, but no mention of this. Does anyone have any experience with mod_perl and Stronghold? We run StrongHold with mod_perl/1.21 (and other stuff), without any problems. Read INSTALL.simple.stronghold to give you a start on how to build modperl for stronghold. Cheers, -- Sander van Zoest [EMAIL PROTECTED] High Geek, MP3.com, Inc.http://www.vanZoest.com/
Re: XML applications in mod_perl/apache xml project (fwd)
I embarking on writing a mod_perl handler that accepts XML posted from client apps/browsers and then does "stuff" with the received XML snippets. I would like to take advantage of some of the projects discussed at xml.apache.org (The Apache XML Project), but I'm not sure how they fit into the mod_perl framework. Any XML gurus on this list have any experiences, pointers, or suggestions with integrating xml.apache.org projects with a mod_perl enabled apache server? I'd like to avoid using the java parsers and jserv if possible, but it seems that some of the nicer features of Cocoon, etc. are only available in java (hence the "Cocoon is a 100% pure Java publishing" tag line :). Currently at MP3.com we are using an XML, apache, mod_perl based system, that we would like to implement as an open source package. It is very much performance centric, so not too many features are available. We are looking into using Xalan-C and Xerces-C (with perl xs wrappers) to accomplish pretty much what we have build in house. I am working on addding some performance tweaks to Xalan and Xerces to make them compete against our in house style sheet language. You might want to consider checking out my session at ApacheCon 2000, to get a better feel of what we have done. Cheers, - Sander van Zoest [EMAIL PROTECTED] High Geek(858) 623-7442 MP3.com, Inc. http://www.mp3.com/ See you at ApacheCon 2000 - Your premiere Music Service Provider (MSP)
Re: cross site scripting security issue headsup
On Wed, 2 Feb 2000, Marc Slemko wrote:
http://www.apache.org/info/css-security/
http://www.cert.org/advisories/CA-2000-02.html
I think I have found a little typo/oversight in the mod_perl example on
http://www.apache.org/info/css-security/encoding_examples.html
It uses escape_html rather then escape_uri on the href line, here is
a tiny patch.
Cheers,
-
Sander van Zoest [EMAIL PROTECTED]
High Geek(858) 623-7442
MP3.com, Inc. http://www.mp3.com/
See you at ApacheCon 2000 - Your premiere Music Service Provider (MSP)
diff -C3 -r1.4 encoding_examples.html
*** encoding_examples.html 2000/02/02 19:26:03 1.4
--- encoding_examples.html 2000/02/03 00:23:54
***
*** 139,145
$Text = "foolt;bgt;bar";
$URL = "foolt;bgt;bar.html";
$r-gt;print(Apache::Util::escape_html($Text), "lt;BRgt;");
! $r-gt;print("lt;A HREF=\"", Apache::Util::escape_html($URL),
"\"gt;linklt;/Agt;");
/PRE
PThis uses the same functions as in the Apache Module Example, called
--- 139,145
$Text = "foolt;bgt;bar";
$URL = "foolt;bgt;bar.html";
$r-gt;print(Apache::Util::escape_html($Text), "lt;BRgt;");
! $r-gt;print("lt;A HREF=\"", Apache::Util::escape_uri($URL),
"\"gt;linklt;/Agt;");
/PRE
PThis uses the same functions as in the Apache Module Example, called
Jobs: San Diego/CA, MP3.com, Inc.
Since we are still somewhat on the jobs thread. I just wanted to point out that MP3.com is still looking for apache/*ml/perl/modperl coders, interested in working intense hours while bringing the music industry onto the net. We run most of our site using open source tools and try to contribute back as much as we can. We primarily run on FreeBSD and Linux. Any other useful and related skills are always wanted as well. Security, Unix and general knowledge of building secure architectures and protocols are a big plus. Plenty of benefits from free food, drinks to health, dental to espp, options for those who are interested in working hard with our team of excellent engineers. Learn from us as we hope to learn from you! Please submit your resume (text/plain please) to [EMAIL PROTECTED] and feel free to contact me for more information. Cheers, - Sander van Zoest [EMAIL PROTECTED] High Geek(858) 623-7442 MP3.com, Inc. http://www.mp3.com/ See you at ApacheCon 2000 - Your premiere Music Service Provider (MSP)
Re: Confirmation of hits, etc.
On Tue, 12 Oct 1999, Rex Staples wrote: Below are several high-profile (and hopefully high-trafficked) sites I am going to include in my proposal, but I was hoping that some of the minds on this list might know either the most recent traffic figures for these sites or of other sites whose traffic is in the 5-10 million page views/day range. You can add that MP3.com, Inc. does more then 408k unique visitors/day and every download, search request, golocal.mp3.com and my.mp3.com goes through modperl. Agents range from: Server: Apache/1.3.4-9 (Unix) mod_perl/1.18-21 on Linux/FreeBSD http://www.mp3.com/pr/990914-keymetrics.html -- Sander van Zoest [EMAIL PROTECTED] High Geek(858) 623-7442 MP3.com, Inc. http://www.mp3.com/
