From pollok at gmail.com Sun Dec 3 18:47:19 2006 From: pollok at gmail.com (Alessandro Poletto) Date: Sun Dec 3 18:47:55 2006 Subject: [ic] tree problem Message-ID: <45737017.19832.911090@pollok.gmail.com> I have a problem with the tree routine. If I use the toggle/memo option of the tree option so i'll open a branch/field of the tree and I don't close the others. I'll try to explain better... I have a tree: A --1 ----x B --2 ---Y Starting position is: A B all works fine if selecting A A --1 B but if after I select B A --1 B --2 My need is this: A B --2 I haven't found nothing about this problem and into the documentation there's nothing about the automatic collapsing of the unused branch. Many thanks in advance to all. ============================================ Toth di Alessandro Poletto http://www.toth.it E-mail: alessandro@polet.to ============================================ From prejnydyl at ozonetec.com Mon Dec 4 16:34:17 2006 From: prejnydyl at ozonetec.com (years) Date: Mon Dec 4 16:34:57 2006 Subject: [ic] upon parent Message-ID: <000401c717eb$f3dbf320$00000000@tommeliten> 31547 From kdeugau at vianet.ca Mon Dec 4 17:34:20 2006 From: kdeugau at vianet.ca (Kris Deugau) Date: Mon Dec 4 17:34:37 2006 Subject: [ic] tree problem In-Reply-To: <45737017.19832.911090@pollok.gmail.com> References: <45737017.19832.911090@pollok.gmail.com> Message-ID: <4574A26C.8060509@vianet.ca> Alessandro Poletto wrote: > I haven't found nothing about this problem and into the documentation > there's nothing about the automatic collapsing of the unused branch. ^^^^^^^^^^^^^^^^^^^^ Please don't. I don't know about anyone else, but "helpful" tricks like this generally just frustrate me while trying to navigate an interface. -kgd From pollok at gmail.com Wed Dec 6 04:42:08 2006 From: pollok at gmail.com (Alessandro Poletto) Date: Wed Dec 6 04:42:03 2006 Subject: [ic] tree problem In-Reply-To: <4574A26C.8060509@vianet.ca> References: <45737017.19832.911090@pollok.gmail.com>, <4574A26C.8060509@vianet.ca> Message-ID: <45769E80.18146.A5A3895@pollok.gmail.com> Yes... I think the same thing but customers are customers and what they ask me I have to made... > Alessandro Poletto wrote: > > I haven't found nothing about this problem and into the documentation > > there's nothing about the automatic collapsing of the unused branch. > ^^^^^^^^^^^^^^^^^^^^ > Please don't. > > I don't know about anyone else, but "helpful" tricks like this generally > just frustrate me while trying to navigate an interface. > > -kgd > _______________________________________________ > interchange-users mailing list > interchange-users@icdevgroup.org > http://www.icdevgroup.org/mailman/listinfo/interchange-users ============================================ Toth di Alessandro Poletto http://www.toth.it E-mail: alessandro@polet.to ============================================ From DB at M-and-D.com Wed Dec 6 14:59:01 2006 From: DB at M-and-D.com (DB) Date: Wed Dec 6 14:59:21 2006 Subject: [ic] Setting title of results page Message-ID: <45772105.5040309@M-and-D.com> I have a page with the following search: [query type=list more=1 ml=150 sql=| SELECT distinct name FROM cat |] [list]

[sql-param name] items - Click for a list of [sql-param name] items

[/list] [/query] Now in the body of the results page, the tag [value category_name] gets displayed as expected. However I also want that value to be used for the results page's title. In the results page's template I have: [comment] ui_template: leftonly_2 ui_type: template ui_name: leftonly_2 ui_version: 5.4.1 ui_label: Page with top/left areas 2. ui_source: templates/leftonly_2 ui_template_layout: LEFTONLY_TOP_2, UI_CONTENT, LEFTONLY_BOTTOM page_title: label: Page Title width: 50 members_only: code: members_only label: Members only? options: 1=Yes,=No* type: yesno meta_keywords: code: meta_keywords db: ^@ label: Meta keywords type: text width: 50 meta_description: code: meta_description db: ^@ label: Meta description type: text width: 50 [/comment] [set page_title][/set] [set members_only][/set] [set meta_keywords][/set] [set meta_description][/set] but if I put [value category_name] into the title slot in the admin content editor, the title of the page is literally "[value category_name]" and is not getting interpreted as I want. Does anyone have an idea why the tag gets displyed correctly in the page body but not in the title? DB From ic at 3edge.com Wed Dec 6 14:11:19 2006 From: ic at 3edge.com (ic@3edge.com) Date: Wed Dec 6 15:11:42 2006 Subject: [ic] Setting title of results page In-Reply-To: <45772105.5040309@M-and-D.com> References: <45772105.5040309@M-and-D.com> Message-ID: <20061206191119.80C9D178A8@mail.papanikos.com> DB writes: > I have a page with the following search: > > [query > type=list > more=1 > ml=150 > sql=| > SELECT distinct name > FROM cat > |] > [list] >

[sql-param name] items - > Click for a list of [sql-param name] items

> [/list] > [/query] > > > Now in the body of the results page, the tag > [value category_name] > gets displayed as expected. However I also want that value to be used > for the results page's title. In the results page's template I have: > > [comment] > ui_template: leftonly_2 > ui_type: template > ui_name: leftonly_2 > ui_version: 5.4.1 > ui_label: Page with top/left areas 2. > ui_source: templates/leftonly_2 > ui_template_layout: LEFTONLY_TOP_2, UI_CONTENT, LEFTONLY_BOTTOM > > page_title: > label: Page Title > width: 50 > > members_only: > code: members_only > label: Members only? > options: 1=Yes,=No* > type: yesno > > meta_keywords: > code: meta_keywords > db: ^@ > label: Meta keywords > type: text > width: 50 > > meta_description: > code: meta_description > db: ^@ > label: Meta description > type: text > width: 50 > > [/comment] > [set page_title][/set] > [set members_only][/set] > [set meta_keywords][/set] > [set meta_description][/set] > > > but if I put > [value category_name] > into the title slot in the admin content editor, the title of the page > is literally "[value category_name]" and is not getting interpreted as I > want. > > Does anyone have an idea why the tag gets displyed correctly in the page > body but not in the title? [seti page_title][value category_name][/seti] ? From peter at pajamian.dhs.org Wed Dec 6 15:17:07 2006 From: peter at pajamian.dhs.org (Peter) Date: Wed Dec 6 15:17:40 2006 Subject: [ic] Setting title of results page In-Reply-To: <45772105.5040309@M-and-D.com> References: <45772105.5040309@M-and-D.com> Message-ID: <45772543.30305@pajamian.dhs.org> On 12/06/2006 11:59 AM, DB wrote: > Now in the body of the results page, the tag > [value category_name] > gets displayed as expected. However I also want that value to be used > for the results page's title. In the results page's template I have: > [set page_title][/set] > but if I put > [value category_name] > into the title slot in the admin content editor, the title of the page > is literally "[value category_name]" and is not getting interpreted as I > want. > > Does anyone have an idea why the tag gets displyed correctly in the page > body but not in the title? You need to change the [set]...[/set] tag above to [seti]...[/seti]. Then it will work. See... Peter From DB at M-and-D.com Wed Dec 6 15:34:59 2006 From: DB at M-and-D.com (DB) Date: Wed Dec 6 15:35:09 2006 Subject: [ic] Setting title of results page References: 45772105.5040309@M-and-D.com Message-ID: <45772973.1070503@M-and-D.com> Thanks guys - that did the trick :) From emailgrant at gmail.com Sat Dec 9 13:34:26 2006 From: emailgrant at gmail.com (Grant) Date: Sat Dec 9 13:34:45 2006 Subject: [ic] ALERT: bad pipe signal received for /page.html Message-ID: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> Hello, I've been plagued by apache2 segfaults ever since I started using Interchange::Link years ago. The latest Link.pm has ALERT messages accompanying the segfaults in error_log: ALERT: bad pipe signal received for /page.html [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal Segmentation fault (11) Does anyone have any advice on solving this? I'm using apache-2.0.58 and mod_perl-2.0.2 in Gentoo Linux. - Grant From emailgrant at gmail.com Sat Dec 9 13:37:04 2006 From: emailgrant at gmail.com (Grant) Date: Sat Dec 9 13:37:17 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> Message-ID: <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> > Hello, I've been plagued by apache2 segfaults ever since I started > using Interchange::Link years ago. The latest Link.pm has ALERT > messages accompanying the segfaults in error_log: > > ALERT: bad pipe signal received for /page.html > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > Segmentation fault (11) > > Does anyone have any advice on solving this? I'm using apache-2.0.58 > and mod_perl-2.0.2 in Gentoo Linux. Also, here is the portion of Link.pm that the ALERT seems to come from: # Return this message to the browser when the server is not running. # Log an error log entry if set to notify sub die_page { my $r = shift; my $msg; warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; $r->content_type ("text/html"); $r->print (<Interrupted

Someone pressed stop...

We have aborted this request because someone terminated it. Please try again soon. EOF } Please let me know if you have any ideas. - Grant From qck at galaxy102.co.uk Sat Dec 9 14:25:44 2006 From: qck at galaxy102.co.uk (Roderick Quinn) Date: Sat Dec 9 14:31:16 2006 Subject: [ic] It's almost impossible to follow a guru's advice in long periods of decline. Message-ID: <002801c71bc8$8d5cb220$cfad8340@uyi> The American IRA and Canadian RRSP are two of the last greatest tax loopholes left. Venture CapitalVenture Capital is a great way to light money on fire. Thanks to Wenger and his boys. I was researching "investment clubs" yesterday with Google; I wanted to find active clubs to send a free copy of my book. That's a good excuse to go to the Brazen Bean for a delicious martini. dddd Date : Dec 11 2006 Company : Amerossi International S t o c k : AMSN Current Price : $0.0006 Projection 2 to 5 Days : $0.006-$0.008 Status : 300-500% dddd but hung out with the rich and famous, guzzling booze, enjoying all the fine thing in life. It's the only financial paper I read. It's almost impossible to follow a guru's advice in long periods of decline. Again you must believe in your ideas and stick with them. The stock must break-out and prove to me that it's going up. Historically, bonds underperform the stock market. People are comfortable with the stock market. They often tempt investors into "adjusting" their system. With too much risk comes almost certain loss as in the lottery and gambling where mathimatically you cannot win in the long run. BondsBonds and CDs offer a relatively safe investment, but the return is low. It doesn't happen all the time, but it's often the case that a small number of stocks in your portfolio will make all the big gains. Click below for more news about clubs, balls and games . I have been using it for years and love it. Congrats to all arsenal-fans all over world. They test and retest your mettle. This is the same topic I talked about earlier in the week with regards to owning X shares of ABC stock at Y price. You will pay stock based commission on trades which might be higher than the costs of mutual funds and so you need to do a little math and determine which is best for you. They test and retest your mettle. If a stock is going up over time, on a linear chart, this will begin to look like a ski jump and offer us little visual value. Traders like Warren Buffet an Martin Zweig would use PE since they are value shoppers. com USA Today Venturi has heart surgery, expected to recover Former U. Golfernews is a member of the HarWester Network. Trading Range StopTake any stock chart and pick a timeframe. Just another day closer to when they tax us for the air we breath. Never stopped going on about the workers, socialism, Lenin, Marx etc. In the end they both had the exact same sized portfolio. Some years are more volatile. PercentYou can pick a percent decline level for any stock or portfolio. Will the home end of Emirates still be called the Northbank? Six nominees, five English, one foreign which seems a little strange with all the overseas players in the Premiership. Click below for more news about clubs, balls and games . I continually reinforce this. Golfernews is a member of the HarWester Network. If you understand this can be very normal, you won't be alarmed when it occurs. I would even go as far as saying. The big dangers in an up market is the euphoria of thinking you can do no wrong. With too much risk comes almost certain loss as in the lottery and gambling where mathimatically you cannot win in the long run. Wignan did play well in first half, but arsenal destined to grab the fourth spot. " This is simply not true. I like to say that if stocks are arithmatic, then futures are calculus. It was a nervous time in the second half but once Henry had nailed his hatrick and West Ham got a second, the party could begin. Wigan played quite well, but Thierry Henry is simply a lethal weapon on a football pitch. It helps if an investor is mentally ready for all types of market conditions. Hope you enjoyed it as much as I did. Small BusinessHave you read the Millionaire Next Door? Joe Cole and John Terry have been solid all year, and Chelsea will be champions again but neither has pulled up any trees. Some banks have recovered nicely. In the end they both had the exact same sized portfolio. Index funds generally outperform the vast majority of index funds in the long run. If Gilberto can stick with Riquelme like he did in the last game we have a great chance but it might just come down to needing an Henry special moment to get us through. Traders like William O'Neil "canslim" would not. Arsenal had to get a better result than Spurs, who had tried to get their game with West Ham postponed at the last minute because of some supposed food poisoning. com Misc sources PGA. These are just the lowest forms of species walking the earth; too bad they get rich for the crap they put out there. SchwagerThe New Market WizardsJack D. SchwagerThe New Market WizardsJack D. Find the highest high and the lowest low for that stock in that timeframe. I watched the game live on local TV here in Bali. From kevin at cursor.biz Sat Dec 9 15:33:12 2006 From: kevin at cursor.biz (Kevin Walsh) Date: Sat Dec 9 15:33:51 2006 Subject: [ic] ALERT: bad pipe signal received for /page.html In-Reply-To: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> Message-ID: <200612092033.13174.kevin@cursor.biz> Grant wrote: > Hello, I've been plagued by apache2 segfaults ever since I started > using Interchange::Link years ago. The latest Link.pm has ALERT > messages accompanying the segfaults in error_log: > > ALERT: bad pipe signal received for /page.html > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > Segmentation fault (11) > > Does anyone have any advice on solving this? I'm using apache-2.0.58 > and mod_perl-2.0.2 in Gentoo Linux. > I just use Apache 1.3 (currently 1.3.34-r14) and mod_interchange with Gentoo GNU/Linux. It works perfectly. :-) I'll create mod_interchange-2 for Apache 2 one day - once there's a demand for it, or I find that I need it for some reason. -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ kevin@cursor.biz _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ From kevin at cursor.biz Sat Dec 9 15:46:23 2006 From: kevin at cursor.biz (Kevin Walsh) Date: Sat Dec 9 15:46:32 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> Message-ID: <200612092046.24353.kevin@cursor.biz> Grant wrote: > > Hello, I've been plagued by apache2 segfaults ever since I started > > using Interchange::Link years ago. The latest Link.pm has ALERT > > messages accompanying the segfaults in error_log: > > > > ALERT: bad pipe signal received for /page.html > > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > > Segmentation fault (11) > > > > [snip] > > > We have aborted this request because someone terminated it. > Please try again soon. > Perhaps the page request really was terminated. Do you have any extra-slow pages or searches etc. that users might bored waiting for? I tend to do that myself; If a page hasn't loaded within 10 seconds, I'll press "stop" and either attempt a reload, or just go elsewhere. -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ kevin@cursor.biz _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ From emailgrant at gmail.com Sat Dec 9 16:35:22 2006 From: emailgrant at gmail.com (Grant) Date: Sat Dec 9 16:35:50 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <200612092046.24353.kevin@cursor.biz> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <200612092046.24353.kevin@cursor.biz> Message-ID: <49bf44f10612091335r2199a3b4wf9b50f18f22ef211@mail.gmail.com> > > > Hello, I've been plagued by apache2 segfaults ever since I started > > > using Interchange::Link years ago. The latest Link.pm has ALERT > > > messages accompanying the segfaults in error_log: > > > > > > ALERT: bad pipe signal received for /page.html > > > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > > > Segmentation fault (11) > > > > > > [snip] > > > > > We have aborted this request because someone terminated it. > > Please try again soon. > > > Perhaps the page request really was terminated. Do you have any > extra-slow pages or searches etc. that users might bored waiting for? > > I tend to do that myself; If a page hasn't loaded within 10 seconds, > I'll press "stop" and either attempt a reload, or just go elsewhere. I would believe that, except it happens to me all the time when I'm browsing my own site. It looks like a 404 page in IE (via XP in vmware) and in firefox it's just a blank page. - Grant From emailgrant at gmail.com Sat Dec 9 19:26:06 2006 From: emailgrant at gmail.com (Grant) Date: Sat Dec 9 19:26:21 2006 Subject: [ic] Updated Interchange::Link Message-ID: <49bf44f10612091626l3d41ac8ct75f7db73022ae96d@mail.gmail.com> If you're using Interchange::Link and you'd like: [bounce href="http://www.domain.com" status="301"] to return 301 instead of 302, make the following changes to your Link.pm: - use Apache2::Const; + use Apache2::Const -compile => qw(DECLINED OK NOT_FOUND FORBIDDEN REDIRECT HTTP_MOVED_PERMANENTLY); close (SOCK) or die "close: $!\n"; + return Apache2::Const::HTTP_MOVED_PERMANENTLY if $set_status eq '301'; return Apache2::Const::REDIRECT; That's one removed line and two added. It would be good if someone checked this into CVS. - Grant P.S. This took me a hideously long time. From kevin at cursor.biz Sat Dec 9 20:02:21 2006 From: kevin at cursor.biz (Kevin Walsh) Date: Sat Dec 9 20:02:44 2006 Subject: [ic] Updated Interchange::Link In-Reply-To: <49bf44f10612091626l3d41ac8ct75f7db73022ae96d@mail.gmail.com> References: <49bf44f10612091626l3d41ac8ct75f7db73022ae96d@mail.gmail.com> Message-ID: <200612100102.22776.kevin@cursor.biz> Grant wrote: > If you're using Interchange::Link and you'd like: > > [bounce href="http://www.domain.com" status="301"] > > to return 301 instead of 302, make the following changes to your Link.pm: > > - use Apache2::Const; > + use Apache2::Const -compile => qw(DECLINED OK NOT_FOUND FORBIDDEN > REDIRECT HTTP_MOVED_PERMANENTLY); > > close (SOCK) or die "close: $!\n"; > + return Apache2::Const::HTTP_MOVED_PERMANENTLY if $set_status eq '301'; > return Apache2::Const::REDIRECT; > > That's one removed line and two added. It would be good if someone > checked this into CVS. > No sooner said than done. Thanks, Grant. -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ kevin@cursor.biz _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ From bryangmyrek at yahoo.com Sun Dec 10 12:56:13 2006 From: bryangmyrek at yahoo.com (Bryan Gmyrek) Date: Sun Dec 10 12:56:27 2006 Subject: [ic] How to not log nsession in usertrack? In-Reply-To: <20061129132325.3AF79830070@mailserver1.zolotek.net> Message-ID: <556025.19655.qm@web31807.mail.mud.yahoo.com> Hi, I'm trying to optimize my server that IC is running on and noticed that a huge usertrack file was slowing things down (I _think_ it was causing a 99% CPU bug but maybe not, it's hard to tell if the 99% thing has gone away since I'm not staring at top all the time). In any case I tried switching to database sessions and it seemed to work but usernames were not being created and the referring url was not being shown in orders, etc, so I went back to using the flat file. I'm planning on doing log-rotation of usertrack now; before I thought it might be necessary for the functioning of IC somehow but just read in another post that it isn't. Even so it would be more optimal I think if nsession sessions weren't logged in usertrack, saving the time of logging a line every time a bot does something ... this is already logged by apache and is easier for me to analyze. Come to think of it maybe I should turn of usertrack logging entirely. Anyone know how to do this and/or how to not log nsession? Thanks! Bryan p.s. On a very loosely related note, Kevin, did anyone ever put together a NonRobotUA directive? http://www.icdevgroup.org/pipermail/interchange-users/2004-March/038319.html New England Art Express - Art Prints, Posters and Framing http://www.neartexpress.com/ ----------------------------------------------------------- ---------------------Legal Notice-------------------------- ----------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From kevin at cursor.biz Sun Dec 10 14:55:11 2006 From: kevin at cursor.biz (Kevin Walsh) Date: Sun Dec 10 14:55:47 2006 Subject: [ic] How to not log nsession in usertrack? In-Reply-To: <556025.19655.qm@web31807.mail.mud.yahoo.com> References: <556025.19655.qm@web31807.mail.mud.yahoo.com> Message-ID: <200612101955.12375.kevin@cursor.biz> Bryan Gmyrek wrote: > I'm trying to optimize my server that IC is running on and noticed that a huge > usertrack file was slowing things down (I _think_ it was causing a 99% CPU bug > but maybe not, it's hard to tell if the 99% thing has gone away since I'm not > staring at top all the time). In any case I tried switching to database > sessions and it seemed to work but usernames were not being created and the > referring url was not being shown in orders, etc, so I went back to using the > flat file. > > I'm planning on doing log-rotation of usertrack now; before I thought it might > be necessary for the functioning of IC somehow but just read in another post > that it isn't. Even so it would be more optimal I think if nsession sessions > weren't logged in usertrack, saving the time of logging a line every time a bot > does something ... this is already logged by apache and is easier for me to > analyze. > > Come to think of it maybe I should turn of usertrack logging entirely. Anyone > know how to do this and/or how to not log nsession? > Usertrack won't have any effect on performance, as it's just a file that Interchange appends to. If the file is big then you could rotate it and, perhaps, delete old rotated files to save disk space. Appending to the usertrack file will have no noticeable effect on your CPU usage. I imagine your problem could be something to do with session expiry. Are you regularly deleting expired session files? I suspect that you are not. A huge sessions directory will have a direct impact on your website's performance, so it must be regularly cleaned. Deleting old temporary files in your ScratchDir directory (defaults to "tmp") is also a good idea. -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ kevin@cursor.biz _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ From bryangmyrek at yahoo.com Mon Dec 11 00:20:06 2006 From: bryangmyrek at yahoo.com (Bryan Gmyrek) Date: Mon Dec 11 00:20:18 2006 Subject: [ic] How to not log nsession in usertrack? In-Reply-To: <200612101955.12375.kevin@cursor.biz> Message-ID: <282491.96006.qm@web31813.mail.mud.yahoo.com> > > > > Come to think of it maybe I should turn of usertrack logging entirely. > Anyone > > know how to do this and/or how to not log nsession? > > > Usertrack won't have any effect on performance, as it's just a file > that Interchange appends to. If the file is big then you could OK, I'm not a file-access guru but couldn't that affect performance if the usertrack file is on the order of a GB? > rotate it and, perhaps, delete old rotated files to save disk space. Will do this. > Appending to the usertrack file will have no noticeable effect on > your CPU usage. > > I imagine your problem could be something to do with session expiry. > Are you regularly deleting expired session files? I suspect that you > are not. A huge sessions directory will have a direct impact on your > website's performance, so it must be regularly cleaned. Deleting old > temporary files in your ScratchDir directory (defaults to "tmp") is > also a good idea. > I do both of these nightly in a cron job, so you suspect wrong ;) But thanks for the tips. I was only not rotating usertrack since I thought perhaps it was used in some of the reporting and shouldn't be rotated. So... it isn't possible to turn off logging to usertrack? Any tips on where I could look in the code to comment out the line/routine that does the logging? Thanks, Bryan New England Art Express - Art Prints, Posters and Framing http://www.neartexpress.com/ ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From paul at gishnetwork.com Mon Dec 11 01:18:31 2006 From: paul at gishnetwork.com (Paul Jordan) Date: Mon Dec 11 01:18:44 2006 Subject: [ic] How to not log nsession in usertrack? In-Reply-To: <282491.96006.qm@web31813.mail.mud.yahoo.com> Message-ID: <056301c71cec$2e347d80$0d01a8c0@workstation> interchange-users-bounces@icdevgroup.org wrote: [snip] >> I imagine your problem could be something to do with session expiry. >> Are you regularly deleting expired session files? I suspect that you >> are not. A huge sessions directory will have a direct impact on your >> website's performance, so it must be regularly cleaned. Deleting old >> temporary files in your ScratchDir directory (defaults to "tmp") is >> also a good idea. >> > I do both of these nightly in a cron job, so you suspect > wrong ;) But thanks for the tips. I was only not rotating > usertrack since I thought perhaps it was used in some of the > reporting and shouldn't be rotated. > > So... it isn't possible to turn off logging to usertrack? > Any tips on where I could look in the code to comment out the > line/routine that does the logging? Have you tried commenting out TrackFile? http://www.interchange.rtfm.info/icdocs/config/TrackFile.html # TrackFile logs/usertrack Paul Jordan From peter at pajamian.dhs.org Mon Dec 11 01:31:58 2006 From: peter at pajamian.dhs.org (Peter) Date: Mon Dec 11 01:32:27 2006 Subject: [ic] How to not log nsession in usertrack? In-Reply-To: <282491.96006.qm@web31813.mail.mud.yahoo.com> References: <282491.96006.qm@web31813.mail.mud.yahoo.com> Message-ID: <457CFB5E.8090309@pajamian.dhs.org> On 12/10/2006 09:20 PM, Bryan Gmyrek wrote: > I was only not rotating usertrack since I thought perhaps it was > used in some of the reporting and shouldn't be rotated. It's used for the affiliate statistics report and probably a few other reports. It's not used for order or sales reports. Peter From kevin at cursor.biz Mon Dec 11 07:20:45 2006 From: kevin at cursor.biz (Kevin Walsh) Date: Mon Dec 11 07:21:26 2006 Subject: [ic] How to not log nsession in usertrack? In-Reply-To: <056301c71cec$2e347d80$0d01a8c0@workstation> References: <056301c71cec$2e347d80$0d01a8c0@workstation> Message-ID: <200612111220.46240.kevin@cursor.biz> "Paul Jordan" wrote: > interchange-users-bounces@icdevgroup.org wrote: > > > I imagine your problem could be something to do with session expiry. > > > Are you regularly deleting expired session files? I suspect that you > > > are not. A huge sessions directory will have a direct impact on your > > > website's performance, so it must be regularly cleaned. Deleting old > > > temporary files in your ScratchDir directory (defaults to "tmp") is > > > also a good idea. > > > > > I do both of these nightly in a cron job, so you suspect > > wrong ;) But thanks for the tips. I was only not rotating > > usertrack since I thought perhaps it was used in some of the > > reporting and shouldn't be rotated. > > > > So... it isn't possible to turn off logging to usertrack? > > Any tips on where I could look in the code to comment out the > > line/routine that does the logging? > > > Have you tried commenting out TrackFile? > > http://www.interchange.rtfm.info/icdocs/config/TrackFile.html > > # TrackFile logs/usertrack > That's the easiest way to check, yes. I still think the problem will be related to the session files, rather than the usertrack, but we'll find out soon enough. :-) -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ kevin@cursor.biz _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ From emailgrant at gmail.com Mon Dec 11 13:02:42 2006 From: emailgrant at gmail.com (Grant) Date: Mon Dec 11 13:03:33 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> Message-ID: <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> > > Hello, I've been plagued by apache2 segfaults ever since I started > > using Interchange::Link years ago. The latest Link.pm has ALERT > > messages accompanying the segfaults in error_log: > > > > ALERT: bad pipe signal received for /page.html > > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > > Segmentation fault (11) > > > > Does anyone have any advice on solving this? I'm using apache-2.0.58 > > and mod_perl-2.0.2 in Gentoo Linux. > > Also, here is the portion of Link.pm that the ALERT seems to come from: > > # Return this message to the browser when the server is not running. > # Log an error log entry if set to notify > > sub die_page { > > my $r = shift; > my $msg; > > warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; > > $r->content_type ("text/html"); > $r->print (< Interrupted > >

Someone pressed stop...

>

> We have aborted this request because someone terminated it. > Please try again soon. > > EOF > > } > > Please let me know if you have any ideas. The segfaults are eliminated by commenting out the $r stuff in the die_page sub. I still get the ALERTs though. Does anyone have any advice on figuring out why I'm having the bad pipe problem? Is there an easy way to add extra debugging info to the sub? Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs 50 fold. - Grant From josh at myprivacy.ca Mon Dec 11 13:30:20 2006 From: josh at myprivacy.ca (Josh Lavin) Date: Mon Dec 11 13:31:04 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> Message-ID: <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> On Dec 11, 2006, at 12:02 PM, Grant wrote: >> > Hello, I've been plagued by apache2 segfaults ever since I started >> > using Interchange::Link years ago. The latest Link.pm has ALERT >> > messages accompanying the segfaults in error_log: >> > >> > ALERT: bad pipe signal received for /page.html >> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal >> > Segmentation fault (11) >> > >> > Does anyone have any advice on solving this? I'm using >> apache-2.0.58 >> > and mod_perl-2.0.2 in Gentoo Linux. >> >> Also, here is the portion of Link.pm that the ALERT seems to come >> from: >> >> # Return this message to the browser when the server is not running. >> # Log an error log entry if set to notify >> >> sub die_page { >> >> my $r = shift; >> my $msg; >> >> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; >> >> $r->content_type ("text/html"); >> $r->print (<> Interrupted >> >>

Someone pressed stop...

>>

>> We have aborted this request because someone terminated it. >> Please try again soon. >> >> EOF >> >> } >> >> Please let me know if you have any ideas. > > The segfaults are eliminated by commenting out the $r stuff in the > die_page sub. I still get the ALERTs though. Does anyone have any > advice on figuring out why I'm having the bad pipe problem? Is there > an easy way to add extra debugging info to the sub? > > Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs > 50 fold. I've been seeing this too, on my Apache 2 and latest Link.pm. I also had to use PERL_SIGNALS=unsafe and so I get quite a lot of these. The visible effect on the browser is that the page or image (which Link.pm apparently still has some part in delivering) does not load. I get them myself when browsing and testing my websites, and I have never stopped loading a page or had any other problems on non-IC sites I host. I was told the problem stems from either the browser and a stop button or some other network fault. I may go back to Apache 1.3 to get around this. -- Josh Lavin Kingdom Design http://www.kingdomdesign.com/ From ron at endpoint.com Mon Dec 11 13:42:13 2006 From: ron at endpoint.com (Ron Phipps) Date: Mon Dec 11 13:43:10 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> Message-ID: <457DA685.9000201@endpoint.com> Josh Lavin wrote: > On Dec 11, 2006, at 12:02 PM, Grant wrote: > >>> > Hello, I've been plagued by apache2 segfaults ever since I started >>> > using Interchange::Link years ago. The latest Link.pm has ALERT >>> > messages accompanying the segfaults in error_log: >>> > >>> > ALERT: bad pipe signal received for /page.html >>> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal >>> > Segmentation fault (11) >>> > >>> > Does anyone have any advice on solving this? I'm using apache-2.0.58 >>> > and mod_perl-2.0.2 in Gentoo Linux. >>> >>> Also, here is the portion of Link.pm that the ALERT seems to come from: >>> >>> # Return this message to the browser when the server is not running. >>> # Log an error log entry if set to notify >>> >>> sub die_page { >>> >>> my $r = shift; >>> my $msg; >>> >>> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; >>> >>> $r->content_type ("text/html"); >>> $r->print (<>> Interrupted >>> >>>

Someone pressed stop...

>>>

>>> We have aborted this request because someone terminated it. >>> Please try again soon. >>> >>> EOF >>> >>> } >>> >>> Please let me know if you have any ideas. >> >> The segfaults are eliminated by commenting out the $r stuff in the >> die_page sub. I still get the ALERTs though. Does anyone have any >> advice on figuring out why I'm having the bad pipe problem? Is there >> an easy way to add extra debugging info to the sub? >> >> Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs 50 >> fold. > > I've been seeing this too, on my Apache 2 and latest Link.pm. I also had > to use PERL_SIGNALS=unsafe and so I get quite a lot of these. > > The visible effect on the browser is that the page or image (which > Link.pm apparently still has some part in delivering) does not load. I > get them myself when browsing and testing my websites, and I have never > stopped loading a page or had any other problems on non-IC sites I host. > > I was told the problem stems from either the browser and a stop button > or some other network fault. I may go back to Apache 1.3 to get around > this. > I saw this occur on two different installations about 4 months ago. It was suggested that I abandon the use of Link.pm and go back to using the cgi method with URL rewrite rules as this was just as fast and proved stable over the years. -- Ron Phipps End Point Corporation ron@endpoint.com From emailgrant at gmail.com Mon Dec 11 13:59:46 2006 From: emailgrant at gmail.com (Grant) Date: Mon Dec 11 14:00:11 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> Message-ID: <49bf44f10612111059wc2a5032p3ff44eb5f1ebb3c9@mail.gmail.com> > >> > Hello, I've been plagued by apache2 segfaults ever since I started > >> > using Interchange::Link years ago. The latest Link.pm has ALERT > >> > messages accompanying the segfaults in error_log: > >> > > >> > ALERT: bad pipe signal received for /page.html > >> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > >> > Segmentation fault (11) > >> > > >> > Does anyone have any advice on solving this? I'm using > >> apache-2.0.58 > >> > and mod_perl-2.0.2 in Gentoo Linux. > >> > >> Also, here is the portion of Link.pm that the ALERT seems to come > >> from: > >> > >> # Return this message to the browser when the server is not running. > >> # Log an error log entry if set to notify > >> > >> sub die_page { > >> > >> my $r = shift; > >> my $msg; > >> > >> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; > >> > >> $r->content_type ("text/html"); > >> $r->print (< >> Interrupted > >> > >>

Someone pressed stop...

> >>

> >> We have aborted this request because someone terminated it. > >> Please try again soon. > >> > >> EOF > >> > >> } > >> > >> Please let me know if you have any ideas. > > > > The segfaults are eliminated by commenting out the $r stuff in the > > die_page sub. I still get the ALERTs though. Does anyone have any > > advice on figuring out why I'm having the bad pipe problem? Is there > > an easy way to add extra debugging info to the sub? > > > > Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs > > 50 fold. > > I've been seeing this too, on my Apache 2 and latest Link.pm. I also > had to use PERL_SIGNALS=unsafe and so I get quite a lot of these. > > The visible effect on the browser is that the page or image (which > Link.pm apparently still has some part in delivering) does not load. > I get them myself when browsing and testing my websites, and I have > never stopped loading a page or had any other problems on non-IC > sites I host. > > I was told the problem stems from either the browser and a stop > button or some other network fault. I may go back to Apache 1.3 to > get around this. Sounds like the exact same problem I'm having. I don't use the UI so I don't have an interchange-5/ folder. If I request an admin page, the html loads and my error_log is suddenly filled with errors like this: ALERT: bad pipe signal received for /interchange-5 It happens every single time. After that, bad pipe alerts appear much more frequently until apache2 is restarted. I wonder if this is a clue. - Grant > Josh Lavin From emailgrant at gmail.com Mon Dec 11 14:01:55 2006 From: emailgrant at gmail.com (Grant) Date: Mon Dec 11 14:02:19 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <457DA685.9000201@endpoint.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <457DA685.9000201@endpoint.com> Message-ID: <49bf44f10612111101u8d2257dydb75e717cd1b47cc@mail.gmail.com> > >>> > Hello, I've been plagued by apache2 segfaults ever since I started > >>> > using Interchange::Link years ago. The latest Link.pm has ALERT > >>> > messages accompanying the segfaults in error_log: > >>> > > >>> > ALERT: bad pipe signal received for /page.html > >>> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > >>> > Segmentation fault (11) > >>> > > >>> > Does anyone have any advice on solving this? I'm using apache-2.0.58 > >>> > and mod_perl-2.0.2 in Gentoo Linux. > >>> > >>> Also, here is the portion of Link.pm that the ALERT seems to come from: > >>> > >>> # Return this message to the browser when the server is not running. > >>> # Log an error log entry if set to notify > >>> > >>> sub die_page { > >>> > >>> my $r = shift; > >>> my $msg; > >>> > >>> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; > >>> > >>> $r->content_type ("text/html"); > >>> $r->print (< >>> Interrupted > >>> > >>>

Someone pressed stop...

> >>>

> >>> We have aborted this request because someone terminated it. > >>> Please try again soon. > >>> > >>> EOF > >>> > >>> } > >>> > >>> Please let me know if you have any ideas. > >> > >> The segfaults are eliminated by commenting out the $r stuff in the > >> die_page sub. I still get the ALERTs though. Does anyone have any > >> advice on figuring out why I'm having the bad pipe problem? Is there > >> an easy way to add extra debugging info to the sub? > >> > >> Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs 50 > >> fold. > > > > I've been seeing this too, on my Apache 2 and latest Link.pm. I also had > > to use PERL_SIGNALS=unsafe and so I get quite a lot of these. > > > > The visible effect on the browser is that the page or image (which > > Link.pm apparently still has some part in delivering) does not load. I > > get them myself when browsing and testing my websites, and I have never > > stopped loading a page or had any other problems on non-IC sites I host. > > > > I was told the problem stems from either the browser and a stop button > > or some other network fault. I may go back to Apache 1.3 to get around > > this. > > > > I saw this occur on two different installations about 4 months ago. It was suggested that I abandon the use of Link.pm and go back to using the cgi method with URL rewrite rules as this was just as fast and proved stable over the years. The problem with the cgi method is it requires your pages to have a URL that includes the catalog name. - Grant From jon at endpoint.com Mon Dec 11 14:13:34 2006 From: jon at endpoint.com (Jon Jensen) Date: Mon Dec 11 14:14:09 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <49bf44f10612111101u8d2257dydb75e717cd1b47cc@mail.gmail.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <457DA685.9000201@endpoint.com> <49bf44f10612111101u8d2257dydb75e717cd1b47cc@mail.gmail.com> Message-ID: On Mon, 11 Dec 2006, Grant wrote: >> I saw this occur on two different installations about 4 months ago. >> It was suggested that I abandon the use of Link.pm and go back to using >> the cgi method with URL rewrite rules as this was just as fast and >> proved stable over the years. > > The problem with the cgi method is it requires your pages to have a URL > that includes the catalog name. mod_rewrite makes it easy to have URLs that look like you want. Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/ From racke at linuxia.de Mon Dec 11 14:28:12 2006 From: racke at linuxia.de (Stefan Hornburg (Racke)) Date: Mon Dec 11 14:28:51 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <49bf44f10612111101u8d2257dydb75e717cd1b47cc@mail.gmail.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <457DA685.9000201@endpoint.com> <49bf44f10612111101u8d2257dydb75e717cd1b47cc@mail.gmail.com> Message-ID: <457DB14C.2030206@linuxia.de> Grant wrote: >> >>> > Hello, I've been plagued by apache2 segfaults ever since I started >> >>> > using Interchange::Link years ago. The latest Link.pm has ALERT >> >>> > messages accompanying the segfaults in error_log: >> >>> > >> >>> > ALERT: bad pipe signal received for /page.html >> >>> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal >> >>> > Segmentation fault (11) >> >>> > >> >>> > Does anyone have any advice on solving this? I'm using >> apache-2.0.58 >> >>> > and mod_perl-2.0.2 in Gentoo Linux. >> >>> >> >>> Also, here is the portion of Link.pm that the ALERT seems to come >> from: >> >>> >> >>> # Return this message to the browser when the server is not running. >> >>> # Log an error log entry if set to notify >> >>> >> >>> sub die_page { >> >>> >> >>> my $r = shift; >> >>> my $msg; >> >>> >> >>> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; >> >>> >> >>> $r->content_type ("text/html"); >> >>> $r->print (<> >>> Interrupted >> >>> >> >>>

Someone pressed stop...

>> >>>

>> >>> We have aborted this request because someone terminated it. >> >>> Please try again soon. >> >>> >> >>> EOF >> >>> >> >>> } >> >>> >> >>> Please let me know if you have any ideas. >> >> >> >> The segfaults are eliminated by commenting out the $r stuff in the >> >> die_page sub. I still get the ALERTs though. Does anyone have any >> >> advice on figuring out why I'm having the bad pipe problem? Is there >> >> an easy way to add extra debugging info to the sub? >> >> >> >> Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs 50 >> >> fold. >> > >> > I've been seeing this too, on my Apache 2 and latest Link.pm. I also >> had >> > to use PERL_SIGNALS=unsafe and so I get quite a lot of these. >> > >> > The visible effect on the browser is that the page or image (which >> > Link.pm apparently still has some part in delivering) does not load. I >> > get them myself when browsing and testing my websites, and I have never >> > stopped loading a page or had any other problems on non-IC sites I >> host. >> > >> > I was told the problem stems from either the browser and a stop button >> > or some other network fault. I may go back to Apache 1.3 to get around >> > this. >> > >> >> I saw this occur on two different installations about 4 months ago. >> It was suggested that I abandon the use of Link.pm and go back to >> using the cgi method with URL rewrite rules as this was just as fast >> and proved stable over the years. > > The problem with the cgi method is it requires your pages to have a > URL that includes the catalog name. That is simply not true. Bye Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team From emailgrant at gmail.com Mon Dec 11 14:48:00 2006 From: emailgrant at gmail.com (Grant) Date: Mon Dec 11 14:48:11 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <457DB14C.2030206@linuxia.de> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <457DA685.9000201@endpoint.com> <49bf44f10612111101u8d2257dydb75e717cd1b47cc@mail.gmail.com> <457DB14C.2030206@linuxia.de> Message-ID: <49bf44f10612111148g47de91edof2e5eb361d9ed4ea@mail.gmail.com> > >> >>> > Hello, I've been plagued by apache2 segfaults ever since I started > >> >>> > using Interchange::Link years ago. The latest Link.pm has ALERT > >> >>> > messages accompanying the segfaults in error_log: > >> >>> > > >> >>> > ALERT: bad pipe signal received for /page.html > >> >>> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > >> >>> > Segmentation fault (11) > >> >>> > > >> >>> > Does anyone have any advice on solving this? I'm using > >> apache-2.0.58 > >> >>> > and mod_perl-2.0.2 in Gentoo Linux. > >> >>> > >> >>> Also, here is the portion of Link.pm that the ALERT seems to come > >> from: > >> >>> > >> >>> # Return this message to the browser when the server is not running. > >> >>> # Log an error log entry if set to notify > >> >>> > >> >>> sub die_page { > >> >>> > >> >>> my $r = shift; > >> >>> my $msg; > >> >>> > >> >>> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; > >> >>> > >> >>> $r->content_type ("text/html"); > >> >>> $r->print (< >> >>> Interrupted > >> >>> > >> >>>

Someone pressed stop...

> >> >>>

> >> >>> We have aborted this request because someone terminated it. > >> >>> Please try again soon. > >> >>> > >> >>> EOF > >> >>> > >> >>> } > >> >>> > >> >>> Please let me know if you have any ideas. > >> >> > >> >> The segfaults are eliminated by commenting out the $r stuff in the > >> >> die_page sub. I still get the ALERTs though. Does anyone have any > >> >> advice on figuring out why I'm having the bad pipe problem? Is there > >> >> an easy way to add extra debugging info to the sub? > >> >> > >> >> Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs 50 > >> >> fold. > >> > > >> > I've been seeing this too, on my Apache 2 and latest Link.pm. I also > >> had > >> > to use PERL_SIGNALS=unsafe and so I get quite a lot of these. > >> > > >> > The visible effect on the browser is that the page or image (which > >> > Link.pm apparently still has some part in delivering) does not load. I > >> > get them myself when browsing and testing my websites, and I have never > >> > stopped loading a page or had any other problems on non-IC sites I > >> host. > >> > > >> > I was told the problem stems from either the browser and a stop button > >> > or some other network fault. I may go back to Apache 1.3 to get around > >> > this. > >> > > >> > >> I saw this occur on two different installations about 4 months ago. > >> It was suggested that I abandon the use of Link.pm and go back to > >> using the cgi method with URL rewrite rules as this was just as fast > >> and proved stable over the years. > > > > The problem with the cgi method is it requires your pages to have a > > URL that includes the catalog name. > > That is simply not true. > > Bye > Racke Are you referring to mod_rewrite? mod_rewrite will only change what appears in the address bar right? I need something that allows IC to generate folder-free URLs. Can IC be configured to generate and use such URLs via the cgi method? - Grant From racke at linuxia.de Mon Dec 11 15:11:09 2006 From: racke at linuxia.de (Stefan Hornburg (Racke)) Date: Mon Dec 11 15:11:42 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <49bf44f10612111148g47de91edof2e5eb361d9ed4ea@mail.gmail.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <457DA685.9000201@endpoint.com> <49bf44f10612111101u8d2257dydb75e717cd1b47cc@mail.gmail.com> <457DB14C.2030206@linuxia.de> <49bf44f10612111148g47de91edof2e5eb361d9ed4ea@mail.gmail.com> Message-ID: <457DBB5D.7070901@linuxia.de> Grant wrote: >> >> >>> > Hello, I've been plagued by apache2 segfaults ever since I >> started >> >> >>> > using Interchange::Link years ago. The latest Link.pm has ALERT >> >> >>> > messages accompanying the segfaults in error_log: >> >> >>> > >> >> >>> > ALERT: bad pipe signal received for /page.html >> >> >>> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal >> >> >>> > Segmentation fault (11) >> >> >>> > >> >> >>> > Does anyone have any advice on solving this? I'm using >> >> apache-2.0.58 >> >> >>> > and mod_perl-2.0.2 in Gentoo Linux. >> >> >>> >> >> >>> Also, here is the portion of Link.pm that the ALERT seems to come >> >> from: >> >> >>> >> >> >>> # Return this message to the browser when the server is not >> running. >> >> >>> # Log an error log entry if set to notify >> >> >>> >> >> >>> sub die_page { >> >> >>> >> >> >>> my $r = shift; >> >> >>> my $msg; >> >> >>> >> >> >>> warn "ALERT: bad pipe signal received for >> $ENV{SCRIPT_NAME}\n"; >> >> >>> >> >> >>> $r->content_type ("text/html"); >> >> >>> $r->print (<> >> >>> Interrupted >> >> >>> >> >> >>>

Someone pressed stop...

>> >> >>>

>> >> >>> We have aborted this request because someone terminated it. >> >> >>> Please try again soon. >> >> >>> >> >> >>> EOF >> >> >>> >> >> >>> } >> >> >>> >> >> >>> Please let me know if you have any ideas. >> >> >> >> >> >> The segfaults are eliminated by commenting out the $r stuff in the >> >> >> die_page sub. I still get the ALERTs though. Does anyone have any >> >> >> advice on figuring out why I'm having the bad pipe problem? Is >> there >> >> >> an easy way to add extra debugging info to the sub? >> >> >> >> >> >> Also, restarting IC with PERL_SIGNALS=unsafe increases the >> ALERTs 50 >> >> >> fold. >> >> > >> >> > I've been seeing this too, on my Apache 2 and latest Link.pm. I also >> >> had >> >> > to use PERL_SIGNALS=unsafe and so I get quite a lot of these. >> >> > >> >> > The visible effect on the browser is that the page or image (which >> >> > Link.pm apparently still has some part in delivering) does not >> load. I >> >> > get them myself when browsing and testing my websites, and I have >> never >> >> > stopped loading a page or had any other problems on non-IC sites I >> >> host. >> >> > >> >> > I was told the problem stems from either the browser and a stop >> button >> >> > or some other network fault. I may go back to Apache 1.3 to get >> around >> >> > this. >> >> > >> >> >> >> I saw this occur on two different installations about 4 months ago. >> >> It was suggested that I abandon the use of Link.pm and go back to >> >> using the cgi method with URL rewrite rules as this was just as fast >> >> and proved stable over the years. >> > >> > The problem with the cgi method is it requires your pages to have a >> > URL that includes the catalog name. >> >> That is simply not true. >> >> Bye >> Racke > > Are you referring to mod_rewrite? mod_rewrite will only change what > appears in the address bar right? I need something that allows IC to > generate folder-free URLs. Can IC be configured to generate and use > such URLs via the cgi method? Look into the FullURL directive. This allows you to specify your Catalog like that: Catalog linuxia /home/racke/linuxia www.linuxia.de www.linuxia.de:443 Now you have only to ensure that the calls from the clients are passed on to IC, e.g.: Alias /images/ /home/racke/linuxia/html/images/ ScriptAliasMatch ^/(.*)$ /usr/lib/cgi-bin/ic/linuxia/$1 You can also use rewrite do achieve that. Bye Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team From emailgrant at gmail.com Mon Dec 11 18:14:02 2006 From: emailgrant at gmail.com (Grant) Date: Mon Dec 11 18:14:15 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <49bf44f10612111059wc2a5032p3ff44eb5f1ebb3c9@mail.gmail.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <49bf44f10612111059wc2a5032p3ff44eb5f1ebb3c9@mail.gmail.com> Message-ID: <49bf44f10612111514n43bdd241m26270f51302f4102@mail.gmail.com> > > >> > Hello, I've been plagued by apache2 segfaults ever since I started > > >> > using Interchange::Link years ago. The latest Link.pm has ALERT > > >> > messages accompanying the segfaults in error_log: > > >> > > > >> > ALERT: bad pipe signal received for /page.html > > >> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > > >> > Segmentation fault (11) > > >> > > > >> > Does anyone have any advice on solving this? I'm using > > >> apache-2.0.58 > > >> > and mod_perl-2.0.2 in Gentoo Linux. > > >> > > >> Also, here is the portion of Link.pm that the ALERT seems to come > > >> from: > > >> > > >> # Return this message to the browser when the server is not running. > > >> # Log an error log entry if set to notify > > >> > > >> sub die_page { > > >> > > >> my $r = shift; > > >> my $msg; > > >> > > >> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; > > >> > > >> $r->content_type ("text/html"); > > >> $r->print (< > >> Interrupted > > >> > > >>

Someone pressed stop...

> > >>

> > >> We have aborted this request because someone terminated it. > > >> Please try again soon. > > >> > > >> EOF > > >> > > >> } > > >> > > >> Please let me know if you have any ideas. > > > > > > The segfaults are eliminated by commenting out the $r stuff in the > > > die_page sub. I still get the ALERTs though. Does anyone have any > > > advice on figuring out why I'm having the bad pipe problem? Is there > > > an easy way to add extra debugging info to the sub? > > > > > > Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs > > > 50 fold. > > > > I've been seeing this too, on my Apache 2 and latest Link.pm. I also > > had to use PERL_SIGNALS=unsafe and so I get quite a lot of these. > > > > The visible effect on the browser is that the page or image (which > > Link.pm apparently still has some part in delivering) does not load. > > I get them myself when browsing and testing my websites, and I have > > never stopped loading a page or had any other problems on non-IC > > sites I host. > > > > I was told the problem stems from either the browser and a stop > > button or some other network fault. I may go back to Apache 1.3 to > > get around this. > > Sounds like the exact same problem I'm having. > > I don't use the UI so I don't have an interchange-5/ folder. If I > request an admin page, the html loads and my error_log is suddenly > filled with errors like this: > > ALERT: bad pipe signal received for /interchange-5 > > It happens every single time. After that, bad pipe alerts appear much > more frequently until apache2 is restarted. I wonder if this is a > clue. I want to refine this a little by saying that requesting any page over and over rapidly via F5 leads to a bunch of ALERTs. At that point, ALERTs happen much more frequently until apache2 is restarted. There is some kind of a cumulative effect here that I don't understand. Any ideas? Can anyone verify this particular behavior? - Grant From emailgrant at gmail.com Mon Dec 11 18:16:37 2006 From: emailgrant at gmail.com (Grant) Date: Mon Dec 11 18:16:49 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <457DBB5D.7070901@linuxia.de> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <457DA685.9000201@endpoint.com> <49bf44f10612111101u8d2257dydb75e717cd1b47cc@mail.gmail.com> <457DB14C.2030206@linuxia.de> <49bf44f10612111148g47de91edof2e5eb361d9ed4ea@mail.gmail.com> <457DBB5D.7070901@linuxia.de> Message-ID: <49bf44f10612111516o7e930932o5d32d4fb2c31326d@mail.gmail.com> > >> >> >>> > Hello, I've been plagued by apache2 segfaults ever since I > >> started > >> >> >>> > using Interchange::Link years ago. The latest Link.pm has ALERT > >> >> >>> > messages accompanying the segfaults in error_log: > >> >> >>> > > >> >> >>> > ALERT: bad pipe signal received for /page.html > >> >> >>> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > >> >> >>> > Segmentation fault (11) > >> >> >>> > > >> >> >>> > Does anyone have any advice on solving this? I'm using > >> >> apache-2.0.58 > >> >> >>> > and mod_perl-2.0.2 in Gentoo Linux. > >> >> >>> > >> >> >>> Also, here is the portion of Link.pm that the ALERT seems to come > >> >> from: > >> >> >>> > >> >> >>> # Return this message to the browser when the server is not > >> running. > >> >> >>> # Log an error log entry if set to notify > >> >> >>> > >> >> >>> sub die_page { > >> >> >>> > >> >> >>> my $r = shift; > >> >> >>> my $msg; > >> >> >>> > >> >> >>> warn "ALERT: bad pipe signal received for > >> $ENV{SCRIPT_NAME}\n"; > >> >> >>> > >> >> >>> $r->content_type ("text/html"); > >> >> >>> $r->print (< >> >> >>> Interrupted > >> >> >>> > >> >> >>>

Someone pressed stop...

> >> >> >>>

> >> >> >>> We have aborted this request because someone terminated it. > >> >> >>> Please try again soon. > >> >> >>> > >> >> >>> EOF > >> >> >>> > >> >> >>> } > >> >> >>> > >> >> >>> Please let me know if you have any ideas. > >> >> >> > >> >> >> The segfaults are eliminated by commenting out the $r stuff in the > >> >> >> die_page sub. I still get the ALERTs though. Does anyone have any > >> >> >> advice on figuring out why I'm having the bad pipe problem? Is > >> there > >> >> >> an easy way to add extra debugging info to the sub? > >> >> >> > >> >> >> Also, restarting IC with PERL_SIGNALS=unsafe increases the > >> ALERTs 50 > >> >> >> fold. > >> >> > > >> >> > I've been seeing this too, on my Apache 2 and latest Link.pm. I also > >> >> had > >> >> > to use PERL_SIGNALS=unsafe and so I get quite a lot of these. > >> >> > > >> >> > The visible effect on the browser is that the page or image (which > >> >> > Link.pm apparently still has some part in delivering) does not > >> load. I > >> >> > get them myself when browsing and testing my websites, and I have > >> never > >> >> > stopped loading a page or had any other problems on non-IC sites I > >> >> host. > >> >> > > >> >> > I was told the problem stems from either the browser and a stop > >> button > >> >> > or some other network fault. I may go back to Apache 1.3 to get > >> around > >> >> > this. > >> >> > > >> >> > >> >> I saw this occur on two different installations about 4 months ago. > >> >> It was suggested that I abandon the use of Link.pm and go back to > >> >> using the cgi method with URL rewrite rules as this was just as fast > >> >> and proved stable over the years. > >> > > >> > The problem with the cgi method is it requires your pages to have a > >> > URL that includes the catalog name. > >> > >> That is simply not true. > >> > >> Bye > >> Racke > > > > Are you referring to mod_rewrite? mod_rewrite will only change what > > appears in the address bar right? I need something that allows IC to > > generate folder-free URLs. Can IC be configured to generate and use > > such URLs via the cgi method? > > Look into the FullURL directive. This allows you to specify your Catalog like that: > > Catalog linuxia /home/racke/linuxia www.linuxia.de www.linuxia.de:443 > > Now you have only to ensure that the calls from the clients are passed on to > IC, e.g.: > > Alias /images/ /home/racke/linuxia/html/images/ > ScriptAliasMatch ^/(.*)$ /usr/lib/cgi-bin/ic/linuxia/$1 > > You can also use rewrite do achieve that. Thank you Racke, I'll check that out. Interchange::Link doesn't seem to be curable. Maybe it's a limitation of mod_perl? - Grant From josh at myprivacy.ca Mon Dec 11 18:24:17 2006 From: josh at myprivacy.ca (Josh Lavin) Date: Mon Dec 11 18:24:50 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <457DA685.9000201@endpoint.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <457DA685.9000201@endpoint.com> Message-ID: On Dec 11, 2006, at 12:42 PM, Ron Phipps wrote: > Josh Lavin wrote: >> On Dec 11, 2006, at 12:02 PM, Grant wrote: >>>> > Hello, I've been plagued by apache2 segfaults ever since I >>>> started >>>> > using Interchange::Link years ago. The latest Link.pm has ALERT >>>> > messages accompanying the segfaults in error_log: >>>> > >>>> > ALERT: bad pipe signal received for /page.html >>>> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal >>>> > Segmentation fault (11) >>>> > >>>> > Does anyone have any advice on solving this? I'm using >>>> apache-2.0.58 >>>> > and mod_perl-2.0.2 in Gentoo Linux. >>>> >>>> Also, here is the portion of Link.pm that the ALERT seems to >>>> come from: >>>> >>>> # Return this message to the browser when the server is not >>>> running. >>>> # Log an error log entry if set to notify >>>> >>>> sub die_page { >>>> >>>> my $r = shift; >>>> my $msg; >>>> >>>> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; >>>> >>>> $r->content_type ("text/html"); >>>> $r->print (<>>> Interrupted >>>> >>>>

Someone pressed stop...

>>>>

>>>> We have aborted this request because someone terminated it. >>>> Please try again soon. >>>> >>>> EOF >>>> >>>> } >>>> >>>> Please let me know if you have any ideas. >>> >>> The segfaults are eliminated by commenting out the $r stuff in the >>> die_page sub. I still get the ALERTs though. Does anyone have any >>> advice on figuring out why I'm having the bad pipe problem? Is >>> there >>> an easy way to add extra debugging info to the sub? >>> >>> Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs >>> 50 fold. >> I've been seeing this too, on my Apache 2 and latest Link.pm. I >> also had to use PERL_SIGNALS=unsafe and so I get quite a lot of >> these. >> The visible effect on the browser is that the page or image (which >> Link.pm apparently still has some part in delivering) does not >> load. I get them myself when browsing and testing my websites, and >> I have never stopped loading a page or had any other problems on >> non-IC sites I host. >> I was told the problem stems from either the browser and a stop >> button or some other network fault. I may go back to Apache 1.3 to >> get around this. > > I saw this occur on two different installations about 4 months > ago. It was suggested that I abandon the use of Link.pm and go > back to using the cgi method with URL rewrite rules as this was > just as fast and proved stable over the years. Is plain CGI really as fast as mod_perl or mod_interchange? That'd be my only concern with switching back to CGI+rewrites. Maybe it is ok -- see mod_interchange's README: "The Interchange link protocol has been implemented via an Apache module which saves us the (small) overhead of the execution of a CGI program." -- Josh Lavin Kingdom Design http://www.kingdomdesign.com/ From ron at endpoint.com Mon Dec 11 18:35:13 2006 From: ron at endpoint.com (Ron Phipps) Date: Mon Dec 11 18:35:54 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <457DA685.9000201@endpoint.com> Message-ID: <457DEB31.7080208@endpoint.com> Josh Lavin wrote: > On Dec 11, 2006, at 12:42 PM, Ron Phipps wrote: >> Josh Lavin wrote: >>> On Dec 11, 2006, at 12:02 PM, Grant wrote: >>>>> > Hello, I've been plagued by apache2 segfaults ever since I started >>>>> > using Interchange::Link years ago. The latest Link.pm has ALERT >>>>> > messages accompanying the segfaults in error_log: >>>>> > >>>>> > ALERT: bad pipe signal received for /page.html >>>>> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal >>>>> > Segmentation fault (11) >>>>> > >>>>> > Does anyone have any advice on solving this? I'm using >>>>> apache-2.0.58 >>>>> > and mod_perl-2.0.2 in Gentoo Linux. >>>>> >>>>> Also, here is the portion of Link.pm that the ALERT seems to come >>>>> from: >>>>> >>>>> # Return this message to the browser when the server is not running. >>>>> # Log an error log entry if set to notify >>>>> >>>>> sub die_page { >>>>> >>>>> my $r = shift; >>>>> my $msg; >>>>> >>>>> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; >>>>> >>>>> $r->content_type ("text/html"); >>>>> $r->print (<>>>> Interrupted >>>>> >>>>>

Someone pressed stop...

>>>>>

>>>>> We have aborted this request because someone terminated it. >>>>> Please try again soon. >>>>> >>>>> EOF >>>>> >>>>> } >>>>> >>>>> Please let me know if you have any ideas. >>>> >>>> The segfaults are eliminated by commenting out the $r stuff in the >>>> die_page sub. I still get the ALERTs though. Does anyone have any >>>> advice on figuring out why I'm having the bad pipe problem? Is there >>>> an easy way to add extra debugging info to the sub? >>>> >>>> Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs 50 >>>> fold. >>> I've been seeing this too, on my Apache 2 and latest Link.pm. I also >>> had to use PERL_SIGNALS=unsafe and so I get quite a lot of these. >>> The visible effect on the browser is that the page or image (which >>> Link.pm apparently still has some part in delivering) does not load. >>> I get them myself when browsing and testing my websites, and I have >>> never stopped loading a page or had any other problems on non-IC >>> sites I host. >>> I was told the problem stems from either the browser and a stop >>> button or some other network fault. I may go back to Apache 1.3 to >>> get around this. >> >> I saw this occur on two different installations about 4 months ago. >> It was suggested that I abandon the use of Link.pm and go back to >> using the cgi method with URL rewrite rules as this was just as fast >> and proved stable over the years. > > Is plain CGI really as fast as mod_perl or mod_interchange? That'd be my > only concern with switching back to CGI+rewrites. > > Maybe it is ok -- see mod_interchange's README: > > "The Interchange link protocol has been > implemented via an Apache module which > saves us the (small) overhead > of the execution of a CGI program." > Josh, I have not done any a/b tests to determine which is faster, others have. Vlink/tlink is currently being used without any speed issues during high traffic periods at: www.bcstore.com www.frozencpu.com www.citypass.com www.reliablemedical.com Quite a bit of time was put in with BCStore to compare which method was stable and fast and it was determined that tlink/vlink was the way to go. I thought that we needed to use mod_interchange/mod_perl for FrozenCPU, but quickly found out that under Apache 2.0/mod_perl the issues far outweighed any perceived speed up. tlink/vlink are compiled c programs and should be very quick in execution. At End Point we use rewrites with tlink/vlink pretty much exclusively. Thanks, -- Ron Phipps End Point Corporation ron@endpoint.com From kevin at cursor.biz Mon Dec 11 20:49:19 2006 From: kevin at cursor.biz (Kevin Walsh) Date: Mon Dec 11 20:49:49 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <457DA685.9000201@endpoint.com> Message-ID: <200612120149.21199.kevin@cursor.biz> Josh Lavin wrote: > Is plain CGI really as fast as mod_perl or mod_interchange? That'd be > my only concern with switching back to CGI+rewrites. > > Maybe it is ok -- see mod_interchange's README: > > "The Interchange link protocol has been > implemented via an Apache module which > saves us the (small) overhead > of the execution of a CGI program." > The overhead referred to is the time taken to fork and exec the CGI executable. The executable file itself will most likely be cached, on even lightly loaded systems, so there's no great concern over the time it takes to open and read the CGI program prior to execution. I've never been a great fan of rewrite rules, and there's a small overhead to be saved there too. Apart from any perceived efficiency enhancements, and pretty URIs without rewrites, mod_interchange provides a couple of facilities such as connection retries, failover to a backup Interchange server and a request drop list etc., that are not available to CGI link programs. Mod_interchange is only available for use with Apache 1.3, but that's not a massive problem. Gentoo, for example, will install and maintain Apache 1.3 instead of 2.x if you ask it to. There's never been any demand for mod_interchange on Apache 2.x, which is the main reason why it's still only available on 1.3. I maintain mod_interchange because I find it useful. If I need to use Apache 2.x for some reason then I'll port it regardless of the demand, or lack thereof. I assumed that the lack of demand for mod_interchange on Apache 2.x was down to the availability of the Interchange::Link mod_perl module. Interchange::Link shares the same advantages as mod_interchange but seems to have its quirks. I'm sure those will be ironed out in time, as long as the problems are reported. Any overhead saved by using mod_interchange can very quickly be eaten up with sloppy page code, so it's much more important to get your pages to be as efficient as possible, rather than worry about the relative merits of the various link facilities. www.interchange.rtfm.info uses mod_interchange, by the way. -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ kevin@cursor.biz _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ From music at labyrinth.net.au Mon Dec 11 21:23:43 2006 From: music at labyrinth.net.au (Music) Date: Mon Dec 11 21:24:04 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com><49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com><49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> Message-ID: <019001c71d94$8cb5d2c0$0200a8c0@IBMKZ894FB2E08> > I've been seeing this too, on my Apache 2 and latest Link.pm. I also had > to use PERL_SIGNALS=unsafe and so I get quite a lot of these. > > The visible effect on the browser is that the page or image (which > Link.pm apparently still has some part in delivering) does not load. I > get them myself when browsing and testing my websites, and I have never > stopped loading a page or had any other problems on non-IC sites I host. > > I was told the problem stems from either the browser and a stop button or > some other network fault. I may go back to Apache 1.3 to get around this. I have no idea if this is related in anyway however just in case there is any connection: I find that IC 5.4.1 on Apache 2.0.46-61.ent.centos3 (using secondary unthreaded perl 5.8.0 and suexec) and the standard CGI link gets into a 'faulty' state that only occurs after certain catalogs have recently had 'Apply Changes' applied. The result is an intermittent error where a bunch of IC tags are not parsed and dumped to the screen (can happen on any page) Depending on the catalog the webpage output looks something like a broken page with something similar displayed: [control-set search_box_small[/component] [/control-set] [calc $Variable->{MV_DHTML_BROWSER} ||= 'MSIE.*[5-9]\..*Windows|Mozilla.*Gecko|Opera.*[7-9]\.'; $Scratch->{dhtml_browser} = $Session->{browser} =~ m{$Variable->{MV_DHTML_BROWSER}}; if($Scratch->{members_only} and ! $Session->{logged_in}) { $Scratch->{mv_successpage} = $Tag->var('MV_PAGE', 1); $Tag->deliver({ location => $Tag->area('login')}); } return; [/calc] To reproduce the error I just need to hit apply changes with a new STANDARD store, and then keep refreshing a page. (Hit F5 over and over again.) The pages will render beautifully however eventually the broken page will appear. Another refresh and the problem disappears. (Very intermittent but consistent) The bad thing is that the faulty condition affects all catalogues on the server and similar garble will intermittently appear on other catalog pages. To fix the problem I need to restart Interchange. I did some more experimenting today inspired by this thread however the problem persists. - I have tried setting all catalogs envrionments to use mod_perl - I have disabled all mod_perl - I have restarting both with and without PERL_SIGNALS=unsafe in command line. - I have only tried this using RPC mode with variations of: ifdef TRAFFIC =~ /rpc/i Message RPC traffic settings. PreFork Yes StartServers 5 MaxServers 0 MaxRequestsPerChild 100 HouseKeeping 2 PIDcheck 120 ChildLife 30 minutes endif I also tried disabling ChildLife and PreFork and increasing start servers. All with no joy. 'Applying Changes' to one catalogue puts the Interchange daemon into faulty state. No errors are displayed in IC error.log, catalog error.log nor apache error logs. Just thought I would document this on the list to see if any feedback etc. From ron at endpoint.com Mon Dec 11 23:32:43 2006 From: ron at endpoint.com (Ron Phipps) Date: Mon Dec 11 23:33:23 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <200612120149.21199.kevin@cursor.biz> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <457DA685.9000201@endpoint.com> <200612120149.21199.kevin@cursor.biz> Message-ID: <457E30EB.40809@endpoint.com> Kevin Walsh wrote: > Josh Lavin wrote: >> Is plain CGI really as fast as mod_perl or mod_interchange? That'd be >> my only concern with switching back to CGI+rewrites. >> >> Maybe it is ok -- see mod_interchange's README: >> >> "The Interchange link protocol has been >> implemented via an Apache module which >> saves us the (small) overhead >> of the execution of a CGI program." >> > The overhead referred to is the time taken to fork and exec the CGI > executable. The executable file itself will most likely be cached, > on even lightly loaded systems, so there's no great concern over the > time it takes to open and read the CGI program prior to execution. > > I've never been a great fan of rewrite rules, and there's a small > overhead to be saved there too. > > Apart from any perceived efficiency enhancements, and pretty URIs > without rewrites, mod_interchange provides a couple of facilities > such as connection retries, failover to a backup Interchange server > and a request drop list etc., that are not available to CGI link > programs. > > Mod_interchange is only available for use with Apache 1.3, but that's > not a massive problem. Gentoo, for example, will install and maintain > Apache 1.3 instead of 2.x if you ask it to. > > There's never been any demand for mod_interchange on Apache 2.x, which > is the main reason why it's still only available on 1.3. I maintain > mod_interchange because I find it useful. If I need to use Apache 2.x > for some reason then I'll port it regardless of the demand, or lack > thereof. > > I assumed that the lack of demand for mod_interchange on Apache 2.x > was down to the availability of the Interchange::Link mod_perl module. > Interchange::Link shares the same advantages as mod_interchange but > seems to have its quirks. I'm sure those will be ironed out in time, > as long as the problems are reported. > > Any overhead saved by using mod_interchange can very quickly be eaten > up with sloppy page code, so it's much more important to get your pages > to be as efficient as possible, rather than worry about the relative > merits of the various link facilities. > > www.interchange.rtfm.info uses mod_interchange, by the way. > With all the being said, I used mod_interchange with Apache 1.3.x for years on FrozenCPU and it worked beautifully during that time and if I were to setup an IC site on Apache 1.3.x today I probably would still use mod_interchange due to the reasons Kevin mentioned. One thing that was especially nice with mod_interchange is that I could easily add files to DropRequestList, this helped when we were attacked by a worm that was trying to exploit a XMLRPC bug which had the side effect of hanging IC due to a parsing bug. I wasn't sure how to fix the parsing bug, but added the filename to the drop list and IC no longer hung. -- Ron Phipps End Point Corporation ron@endpoint.com From kevin at cursor.biz Mon Dec 11 23:51:31 2006 From: kevin at cursor.biz (Kevin Walsh) Date: Mon Dec 11 23:52:57 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <457E30EB.40809@endpoint.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <200612120149.21199.kevin@cursor.biz> <457E30EB.40809@endpoint.com> Message-ID: <200612120451.33054.kevin@cursor.biz> Ron Phipps wrote: > One thing that was especially nice with mod_interchange is that I > could easily add files to DropRequestList, this helped when we > were attacked by a worm that was trying to exploit a XMLRPC bug > which had the side effect of hanging IC due to a parsing bug. I > wasn't sure how to fix the parsing bug, but added the filename to > the drop list and IC no longer hung. > Just for the record, the DoS bug referenced above has been fixed now. It was nice to be able to drop the crafty requests while the bug was being investigated. -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ kevin@cursor.biz _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ From kevin at cursor.biz Tue Dec 12 00:12:24 2006 From: kevin at cursor.biz (Kevin Walsh) Date: Tue Dec 12 00:12:36 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <019001c71d94$8cb5d2c0$0200a8c0@IBMKZ894FB2E08> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <019001c71d94$8cb5d2c0$0200a8c0@IBMKZ894FB2E08> Message-ID: <200612120512.25362.kevin@cursor.biz> "Music" wrote: > ifdef TRAFFIC =~ /rpc/i > Message RPC traffic settings. > PreFork Yes > StartServers 5 > MaxServers 0 > MaxRequestsPerChild 100 > HouseKeeping 2 > PIDcheck 120 > ChildLife 30 minutes > endif > > I also tried disabling ChildLife and PreFork and increasing start servers. > > All with no joy. > > 'Applying Changes' to one catalogue puts the Interchange daemon into faulty > state. > > No errors are displayed in IC error.log, catalog error.log nor apache error > logs. > > Just thought I would document this on the list to see if any feedback etc. > Just as an experiment, could you reduce the ChildLife to 60 (1 minute), restart Interchange and reproduce the problem. I suspect that the problem will clear itself within one minute. If that happens then we know that the problem is probably in Interchange itself, rather than than in Interchange::Link. The thinking is that the "apply changes" (or whatever), causes one of the Interchange children to throw its toys out of its pram. The constant refreshes then causes the naughty child to receive a request every now and again, resulting in a moody page. One thing that may debunk my theory is your assertion that the problem still occurs when PreFork is switched off. Can you check that again for me. I'm afraid I don't have an Interchange::Link setup to play with. If someone wants to allow me some time on their machine, and a guaranteed way to reproduce the problem, I'm sure I could track it down reasonably quickly. -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ kevin@cursor.biz _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ From cplists at princeservices.com Tue Dec 12 00:15:07 2006 From: cplists at princeservices.com (Cameron B. Prince) Date: Tue Dec 12 00:15:48 2006 Subject: [ic] Admin New Entry Problem Message-ID: <00bc01c71dac$860603b0$0401a8c0@PSLAPTOP1A> Hey guys, I'm having a problem with the Admin's New Entry function. This is using a default standard catalog on IC v5.4.1 with MySQL. When you edit a table that uses the autonumber counter files as a key, such as products, you can duplicate the problem by clicking New Entry. Leave the pre-filled key intact and click Ok to create the new entry. You will see that you are returned to the flex_editor but instead of it having the next key pre-filled, all the fields are empty. You can click New Entry again to create another item, but you will find that the counter has been incremented twice. I updated the meta for the New Entry menu item and added a ui_return_to=admin/flex_select to cause the Ok to take you back to the edit page rather than having the empty flex_editor but was surprised to find the counter was still incremented twice after creating a new entry. So there are really two issues: 1) Is there a logical reason that I'm not realizing for incrementing the counter twice? If not, how can this be prevented? 2) I understand this will not be ideal in every case, but I'd like the New Entry function to return to the flex_editor to edit the item I just created. Can you tell me if this is possible? Thanks for your help and Merry Christmas to everyone, Cameron From kevin at cursor.biz Tue Dec 12 00:15:51 2006 From: kevin at cursor.biz (Kevin Walsh) Date: Tue Dec 12 00:16:01 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <457DBB5D.7070901@linuxia.de> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612111148g47de91edof2e5eb361d9ed4ea@mail.gmail.com> <457DBB5D.7070901@linuxia.de> Message-ID: <200612120515.52518.kevin@cursor.biz> "Stefan Hornburg (Racke)" wrote: > Grant wrote: > > Are you referring to mod_rewrite? mod_rewrite will only change what > > appears in the address bar right? I need something that allows IC to > > generate folder-free URLs. Can IC be configured to generate and use > > such URLs via the cgi method? > > > Look into the FullURL directive. This allows you to specify your Catalog like that: > > Catalog linuxia /home/racke/linuxia www.linuxia.de www.linuxia.de:443 > You can do that without FullURL too - as long as you only have one website per Interchange instance: Catalog linuxia /home/racke/linuxia / -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ kevin@cursor.biz _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ From kevin at cursor.biz Tue Dec 12 00:36:44 2006 From: kevin at cursor.biz (Kevin Walsh) Date: Tue Dec 12 00:36:52 2006 Subject: [ic] Admin New Entry Problem In-Reply-To: <00bc01c71dac$860603b0$0401a8c0@PSLAPTOP1A> References: <00bc01c71dac$860603b0$0401a8c0@PSLAPTOP1A> Message-ID: <200612120536.45737.kevin@cursor.biz> "Cameron B. Prince" wrote: > I'm having a problem with the Admin's New Entry function. This is using a > default standard catalog on IC v5.4.1 with MySQL. When you edit a table that > uses the autonumber counter files as a key, such as products... [snip] > I have no ideas for you at the moment. I'm just wondering why your products table has an auto-incrementing key. Are you able to reproduce the problem on the online demo? http://demo.icdevgroup.org/ -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ kevin@cursor.biz _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ From cplists at teslauniverse.com Tue Dec 12 00:54:03 2006 From: cplists at teslauniverse.com (Cameron B. Prince) Date: Tue Dec 12 00:54:23 2006 Subject: [ic] Admin New Entry Problem In-Reply-To: <200612120536.45737.kevin@cursor.biz> Message-ID: <00bd01c71db1$edfa76e0$0401a8c0@PSLAPTOP1A> Hi Kevin, > > I'm having a problem with the Admin's New Entry function. This is using > a > > default standard catalog on IC v5.4.1 with MySQL. When you edit a table > that > > uses the autonumber counter files as a key, such as products... [snip] > > > I have no ideas for you at the moment. I'm just wondering why your > products table has an auto-incrementing key. Almost all, if not all, the default tables will be pre-filled with the number from the corresponding products/.tablename.autonumber file when creating a new entry. > Are you able to reproduce the problem on the online demo? > > http://demo.icdevgroup.org/ Yes, give it a try. Thanks, Cameron From cplists at princeservices.com Tue Dec 12 00:55:16 2006 From: cplists at princeservices.com (Cameron B. Prince) Date: Tue Dec 12 00:55:53 2006 Subject: [ic] Admin New Entry Problem In-Reply-To: <200612120536.45737.kevin@cursor.biz> Message-ID: <00be01c71db2$18f0b1c0$0401a8c0@PSLAPTOP1A> Hi Kevin, > > I'm having a problem with the Admin's New Entry function. This is using > a > > default standard catalog on IC v5.4.1 with MySQL. When you edit a table > that > > uses the autonumber counter files as a key, such as products... [snip] > > > I have no ideas for you at the moment. I'm just wondering why your > products table has an auto-incrementing key. Almost all, if not all, the default tables will be pre-filled with the number from the corresponding products/.tablename.autonumber file when creating a new entry. > Are you able to reproduce the problem on the online demo? > > http://demo.icdevgroup.org/ Yes, give it a try. Thanks, Cameron From music at labyrinth.net.au Tue Dec 12 01:33:55 2006 From: music at labyrinth.net.au (Music) Date: Tue Dec 12 01:34:23 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com><183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca><019001c71d94$8cb5d2c0$0200a8c0@IBMKZ894FB2E08> <200612120512.25362.kevin@cursor.biz> Message-ID: <03e501c71db7$84e8abd0$0200a8c0@IBMKZ894FB2E08> ----- Original Message ----- From: "Kevin Walsh" To: Sent: Tuesday, December 12, 2006 4:12 PM Subject: Re: [ic] Re: ALERT: bad pipe signal received for /page.html > "Music" wrote: >> ifdef TRAFFIC =~ /rpc/i >> Message RPC traffic settings. >> PreFork Yes >> StartServers 5 >> MaxServers 0 >> MaxRequestsPerChild 100 >> HouseKeeping 2 >> PIDcheck 120 >> ChildLife 30 minutes >> endif >> >> I also tried disabling ChildLife and PreFork and increasing start >> servers. >> >> All with no joy. >> >> 'Applying Changes' to one catalogue puts the Interchange daemon into >> faulty >> state. >> >> No errors are displayed in IC error.log, catalog error.log nor apache >> error >> logs. >> >> Just thought I would document this on the list to see if any feedback >> etc. >> > Just as an experiment, could you reduce the ChildLife to 60 (1 minute), > restart Interchange and reproduce the problem. I suspect that the problem > will clear itself within one minute. Yes, spot on. The problem pages disappeared after the 60 seconds! > > If that happens then we know that the problem is probably in Interchange > itself, rather than than in Interchange::Link. Not using Interchange:Link on this server - just regular tlink CGI running in Inet Mode. > > The thinking is that the "apply changes" (or whatever), causes one of > the Interchange children to throw its toys out of its pram. The constant > refreshes then causes the naughty child to receive a request every now > and again, resulting in a moody page. > > One thing that may debunk my theory is your assertion that the problem > still occurs when PreFork is switched off. Can you check that again > for me. Testing with Pre-Fork - Oh dear - it appears Pre-For is the problem. I commented out Pre-Fork and ChildLife and the server is running very nicely. I can't reporduce the problem. Now I have to try and remember why I added Pre-Fork and ChildLife; I hope it is not too dramatic a jolt! I have dropped the PERL_SIGNALS=unsafe in restart command now also and all is running well. > > I'm afraid I don't have an Interchange::Link setup to play with. If > someone wants to allow me some time on their machine, and a guaranteed > way to reproduce the problem, I'm sure I could track it down reasonably > quickly. You are more than welcome to test our Apache 2 setup however as I say not using Interchange:Link on this one as it doesn't play with the version of mod_perl (1.99_09-10.ent) available for centos3. >There's never been any demand for mod_interchange on Apache 2.x There is from some of us!! :-) From peter at pajamian.dhs.org Tue Dec 12 02:00:00 2006 From: peter at pajamian.dhs.org (Peter) Date: Tue Dec 12 02:00:28 2006 Subject: [ic] Admin New Entry Problem In-Reply-To: <00bc01c71dac$860603b0$0401a8c0@PSLAPTOP1A> References: <00bc01c71dac$860603b0$0401a8c0@PSLAPTOP1A> Message-ID: <457E5370.30302@pajamian.dhs.org> On 12/11/2006 09:15 PM, Cameron B. Prince wrote: > I'm having a problem with the Admin's New Entry function. This is using a > default standard catalog on IC v5.4.1 with MySQL. When you edit a table that > uses the autonumber counter files as a key, such as products, you can > duplicate the problem by clicking New Entry. Leave the pre-filled key intact > and click Ok to create the new entry. You will see that you are returned to > the flex_editor but instead of it having the next key pre-filled, all the > fields are empty. > > You can click New Entry again to create another item, but you will find that > the counter has been incremented twice. I updated the meta for the New Entry > menu item and added a ui_return_to=admin/flex_select to cause the Ok to take > you back to the edit page rather than having the empty flex_editor but was > surprised to find the counter was still incremented twice after creating a > new entry. I've seen this exact issue and never had the time to look into it. If I get the time I'll be happy to look into it, or if someone either (1) finds the problem themselves and gives me an idea where to look so I don't have to spend all day and a half tracking it down or (2) pays me to do it then I'll be likely to commit a fix for it in the near future, otherwise may not happen for a while (I'm pretty swamped with other things that take priority). That's speaking for me, someone else may fix it. FWIW this problem goes back at least as far as 5.2.0 and is not specific to MySQL (I get the same problem with PostgreSQL). It's not specific to standard, either, I see it in Foundation-based sites. > 1) Is there a logical reason that I'm not realizing for incrementing the > counter twice? If not, how can this be prevented? Probably not, it's just a minor bug. > 2) I understand this will not be ideal in every case, but I'd like the New > Entry function to return to the flex_editor to edit the item I just created. > Can you tell me if this is possible? That sounds like a good idea. It should be possible. Peter From pienihetki at gmail.com Tue Dec 12 07:55:40 2006 From: pienihetki at gmail.com (pienihetki) Date: Tue Dec 12 07:56:07 2006 Subject: [ic] SOAP - login tag issue Message-ID: <457EA6CC.306@gmail.com> Trying to use the code below to prove I can login to my site using SOAP. If I turn on debug in interchange I do see the login reported as successful in the SOAP log. However, the return value from calling the tag is always undefined! I am using IC 4.8.7 and SOAP::Lite 0.68. Any tips on how to debug this? Thanks. use SOAP::Lite; my $cat = 'catalog'; my $id = 'ABCDEFGH:soap'; my $Tag = SOAP::Lite -> uri('http://10.27.29.148/Vend/SOAP') -> proxy("http://10.27.92.148:7780/$cat/$id"); my $login_opt = { username => 'test', password => 'test', function => 'login' }; my $ok = $Tag->userdb( $login_opt ); if (defined($ok)) { print "OK defined\n"; } else { print "Ok not defined\n"; } From ron at endpoint.com Tue Dec 12 13:03:50 2006 From: ron at endpoint.com (Ron Phipps) Date: Tue Dec 12 13:04:32 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <03e501c71db7$84e8abd0$0200a8c0@IBMKZ894FB2E08> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com><183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca><019001c71d94$8cb5d2c0$0200a8c0@IBMKZ894FB2E08> <200612120512.25362.kevin@cursor.biz> <03e501c71db7$84e8abd0$0200a8c0@IBMKZ894FB2E08> Message-ID: <457EEF06.2020607@endpoint.com> Music wrote: > > ----- Original Message ----- From: "Kevin Walsh" > To: > Sent: Tuesday, December 12, 2006 4:12 PM > Subject: Re: [ic] Re: ALERT: bad pipe signal received for /page.html > > >> "Music" wrote: >>> ifdef TRAFFIC =~ /rpc/i >>> Message RPC traffic settings. >>> PreFork Yes >>> StartServers 5 >>> MaxServers 0 >>> MaxRequestsPerChild 100 >>> HouseKeeping 2 >>> PIDcheck 120 >>> ChildLife 30 minutes >>> endif >>> >>> I also tried disabling ChildLife and PreFork and increasing start >>> servers. >>> >>> All with no joy. >>> >>> 'Applying Changes' to one catalogue puts the Interchange daemon into >>> faulty >>> state. >>> >>> No errors are displayed in IC error.log, catalog error.log nor apache >>> error >>> logs. >>> >>> Just thought I would document this on the list to see if any feedback >>> etc. >>> >> Just as an experiment, could you reduce the ChildLife to 60 (1 minute), >> restart Interchange and reproduce the problem. I suspect that the >> problem >> will clear itself within one minute. > > Yes, spot on. The problem pages disappeared after the 60 seconds! > >> >> If that happens then we know that the problem is probably in Interchange >> itself, rather than than in Interchange::Link. > > Not using Interchange:Link on this server - just regular tlink CGI > running in Inet Mode. > >> >> The thinking is that the "apply changes" (or whatever), causes one of >> the Interchange children to throw its toys out of its pram. The constant >> refreshes then causes the naughty child to receive a request every now >> and again, resulting in a moody page. >> >> One thing that may debunk my theory is your assertion that the problem >> still occurs when PreFork is switched off. Can you check that again >> for me. > > Testing with Pre-Fork - Oh dear - it appears Pre-For is the problem. > I commented out Pre-Fork and ChildLife and the server is running very > nicely. > I can't reporduce the problem. Now I have to try and remember why I > added Pre-Fork and ChildLife; I hope it is not too dramatic a jolt! > > I have dropped the PERL_SIGNALS=unsafe in restart command now also and > all is running well. You may have been running Pre-Fork mode to help with issues where sendmail or your gateway charges were not working properly. If that is the case make sure that MaxServers 0 is present in your high and low traffic areas of interchange.cfg, this is the new default. -- Ron Phipps End Point Corporation ron@endpoint.com From MichaelC at glcweb.co.uk Tue Dec 12 18:12:45 2006 From: MichaelC at glcweb.co.uk (Michael Curtis) Date: Tue Dec 12 18:13:11 2006 Subject: [ic] Protx issues Message-ID: Hi all FreeBSD 6.0 IC 5.4 Mysql Protx 1.0.9f Configuring the Standard store for Protx Payment Gateway using Lynn StGeorges module and instructions All went well until I tried to create the new transactions table I copied the new transactions.txt to the correct location I copied the new transactions.mysql to the correct location I deleted .transactions.sql Then restarted Interchange Errors are that generated are: Snip................... > sync2 varchar(128), > protx1 varchar(128), > protx2 varchar(128), > protx3 varchar(128) > ) > - - - [11/December/2006:22:54:50 +0000] - - table transactions index failed: Table 'test_standard.transactions' doesn't exist - - - [11/December/2006:22:54:50 +0000] - - DBI: Post creation query 'CREATE INDEX transactions_order_number ON transactions (order_number)' failed: Table 'test_standard.transactions' doesn't exist - - - [11/December/2006:22:54:50 +0000] - - table 'transactions' failed: list_fields execute on transactions: Table 'test_standard.transactions' doesn't exist at /usr/local/interchange/lib/Vend/Table/DBI.pm line 1752. I have been over all file permissions etc and they are all o.k If I roll back to the standard transaction files the standard transaction table is created and all is o.k I could create the table by creating a .sql and importing that but I do not know if that may create other problems TIA Mike Curtis -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.15.16/582 - Release Date: 11/12/2006 16:32 From emailgrant at gmail.com Tue Dec 12 18:43:29 2006 From: emailgrant at gmail.com (Grant) Date: Tue Dec 12 18:43:45 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> Message-ID: <49bf44f10612121543t348d3112i690232821392fed6@mail.gmail.com> > >> > Hello, I've been plagued by apache2 segfaults ever since I started > >> > using Interchange::Link years ago. The latest Link.pm has ALERT > >> > messages accompanying the segfaults in error_log: > >> > > >> > ALERT: bad pipe signal received for /page.html > >> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > >> > Segmentation fault (11) > >> > > >> > Does anyone have any advice on solving this? I'm using > >> apache-2.0.58 > >> > and mod_perl-2.0.2 in Gentoo Linux. > >> > >> Also, here is the portion of Link.pm that the ALERT seems to come > >> from: > >> > >> # Return this message to the browser when the server is not running. > >> # Log an error log entry if set to notify > >> > >> sub die_page { > >> > >> my $r = shift; > >> my $msg; > >> > >> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; > >> > >> $r->content_type ("text/html"); > >> $r->print (< >> Interrupted > >> > >>

Someone pressed stop...

> >>

> >> We have aborted this request because someone terminated it. > >> Please try again soon. > >> > >> EOF > >> > >> } > >> > >> Please let me know if you have any ideas. > > > > The segfaults are eliminated by commenting out the $r stuff in the > > die_page sub. I still get the ALERTs though. Does anyone have any > > advice on figuring out why I'm having the bad pipe problem? Is there > > an easy way to add extra debugging info to the sub? > > > > Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs > > 50 fold. > > I've been seeing this too, on my Apache 2 and latest Link.pm. I also > had to use PERL_SIGNALS=unsafe and so I get quite a lot of these. > > The visible effect on the browser is that the page or image (which > Link.pm apparently still has some part in delivering) does not load. > I get them myself when browsing and testing my websites, and I have > never stopped loading a page or had any other problems on non-IC > sites I host. > > I was told the problem stems from either the browser and a stop > button or some other network fault. I may go back to Apache 1.3 to > get around this. I've been working on this all day and I think I may have a solution. Incidentally, I want to mention that if I add $! to the Link.pm warn line, I can see that there are two different types of ALERTs in error_log: Broken pipe Inappropriate ioctl for device Also incidentally, hitting F5 repeatedly always prints a few ALERTS in error_log, but the number of ALERTs printed seems to be about 10 times more for an http page than for the same page accessed via https. I checked and tested the settings in my *:80 and *:443 vhosts trying to narrow that down, but I didn't come up with anything. Now, as I mentioned a few posts back, commenting out the html delivery stuff in the die_page sub of Link.pm eliminates the segfaults in error_log but not the ALERTs. Today I enabled the prefork mpm in apache2 and tinkered with the Server/Child settings in interchange.cfg and httpd.conf and that did seem to reduce the ALERTs somewhat. After all of this, I've been browsing around my site and I haven't seen a single image or page fail to load like it used to. The thing is, ALERTs still show up in error_log even for requests I'm sure I created myself AND WERE SERVED SUCCESSFULLY. I hypothesize that the failed requests were because a $SIG{PIPE} was generated for whatever reason (although not because the user clicked the stop button), the html was delivered, it caused a segfault, and the request failed. I should mention though, that if the failing request syndrome is fixed, it could also be from the apache2, httpd.conf, or interchange.cfg modifications mentioned above. I doubt it though. Incidentally, I'd like to mention that the ALERTs can be generated pretty reliably by hitting the browser's stop button in the middle of a request, clicking on the same link again or a different link in the middle of a request (my Mom probably still double clicks links), or just refreshing the page in the middle of a request. If the failed requests do stop at this point, I think the die_page section of Link.pm is doing more harm than good. Is there anything wrong with not handling $SIG{PIPE} at all? - Grant From lyn at zolotek.net Wed Dec 13 06:19:32 2006 From: lyn at zolotek.net (Lyn St George) Date: Wed Dec 13 06:18:13 2006 Subject: [ic] Protx issues In-Reply-To: Message-ID: <20061213111202.F1904830073@mailserver1.zolotek.net> On Tue, 12 Dec 2006 23:12:45 -0000, Michael Curtis wrote: >Hi all > >FreeBSD 6.0 >IC 5.4 >Mysql >Protx 1.0.9f > >Configuring the Standard store for Protx Payment Gateway using Lynn StGeorges module and instructions > >All went well until I tried to create the new transactions table > >I copied the new transactions.txt to the correct location >I copied the new transactions.mysql to the correct location >I deleted .transactions.sql > >Then restarted Interchange > >Errors are that generated are: >Snip................... >> sync2 varchar(128), >> protx1 varchar(128), >> protx2 varchar(128), >> protx3 varchar(128) >> ) You could probably delete all of those unused fields - they were put there to future-proof it for an update to the virtual terminal, but as I've split the terminal out these are now superfluous. Though keep the ones that are listed in log_transaction. >- - - [11/December/2006:22:54:50 +0000] - - table transactions index failed: Table 'test_standard.transactions' doesn't exist >- - - [11/December/2006:22:54:50 +0000] - - DBI: Post creation query 'CREATE INDEX transactions_order_number ON transactions (order_number)' failed: Table 'test_standard.transactions' doesn't exist >- - - [11/December/2006:22:54:50 +0000] - - table 'transactions' failed: list_fields execute on transactions: Table 'test_standard.transactions' doesn't exist at /usr/local/interchange/lib/Vend/Table/DBI.pm line 1752. > >I have been over all file permissions etc and they are all o.k > >If I roll back to the standard transaction files the standard transaction table is created and all is o.k > >I could create the table by creating a .sql and importing that but I do not know if that may create other problems I don't know if BSD is different to Linux, but maybe you need to explicitly specify these fields in dbconf/mysql/transactions.mysql? Have you checked that the files are in Unix line endings? Having them in DOS line-endings can cause similar problems. >TIA > >Mike Curtis > - Lyn From emailgrant at gmail.com Wed Dec 13 10:07:57 2006 From: emailgrant at gmail.com (Grant) Date: Wed Dec 13 10:08:37 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <49bf44f10612121543t348d3112i690232821392fed6@mail.gmail.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <49bf44f10612121543t348d3112i690232821392fed6@mail.gmail.com> Message-ID: <49bf44f10612130707m6b693904waac5228452fb609b@mail.gmail.com> > > >> > Hello, I've been plagued by apache2 segfaults ever since I started > > >> > using Interchange::Link years ago. The latest Link.pm has ALERT > > >> > messages accompanying the segfaults in error_log: > > >> > > > >> > ALERT: bad pipe signal received for /page.html > > >> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > > >> > Segmentation fault (11) > > >> > > > >> > Does anyone have any advice on solving this? I'm using > > >> apache-2.0.58 > > >> > and mod_perl-2.0.2 in Gentoo Linux. > > >> > > >> Also, here is the portion of Link.pm that the ALERT seems to come > > >> from: > > >> > > >> # Return this message to the browser when the server is not running. > > >> # Log an error log entry if set to notify > > >> > > >> sub die_page { > > >> > > >> my $r = shift; > > >> my $msg; > > >> > > >> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; > > >> > > >> $r->content_type ("text/html"); > > >> $r->print (< > >> Interrupted > > >> > > >>

Someone pressed stop...

> > >>

> > >> We have aborted this request because someone terminated it. > > >> Please try again soon. > > >> > > >> EOF > > >> > > >> } > > >> > > >> Please let me know if you have any ideas. > > > > > > The segfaults are eliminated by commenting out the $r stuff in the > > > die_page sub. I still get the ALERTs though. Does anyone have any > > > advice on figuring out why I'm having the bad pipe problem? Is there > > > an easy way to add extra debugging info to the sub? > > > > > > Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs > > > 50 fold. > > > > I've been seeing this too, on my Apache 2 and latest Link.pm. I also > > had to use PERL_SIGNALS=unsafe and so I get quite a lot of these. > > > > The visible effect on the browser is that the page or image (which > > Link.pm apparently still has some part in delivering) does not load. > > I get them myself when browsing and testing my websites, and I have > > never stopped loading a page or had any other problems on non-IC > > sites I host. > > > > I was told the problem stems from either the browser and a stop > > button or some other network fault. I may go back to Apache 1.3 to > > get around this. > > I've been working on this all day and I think I may have a solution. > > Incidentally, I want to mention that if I add $! to the Link.pm warn > line, I can see that there are two different types of ALERTs in > error_log: > > Broken pipe > Inappropriate ioctl for device > > Also incidentally, hitting F5 repeatedly always prints a few ALERTS in > error_log, but the number of ALERTs printed seems to be about 10 times > more for an http page than for the same page accessed via https. I > checked and tested the settings in my *:80 and *:443 vhosts trying to > narrow that down, but I didn't come up with anything. > > Now, as I mentioned a few posts back, commenting out the html delivery > stuff in the die_page sub of Link.pm eliminates the segfaults in > error_log but not the ALERTs. Today I enabled the prefork mpm in > apache2 and tinkered with the Server/Child settings in interchange.cfg > and httpd.conf and that did seem to reduce the ALERTs somewhat. > > After all of this, I've been browsing around my site and I haven't > seen a single image or page fail to load like it used to. The thing > is, ALERTs still show up in error_log even for requests I'm sure I > created myself AND WERE SERVED SUCCESSFULLY. I hypothesize that the > failed requests were because a $SIG{PIPE} was generated for whatever > reason (although not because the user clicked the stop button), the > html was delivered, it caused a segfault, and the request failed. I > should mention though, that if the failing request syndrome is fixed, > it could also be from the apache2, httpd.conf, or interchange.cfg > modifications mentioned above. I doubt it though. > > Incidentally, I'd like to mention that the ALERTs can be generated > pretty reliably by hitting the browser's stop button in the middle of > a request, clicking on the same link again or a different link in the > middle of a request (my Mom probably still double clicks links), or > just refreshing the page in the middle of a request. > > If the failed requests do stop at this point, I think the die_page > section of Link.pm is doing more harm than good. Is there anything > wrong with not handling $SIG{PIPE} at all? > > - Grant I still have yet to see a single failed image or page request in the browser since the above changes, although ALERTs are still generated in error_log. Can anyone verify this? - Grant From emailgrant at gmail.com Wed Dec 13 10:37:17 2006 From: emailgrant at gmail.com (Grant) Date: Wed Dec 13 10:37:31 2006 Subject: [ic] PIDcheck vs. ChildLife Message-ID: <49bf44f10612130737g23f3a423v7f5084851f43cbcb@mail.gmail.com> What is the difference between PIDcheck and ChildLife? It sounds like they do the same thing, unless a PID and child aren't the same thing. Will setting one or both of these directives interrupt a job's execution? - Grant From jon at endpoint.com Wed Dec 13 15:18:54 2006 From: jon at endpoint.com (Jon Jensen) Date: Wed Dec 13 15:19:17 2006 Subject: [ic] PIDcheck vs. ChildLife In-Reply-To: <49bf44f10612130737g23f3a423v7f5084851f43cbcb@mail.gmail.com> References: <49bf44f10612130737g23f3a423v7f5084851f43cbcb@mail.gmail.com> Message-ID: On Wed, 13 Dec 2006, Grant wrote: > What is the difference between PIDcheck and ChildLife? It sounds like > they do the same thing, unless a PID and child aren't the same thing. > > Will setting one or both of these directives interrupt a job's > execution? PIDcheck says that the housekeeping routine should look for out-of-control or dead Interchange child processes and kill them if they've been running more than that many seconds: http://www.icdevgroup.org/docs/confs/PIDcheck.html ChildLife limits how long a child is allowed to live, primarily for PreFork mode persistent children. For example, you may want to say that a child can only live for 10 minutes total, regardless of whether it's met its MaxRequestsPerChild limit yet: http://www.icdevgroup.org/docs/confs/ChildLife.html Most likely you do not need ChildLife, but you should almost always have PIDcheck set to a couple of minutes, so you don't have runaway child processes going longer than that. Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/ From DB at M-and-D.com Wed Dec 13 19:53:02 2006 From: DB at M-and-D.com (DB) Date: Wed Dec 13 19:53:16 2006 Subject: [ic] removing .../cgi-bin/catname/... from URLs Message-ID: <4580A06E.3090408@M-and-D.com> Hi - I have an interchange store where a tag such as [page home]home will when clicked send me to the url http://domain1.com/home.html Now I've set up another machine and another store, but on this new one [page home]home sends me to http://domain2.com/cgi-bin/catname/home.html I can't for the life of me remember how I got the simplified urls to be the default. I have the rewrite rules in place on the new store, but what's the magic I need to have IC use the simpler URLs by default? Can anyone jog my memory? DB From jon at endpoint.com Wed Dec 13 20:11:01 2006 From: jon at endpoint.com (Jon Jensen) Date: Wed Dec 13 20:11:22 2006 Subject: [ic] removing .../cgi-bin/catname/... from URLs In-Reply-To: <4580A06E.3090408@M-and-D.com> References: <4580A06E.3090408@M-and-D.com> Message-ID: On Wed, 13 Dec 2006, DB wrote: > Now I've set up another machine and another store, but on this new one > > [page home]home > > sends me to > > http://domain2.com/cgi-bin/catname/home.html > > I can't for the life of me remember how I got the simplified urls to be > the default. I have the rewrite rules in place on the new store, but > what's the magic I need to have IC use the simpler URLs by default? Can > anyone jog my memory? In your interchange.cfg Catalog definition, the last path prefix alias is the one that will be used for writing URLs. E.g.: Catalog mycat /home/someuser/catalogs/mycat /cgi-bin/mycat / [area home] -> http://domain2.com/home.html Whereas: Catalog mycat /home/someuser/catalogs/mycat / /cgi-bin/mycat [area home] -> http://domain2.com/cgi-bin/mycat/home.html Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/ From emailgrant at gmail.com Wed Dec 13 20:23:55 2006 From: emailgrant at gmail.com (Grant) Date: Wed Dec 13 20:24:17 2006 Subject: [ic] PIDcheck vs. ChildLife In-Reply-To: References: <49bf44f10612130737g23f3a423v7f5084851f43cbcb@mail.gmail.com> Message-ID: <49bf44f10612131723k49f8c073x970594385bc7da37@mail.gmail.com> > > What is the difference between PIDcheck and ChildLife? It sounds like > > they do the same thing, unless a PID and child aren't the same thing. > > > > Will setting one or both of these directives interrupt a job's > > execution? > > PIDcheck says that the housekeeping routine should look for out-of-control > or dead Interchange child processes and kill them if they've been running > more than that many seconds: > > http://www.icdevgroup.org/docs/confs/PIDcheck.html > > ChildLife limits how long a child is allowed to live, primarily for > PreFork mode persistent children. For example, you may want to say that a > child can only live for 10 minutes total, regardless of whether it's met > its MaxRequestsPerChild limit yet: > > http://www.icdevgroup.org/docs/confs/ChildLife.html > > Most likely you do not need ChildLife, but you should almost always have > PIDcheck set to a couple of minutes, so you don't have runaway child > processes going longer than that. > > Jon Thanks Jon. I have jobs that execute for over 2 minutes, but PIDcheck is set to 120. Shouldn't PIDcheck be killing those jobs off at 2 minutes? - Grant From DB at M-and-D.com Wed Dec 13 20:49:32 2006 From: DB at M-and-D.com (DB) Date: Wed Dec 13 20:49:43 2006 Subject: [ic] removing .../cgi-bin/catname/... from URLs References: 4580A06E.3090408@M-and-D.com Message-ID: <4580ADAC.8050603@M-and-D.com> >> Now I've set up another machine and another store, but on this new one >> >> [page home]home >> >> sends me to >> >> http://domain2.com/cgi-bin/catname/home.html >> >> I can't for the life of me remember how I got the simplified urls to be >> the default. I have the rewrite rules in place on the new store, but >> what's the magic I need to have IC use the simpler URLs by default? Can >> anyone jog my memory? > > In your interchange.cfg Catalog definition, the last path prefix alias is > the one that will be used for writing URLs. E.g.: > > Catalog mycat /home/someuser/catalogs/mycat /cgi-bin/mycat / > > [area home] -> http://domain2.com/home.html > > Whereas: > > Catalog mycat /home/someuser/catalogs/mycat / /cgi-bin/mycat > > [area home] -> http://domain2.com/cgi-bin/mycat/home.html > > Jon Hi - I've verified that Catalog definition indeed has the format: Catalog mycat /home/someuser/catalogs/mycat /cgi-bin/mycat / yet IC is still including the .../cgi-bin/mycat/... in the URLs. I restarted IC just for kicks yet still no luck. Can you suggest a way to troubleshoot? I've noticed that the misbehaving store has a CGI_URL defined in the Prefernces tab of the Admin GUI, but the behaving store does not. Could this be the cause? DB From Mutilovic at notyourtypicalrealtor.com Wed Dec 13 23:52:21 2006 From: Mutilovic at notyourtypicalrealtor.com (Huerta Andrey) Date: Wed Dec 13 23:59:59 2006 Subject: [ic] Make it larger! Message-ID: <463501c71f3b$02864ef4$c9edd43e@[62.212.237.201]> Hei buddy You Love Big tits? But Girls love big schlong! If you don't have one - GET ONE! Not only a larger one-eyed monster will make you feel better, it will make you look better! Get a months supply and see the difference! No Pumps! No Surgery! No Exercises! 100% Guaranteed Safe Results Or Your Money Back! Take a look at how it works: http:// -- cmndfjgdfgjwhewdqpqqdc gmjojukljlkljljtjljljtjuflkoktjqksjimgkqkfkfkfjfkfjpkljujqghkhjrkn ' if you ask me you're throwing that money away.' 'It'll come back,' replied Rimsky quietly, ' and then he'll pay dearly for this little picnic.' And pointing at Varenukha's briefcase he said : 'Go on, Ivan Savyelich, don't waste any time.' Varenukha picked up his briefcase and trotted off. He went down to the ground floor, saw a very long queue outside the box office and heard from the cashier that she was expecting to have to put up the ' House Full' notices that evening because they were being positively overwhelmed since the special bill had been posted up. Varenukha told her to be sure not to sell the thirty best seats in the boxes and stalls, then rushed out of the box office, fought off the From peter at pajamian.dhs.org Thu Dec 14 00:13:21 2006 From: peter at pajamian.dhs.org (Peter) Date: Thu Dec 14 00:13:51 2006 Subject: [ic] removing .../cgi-bin/catname/... from URLs In-Reply-To: <4580ADAC.8050603@M-and-D.com> References: 4580A06E.3090408@M-and-D.com <4580ADAC.8050603@M-and-D.com> Message-ID: <4580DD71.6020109@pajamian.dhs.org> On 12/13/2006 05:49 PM, DB wrote: >>> Now I've set up another machine and another store, but on this new one >>> >>> [page home]home >>> >>> sends me to >>> >>> http://domain2.com/cgi-bin/catname/home.html >>> >>> I can't for the life of me remember how I got the simplified urls to be >>> the default. I have the rewrite rules in place on the new store, but >>> what's the magic I need to have IC use the simpler URLs by default? Can >>> anyone jog my memory? >> In your interchange.cfg Catalog definition, the last path prefix alias is >> the one that will be used for writing URLs. E.g.: >> >> Catalog mycat /home/someuser/catalogs/mycat /cgi-bin/mycat / >> >> [area home] -> http://domain2.com/home.html >> >> Whereas: >> >> Catalog mycat /home/someuser/catalogs/mycat / /cgi-bin/mycat >> >> [area home] -> http://domain2.com/cgi-bin/mycat/home.html >> >> Jon > > > Hi - I've verified that Catalog definition indeed has the format: > > Catalog mycat /home/someuser/catalogs/mycat /cgi-bin/mycat / > > yet IC is still including the .../cgi-bin/mycat/... in the URLs. I > restarted IC just for kicks yet still no luck. Can you suggest a way to > troubleshoot? > > I've noticed that the misbehaving store has a CGI_URL defined in the > Prefernces tab of the Admin GUI, but the behaving store does not. Could > this be the cause? Indirectly, yes. Look for VendURL and SecureURL in catalog.cfg. Also see: Peter From jon at endpoint.com Thu Dec 14 00:54:06 2006 From: jon at endpoint.com (Jon Jensen) Date: Thu Dec 14 00:54:38 2006 Subject: [ic] removing .../cgi-bin/catname/... from URLs In-Reply-To: <4580DD71.6020109@pajamian.dhs.org> References: 4580A06E.3090408@M-and-D.com <4580ADAC.8050603@M-and-D.com> <4580DD71.6020109@pajamian.dhs.org> Message-ID: On Wed, 13 Dec 2006, Peter wrote: >> I've verified that Catalog definition indeed has the format: >> >> Catalog mycat /home/someuser/catalogs/mycat /cgi-bin/mycat / >> >> yet IC is still including the .../cgi-bin/mycat/... in the URLs. I >> restarted IC just for kicks yet still no luck. Can you suggest a way to >> troubleshoot? >> >> I've noticed that the misbehaving store has a CGI_URL defined in the >> Prefernces tab of the Admin GUI, but the behaving store does not. Could >> this be the cause? > > Indirectly, yes. Look for VendURL and SecureURL in catalog.cfg. DB, I need to explain my earlier reply better. What Peter says about VendURL is in general correct. However, when you have any URL prefix aliases defined for the catalog, if a request comes in through one of them, that will override VendURL for all future URLs written by [area] etc. The manual explains this: http://www.icdevgroup.org/docs/confs/Catalog.html So my example only makes sense if taken in the context of an Apache setup for making pretty catalog URLs, such as this: ScriptAlias /cgi-bin/ /path/to/your/cgi-bin/dir/ RewriteEngine on RewriteRule ^/store/(.*) /cgi-bin/standard/$1 [PT,L] Then you'd set up interchange.cfg like this: Catalog standard /path/to/catalogs/standard /cgi-bin/standard /store Thus, users would go to this URL to enter the site: http://your.domain/store/ But Interchange would see you coming in through: http://your.domain/cgi-bin/standard/ because of the Apache RewriteRule. The first URL prefix is considered the "main" one, not an alias, and does not take over URL generation as an alias does, so the Catalog definition above doesn't lead to aliases URL generation; it just stays normal. But in the end it turns out that the /store alias I showed in my example isn't even necessary; Interchange never uses it or needs it to find the catalog, because it's seeing /cgi-bin/standard as the path prefix after URL rewriting. So, to sum up, I think your problem may be fixed with this Catalog directive: Catalog mycat /home/someuser/catalogs/mycat / assuming you have in Apache something like: RewriteRule ^/(.*) /cgi-bin/mycat/$1 [PT,L] Though to take over the whole URL space like that, you'd need to have some previous RewriteRules that would make exceptions to statically serve images, CSS, JavaScript, robots.txt, favicon.ico, etc. directly from Apache, not passing them to Interchange. You'll get a lot more wasted requests passed through to Interchange by hostile bots, etc., which wouldn't be if you use a prefix like /store/ or /ic/ or /app/ or something like that. You can still make the home page use the root URL http://your.domain/ with another RewriteRule like: RewriteRule ^/(index.html?)?$ /cgi-bin/standard/index [PT,L] HTH, Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/ From frank at goldissue.com Thu Dec 14 01:39:25 2006 From: frank at goldissue.com (Frank Reitzenstein) Date: Thu Dec 14 01:39:42 2006 Subject: [ic] removing .../cgi-bin/catname/... from URLs In-Reply-To: References: 4580A06E.3090408@M-and-D.com <4580ADAC.8050603@M-and-D.com> <4580DD71.6020109@pajamian.dhs.org> Message-ID: <4580F19D.8070906@goldissue.com> Jon Jensen wrote: > On Wed, 13 Dec 2006, Peter wrote: > >>> I've verified that Catalog definition indeed has the format: >>> >>> Catalog mycat /home/someuser/catalogs/mycat /cgi-bin/mycat / >>> >>> yet IC is still including the .../cgi-bin/mycat/... in the URLs. I >>> restarted IC just for kicks yet still no luck. Can you suggest a way to >>> troubleshoot? >>> >>> I've noticed that the misbehaving store has a CGI_URL defined in the >>> Prefernces tab of the Admin GUI, but the behaving store does not. Could >>> this be the cause? >> >> >> Indirectly, yes. Look for VendURL and SecureURL in catalog.cfg. > > > DB, > > I need to explain my earlier reply better. What Peter says about > VendURL is in general correct. However, when you have any URL prefix > aliases defined for the catalog, if a request comes in through one of > them, that will override VendURL for all future URLs written by [area] > etc. The manual explains this: > > http://www.icdevgroup.org/docs/confs/Catalog.html > > So my example only makes sense if taken in the context of an Apache > setup for making pretty catalog URLs, such as this: > > ScriptAlias /cgi-bin/ /path/to/your/cgi-bin/dir/ > RewriteEngine on > RewriteRule ^/store/(.*) /cgi-bin/standard/$1 [PT,L] > > Then you'd set up interchange.cfg like this: > > Catalog standard /path/to/catalogs/standard /cgi-bin/standard > /store > > Thus, users would go to this URL to enter the site: > > http://your.domain/store/ > > But Interchange would see you coming in through: > > http://your.domain/cgi-bin/standard/ > > because of the Apache RewriteRule. > > The first URL prefix is considered the "main" one, not an alias, and > does not take over URL generation as an alias does, so the Catalog > definition above doesn't lead to aliases URL generation; it just stays > normal. > > But in the end it turns out that the /store alias I showed in my > example isn't even necessary; Interchange never uses it or needs it to > find the catalog, because it's seeing /cgi-bin/standard as the path > prefix after URL rewriting. > > So, to sum up, I think your problem may be fixed with this Catalog > directive: > > Catalog mycat /home/someuser/catalogs/mycat / > > assuming you have in Apache something like: > > RewriteRule ^/(.*) /cgi-bin/mycat/$1 [PT,L] > > Though to take over the whole URL space like that, you'd need to have > some previous RewriteRules that would make exceptions to statically > serve images, CSS, JavaScript, robots.txt, favicon.ico, etc. directly > from Apache, not passing them to Interchange. > > You'll get a lot more wasted requests passed through to Interchange by > hostile bots, etc., which wouldn't be if you use a prefix like /store/ > or /ic/ or /app/ or something like that. You can still make the home > page use the root URL http://your.domain/ with another RewriteRule like: > > RewriteRule ^/(index.html?)?$ /cgi-bin/standard/index [PT,L] > > HTH, > Jon > Hello Peter, Below is an apache virtual host which does what you are seeking. To get a seamless catalog at "/" all we would need to do is change products/variable.txt as follows: CGI_URL /shop/example (ie /cgi-bin/example) to CGI_URL / Unfortunately we can't. We still need to check out at https://www.goldissue.com I tried using ports 444, 445, 446 for additional secure servers, but it worked most of the time, then people would ring in and say that they couldn't check out. Our server is on a very fast adsl connection, but the isp is too inflexibble to supply the class C subnets we would like. In other words urls like https://www.theyoungjerk.com:444 caused us some grief. So what happens instead is that the visitor arrives at http://www.example.com ok, but when he clicks home on the nav bar he goes to www.example.com/shop/example Here is a live example. You will need to replace /shop/example with /cgi-bin/example: DocumentRoot "/var/www/html/example" ServerName www.example.com SSLProxyEngine on RewriteEngine on RewriteRule ^\/Brahmi\/$ "http://www.example.com/PW-012.html" [P,L] RewriteRule ^\/Acne\/$ "http://www.example.com/ET-036.html" [P,L] RewriteRule ^\/Ginkgo\/$ "http://www.example.com/NA-010" [P,L] RewriteRule ^\/Tryptophan\/$ "http://www.example.com/MM-001" [P,L] RewriteRule ^\/Cod-Liver-Oil\/$ "http://www.example.com/TL-168" [P,L] RewriteRule ^\/Tea-Tree-Oil\/$ "http://www.example.com/DE-007" [P,L] RewriteRule ^\/Health\sConcerns\/(.*)$ "http://www.example.com/Health_Concerns/$1" [L] RewriteRule ^\/Health_Concerns\/$ "http://www.example.com/shop/example/scan/st=db/fi=cat/sp=imagecat/co=yes/sf=sel/ml=100/se=5/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/Weight\sLoss\/(.*)$ "http://www.example.com/Weight_Loss/$1" [L] RewriteRule ^\/Weight_Loss\/$ "http://www.example.com/shop/example/scan/st=db/fi=cat/sp=imagecat/co=yes/sf=sel/ml=100/se=13/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/Amino\sAcids\/(.*)$ "http://www.example.com/Amino_Acids/$1" [L] RewriteRule ^\/Amino_Acids\/$ "http://www.example.com/shop/example/scan/st=db/fi=cat/sp=imagecat/co=yes/sf=sel/ml=100/se=1/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/Fitness\sAccessories\/(.*)$ "http://www.example.com/Fitness_Accessories/$1" [L] RewriteRule ^\/Fitness_Accessories\/$ "http://www.example.com/shop/example/scan/st=db/fi=cat/sp=imagecat/co=yes/sf=sel/ml=100/se=4/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/Shakes\s&\sDrinks\/(.*)$ "http://www.example.com/Shakes_&_Drinks/$1" [L] RewriteRule ^\/Shakes_&_Drinks\/$ "http://www.example.com/shop/example/scan/st=db/fi=cat/sp=imagecat/co=yes/sf=sel/ml=100/se=10/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/Herbs\s&\sAlternative\sBlends\/(.*)$ "http://www.example.com/Herbs_&_Alternative_Blends/$1" [L] RewriteRule ^\/Herbs_&_Alternative_Blends\/$ "http://www.example.com/shop/example/scan/st=db/fi=cat/sp=imagecat/co=yes/sf=sel/ml=100/se=7/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/EFAs\sand\sDietary\sOils\/(.*)$ "http://www.example.com/EFAs_and_Dietary_Oils/$1" [L] RewriteRule ^\/EFAs_and_Dietary_Oils\/$ "http://www.example.com/shop/example/scan/st=db/fi=cat/sp=imagecat/co=yes/sf=sel/ml=100/se=3/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/Sports\sNutrition\/(.*)$ "http://www.example.com/Sports_Nutrition/$1" [L] RewriteRule ^\/Sports_Nutrition\/$ "http://www.example.com/shop/example/scan/st=db/fi=cat/sp=imagecat/co=yes/sf=sel/ml=100/se=11/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/Vitamins\s&\sMinerals\/(.*)$ "http://www.example.com/Vitamins_&_Minerals/$1" [L] RewriteRule ^\/Vitamins_&_Minerals\/$ "http://www.example.com/shop/example/scan/st=db/fi=cat/sp=imagecat/co=yes/sf=sel/ml=100/se=12/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/Protein\/$ "http://www.example.com/shop/example/scan/st=db/fi=cat/sp=imagecat/co=yes/sf=sel/ml=100/se=9/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/Creatine\/$ "http://www.example.com/shop/example/scan/st=db/fi=cat/sp=imagecat/co=yes/sf=sel/ml=100/se=2/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/Nutrition\sBars\/(.*)$ "http://www.example.com/Nutrition_Bars/$1" [L] RewriteRule ^\/Nutrition_Bars\/$ "http://www.example.com/shop/example/scan/st=db/fi=cat/sp=imagecat/co=yes/sf=sel/ml=100/se=8/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/([A-Z].*)\/(.*)\s(.*)\s(.*)\s(.*)\/$ "http://www.example.com/$1/$2_$3_$4_$5/" [L] RewriteRule ^\/[A-Z].*\/([A-Z].*)_(.*)_(.*)_(.*)\/ "http://www.example.com/scan/st=db/fi=products/ml=100/sp=results/co=yes/sf=cat/se=$1 $2 $3 $4/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/([A-Z].*)\/(.*)\s(.*)\s(.*)\/$ "http://www.example.com/$1/$2_$3_$4/" [L] RewriteRule ^\/[A-Z].*\/([A-Z].*)_(.*)_(.*)\/ "http://www.example.com/scan/st=db/fi=products/ml=100/sp=results/co=yes/sf=cat/se=$1 $2 $3/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/([A-Z].*)\/(.*)\s(.*)\/$ "http://www.example.com/$1/$2_$3/" [L] RewriteRule ^\/[A-Z].*\/([A-Z].*)_(.*)\/ "http://www.example.com/scan/st=db/fi=products/ml=100/sp=results/co=yes/sf=cat/se=$1 $2/va=banner_image=/va=banner_text=.html" [P,L] RewriteRule ^\/[A-Z].*\/([A-Z].*)\/ "http://www.example.com/scan/st=db/fi=products/ml=100/sp=results/co=yes/sf=cat/se=$1/va=banner_image=/va=banner_text=.html" [P,L] ######################################################## RewriteRule ^$ /shop/example/index.html [PT,L] RewriteRule ^/$ /shop/example/index.html [PT,L] RewriteRule ^/index\.html$ /shop/example/index.htm [PT,L] RewriteRule ^/shop/example/.* - [PT,L] RewriteRule ^/.*images/.* - [PT,L] RewriteRule ^/(.*) /shop/example/$1 [PT,L] RewriteRule ^/admin$ /shop/example/admin/index.html [PT,L] RewriteRule ^/admin/$ /shop/example/admin/index.html [PT,L] RewriteRule ^/admin/index\.html$ /shop/example/admin/index.htm [PT,L] RewriteRule ^/shop/example/admin/.* - [PT,L] RewriteRule ^/admin/(.*) /shop/example/admin/$1 [PT,L] CustomLog /etc/httpd/logs/www.example.com/access_log combined Redirect permanent /shop/example/arginine.html "http://www.example.com/l_arginine_powder" Redirect permanent /shop/example/arginine "http://www.example.com/l_arginine_powder" Regards, Frank. From racke at linuxia.de Thu Dec 14 05:22:24 2006 From: racke at linuxia.de (Stefan Hornburg (Racke)) Date: Thu Dec 14 05:23:03 2006 Subject: [ic] Admin New Entry Problem In-Reply-To: <457E5370.30302@pajamian.dhs.org> References: <00bc01c71dac$860603b0$0401a8c0@PSLAPTOP1A> <457E5370.30302@pajamian.dhs.org> Message-ID: <458125E0.6070202@linuxia.de> Peter wrote: > On 12/11/2006 09:15 PM, Cameron B. Prince wrote: >> I'm having a problem with the Admin's New Entry function. This is using a >> default standard catalog on IC v5.4.1 with MySQL. When you edit a table that >> uses the autonumber counter files as a key, such as products, you can >> duplicate the problem by clicking New Entry. Leave the pre-filled key intact >> and click Ok to create the new entry. You will see that you are returned to >> the flex_editor but instead of it having the next key pre-filled, all the >> fields are empty. >> >> You can click New Entry again to create another item, but you will find that >> the counter has been incremented twice. I updated the meta for the New Entry >> menu item and added a ui_return_to=admin/flex_select to cause the Ok to take >> you back to the edit page rather than having the empty flex_editor but was >> surprised to find the counter was still incremented twice after creating a >> new entry. > > I've seen this exact issue and never had the time to look into it. If I > get the time I'll be happy to look into it, or if someone either (1) > finds the problem themselves and gives me an idea where to look so I > don't have to spend all day and a half tracking it down or (2) pays me > to do it then I'll be likely to commit a fix for it in the near future, > otherwise may not happen for a while (I'm pretty swamped with other > things that take priority). That's speaking for me, someone else may > fix it. > > FWIW this problem goes back at least as far as 5.2.0 and is not specific > to MySQL (I get the same problem with PostgreSQL). It's not specific to > standard, either, I see it in Foundation-based sites. > >> 1) Is there a logical reason that I'm not realizing for incrementing the >> counter twice? If not, how can this be prevented? > > Probably not, it's just a minor bug. The counter is really incremented twice: 1. flex_editor unless ($db->config('AUTO_SEQUENCE')) { $db->config('AUTO_NUMBER', '000001') unless $db->config('AUTO_NUMBER'); $CGI->{item_id} = $db->autonumber(); } 2. [table-editor] if($opt->{ui_new_item} and ! $opt->{notable}) { if( ! $db->config('_Auto_number') and ! $db->config('AUTO_SEQUENCE')) { $db->config('AUTO_NUMBER', '000001'); $key = $db->autonumber($key); } else { $key = ''; $opt->{mv_data_auto_number} = 1; $key_message = errmsg('(new key will be assigned if left blank)'); } } The code looks slightly different, so I wonder whether we can just drop the code in flex_editor without regressions. It appears superfluous to me. Bye Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team From emailgrant at gmail.com Thu Dec 14 11:17:58 2006 From: emailgrant at gmail.com (Grant) Date: Thu Dec 14 11:18:18 2006 Subject: [ic] Bad HouseKeeping Message-ID: <49bf44f10612140817v6c6db45cn657eb07fb81f5c56@mail.gmail.com> I'm using IC 5.2 and ps -ef shows three interchange processes that started some time yesterday and two that started an hour and a half ago which is the last time I restarted IC. Here are my interchange.cfg settings: PreFork Yes StartServers 5 MaxServers 50 MaxRequestsPerChild 100 ChildLife 600 HouseKeeping 2 PIDcheck 120 Shouldn't housekeeping clean up the above-mentioned five processes? There are currently no jobs running. Should each IC process be using about 30MB? - Grant From barb at emeraldcitymusic.com Thu Dec 14 13:54:43 2006 From: barb at emeraldcitymusic.com (Barb Sorensen) Date: Thu Dec 14 13:53:38 2006 Subject: [ic] Need help with install please. Newbie here... Message-ID: HI, I am not a programmer or a geek guru but just hack my way through things 85% of the time I know what I"m doing but this telnet stuff is new to me..... I downloaded, unzipped and uploaded the interchange package to my server. I am on 1and1.com and have a Home account (no ssh and no telnet apparently as far as I can tell - I did not know I needed it to install interchange and I just switched form my old host to 1and1.com and am beginning to think I made am istake and hoping to salvage it somehow ..) When I opened the read me file it says to run Makefile.PL.. Which I did and it says it's installing Interchange but then the next instructions say to run "make" and some other commands but that is where I get stuck.. I know .. I haven't even left the starting gate and I"m excited about getting there already LOL! When I run "make" I get an error 404: not found message Also.. The pages look like text pages not a pretty front. Is that supposed to be that way? Just wanting to be sure I am doing this correctly.. So then somewhere I stumbled across something that says I need telnet to install it.. Is there a way to install without telnet? My "home" package with 1and1.com says that instead of using tenet they use ssh. And if I want to use the SSH I have to upgrade to the next bigger "business" package which is what I am trying to avoid doing as well. Has anyone here on this list installed in a Home package on 1and1.com or know how to go about this? Thanks Regards Barb http://www.barbsorensen.com From racke at linuxia.de Thu Dec 14 14:56:55 2006 From: racke at linuxia.de (Stefan Hornburg (Racke)) Date: Thu Dec 14 14:57:40 2006 Subject: [ic] Need help with install please. Newbie here... In-Reply-To: References: Message-ID: <4581AC87.4090402@linuxia.de> Barb Sorensen wrote: > HI, > I am not a programmer or a geek guru but just hack my way through things > 85% of the time I know what I"m doing but this telnet stuff is new to > me..... > > I downloaded, unzipped and uploaded the interchange package to my server. > I am on 1and1.com and have a Home account (no ssh and no telnet apparently > as far as I can tell - I did not know I needed it to install interchange and > I just switched form my old host to 1and1.com and am beginning to think I > made am istake and hoping to salvage it somehow ..) First of all check with your ISP if you allowed to run a daemon (server program) on your account. Second, you really need a shell access to the server. > > When I opened the read me file it says to run Makefile.PL.. Which I did and > it says it's installing Interchange > > but then the next instructions say to run "make" and some other commands > but that is where I get stuck.. > I know .. I haven't even left the starting gate and I"m excited about > getting there already LOL! > > When I run "make" I get an error 404: not found message You need to run these commands on as shell commands. Bye Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team From barb at emeraldcitymusic.com Fri Dec 15 00:57:13 2006 From: barb at emeraldcitymusic.com (Barb Sorensen) Date: Fri Dec 15 00:55:53 2006 Subject: [ic] FW: Need help with install please. Newbie here... In-Reply-To: Message-ID: HI Stefan. Thanks OK I broke down and upgraded my server to "business" so I could have the ssh access.. Firs thing I did was go to the ftp address. it asked me for a password and I entered it and then it gave me a list of all the files in the directory for interchange. :) Looks Like I have access then I clicked on the configure file since the README instructions day to do that first then I clicked on Makefile.pl as per the instructions after the ./configure file ran it's course. and it again asked me for user and password and then it too ran it's course, installed to /interchange and said "done" then I wasn't sure where to go but I remembered that after I ran the configure file that the instructions at that point said to also run Makefuile/.pl ( which I did ) and then run "make" and then run "make test" and then run " make install" so I type in /interchange/make and it began to churn away .... And it's been going for a little while.. Should it take this long, or is it waiting for another command? I ddid not see a "make" file in the folder.. And I"m not that familiar with ssh commands and perl... So not sure if this is right or did Miss something?: Where to now? It's still on "make".. Toiling away ... Thanks Regards Barb ------ Forwarded Message From: Barb Sorensen Date: Thu, 14 Dec 2006 12:54:43 -0600 To: Subject: Need help with install please. Newbie here... HI, I am not a programmer or a geek guru but just hack my way through things 85% of the time I know what I"m doing but this telnet stuff is new to me..... I downloaded, unzipped and uploaded the interchange package to my server. I am on 1and1.com and have a Home account (no ssh and no telnet apparently as far as I can tell - I did not know I needed it to install interchange and I just switched form my old host to 1and1.com and am beginning to think I made am istake and hoping to salvage it somehow ..) When I opened the read me file it says to run Makefile.PL.. Which I did and it says it's installing Interchange but then the next instructions say to run "make" and some other commands but that is where I get stuck.. I know .. I haven't even left the starting gate and I"m excited about getting there already LOL! When I run "make" I get an error 404: not found message Also.. The pages look like text pages not a pretty front. Is that supposed to be that way? Just wanting to be sure I am doing this correctly.. So then somewhere I stumbled across something that says I need telnet to install it.. Is there a way to install without telnet? My "home" package with 1and1.com says that instead of using tenet they use ssh. And if I want to use the SSH I have to upgrade to the next bigger "business" package which is what I am trying to avoid doing as well. Has anyone here on this list installed in a Home package on 1and1.com or know how to go about this? Thanks Regards Barb http://www.barbsorensen.com ------ End of Forwarded Message From peter at pajamian.dhs.org Fri Dec 15 04:27:38 2006 From: peter at pajamian.dhs.org (Peter) Date: Fri Dec 15 04:28:13 2006 Subject: [ic] FW: Need help with install please. Newbie here... In-Reply-To: References: Message-ID: <45826A8A.6040200@pajamian.dhs.org> On 12/14/2006 09:57 PM, Barb Sorensen wrote: > HI Stefan. Thanks > OK I broke down and upgraded my server to "business" so I could have the > ssh access.. > Firs thing I did was go to the ftp address. > it asked me for a password and I entered it and then it gave me a list of > all the files in the directory for interchange. :) > Looks Like I have access > then I clicked on the configure file since the README instructions day to > do that first > then I clicked on Makefile.pl as per the instructions after the > ./configure file ran it's course. > and it again asked me for user and password and then it too ran it's course, > installed to /interchange and said "done" > > then I wasn't sure where to go but I remembered that after I ran the > configure file that the instructions at that point said to also run > Makefuile/.pl ( which I did ) and then run "make" and then run "make test" > and then run " make install" > > so I type in /interchange/make and it began to churn away .... And it's > been going for a little while.. Should it take this long, or is it waiting > for another command? I ddid not see a "make" file in the folder.. And I"m > not that familiar with ssh commands and perl... So not sure if this is right > or did Miss something?: > Where to now? It's still on "make".. Toiling away ... Hi Barb, I have recently written up a general overview about how to install programs in Linux (and other Unixes) from source for a forum that I frequent, it may help you to read through it. You can find it at . You may want to go back to the beginning of the thread at and read the entire thread. Installing and running Interchange generally requires at least a basic knowledge of Unix command line shell concepts. There are lots of consultants who will gladly help you out for a modest fee if you find that you can't handle it yourself. Also, please don't top post per the rules and guidelines of this mailing list, see for more info. Regards, Peter From emailgrant at gmail.com Fri Dec 15 11:02:28 2006 From: emailgrant at gmail.com (Grant) Date: Fri Dec 15 11:03:05 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <49bf44f10612130707m6b693904waac5228452fb609b@mail.gmail.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <49bf44f10612121543t348d3112i690232821392fed6@mail.gmail.com> <49bf44f10612130707m6b693904waac5228452fb609b@mail.gmail.com> Message-ID: <49bf44f10612150802s449fa7c3y7fbca8dbd00abc50@mail.gmail.com> > > > >> > Hello, I've been plagued by apache2 segfaults ever since I started > > > >> > using Interchange::Link years ago. The latest Link.pm has ALERT > > > >> > messages accompanying the segfaults in error_log: > > > >> > > > > >> > ALERT: bad pipe signal received for /page.html > > > >> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > > > >> > Segmentation fault (11) > > > >> > > > > >> > Does anyone have any advice on solving this? I'm using > > > >> apache-2.0.58 > > > >> > and mod_perl-2.0.2 in Gentoo Linux. > > > >> > > > >> Also, here is the portion of Link.pm that the ALERT seems to come > > > >> from: > > > >> > > > >> # Return this message to the browser when the server is not running. > > > >> # Log an error log entry if set to notify > > > >> > > > >> sub die_page { > > > >> > > > >> my $r = shift; > > > >> my $msg; > > > >> > > > >> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; > > > >> > > > >> $r->content_type ("text/html"); > > > >> $r->print (< > > >> Interrupted > > > >> > > > >>

Someone pressed stop...

> > > >>

> > > >> We have aborted this request because someone terminated it. > > > >> Please try again soon. > > > >> > > > >> EOF > > > >> > > > >> } > > > >> > > > >> Please let me know if you have any ideas. > > > > > > > > The segfaults are eliminated by commenting out the $r stuff in the > > > > die_page sub. I still get the ALERTs though. Does anyone have any > > > > advice on figuring out why I'm having the bad pipe problem? Is there > > > > an easy way to add extra debugging info to the sub? > > > > > > > > Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs > > > > 50 fold. > > > > > > I've been seeing this too, on my Apache 2 and latest Link.pm. I also > > > had to use PERL_SIGNALS=unsafe and so I get quite a lot of these. > > > > > > The visible effect on the browser is that the page or image (which > > > Link.pm apparently still has some part in delivering) does not load. > > > I get them myself when browsing and testing my websites, and I have > > > never stopped loading a page or had any other problems on non-IC > > > sites I host. > > > > > > I was told the problem stems from either the browser and a stop > > > button or some other network fault. I may go back to Apache 1.3 to > > > get around this. > > > > I've been working on this all day and I think I may have a solution. > > > > Incidentally, I want to mention that if I add $! to the Link.pm warn > > line, I can see that there are two different types of ALERTs in > > error_log: > > > > Broken pipe > > Inappropriate ioctl for device > > > > Also incidentally, hitting F5 repeatedly always prints a few ALERTS in > > error_log, but the number of ALERTs printed seems to be about 10 times > > more for an http page than for the same page accessed via https. I > > checked and tested the settings in my *:80 and *:443 vhosts trying to > > narrow that down, but I didn't come up with anything. > > > > Now, as I mentioned a few posts back, commenting out the html delivery > > stuff in the die_page sub of Link.pm eliminates the segfaults in > > error_log but not the ALERTs. Today I enabled the prefork mpm in > > apache2 and tinkered with the Server/Child settings in interchange.cfg > > and httpd.conf and that did seem to reduce the ALERTs somewhat. > > > > After all of this, I've been browsing around my site and I haven't > > seen a single image or page fail to load like it used to. The thing > > is, ALERTs still show up in error_log even for requests I'm sure I > > created myself AND WERE SERVED SUCCESSFULLY. I hypothesize that the > > failed requests were because a $SIG{PIPE} was generated for whatever > > reason (although not because the user clicked the stop button), the > > html was delivered, it caused a segfault, and the request failed. I > > should mention though, that if the failing request syndrome is fixed, > > it could also be from the apache2, httpd.conf, or interchange.cfg > > modifications mentioned above. I doubt it though. > > > > Incidentally, I'd like to mention that the ALERTs can be generated > > pretty reliably by hitting the browser's stop button in the middle of > > a request, clicking on the same link again or a different link in the > > middle of a request (my Mom probably still double clicks links), or > > just refreshing the page in the middle of a request. > > > > If the failed requests do stop at this point, I think the die_page > > section of Link.pm is doing more harm than good. Is there anything > > wrong with not handling $SIG{PIPE} at all? > > > > - Grant > > I still have yet to see a single failed image or page request in the > browser since the above changes, although ALERTs are still generated > in error_log. Can anyone verify this? > > - Grant I'm sure this is fixed. I propose the die_page call and sub are removed from Link.pm in CVS. - Grant From josh at myprivacy.ca Fri Dec 15 12:07:15 2006 From: josh at myprivacy.ca (Josh Lavin) Date: Fri Dec 15 12:08:05 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <49bf44f10612121543t348d3112i690232821392fed6@mail.gmail.com> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <49bf44f10612121543t348d3112i690232821392fed6@mail.gmail.com> Message-ID: <21375B2F-06D8-4614-98D5-1B28FCB26E47@myprivacy.ca> On Dec 12, 2006, at 5:43 PM, Grant wrote: >> >> > Hello, I've been plagued by apache2 segfaults ever since I >> started >> >> > using Interchange::Link years ago. The latest Link.pm has ALERT >> >> > messages accompanying the segfaults in error_log: >> >> > >> >> > ALERT: bad pipe signal received for /page.html >> >> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal >> >> > Segmentation fault (11) >> >> > >> >> > Does anyone have any advice on solving this? I'm using >> >> apache-2.0.58 >> >> > and mod_perl-2.0.2 in Gentoo Linux. >> >> >> >> Also, here is the portion of Link.pm that the ALERT seems to come >> >> from: >> >> >> >> # Return this message to the browser when the server is not >> running. >> >> # Log an error log entry if set to notify >> >> >> >> sub die_page { >> >> >> >> my $r = shift; >> >> my $msg; >> >> >> >> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME} >> \n"; >> >> >> >> $r->content_type ("text/html"); >> >> $r->print (<> >> Interrupted >> >> >> >>

Someone pressed stop...

>> >>

>> >> We have aborted this request because someone terminated it. >> >> Please try again soon. >> >> >> >> EOF >> >> >> >> } >> >> >> >> Please let me know if you have any ideas. >> > >> > The segfaults are eliminated by commenting out the $r stuff in the >> > die_page sub. I still get the ALERTs though. Does anyone have any >> > advice on figuring out why I'm having the bad pipe problem? Is >> there >> > an easy way to add extra debugging info to the sub? >> > >> > Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs >> > 50 fold. >> >> I've been seeing this too, on my Apache 2 and latest Link.pm. I also >> had to use PERL_SIGNALS=unsafe and so I get quite a lot of these. >> >> The visible effect on the browser is that the page or image (which >> Link.pm apparently still has some part in delivering) does not load. >> I get them myself when browsing and testing my websites, and I have >> never stopped loading a page or had any other problems on non-IC >> sites I host. >> >> I was told the problem stems from either the browser and a stop >> button or some other network fault. I may go back to Apache 1.3 to >> get around this. > > I've been working on this all day and I think I may have a solution. > > Incidentally, I want to mention that if I add $! to the Link.pm warn > line, I can see that there are two different types of ALERTs in > error_log: > > Broken pipe > Inappropriate ioctl for device > > Also incidentally, hitting F5 repeatedly always prints a few ALERTS in > error_log, but the number of ALERTs printed seems to be about 10 times > more for an http page than for the same page accessed via https. I > checked and tested the settings in my *:80 and *:443 vhosts trying to > narrow that down, but I didn't come up with anything. > > Now, as I mentioned a few posts back, commenting out the html delivery > stuff in the die_page sub of Link.pm eliminates the segfaults in > error_log but not the ALERTs. Today I enabled the prefork mpm in > apache2 and tinkered with the Server/Child settings in interchange.cfg > and httpd.conf and that did seem to reduce the ALERTs somewhat. > > After all of this, I've been browsing around my site and I haven't > seen a single image or page fail to load like it used to. The thing > is, ALERTs still show up in error_log even for requests I'm sure I > created myself AND WERE SERVED SUCCESSFULLY. I hypothesize that the > failed requests were because a $SIG{PIPE} was generated for whatever > reason (although not because the user clicked the stop button), the > html was delivered, it caused a segfault, and the request failed. I > should mention though, that if the failing request syndrome is fixed, > it could also be from the apache2, httpd.conf, or interchange.cfg > modifications mentioned above. I doubt it though. > > Incidentally, I'd like to mention that the ALERTs can be generated > pretty reliably by hitting the browser's stop button in the middle of > a request, clicking on the same link again or a different link in the > middle of a request (my Mom probably still double clicks links), or > just refreshing the page in the middle of a request. > > If the failed requests do stop at this point, I think the die_page > section of Link.pm is doing more harm than good. Is there anything > wrong with not handling $SIG{PIPE} at all? Grant, Shouldn't the $SIG{PIPE} be ignored at least? I don't know if there are implications for not handling it. Search perlipc manpage for PIPE. -- Josh Lavin Kingdom Design http://www.kingdomdesign.com/ From emailgrant at gmail.com Fri Dec 15 12:35:43 2006 From: emailgrant at gmail.com (Grant) Date: Fri Dec 15 12:35:58 2006 Subject: [ic] Re: ALERT: bad pipe signal received for /page.html In-Reply-To: <21375B2F-06D8-4614-98D5-1B28FCB26E47@myprivacy.ca> References: <49bf44f10612091034n7e7a5ee7g34fad9eb5a1954a8@mail.gmail.com> <49bf44f10612091037hce3fa80m76077e0be4632510@mail.gmail.com> <49bf44f10612111002l231637f2r22b8370e5534457@mail.gmail.com> <183A6A5F-82D3-4C02-BCEA-6D645C96C2BB@myprivacy.ca> <49bf44f10612121543t348d3112i690232821392fed6@mail.gmail.com> <21375B2F-06D8-4614-98D5-1B28FCB26E47@myprivacy.ca> Message-ID: <49bf44f10612150935xaa7e17bm6373cd84acb58635@mail.gmail.com> > >> >> > Hello, I've been plagued by apache2 segfaults ever since I > >> started > >> >> > using Interchange::Link years ago. The latest Link.pm has ALERT > >> >> > messages accompanying the segfaults in error_log: > >> >> > > >> >> > ALERT: bad pipe signal received for /page.html > >> >> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > >> >> > Segmentation fault (11) > >> >> > > >> >> > Does anyone have any advice on solving this? I'm using > >> >> apache-2.0.58 > >> >> > and mod_perl-2.0.2 in Gentoo Linux. > >> >> > >> >> Also, here is the portion of Link.pm that the ALERT seems to come > >> >> from: > >> >> > >> >> # Return this message to the browser when the server is not > >> running. > >> >> # Log an error log entry if set to notify > >> >> > >> >> sub die_page { > >> >> > >> >> my $r = shift; > >> >> my $msg; > >> >> > >> >> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME} > >> \n"; > >> >> > >> >> $r->content_type ("text/html"); > >> >> $r->print (< >> >> Interrupted > >> >> > >> >>

Someone pressed stop...

> >> >>

> >> >> We have aborted this request because someone terminated it. > >> >> Please try again soon. > >> >> > >> >> EOF > >> >> > >> >> } > >> >> > >> >> Please let me know if you have any ideas. > >> > > >> > The segfaults are eliminated by commenting out the $r stuff in the > >> > die_page sub. I still get the ALERTs though. Does anyone have any > >> > advice on figuring out why I'm having the bad pipe problem? Is > >> there > >> > an easy way to add extra debugging info to the sub? > >> > > >> > Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs > >> > 50 fold. > >> > >> I've been seeing this too, on my Apache 2 and latest Link.pm. I also > >> had to use PERL_SIGNALS=unsafe and so I get quite a lot of these. > >> > >> The visible effect on the browser is that the page or image (which > >> Link.pm apparently still has some part in delivering) does not load. > >> I get them myself when browsing and testing my websites, and I have > >> never stopped loading a page or had any other problems on non-IC > >> sites I host. > >> > >> I was told the problem stems from either the browser and a stop > >> button or some other network fault. I may go back to Apache 1.3 to > >> get around this. > > > > I've been working on this all day and I think I may have a solution. > > > > Incidentally, I want to mention that if I add $! to the Link.pm warn > > line, I can see that there are two different types of ALERTs in > > error_log: > > > > Broken pipe > > Inappropriate ioctl for device > > > > Also incidentally, hitting F5 repeatedly always prints a few ALERTS in > > error_log, but the number of ALERTs printed seems to be about 10 times > > more for an http page than for the same page accessed via https. I > > checked and tested the settings in my *:80 and *:443 vhosts trying to > > narrow that down, but I didn't come up with anything. > > > > Now, as I mentioned a few posts back, commenting out the html delivery > > stuff in the die_page sub of Link.pm eliminates the segfaults in > > error_log but not the ALERTs. Today I enabled the prefork mpm in > > apache2 and tinkered with the Server/Child settings in interchange.cfg > > and httpd.conf and that did seem to reduce the ALERTs somewhat. > > > > After all of this, I've been browsing around my site and I haven't > > seen a single image or page fail to load like it used to. The thing > > is, ALERTs still show up in error_log even for requests I'm sure I > > created myself AND WERE SERVED SUCCESSFULLY. I hypothesize that the > > failed requests were because a $SIG{PIPE} was generated for whatever > > reason (although not because the user clicked the stop button), the > > html was delivered, it caused a segfault, and the request failed. I > > should mention though, that if the failing request syndrome is fixed, > > it could also be from the apache2, httpd.conf, or interchange.cfg > > modifications mentioned above. I doubt it though. > > > > Incidentally, I'd like to mention that the ALERTs can be generated > > pretty reliably by hitting the browser's stop button in the middle of > > a request, clicking on the same link again or a different link in the > > middle of a request (my Mom probably still double clicks links), or > > just refreshing the page in the middle of a request. > > > > If the failed requests do stop at this point, I think the die_page > > section of Link.pm is doing more harm than good. Is there anything > > wrong with not handling $SIG{PIPE} at all? > > Grant, > > Shouldn't the $SIG{PIPE} be ignored at least? I don't know if there > are implications for not handling it. Search perlipc manpage for PIPE. I see the section you're referring to in the perlipc manpage, but I don't know enough about perl to interpret it. Be careful to check both the open() and the close() return values. If you're writing to a pipe, you should also trap SIGPIPE. Otherwise, think of what happens when you start up a pipe to a command that doesn't exist: the open() will in all likelihood succeed (it only reflects the fork()'s success), but then your output will fail--spec- tacularly. Perl can't know whether the command worked because your command is actually running in a separate process whose exec() might have failed. Therefore, while readers of bogus commands return just a quick end of file, writers to bogus command will trigger a signal they'd better be prepared to handle. Consider: open(FH, "|bogus") or die "can't fork: $!"; print FH "bang\n" or die "can't write: $!"; close FH or die "can't close: $!"; That won't blow up until the close, and it will blow up with a SIGPIPE. To catch it, you could use this: $SIG{PIPE} = 'IGNORE'; open(FH, "|bogus") or die "can't fork: $!"; print FH "bang\n" or die "can't write: $!"; close FH or die "can't close: status=$?"; - Grant From barb at emeraldcitymusic.com Fri Dec 15 15:02:34 2006 From: barb at emeraldcitymusic.com (Barb Sorensen) Date: Fri Dec 15 15:01:22 2006 Subject: [ic] Can't locate set cronjob (was - Need help with install please. Newbie here) In-Reply-To: Message-ID: HI, Thanks..that helped tons. 1) I'm retitling this email subject line to be easier for other folks to find their error message help . 2) I"m sorry for "Top posting" but I didn't know what that means. I have not heard that phrase before But from the link you posted I"m guessing that means not to repost the full emails I already wrote.. At the top of a new post? So I won't. Thanks for alerting me to this. 3) OK . In re: to this install... Thanks for the links.. They helped tons! I recognized I have an Application on my MAC named Terminal. And it offered ssh and so I entered my info and it seemed to connect to the server :) I uploaded version 5.4.1 stable release. Then I typed in ./configure and it ran ok then I typed in perl Makefile.PL and it ran and asked me where to install it. I typed in the correct address and hit go. It gave me this info next: Writing Makefile for Interchange ~/websites/barbsboutique/interchange > I then typed in "make" and hit go And it seemed to run fine. then I typed in "make test && make install" It began to run and then I got this "Can't locate Set/Crontab.pm in @INC" BEGIN failed--compilation aborted at Compilation failed in require at Compilation failed in require at blib/script/interchange line 249. BEGIN failed--compilation aborted at blib/script/interchange line 249. not ok 1 server/startup........-rw-r--r-- # When the above test fails, it may be due to your ISP or some other # mechanism blocking port 8786. SO I deleted everything and instead of me adjusting permissions myself I uploaded the tarball.bz2 and ran it and yet by the time I get to " make test" it stil gives me the same error. Any ideas? Thanks Regards Barb From docelic at mail.inet.hr Fri Dec 15 15:16:45 2006 From: docelic at mail.inet.hr (Davor Ocelic) Date: Fri Dec 15 15:18:41 2006 Subject: [ic] Can't locate set cronjob (was - Need help with install please. Newbie here) In-Reply-To: References: Message-ID: <20061215211645.3d003003.docelic@mail.inet.hr> On Fri, 15 Dec 2006 14:02:34 -0600 Barb Sorensen wrote: > It began to run and then I got this > "Can't locate Set/Crontab.pm in @INC" > BEGIN failed--compilation aborted at > Compilation failed in require at > Compilation failed in require at blib/script/interchange line 249. > BEGIN failed--compilation aborted at blib/script/interchange line 249. > not ok 1 > server/startup........-rw-r--r-- > > Hey Barb. This means you need to install the Set::Crontab Perl module. The common way to do this is to run perl -MCPAN -e 'install "Set::Crontab"' in your shell (at the place where you'll be running Interchange). Since this will most likely be the first time you are invoking CPAN there, CPAN will ask you a series of questions to configure itself. You should find a way about it since just accepting the defaults works most of the time. Once CPAN is configured, it will download the said Perl module, compile and install it. Then resume your installation procedure from and including the command that gave the error onwards. -doc From interchange at hertell.com Fri Dec 15 16:57:31 2006 From: interchange at hertell.com (Rene Hertell) Date: Fri Dec 15 16:58:00 2006 Subject: [ic] Can't locate set cronjob (was - Need help with install please. Newbie here) In-Reply-To: References: Message-ID: <45831A4B.4000006@hertell.com> Barb Sorensen wrote: > HI, Thanks..that helped tons. > > 1) I'm retitling this email subject line to be easier for other folks to > find their error message help . Please start a new thread if you want to post a new message.. Jut simply renaming a subject breaks the threads of messages If your mail-client does not support threaded views, then check your messages from the achieves and you'll see what i mean: http://www.icdevgroup.org/pipermail/interchange-users/2006-December/thread.html#end Ren? From peter at pajamian.dhs.org Fri Dec 15 17:16:32 2006 From: peter at pajamian.dhs.org (Peter) Date: Fri Dec 15 17:17:03 2006 Subject: [ic] Can't locate set cronjob (was - Need help with install please. Newbie here) In-Reply-To: References: Message-ID: <45831EC0.9090102@pajamian.dhs.org> On 12/15/2006 12:02 PM, Barb Sorensen wrote: > 2) I"m sorry for "Top posting" but I didn't know what that means. I have not > heard that phrase before But from the link you posted I"m guessing that > means not to repost the full emails I already wrote.. At the top of a new > post? No, top posting means that you post your reply above the text you're replying to. This is considered bad form. The proper way to reply is to add your reply text in after each point made in the text as I'm doing here. That way when people read the email in the archives later on they can easily follow each issue included there and the full conversation leading to a resolution and don't have to try to match up which parts go with what. > then I typed in "make test && make install" > > It began to run and then I got this > "Can't locate Set/Crontab.pm in @INC" This means that your perl is missing a module that Interchange needs to run. There are several perl modules that usually need to be installed prior to running Interchange on a server. You should contact your hosting provider and ask them to install the "Bundle::InterchangeKitchenSink" bundle onto the server for you. They will probably do it for you if you ask. if they won't then you'll have to install them into your own space on the server as a non-root user, google for "installing perl modules as non-root" for lots of web pages telling you how to do so. Peter From peter at pajamian.dhs.org Fri Dec 15 17:23:26 2006 From: peter at pajamian.dhs.org (Peter) Date: Fri Dec 15 17:23:41 2006 Subject: [ic] Can't locate set cronjob (was - Need help with install please. Newbie here) In-Reply-To: <45831A4B.4000006@hertell.com> References: <45831A4B.4000006@hertell.com> Message-ID: <4583205E.8080200@pajamian.dhs.org> On 12/15/2006 01:57 PM, Rene Hertell wrote: > Please start a new thread if you want to post a new message.. Jut simply > renaming a subject breaks the threads of messages > > If your mail-client does not support threaded views, then check your > messages from the achieves and you'll see what i mean: > > http://www.icdevgroup.org/pipermail/interchange-users/2006-December/thread.html#end What that is referring to is that a lot of people will "hijack" a message thread to post their own question. This might happen if, for example someone hit the reply button on this message, deleted all the quoted text, typed in their own problem and hit send. Two things would happen... 1. Email clients keep track of what messages were replied to in the headers of the email. This allows a mail reader to organise the emails by subject and show where in the "thread" that email occurred. People who use that feature will see a completely different email appearing inside someone else's thread and it becomes annoying. 2. If the subject isn't changed then it's also an additional level of annoyance because the subject says one thing and the email is about something completely different. As a rule of thumb when you are starting a new discussion compose a new email, don't use the reply button unless you are genuinely replying to an existing email. Peter From list at candhdevelopment.com Sat Dec 16 16:19:44 2006 From: list at candhdevelopment.com (list) Date: Sat Dec 16 16:20:14 2006 Subject: [ic] (no subject) Message-ID: <200612161619601.SM01052@c-e18fdc26944b4> Hello, interchange-users, Killing Interchange server 4315 with TERM. Low traffic settings. Calling UI......UI is loaded... Interchange V5.4.1 Running with new signals, external programs could be unreliable. Re-run with environment variable PERL_SIGNALS set to "unsafe" to change this. Configuring catalog demo...demo config error: Please specify the VendURL directive in the configuration file 'catalog.cfg' demo: error in configuration. Skipping. demo: config error. Skipping. Interchange server started in UNIX mode(s) (process id 4426) ------------------- I guessed that it 'must' be ( /home/ddws/catalogs/demo/catalog.cgf ) that the script was talking about? # The URLs which are written to refer back to our catalog. VendURL http://__SERVER_NAME____CGI_URL__ SecureURL __SECURE_SERVER____CGI_URL__ ifndef SECURE_ENABLE SecureURL http://__SERVER_NAME____CGI_URL__ endif # Set the image path for relative images ImageDir __IMAGE_DIR__/ ImageDirInternal http://__SERVER_NAME____IMAGE_DIR__/ Could there be "something" not allowing _SERVER_NAME_CGI_URL_ to work? Best regards. Don Carpenter list@candhdevelopment.com 2006-12-16 From peter at pajamian.dhs.org Sat Dec 16 18:29:34 2006 From: peter at pajamian.dhs.org (Peter) Date: Sat Dec 16 18:30:16 2006 Subject: [ic] (no subject) In-Reply-To: <200612161619601.SM01052@c-e18fdc26944b4> References: <200612161619601.SM01052@c-e18fdc26944b4> Message-ID: <4584815E.4040304@pajamian.dhs.org> On 12/16/2006 01:19 PM, list wrote: > demo: error in configuration. Skipping. > demo: config error. Skipping. > Interchange server started in UNIX mode(s) (process id 4426) What do the error logs say? Peter From list at candhdevelopment.com Sat Dec 16 19:31:27 2006 From: list at candhdevelopment.com (list) Date: Sat Dec 16 19:31:51 2006 Subject: [ic] (no subject) Message-ID: <200612161931711.SM01052@c-e18fdc26944b4> Hello, Peter, from; /usr/local/interchange/error.log 6:13:34:49 -1000] - - STOP server (5152) on signal TERM - - - [16/December/2006:13:34:53 -1000] - - Low traffic settings. - - - [16/December/2006:13:34:54 -1000] - - ...UI is loaded... - - - [16/December/2006:13:34:54 -1000] - - Interchange V5.4.1 - - - [16/December/2006:13:34:54 -1000] - - Running with new signals, external programs could be unreliable. Re-run with environment variable PERL_SIGNALS set to "unsafe" to change this. - - - [16/December/2006:13:34:54 -1000] - - Config 'demo' at server startup - - - [16/December/2006:13:34:54 -1000] - - demo: config error -- Couldn't change to /home/ddws/catalogs/demo: No such file or directory. Skipping. - - - [16/December/2006:13:34:55 -1000] - - START server (5448) (UNIX) - - - [16/December/2006:13:34:55 -1000] - - START server (5448) (UNIX) When I check... bash-3.1$ clear bash-3.1$ cd /home/ddws/catalogs/demo/ bash-3.1$ ls catalog.cfg error.log include pages session tmp config etc logs products special_pages upload dbconf images orders README templates variables bash-3.1$ It's there. It seems to be something to do with VendURL? Thanks! ======= At 2006-12-16, 15:29:00 you wrote: ======= >On 12/16/2006 01:19 PM, list wrote: >> demo: error in configuration. Skipping. >> demo: config error. Skipping. >> Interchange server started in UNIX mode(s) (process id 4426) > >What do the error logs say? > >Peter > >_______________________________________________ >interchange-users mailing list >interchange-users@icdevgroup.org >http://www.icdevgroup.org/mailman/listinfo/interchange-users = = = = = = = = = = = = = = = = = = = = Best regards. list list@candhdevelopment.com 2006-12-16 From peter at pajamian.dhs.org Sat Dec 16 19:46:24 2006 From: peter at pajamian.dhs.org (Peter) Date: Sat Dec 16 19:46:45 2006 Subject: [ic] (no subject) In-Reply-To: <200612161931711.SM01052@c-e18fdc26944b4> References: <200612161931711.SM01052@c-e18fdc26944b4> Message-ID: <45849360.4010700@pajamian.dhs.org> On 12/16/2006 04:31 PM, list wrote: > - - - [16/December/2006:13:34:54 -1000] - - demo: config error -- Couldn't change to /home/ddws/catalogs/demo: No such file or directory. Skipping. > When I check... > It's there. Check the permissions on the directory and all directories above it, make sure that Intechange has read/write/execute permissions on that directory. > It seems to be something to do with VendURL? It doesn't even get to VendURL, in fact it can't even read the catalog.cfg file because it can't access the directory. Also please don't top post your replies. See the list guidelines at Peter From list at candhdevelopment.com Sat Dec 16 22:08:10 2006 From: list at candhdevelopment.com (list) Date: Sat Dec 16 22:08:25 2006 Subject: [ic] (no subject) Message-ID: <200612162208452.SM01052@c-e18fdc26944b4> Hello, Peter, That seemed to work... It let me know that I needed DBD::mysql error log - - - [16/December/2006:16:31:49 -1000] - - demo config error: Required Perl module DBD::mysql not present. Aborting catalog. In line 2 of the configuration file 'dbconf/mysql/mysql.cfg': - - - [16/December/2006:16:31:49 -1000] - - demo: config error. Skipping. - - - [16/December/2006:16:31:50 -1000] - - START server (16889) (UNIX) - - - [16/December/2006:16:31:50 -1000] - - START server (16889) (UNIX) But when I try to intsall DBD::mysql it won't do it without force. I installed a fresh install of perl wo/threads ..so I could be missing some modules... Shoul I force DBD::mysql install If so, how, I am new at this. Best regards. Don list@candhdevelopment.com 2006-12-16 From peter at pajamian.dhs.org Sat Dec 16 22:21:00 2006 From: peter at pajamian.dhs.org (Peter) Date: Sat Dec 16 22:21:20 2006 Subject: [ic] (no subject) In-Reply-To: <200612162208452.SM01052@c-e18fdc26944b4> References: <200612162208452.SM01052@c-e18fdc26944b4> Message-ID: <4584B79C.90809@pajamian.dhs.org> On 12/16/2006 07:08 PM, list wrote: > But when I try to intsall DBD::mysql it won't do it without force. That's because the installer can't run the tests if mysql is password protected so it aborts. > Shoul I force DBD::mysql install Yes. > If so, how, I am new at this. In the CPAN shell: force install DBD::mysql Peter From oleg at eville.us Sun Dec 17 15:09:09 2006 From: oleg at eville.us (Oleg Raskin) Date: Sun Dec 17 15:09:26 2006 Subject: [ic] mv_nextpage URL Message-ID: <1699.24.94.155.85.1166386149.squirrel@noc.eville.us> Greetings. This may seem like a very simple question, but I've not found an answer in the mailing list as of yet. I have a form that goes to process.html and performs some database operations in a procedure defined through mv_check. That part works fine, however part of this procedure sets the mv_nextpage depending on form values being submitted. The problem is that mv_nextpage can only be an interchange page and I need it to go to a page outside of the interchange catalog. Naturally, I am getting the "missing" page every time. How can this be done? Many thanks. From kevin at cursor.biz Sun Dec 17 17:40:52 2006 From: kevin at cursor.biz (Kevin Walsh) Date: Sun Dec 17 17:41:11 2006 Subject: [ic] mv_nextpage URL In-Reply-To: <1699.24.94.155.85.1166386149.squirrel@noc.eville.us> References: <1699.24.94.155.85.1166386149.squirrel@noc.eville.us> Message-ID: <200612172240.53283.kevin@cursor.biz> "Oleg Raskin" wrote: > This may seem like a very simple question, but I've not found an answer in > the mailing list as of yet. I have a form that goes to process.html and > performs some database operations in a procedure defined through mv_check. > That part works fine, however part of this procedure sets the mv_nextpage > depending on form values being submitted. The problem is that mv_nextpage > can only be an interchange page and I need it to go to a page outside of > the interchange catalog. Naturally, I am getting the "missing" page every > time. How can this be done? > Set mv_nextpage to a "bouncer" page and set another variable to the target URI, such as "http://www.example.com/foo.html". Your new "bouncer" page only needs to contain the following two lines: [bounce href="[cgi your_uri_target]" if="[cgi your_uri_target]"] [bounce page="index"] See the [bounce] tag documentation for more information: http://www.interchange.rtfm.info/icdocs/tags/bounce.html -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ kevin@cursor.biz _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ From list at candhdevelopment.com Mon Dec 18 13:22:57 2006 From: list at candhdevelopment.com (list) Date: Mon Dec 18 13:23:24 2006 Subject: [ic] No css on public side Message-ID: <200612181322851.SM01104@c-e18fdc26944b4> Hello, interchange-users, could it be permissons issue? >From the error log [18/December/2006:07:59:57 -1000] standard /cgi-bin/standard/index.html CSS dir images does not exist. Best regards. list list@candhdevelopment.com 2006-12-18 From DDavenport at newagedigital.com Mon Dec 18 14:06:13 2006 From: DDavenport at newagedigital.com (Daniel Davenport) Date: Mon Dec 18 14:07:24 2006 Subject: [ic] No css on public side Message-ID: <6646EB737DB9164B9A6992E17A47DC74210D89@mssbs01.NewAgeDigital.local> > -----Original Message----- > From: interchange-users-bounces@icdevgroup.org > [mailto:interchange-users-bounces@icdevgroup.org] On Behalf Of list > Sent: 2006 December 18 -- Monday 1:23 PM > To: interchange-users@icdevgroup.org > Subject: [ic] No css on public side > > Hello, interchange-users, > > could it be permissons issue? > > >From the error log > > [18/December/2006:07:59:57 -1000] standard > /cgi-bin/standard/index.html CSS dir images does not exist. Possibly. IC likes having write access to the images directory, as it auto generates some files (among them, the CSS file for the default catalog). But also make sure there's a link in the catalog directory, named "images", that points to the folder where you want IC to generate the files. -- Daniel Davenport New Age Digital http://www.newagedigital.com From list at candhdevelopment.com Mon Dec 18 14:48:39 2006 From: list at candhdevelopment.com (list) Date: Mon Dec 18 14:49:02 2006 Subject: [ic] No css on public side Message-ID: <200612181448675.SM01104@c-e18fdc26944b4> Hello, Daniel Davenport, > But also make sure there's a link in the catalog directory, >named "images", that points to the folder where you want IC to generate >the files. The link is there. The owner is root, group is interch. I tried to change owner to interch... (with webmin file editer) but it won't let me. I assume it's because it is a link? Actually, I have IC as the owner for everything 'even' public files. Could this be part of the problem? I have tried a few different things :-) >interchange-users@icdevgroup.org >http://www.icdevgroup.org/mailman/listinfo/interchange-users = = = = = = = = = = = = = = = = = = = = Best regards. list list@candhdevelopment.com 2006-12-18 From DDavenport at newagedigital.com Tue Dec 19 07:52:07 2006 From: DDavenport at newagedigital.com (Daniel Davenport) Date: Tue Dec 19 07:52:28 2006 Subject: [ic] No css on public side Message-ID: <6646EB737DB9164B9A6992E17A47DC74210DA2@mssbs01.NewAgeDigital.local> > -----Original Message----- > From: interchange-users-bounces@icdevgroup.org > [mailto:interchange-users-bounces@icdevgroup.org] On Behalf Of list > Sent: 2006 December 18 -- Monday 2:49 PM > To: interchange-users@icdevgroup.org > Subject: Re: RE: [ic] No css on public side > > Hello, Daniel Davenport, > > > But also make sure there's a link in the catalog directory, > >named "images", that points to the folder where you want IC > > to generate the files. > > The link is there. The owner is root, group is interch. > > I tried to change owner to interch... (with webmin file > editer) but it won't let me. > I assume it's because it is a link? Probably. Actually, the permissions on the link generally don't matter -- they're almost always 777. It's where the link points that the permissions are important. > Actually, I have IC as the owner for everything 'even' public > files. Could this be part of the problem? As long as the static files (images, css, etc) are readable by apache, it generally doesn't matter who the owner is -- any files ic would create, it'd own. Files in the catalog directory, though, should generally be owned by either ic's user/group or the catalog's. From techlist at bnetmd.net Wed Dec 20 09:31:35 2006 From: techlist at bnetmd.net (Glenn McCalley) Date: Wed Dec 20 09:32:13 2006 Subject: [ic] admissions taxes based on item - not buyer Message-ID: <008901c72443$91ea5210$6701a8c0@GLENN2> Hi there, We need to charge an admissions tax on sales of tickets based upon the state in which the -event- is located, NOT the state of the purchaser. Needs to be based on an item attribute like "tix_tax" ( a percentage) and calculated on each item. Can't apply to the total because an event in New Jersey has a different tax rate than an event in New York, and there could be items other than tickets in the order. Looked at "Levies" and that seems to still work based on some constant that applies to the whole order, not individual items. I can show a total Admissions Tax for the entire order or show separate tax items for each ticket, but it has to be based on the ticket not the purchaser. Any thoughts on how to do this other than Perl to cycle through "if item = xxx" and check for a ticket? THanks! Glenn. From kevin at cursor.biz Wed Dec 20 10:43:05 2006 From: kevin at cursor.biz (Kevin Walsh) Date: Wed Dec 20 10:45:00 2006 Subject: [ic] admissions taxes based on item - not buyer In-Reply-To: <008901c72443$91ea5210$6701a8c0@GLENN2> References: <008901c72443$91ea5210$6701a8c0@GLENN2> Message-ID: <200612201543.06226.kevin@cursor.biz> "Glenn McCalley" wrote: > We need to charge an admissions tax on sales of tickets based upon the state > in which the -event- is located, NOT the state of the purchaser. Needs to > be based on an item attribute like "tix_tax" ( a percentage) and calculated > on each item. Can't apply to the total because an event in New Jersey has a > different tax rate than an event in New York, and there could be items other > than tickets in the order. > > Looked at "Levies" and that seems to still work based on some constant that > applies to the whole order, not individual items. > > I can show a total Admissions Tax for the entire order or show separate tax > items for each ticket, but it has to be based on the ticket not the > purchaser. > > Any thoughts on how to do this other than Perl to cycle through "if item = > xxx" and check for a ticket? > That's the way I'd probably do it. I'd most likely create a UserTag that loops through the cart and applies either an admissions tax or a sales tax depending upon the current item in the loop. The total tax value would be returned for Interchange to use. You'd presumably charge sales tax, rather than admissions tax, on any shipping costs involved - or perhaps you hold tickets at the door, rather than posting them at all. Your shiny new UserTag could be used by creating a "salestax.asc" file with one line, as follows: default [your-usertag-name] See here for more tax-related information: http://www.interchange.rtfm.info/icdocs/Interchange_sales_tax_calculations.html The only thing left to do is to work out how you want to look up the sales and admission tax percentage values for each US location (performance location for admissions and customer's location for other sales), and code that into the UserTag. I wouldn't store the percentages in item attributes, by the way; I'd store the performance location and code the UserTag to do the percentage lookup. That'd reduce the amount of maintenance required when the tax rates change. Whatever you do, make sure you do it securely - you don't really want people to create their own item attributes and make up some random sales tax amounts, do you? -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ kevin@cursor.biz _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ From cplists at princeservices.com Wed Dec 20 15:25:10 2006 From: cplists at princeservices.com (Cameron B. Prince) Date: Wed Dec 20 15:25:29 2006 Subject: [ic] Image Upload / Imagehelper Widget Message-ID: <007501c72474$f2bce360$0401a8c0@PSLAPTOP1A> Hey guys, Is there a way to remove an image with the Imagehelper widget? I received a call from a client who wanted to remove a large image, but leave the standard and thumbnail images intact. She told me that before the upgrade from IC v4.8 to v5.2 she could put a space in the field and it would cause the image to be removed. Now when you enter a space, the Ok button no longer functions until you re-edit the item. Is this a bug or are we overlooking something obvious? Thanks, Cameron From jon at endpoint.com Wed Dec 20 15:46:43 2006 From: jon at endpoint.com (Jon Jensen) Date: Wed Dec 20 15:47:21 2006 Subject: [ic] Image Upload / Imagehelper Widget In-Reply-To: <007501c72474$f2bce360$0401a8c0@PSLAPTOP1A> References: <007501c72474$f2bce360$0401a8c0@PSLAPTOP1A> Message-ID: On Wed, 20 Dec 2006, Cameron B. Prince wrote: > Is there a way to remove an image with the Imagehelper widget? > > I received a call from a client who wanted to remove a large image, but > leave the standard and thumbnail images intact. She told me that before > the upgrade from IC v4.8 to v5.2 she could put a space in the field and > it would cause the image to be removed. > > Now when you enter a space, the Ok button no longer functions until you > re-edit the item. > > Is this a bug or are we overlooking something obvious? I wonder if there is now a post-filter on that field in the metadata, stripping out the space. I thought I had seen some imagehelper setups that had a blank filename as the first entry, but apparently you're not getting that. Sorry I don't have more to suggest. Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/ From cplists at princeservices.com Wed Dec 20 16:33:51 2006 From: cplists at princeservices.com (Cameron B. Prince) Date: Wed Dec 20 16:33:41 2006 Subject: [ic] Image Upload / Imagehelper Widget In-Reply-To: Message-ID: <009101c7247e$8b4bfa40$0401a8c0@PSLAPTOP1A> Hey Jon, > I wonder if there is now a post-filter on that field in the metadata, > stripping out the space. I thought I had seen some imagehelper setups that > had a blank filename as the first entry, but apparently you're not getting > that. Sorry I don't have more to suggest. Thanks for replying... I checked the meta and there are no filters defined for the field. This is in the client's catalog and also on the demo site. It's really weird. What's happening is almost like some javascript function is disabling the whole form. Even if you switch to the General tab, the Ok button does nothing after putting a space in the image field. You know, Mike and I worked on what we called the "Ultimate Image Widget" back when he and I were working on the Red Hat store together. It was basically a combination of the imagelisting and imagehelper widgets that allowed you to either select an existing image or use a file input to upload a new one. I wonder whatever happened to this. I believe I recall seeing it mentioned in a WHATSNEW file some time ago so I don't think I dreamed the whole thing. I may try to resurrect this for the client and it would probably be helpful to check it into the source. Thanks, Cameron From jon at endpoint.com Wed Dec 20 16:51:58 2006 From: jon at endpoint.com (Jon Jensen) Date: Wed Dec 20 16:52:24 2006 Subject: [ic] Image Upload / Imagehelper Widget In-Reply-To: <009101c7247e$8b4bfa40$0401a8c0@PSLAPTOP1A> References: <009101c7247e$8b4bfa40$0401a8c0@PSLAPTOP1A> Message-ID: On Wed, 20 Dec 2006, Cameron B. Prince wrote: > You know, Mike and I worked on what we called the "Ultimate Image > Widget" back when he and I were working on the Red Hat store together. > It was basically a combination of the imagelisting and imagehelper > widgets that allowed you to either select an existing image or use a > file input to upload a new one. I wonder whatever happened to this. I > believe I recall seeing it mentioned in a WHATSNEW file some time ago so > I don't think I dreamed the whole thing. Ok, I just checked a site where we have this working. It's using the imagehelper widget with the standard nullselect filter, and that's it. The first option is "(none)", and I see that code in code/Widget/imagehelper.widget. Perhaps upgrading to the latest IC, or at least that widget, would work for you. Or even just backporting the "(none)" first option code. Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/ From cplists at princeservices.com Wed Dec 20 19:41:57 2006 From: cplists at princeservices.com (Cameron B. Prince) Date: Wed Dec 20 19:41:33 2006 Subject: [ic] Image Upload / Imagehelper Widget In-Reply-To: Message-ID: <00a001c72498$d1e78b30$0401a8c0@PSLAPTOP1A> Hi Jon, > Ok, I just checked a site where we have this working. It's using the > imagehelper widget with the standard nullselect filter, and that's it. The > first option is "(none)", and I see that code in > code/Widget/imagehelper.widget. Perhaps upgrading to the latest IC, or at > least that widget, would work for you. Or even just backporting the > "(none)" first option code. What do you have in the Directory meta field for the widget? It looks like that is what is triggering the select box based on this: if($path =~ s!/\*(?:\.([^/]+))?$!!) { Thanks, Cameron From jon at endpoint.com Wed Dec 20 22:17:59 2006 From: jon at endpoint.com (Jon Jensen) Date: Wed Dec 20 22:18:19 2006 Subject: [ic] Image Upload / Imagehelper Widget In-Reply-To: <00a001c72498$d1e78b30$0401a8c0@PSLAPTOP1A> References: <00a001c72498$d1e78b30$0401a8c0@PSLAPTOP1A> Message-ID: On Wed, 20 Dec 2006, Cameron B. Prince wrote: >> Ok, I just checked a site where we have this working. It's using the >> imagehelper widget with the standard nullselect filter, and that's it. >> The first option is "(none)", and I see that code in >> code/Widget/imagehelper.widget. Perhaps upgrading to the latest IC, or >> at least that widget, would work for you. Or even just backporting the >> "(none)" first option code. > > What do you have in the Directory meta field for the widget? It looks > like that is what is triggering the select box based on this: > > if($path =~ s!/\*(?:\.([^/]+))?$!!) { Nothing in a "Directory" field, but the "outboard" field is a simple "/path/to/images/*". Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/ From Moskova at infotecharch.com Thu Dec 21 03:46:40 2006 From: Moskova at infotecharch.com (Wareham Diego) Date: Thu Dec 21 03:47:54 2006 Subject: [ic] + 5 inches or money back Message-ID: <35ae01c724dc$0027f6f5$4b556bd0@Gene.midco.net> YO sir I don't care why your woody is so small, but 79% of women do. They are pretty sure that bigger thing will make their desire stronger. You have the chance to change your life. Here http://www.mucous.us you can get the thing. It will help you for sure. The remedy can be sent worldwide. If you wont be satisfied - we will return all you money. No bullshit. -- uhprpnqipsqqpopipspipoppuspjpgqlplplolqtqqqsqupsqqpuqgppofrunsogni weiuvbmdngsdfwelkgjhhpjw 'God knows, the blockheads! They grabbed me, tied me up with some filthy rags and dumped me in a lorry!' 'May I ask why you came into the restaurant in nothing but your underwear?' 'There's nothing odd about it,' answered Ivan. ' I went for a swim in the Moscow River and someone pinched my clothes and left me this junk instead! I couldn't walk round Moscow naked, could I? I had to put on what there was, because I was in a hurry to get to the Griboyedov restaurant.' The doctor glanced questioningly at Ryukhin, who mumbled sulkily: 'Yes, that's the name of the restaurant.' From michael.curtis at citigroup.com Thu Dec 21 05:13:18 2006 From: michael.curtis at citigroup.com (Curtis, Michael [CCC-OT_IT]) Date: Thu Dec 21 05:14:07 2006 Subject: [ic] Protx Payment Gateway Message-ID: <948D099B6BEC8843BC4325E8F4A2C94604CE2A94@exukmb20.eur.nsroot.net> Rather a lot to enquire about but as all seem to relate to Protx Payment Gateway issues then please bear with me Original configuration FreeBSD 6.0 Perl 5.8.8 Unthreaded IC 5.4.1 Mysql 5.x Configuration now Fedora Core 6 Perl 5.8.8 Threaded IC 5.4.1 Mysql 5.x Standard Store was created and locale changed to UK with shipping configured to use Royal mail so test orders (From P.O's) could be created....they were all o.k. Installed Protx 1.0.9f according to the doc's and now I have a few problems 1 using transactions.txt & transactions.mysql from the protx upgrade & then removing .transactions.sql The table fails to build and the catalog fails to start, reinstating the original transactions.txt & transactions.mysql then the table will build and the catalog starts 2 Adding the columns with mysql admin using transactions.mysql to identify the additional columns allows the catalog to start but the 'key' column 'code' is now empty i.e. I did have entries such as 'TEST001' now there is no data in the table.column 'transactions.code' on a fresh order, transactions.code is not updated (There must be somewhere in UI to set the numbering system but I cannot find it!) 3 On trying to use a Credit Card transaction I get x.x.0.50 rqAKSV6h:x.x.0.50 - [16/December/2006:19:35:42 +0000] standard4 /cgi-bin/standard4/process Non-existent order routing main, skipping. x.x.0.50 rqAKSV6h:x.x.0.50 - [16/December/2006:19:35:43 +0000] standard4 /cgi-bin/standard4/process Unknown charge type: protx x.x.0.50 rqAKSV6h:x.x.0.50 - [16/December/2006:19:35:43 +0000] standard4 /cgi-bin/standard4/process Safe: Real-time charge failed. Reason: > > > die errmsg( > "Real-time charge failed. Reason: %s\n", > errmsg($Session->{cybercash_error}), > ); > > x.x.0.50 rqAKSV6h:x.x.0.50 - [16/December/2006:19:35:43 +0000] standard4 /cgi-bin/standard4/process Route log failed. x.x.0.50 rqAKSV6h:x.x.0.50 - [16/December/2006:19:35:43 +0000] standard4 /cgi-bin/standard4/process ERRORS on ORDER : > Error during creation of order routing log: > Route log failed. at /usr/local/interchange/lib/Vend/Order.pm line 1835. Your help in solving these issues will be most welcome Regards Michael From lyn at zolotek.net Thu Dec 21 11:15:52 2006 From: lyn at zolotek.net (Lyn St George) Date: Thu Dec 21 11:14:51 2006 Subject: [ic] Protx Payment Gateway In-Reply-To: <948D099B6BEC8843BC4325E8F4A2C94604CE2A94@exukmb20.eur.nsroot.net> Message-ID: <20061221160758.03ADF830086@mailserver1.zolotek.net> On Thu, 21 Dec 2006 10:13:18 -0000, Curtis, Michael [CCC-OT_IT] wrote: >Rather a lot to enquire about but as all seem to relate to Protx Payment Gateway issues then please bear with me > >Original configuration >FreeBSD 6.0 >Perl 5.8.8 Unthreaded >IC 5.4.1 >Mysql 5.x > >Configuration now >Fedora Core 6 >Perl 5.8.8 Threaded >IC 5.4.1 >Mysql 5.x Your threaded perl may be an issue elsewhere, but probably not in this particular case. >Standard Store was created and locale changed to UK with shipping configured to use Royal mail so test orders (From P.O's) could be created....they were all o.k. > >Installed Protx 1.0.9f according to the doc's and now I have a few problems > >1 using transactions.txt & transactions.mysql from the protx upgrade & then removing .transactions.sql >The table fails to build and the catalog fails to start, reinstating the original transactions.txt & transactions.mysql then the table will build and the catalog starts Are you sure that the files did not have DOS line endings when uploaded? That can cause a variety of similar effects. >2 Adding the columns with mysql admin using transactions.mysql to identify the additional columns allows the catalog to start but the 'key' column 'code' is now empty i.e. I did have entries such as 'TEST001' now there is no data in the table.column 'transactions.code' on a fresh order, transactions.code is not updated (There must be somewhere in UI to set the numbering system but I cannot find it!) When you install a new, empty, transactions.txt and then remove the .transactions.sql marker and restart Interchange, it will import the data from the new transactions.txt into your MySQL table and overwrite whatever is there. The fact that your mysql admin panel could add new columns to the table further suggests that the uploaded files were faulty (in the Unix sense) The counter is in etc/order.number. >3 On trying to use a Credit Card transaction I get >x.x.0.50 rqAKSV6h:x.x.0.50 - [16/December/2006:19:35:42 +0000] standard4 /cgi-bin/standard4/process Non-existent order routing main, skipping. >x.x.0.50 rqAKSV6h:x.x.0.50 - [16/December/2006:19:35:43 +0000] standard4 /cgi-bin/standard4/process Unknown charge type: protx >x.x.0.50 rqAKSV6h:x.x.0.50 - [16/December/2006:19:35:43 +0000] standard4 /cgi-bin/standard4/process Safe: Real-time charge failed. Reason: Did the Protx module load when Interchange started? Probably not or it would not be 'unknown'. [snip] >Your help in solving these issues will be most welcome > >Regards > >Michael > - Lyn From DB at M-and-D.com Thu Dec 21 11:20:12 2006 From: DB at M-and-D.com (DB) Date: Thu Dec 21 11:21:12 2006 Subject: [ic] change displayed URL of results page Message-ID: <458AB43C.2070208@M-and-D.com> Is there anyway to change the URL of a results page from something like: http://domain.com/scan/se=AA/sf=category/st=db/sp=results/tf=sku/ml=20.html to something like: http://domain.com/somethingelse.html ? Is this possible with any IC and/or Apache tricks? DB From MichaelC at glcweb.co.uk Thu Dec 21 16:26:16 2006 From: MichaelC at glcweb.co.uk (Michael Curtis) Date: Thu Dec 21 16:26:43 2006 Subject: [ic] Protx Payment Gateway Message-ID: > > On Thu, 21 Dec 2006 10:13:18 -0000, Curtis, Michael [CCC-OT_IT] wrote: > > >Configuration now > >Fedora Core 6 > >Perl 5.8.8 Threaded > >IC 5.4.1 > >Mysql 5.x > > >The table fails to build and the catalog fails to start, reinstating the > original transactions.txt > & transactions.mysql then the table will build and the catalog starts > > Are you sure that the files did not have DOS line endings when uploaded? > That can cause a variety of similar effects. It must be along those lines, tried Vi, Nano to edit but all looks fine, tried cp the file from the untarred Protx directory i.e not opened in an editor, still no joy, tried retyping the transactions.txt and got to nine entries before the table rebuild failed > > The counter is in etc/order.number. That location confirms numbering starting at TEST00001 but still no order ref showing in 'transactions.code' > > Did the Protx module load when Interchange started? Probably not > or it would not be 'unknown'. You were spot on with that, I put the 'include' statement in catalog.cfg Doh!! Further error messages with that now but I suspect Firewall issues and will have to read up on Protx requirements Many thanks Lyn........ Your further help in solving these issues will be most welcome > > > >Regards > > > >Michael > > > > - > Lyn > > _______________________________________________ > interchange-users mailing list > interchange-users@icdevgroup.org > http://www.icdevgroup.org/mailman/listinfo/interchange-users > > -- > This message has been scanned for viruses and > dangerous content by IC-MailScanner, and is > believed to be clean. > > For queries or information please contact:- > > ================================= > Internet Central Technical Support > > > http://www.netcentral.co.uk > ================================= > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.432 / Virus Database: 268.15.26/594 - Release Date: > 20/12/2006 15:54 > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.15.26/594 - Release Date: 20/12/2006 15:54 From DDavenport at newagedigital.com Thu Dec 21 17:23:05 2006 From: DDavenport at newagedigital.com (Daniel Davenport) Date: Thu Dec 21 17:23:31 2006 Subject: [ic] change displayed URL of results page Message-ID: <6646EB737DB9164B9A6992E17A47DC74210E4B@mssbs01.NewAgeDigital.local> > -----Original Message----- > From: interchange-users-bounces@icdevgroup.org > [mailto:interchange-users-bounces@icdevgroup.org] On Behalf Of DB > Sent: 2006 December 21 -- Thursday 11:20 AM > To: interchange-users@icdevgroup.org > Subject: [ic] change displayed URL of results page > > Is there anyway to change the URL of a results page from > something like: > > http://domain.com/scan/se=AA/sf=category/st=db/sp=results/tf=s > ku/ml=20.html > > to something like: > > http://domain.com/somethingelse.html ? > > Is this possible with any IC and/or Apache tricks? > > DB Of course it's possible -- anything is, if you want it badly enough. =) Two ways i can think of off the top of my head are ActionMaps and a little mod_rewrite magic. Rewrites are pretty simple, but can be effective. You could, for example, just match (.*)/your_url(\.html)?$, and rewrite it to $1/scan/se=category/se=AA/ml=20. The only real problem is that more-links on the results page still end up with long, ugly urls. Only way around that is to do your own more-links, afaik, and that could complicate your rewrite rules a bit. ActionMaps are a bit more involved. The /scan/... urls are actually done via an action map (internal to IC?), so of course it's possible to do your own action that works like /scan. But since you'd be pretty much taking over the job that /scan does, you'll likely need to set a lot of the cgi and search variables yourself (unless someone else knows of an easier way...). Another option, if you only care about the search being available via your url, might be to make a page that just bounces to the /scan... url. But that's ugly -- among other things, it replaces your nice short url in the address bar with the /scan... one. -- Daniel Davenport New Age Digital http://www.newagedigital.com From kevin at cursor.biz Thu Dec 21 20:15:05 2006 From: kevin at cursor.biz (Kevin Walsh) Date: Thu Dec 21 20:16:36 2006 Subject: [ic] change displayed URL of results page In-Reply-To: <6646EB737DB9164B9A6992E17A47DC74210E4B@mssbs01.NewAgeDigital.local> References: <6646EB737DB9164B9A6992E17A47DC74210E4B@mssbs01.NewAgeDigital.local> Message-ID: <200612220115.07451.kevin@cursor.biz> "Daniel Davenport" wrote: > > Is there anyway to change the URL of a results page from > > something like: > > > > http://domain.com/scan/se=AA/sf=category/st=db/sp=results/tf=s > > ku/ml=20.html > > > > to something like: > > > > http://domain.com/somethingelse.html ? > > > > Is this possible with any IC and/or Apache tricks? > > > [snip] > > ActionMaps are a bit more involved. The /scan/... urls are actually > done via an action map (internal to IC?), so of course it's possible to > do your own action that works like /scan. But since you'd be pretty > much taking over the job that /scan does, you'll likely need to set a > lot of the cgi and search variables yourself (unless someone else knows > of an easier way...). > It's not too involved. You could use something like the following: ActionMap cat <{mv_searchtype} = 'db'; $CGI->{mv_search_field} = 'category'; $CGI->{mv_searchspec} = $cat; $CGI->{mv_sort_field} = 'sku'; $CGI->{mv_matchlimit} = 20; $CGI->{mv_todo} = 'search'; $Tag->update('process'); return 1; } EOA Using the above local ActionMap example, you could search for all products in the "AA" category using a URI like "http://www.example.com/cat/AA.html". Substitute "AA" for "foobar", or whatever you'd like to look for in the "products.category" column. See also: http://www.interchange.rtfm.info/icdocs/config/ActionMap.html http://www.interchange.rtfm.info/icdocs/Search_parameters.html -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ kevin@cursor.biz _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ From emailgrant at gmail.com Thu Dec 21 20:56:23 2006 From: emailgrant at gmail.com (Grant) Date: Thu Dec 21 20:56:48 2006 Subject: [ic] Payment.pm bug fixed Message-ID: <49bf44f10612211756y146c0975y8890dea64eeadcd6@mail.gmail.com> I've never been able to submit extra information along with my Authorize.net transactions, except for the name and address. The city, state, zip code, and country would never show up on the other end. I'm finally able to submit all of the above information after commenting out all of the sections in Payment.pm which contain "billing_set". Here is a link to Payment.pm: http://www.icdevgroup.org/cgi-bin/cvsweb/~checkout~/interchange/lib/Vend/Payment.pm?rev=2.17;content-type=text%2Fplain;hideattic=0 Can anyone tell me what the billing_set stuff does? I'm using IC 5.2. - Grant From michael.curtis at citigroup.com Fri Dec 22 02:42:07 2006 From: michael.curtis at citigroup.com (Curtis, Michael [CCC-OT_IT]) Date: Fri Dec 22 02:42:29 2006 Subject: [ic] Protx Payment Gateway Message-ID: <948D099B6BEC8843BC4325E8F4A2C94604CE2A99@exukmb20.eur.nsroot.net> > > >The table fails to build and the catalog fails to start, reinstating the > original transactions.txt > & transactions.mysql then the table will build and the catalog starts > The problem is with the column 'repeats'. With this column in then the table will not build, not even if I edit the 'transactions.txt' file with vi/nano! Leave it out and the table builds fine > The counter is in etc/order.number. That location confirms numbering starting at TEST00001 but still no order ref showing in 'transactions.code' > Many thanks Lyn........ Your further help in solving these issues will be most welcome > > > >Regards > > > >Michael > > > > - > Lyn > > _______________________________________________ > interchange-users mailing list > interchange-users@icdevgroup.org > http://www.icdevgroup.org/mailman/listinfo/interchange-users > > -- > This message has been scanned for viruses and > dangerous content by IC-MailScanner, and is > believed to be clean. > > For queries or information please contact:- > > ================================= > Internet Central Technical Support > > > http://www.netcentral.co.uk > ================================= > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.432 / Virus Database: 268.15.26/594 - Release Date: > 20/12/2006 15:54 > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.15.26/594 - Release Date: 20/12/2006 15:54 _______________________________________________ interchange-users mailing list interchange-users@icdevgroup.org http://www.icdevgroup.org/mailman/listinfo/interchange-users From lyn at zolotek.net Fri Dec 22 05:21:10 2006 From: lyn at zolotek.net (Lyn St George) Date: Fri Dec 22 05:19:21 2006 Subject: [ic] Protx Payment Gateway In-Reply-To: <948D099B6BEC8843BC4325E8F4A2C94604CE2A99@exukmb20.eur.nsroot.net> Message-ID: <20061222101313.3C950830087@mailserver1.zolotek.net> On Fri, 22 Dec 2006 07:42:07 -0000, Curtis, Michael [CCC-OT_IT] wrote: > >> >> >The table fails to build and the catalog fails to start, reinstating the >> original transactions.txt >> & transactions.mysql then the table will build and the catalog starts >> >The problem is with the column 'repeats'. With this column in then the table will not build, not even if I edit the 'transactions.txt' file with vi/nano! >Leave it out and the table builds fine I've just looked through the docs for that, and it is mentioned as 'repeat', ie not plural. However this is one of those that were put in as an attempt at "future proofing", and as I mentioned before they can all be omitted. The only ones you need are those listed for log_transaction. I'm in the process of doing a new version, both for their new API and also to handle their problem with duplicate orders (what happens is that they send back an 'empty' response, which IC reads as failure and so the customer resends the order. However Protx have taken the money at their end, even though they don't say so, and have no system for checking duplicate payments. The result is irate customers ...). It also checks for their availability (they have their share of outages) and optionally logs the transaction offline for you to complete manually later - generally thought to be better than telling the customer to come back later. If you want to try this one then I'll send it offlist. >Many thanks Lyn........ >Your further help in solving these issues will be most welcome >> > >> >Regards >> > >> >Michael >> > >> >> - >> Lyn - Lyn From michael.curtis at citigroup.com Fri Dec 22 05:54:59 2006 From: michael.curtis at citigroup.com (Curtis, Michael [CCC-OT_IT]) Date: Fri Dec 22 05:55:31 2006 Subject: [ic] Protx Payment Gateway Message-ID: <948D099B6BEC8843BC4325E8F4A2C94604CE2A9A@exukmb20.eur.nsroot.net> I'm in the process of doing a new version, both for their new API and also to handle their problem with duplicate orders (what happens is that they send back an 'empty' response, which IC reads as failure and so the customer resends the order. However Protx have taken the money at their end, even though they don't say so, and have no system for checking duplicate payments. The result is irate customers ...). It also checks for their availability (they have their share of outages) and optionally logs the transaction offline for you to complete manually later - generally thought to be better than telling the customer to come back later. If you want to try this one then I'll send it offlist. ---------- Yes Please..I have just looked at 5.5 demo and I am impressed, not shure of what features of 5.5 I will end up with in 5.4.1 and so will try a two pronged approach (dev and er! superdev?) Can you please sent it to michael.curtis@glcweb.co.uk as this I can access from anywhere As for 'repeat' in transactions.txt that was from the doc's, 'repeats' in the email was from memory so me wrong there Rgds Michael >Many thanks Lyn........ >Your further help in solving these issues will be most welcome >> > >> >Regards >> > >> >Michael >> > >> >> - >> Lyn - Lyn _______________________________________________ interchange-users mailing list interchange-users@icdevgroup.org http://www.icdevgroup.org/mailman/listinfo/interchange-users From peter at pajamian.dhs.org Fri Dec 22 06:48:52 2006 From: peter at pajamian.dhs.org (Peter) Date: Fri Dec 22 06:49:30 2006 Subject: [ic] Protx Payment Gateway In-Reply-To: <948D099B6BEC8843BC4325E8F4A2C94604CE2A99@exukmb20.eur.nsroot.net> References: <948D099B6BEC8843BC4325E8F4A2C94604CE2A99@exukmb20.eur.nsroot.net> Message-ID: <458BC624.8010603@pajamian.dhs.org> On 12/21/2006 11:42 PM, Curtis, Michael [CCC-OT_IT] wrote: > The problem is with the column 'repeats'. With this column in then > the table will not build, not even if I edit the 'transactions.txt' > file with vi/nano! Leave it out and the table builds fine It probably has something to do with the fact that REPEAT is a reserved word in mysql. Peter From emailgrant at gmail.com Fri Dec 22 08:55:21 2006 From: emailgrant at gmail.com (Grant) Date: Fri Dec 22 08:56:08 2006 Subject: [ic] Re: Payment.pm bug fixed In-Reply-To: <49bf44f10612211756y146c0975y8890dea64eeadcd6@mail.gmail.com> References: <49bf44f10612211756y146c0975y8890dea64eeadcd6@mail.gmail.com> Message-ID: <49bf44f10612220555t41f69248i88ba2daad8e879f@mail.gmail.com> > I've never been able to submit extra information along with my > Authorize.net transactions, except for the name and address. The > city, state, zip code, and country would never show up on the other > end. I'm finally able to submit all of the above information after > commenting out all of the sections in Payment.pm which contain > "billing_set". Here is a link to Payment.pm: > > http://www.icdevgroup.org/cgi-bin/cvsweb/~checkout~/interchange/lib/Vend/Payment.pm?rev=2.17;content-type=text%2Fplain;hideattic=0 > > Can anyone tell me what the billing_set stuff does? I'm using IC 5.2. > > - Grant I wanted to add that this is important because it qualifies me for the discounted rate with my processor which is about half. - Grant From zeolite61 at yahoo.com Fri Dec 22 12:21:56 2006 From: zeolite61 at yahoo.com (Ken Douglas) Date: Fri Dec 22 12:22:22 2006 Subject: [ic] SEO Module Community Project Message-ID: <20061222172156.24705.qmail@web59101.mail.re1.yahoo.com> Hi, I have searched thru mailing-list archive (example thread http://www.icdevgroup.org/pipermail/interchange-users/2005-April/042831.html ) and found various partial and non-standard ways to achieve some kind of SEO-optimized URLs. In the past Perusion, Mike Heins' company, has Community Projects located in http://www.perusion.com/c/public/communityprojects/projectlistings.html. Logic is simple setup a public project with a cost then interested parties pledge money. So Mike can setup this and we can go on. A similar example project is OpenSEF located in http://projects.j-prosolution.com/en/projects/os-projects/project-opensef.html . This a Joomla/Mambo CMS component and it lets you do creative ways of URL rewriting. You can have: http://www.domain.com/section/category/item.html http://www.domain.com/section/some-prefix-item.html http://www.domain.com/category/item-some-suffix.html http://www.domain.com/section/category/item.asp In short you can change everything after your top-level domain address. But, of course, this comes with a performance penalty. This can be neutralized by using cache. One more point is that you may only want to use it only on product and category display pages not on account or order pages. Otherwise it can be problematic. These days you should utilize every chance to show up high in Google and keywords in URLs help a lot. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From zeolite61 at yahoo.com Fri Dec 22 12:22:02 2006 From: zeolite61 at yahoo.com (Ken Douglas) Date: Fri Dec 22 12:22:26 2006 Subject: [ic] SEO Module Community Project Message-ID: <782136.28834.qm@web59106.mail.re1.yahoo.com> Hi, I have searched thru mailing-list archive (example thread http://www.icdevgroup.org/pipermail/interchange-users/2005-April/042831.html ) and found various partial and non-standard ways to achieve some kind of SEO-optimized URLs. In the past Perusion, Mike Heins' company, has Community Projects located in http://www.perusion.com/c/public/communityprojects/projectlistings.html. Logic is simple setup a public project with a cost then interested parties pledge money. So Mike can setup this and we can go on. A similar example project is OpenSEF located in http://projects.j-prosolution.com/en/projects/os-projects/project-opensef.html . This a Joomla/Mambo CMS component and it lets you do creative ways of URL rewriting. You can have: http://www.domain.com/section/category/item.html http://www.domain.com/section/some-prefix-item.html http://www.domain.com/category/item-some-suffix.html http://www.domain.com/section/category/item.asp In short you can change everything after your top-level domain address. But, of course, this comes with a performance penalty. This can be neutralized by using cache. One more point is that you may only want to use it only on product and category display pages not on account or order pages. Otherwise it can be problematic. These days you should utilize every chance to show up high in Google and keywords in URLs help a lot. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From cplists at princeservices.com Sat Dec 23 03:03:48 2006 From: cplists at princeservices.com (Cameron B. Prince) Date: Sat Dec 23 03:03:40 2006 Subject: [ic] Image Upload / Imagehelper Widget In-Reply-To: Message-ID: <006b01c72668$e1ea4730$0401a8c0@PSLAPTOP1A> Hi Jon, > Nothing in a "Directory" field, but the "outboard" field is > a simple "/path/to/images/*". That was it... Thanks, Cameron From lyn at zolotek.net Sat Dec 23 04:09:34 2006 From: lyn at zolotek.net (Lyn St George) Date: Sat Dec 23 04:07:40 2006 Subject: [ic] Protx Payment Gateway In-Reply-To: <948D099B6BEC8843BC4325E8F4A2C94604CE2A9A@exukmb20.eur.nsroot.net> Message-ID: <20061223090134.21914830087@mailserver1.zolotek.net> On Fri, 22 Dec 2006 10:54:59 -0000, Curtis, Michael [CCC-OT_IT] wrote: [snip about new version] >than telling the customer to come back later. If you want to try >this one then I'll send it offlist. > >---------- > >Yes Please..I have just looked at 5.5 demo and I am impressed, not shure of what features of 5.5 I will end up with in 5.4.1 and so will try a two pronged approach (dev and er! superdev?) >Can you please sent it to michael.curtis@glcweb.co.uk as this I can access from anywhere I'll send it after the 27th - Protx have disabled my test account and as I haven't looked at this for a while I need to run at least one test before sending it. (Protx are back on the 27th) >Rgds > >Michael - Lyn From jonathan.millerobrq at viatel.com Mon Dec 25 00:02:04 2006 From: jonathan.millerobrq at viatel.com (Brenton Small) Date: Sun Dec 24 16:02:58 2006 Subject: [ic] demonstration Message-ID: <884027917264.035696461791@viatel.com> Fantastis DVD safe quality exclusive generous videos http://girlslovearnie.info From bob at nleaudio.com Tue Dec 26 11:17:58 2006 From: bob at nleaudio.com (Bob Puff) Date: Tue Dec 26 11:09:35 2006 Subject: [ic] Dead 5.2 in RPC? Message-ID: <45914B36.6090309@nleaudio.com> Hi Gang, I recently had some significant trouble with a 5.2 cart and authorize.net duplicating charges - it would tell the customer the card was declined, when the charge really did go through. In searching the archives, the only solution I found was to use RPC mode (I have been running several carts on this same box in High setting for years, no problems). Two days after I switched to RPC mode, interchange hangs up. I had to kill -9 all the ic processes, and restart. I saw no errors in any of the error.logs that warned of any problems. It didn't appear that my box ran out of memory, as top reports about the same memory usage as before the switch. Where can I look? Obviously, a lockup like this is not a good thing! Alternatively, if there were a fix for the authorizenet problem, I may want to implement that, and go back to High traffic settings. Bob From ron at endpoint.com Tue Dec 26 11:20:39 2006 From: ron at endpoint.com (Ron Phipps) Date: Tue Dec 26 11:21:32 2006 Subject: [ic] Dead 5.2 in RPC? In-Reply-To: <45914B36.6090309@nleaudio.com> References: <45914B36.6090309@nleaudio.com> Message-ID: <45914BD7.2060601@endpoint.com> Bob Puff wrote: > Hi Gang, > > I recently had some significant trouble with a 5.2 cart and > authorize.net duplicating charges - it would tell the customer the card > was declined, when the charge really did go through. In searching the > archives, the only solution I found was to use RPC mode (I have been > running several carts on this same box in High setting for years, no > problems). Two days after I switched to RPC mode, interchange hangs > up. I had to kill -9 all the ic processes, and restart. I saw no > errors in any of the error.logs that warned of any problems. It didn't > appear that my box ran out of memory, as top reports about the same > memory usage as before the switch. > > Where can I look? Obviously, a lockup like this is not a good thing! > > Alternatively, if there were a fix for the authorizenet problem, I may > want to implement that, and go back to High traffic settings. > > Bob Hello Bob, Try editing your interchange.cfg file and in the high traffic area change the max servers setting to: MaxServers 0 and then switch back to high traffic. -- Ron Phipps End Point Corporation ron@endpoint.com From bob at nleaudio.com Tue Dec 26 12:21:59 2006 From: bob at nleaudio.com (Bob Puff) Date: Tue Dec 26 12:22:35 2006 Subject: [ic] Re: Dead 5.2 in RPC? In-Reply-To: <200612261700.kBQH072p022729@icdevgroup.org> References: <200612261700.kBQH072p022729@icdevgroup.org> Message-ID: <20061226172033.M96687@nleaudio.com> > Bob Puff wrote: > > Hi Gang, > > > > I recently had some significant trouble with a 5.2 cart and > > authorize.net duplicating charges - it would tell the customer the card > > was declined, when the charge really did go through. In searching the > > archives, the only solution I found was to use RPC mode (I have been > > running several carts on this same box in High setting for years, no > > problems). Two days after I switched to RPC mode, interchange hangs > > up. I had to kill -9 all the ic processes, and restart. I saw no > > errors in any of the error.logs that warned of any problems. It didn't > > appear that my box ran out of memory, as top reports about the same > > memory usage as before the switch. > > > > Where can I look? Obviously, a lockup like this is not a good thing! > > > > Alternatively, if there were a fix for the authorizenet problem, I may > > want to implement that, and go back to High traffic settings. > > > > Bob > > Hello Bob, > > Try editing your interchange.cfg file and in the high traffic area > change the max servers setting to: MaxServers 0 and then switch back > to high traffic. > > -- > Ron Phipps > End Point Corporation > ron@endpoint.com Hi Ron, Will that fix the authorizenet problems? I'm a little gun-shy, after having to do like 20 refunds due to this bug. Thanks! Bob P.S. I am running Perl 5.8.4, non-threaded From ryantxln at resourceskc.com Tue Dec 26 20:32:42 2006 From: ryantxln at resourceskc.com (Tia Edwards) Date: Tue Dec 26 12:37:09 2006 Subject: [ic] double-dyed . Message-ID: <616941937266.214014470611@resourceskc.com> [Unknown Tag *$$dating* Please Fix] http://supportotherwomen.info From ron at endpoint.com Tue Dec 26 12:41:21 2006 From: ron at endpoint.com (Ron Phipps) Date: Tue Dec 26 12:42:13 2006 Subject: [ic] Re: Dead 5.2 in RPC? In-Reply-To: <20061226172033.M96687@nleaudio.com> References: <200612261700.kBQH072p022729@icdevgroup.org> <20061226172033.M96687@nleaudio.com> Message-ID: <45915EC1.2000705@endpoint.com> Bob Puff wrote: >> Bob Puff wrote: >>> Hi Gang, >>> >>> I recently had some significant trouble with a 5.2 cart and >>> authorize.net duplicating charges - it would tell the customer the card >>> was declined, when the charge really did go through. In searching the >>> archives, the only solution I found was to use RPC mode (I have been >>> running several carts on this same box in High setting for years, no >>> problems). Two days after I switched to RPC mode, interchange hangs >>> up. I had to kill -9 all the ic processes, and restart. I saw no >>> errors in any of the error.logs that warned of any problems. It didn't >>> appear that my box ran out of memory, as top reports about the same >>> memory usage as before the switch. >>> >>> Where can I look? Obviously, a lockup like this is not a good thing! >>> >>> Alternatively, if there were a fix for the authorizenet problem, I may >>> want to implement that, and go back to High traffic settings. >>> >>> Bob >> Hello Bob, >> >> Try editing your interchange.cfg file and in the high traffic area >> change the max servers setting to: MaxServers 0 and then switch back >> to high traffic. >> >> -- >> Ron Phipps >> End Point Corporation >> ron@endpoint.com > > > Hi Ron, > > Will that fix the authorizenet problems? I'm a little gun-shy, after having > to do like 20 refunds due to this bug. Thanks! > > Bob > > P.S. I am running Perl 5.8.4, non-threaded > Hello Bob, I can't guarantee it will fix the problem, but your symptoms all sound like things I have ran into in the past (if you search the archives you'll find a lot of info about "double triple charges with signio" and the fix was to run in RPC mode with MaxServers 0. Recently I was instructed to setup all sites at End Point with MaxServers 0 in high traffic mode to get the stability of high traffic mode with the fix for perl signaling problems that cause issues when calling sendmail or external programs. There was also a thread about authorizenet issues awhile ago and I think the solution may have been to use another method to contact authorizenet (using wget instead of lwp). -- Ron Phipps End Point Corporation ron@endpoint.com From bob at nleaudio.com Wed Dec 27 02:03:20 2006 From: bob at nleaudio.com (Bob Puff) Date: Wed Dec 27 01:54:25 2006 Subject: [ic] Re: Dead 5.2 in RPC? Message-ID: <45921AB8.60308@nleaudio.com> >> Hi Ron, >> >> Will that fix the authorizenet problems? I'm a little gun-shy, after having >> to do like 20 refunds due to this bug. Thanks! >> >> Bob >> >> P.S. I am running Perl 5.8.4, non-threaded >> > > Hello Bob, > > I can't guarantee it will fix the problem, but your symptoms all sound like > things I have ran into in the past (if you search the archives you'll find a lot of info > about "double triple charges with signio" and the fix was to run in RPC mode > with MaxServers 0. Recently I was instructed to setup all sites at End Point with > MaxServers 0 in high traffic mode to get the stability of high traffic mode with the fix > for perl signaling problems that cause issues when calling sendmail or external > programs. > > There was also a thread about authorizenet issues awhile ago and I think the solution may > have been to use another method to contact authorizenet (using wget instead of lwp). > > -- > Ron Phipps > End Point Corporation > ron@endpoint.com Hi Ron, I thought the thing that fixed the perl signal problems was the RPC mode, not necessarily the MaxServers thing. Has the high traffic setting been working ok for you? I did a search in the archives on authorizenet and wget, and came up with nothing. Any other suggestions for info on this? Bob From ron at endpoint.com Wed Dec 27 13:11:09 2006 From: ron at endpoint.com (Ron Phipps) Date: Wed Dec 27 13:12:03 2006 Subject: [ic] Re: Dead 5.2 in RPC? In-Reply-To: <45921AB8.60308@nleaudio.com> References: <45921AB8.60308@nleaudio.com> Message-ID: <4592B73D.60109@endpoint.com> Bob Puff wrote: >>> Hi Ron, >>> >>> Will that fix the authorizenet problems? I'm a little gun-shy, after >>> having >>> to do like 20 refunds due to this bug. Thanks! >>> >>> Bob >>> >>> P.S. I am running Perl 5.8.4, non-threaded >>> >> >> Hello Bob, >> >> I can't guarantee it will fix the problem, but your symptoms all sound >> like things I have ran into in the past (if you search the archives >> you'll find a lot of info about "double triple charges with signio" >> and the fix was to run in RPC mode with MaxServers 0. Recently I was >> instructed to setup all sites at End Point with MaxServers 0 in high >> traffic mode to get the stability of high traffic mode with the fix >> for perl signaling problems that cause issues when calling sendmail or >> external programs. >> >> There was also a thread about authorizenet issues awhile ago and I >> think the solution may have been to use another method to contact >> authorizenet (using wget instead of lwp). >> >> -- >> Ron Phipps >> End Point Corporation >> ron@endpoint.com > > Hi Ron, > > I thought the thing that fixed the perl signal problems was the RPC > mode, not necessarily the MaxServers thing. Has the high traffic > setting been working ok for you? > > I did a search in the archives on authorizenet and wget, and came up > with nothing. Any other suggestions for info on this? > > Bob Hi Bob, It's definitely MaxServers 0 that gets around the signaling issue when calling external programs. High traffic with MaxServers 0 is working wonderfully for us. It's used at FrozenCPU.com, Backcountry.com, Reliabemedical.com, any of the sites maintained by End Point are using that setup.saz Here's a link to the commit about using wget: http://www.icdevgroup.org/pipermail/interchange-cvs/2005-May/006341.html I'm not sure where the main thread is about this problem, but it's in the archives. Here is another post about the matter: http://www.icdevgroup.org/pipermail/interchange-users/2005-June/043376.html You may try searching for wget and Payment.pm or wget and Payment and see what turns up. -- Ron Phipps End Point Corporation ron@endpoint.com From tpruitt at pruittcom.com Wed Dec 27 16:55:17 2006 From: tpruitt at pruittcom.com (Tommy Pruitt) Date: Wed Dec 27 16:57:10 2006 Subject: [ic] error when order on admin Enter Order page Message-ID: I get the following error when entering an order via the admin pages using the "Enter Order" tab. There were errors in your last entry. Pointers are shown in this color below. * po_number: Please include your PO number We have a PO entered in the PO box. Thanks for any help. Tommy From icdev at mrlock.com Wed Dec 27 17:14:49 2006 From: icdev at mrlock.com (Steve Graham) Date: Wed Dec 27 17:15:07 2006 Subject: [ic] error when order on admin Enter Order page In-Reply-To: References: Message-ID: <7.0.1.0.0.20061227161323.01c42fd0@mrlock.com> At 03:55 PM 12/27/2006, you wrote: >I get the following error when entering an order via the admin pages >using the "Enter Order" tab. > >There were errors in your last entry. Pointers are shown in this color >below. > > * po_number: Please include your PO number > >We have a PO entered in the PO box. > >Thanks for any help. >Tommy I'm not sure I can offer any assistance, but you need to let everyone know what version of IC you are using. Can you test and create this error in the demo version? http://www.icdevgroup.org/i/dev/demo Steve From tpruitt at pruittcom.com Thu Dec 28 13:18:54 2006 From: tpruitt at pruittcom.com (Tommy Pruitt) Date: Thu Dec 28 13:20:53 2006 Subject: [ic] error when order on admin Enter Order page In-Reply-To: <7.0.1.0.0.20061227161323.01c42fd0@mrlock.com> Message-ID: >>At 03:55 PM 12/27/2006, you wrote: >>I get the following error when entering an order via the admin pages >>using the "Enter Order" tab. >> >>There were errors in your last entry. Pointers are shown in this color >>below. >> >> * po_number: Please include your PO number >> >>We have a PO entered in the PO box. >> >>Thanks for any help. >>Tommy > >I'm not sure I can offer any assistance, but you need to let everyone >know what version of IC you are using. >Can you test and create this error in the demo version? >http://www.icdevgroup.org/i/dev/demo > >Steve I am running 5.4.1 On the demo store I get a different error message. Do you think upgrading to 5.5 will resolve the problem? There were errors in your last entry. Pointers are shown in this color below. prof_po_accepted: This site doesn't accept purchase orders. You should not have been offered that option; please contact us. _______________________________________________ interchange-users mailing list interchange-users@icdevgroup.org http://www.icdevgroup.org/mailman/listinfo/interchange-users -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From icdev at mrlock.com Thu Dec 28 14:00:38 2006 From: icdev at mrlock.com (Steve Graham) Date: Thu Dec 28 14:00:59 2006 Subject: [ic] error when order on admin Enter Order page In-Reply-To: References: <7.0.1.0.0.20061227161323.01c42fd0@mrlock.com> Message-ID: <7.0.1.0.0.20061228125648.01cbd870@mrlock.com> >I am running 5.4.1 >On the demo store I get a different error message. Do you think >upgrading to 5.5 will resolve the problem? > >There were errors in your last entry. Pointers are shown in this color >below. > >prof_po_accepted: This site doesn't accept purchase orders. You should >not have been offered that option; please contact us. I also run 5.4, but I don't use the admin order entry - we get our people to enter orders from the front end just like customers. If I really needed it, I would try to debug the admin entry on the back end to fit my needs. I can't say about upgrading to 5.5, because I haven't looked to see if there are any database changes - proceed carefully on that option. You might be able to copy the needed (newer admin) file from 5.5 and see if it works on your 5.4 backend - I would try this first (easiest :) - make sure you backup your old file. Others on this list might have a little more insight, but I think most are out on vacation. Good luck -Steve From josh at myprivacy.ca Thu Dec 28 14:53:47 2006 From: josh at myprivacy.ca (Josh Lavin) Date: Thu Dec 28 14:54:18 2006 Subject: [ic] error when order on admin Enter Order page In-Reply-To: References: Message-ID: <0525A7EC-67C7-41F6-B35A-81FA84566DF2@myprivacy.ca> On Dec 27, 2006, at 3:55 PM, Tommy Pruitt wrote: > I get the following error when entering an order via the admin pages > using the "Enter Order" tab. > > There were errors in your last entry. Pointers are shown in this color > below. > > * po_number: Please include your PO number > > We have a PO entered in the PO box. Upgrading might help, if there's some unknown problem, but that could be a lot of work. With that error, the first thing I would check is to make sure the PO number field is named the same as the label it has. The error makes it seem that the field should be called "po_number". That's my meager contribution... -- Josh Lavin Kingdom Design http://www.kingdomdesign.com/ From josh at myprivacy.ca Thu Dec 28 17:21:13 2006 From: josh at myprivacy.ca (Josh Lavin) Date: Thu Dec 28 17:21:45 2006 Subject: [ic] Email as username with 5.4.0 Message-ID: <0643C9D8-C12C-493A-9363-9FD027250D2A@myprivacy.ca> Hello list, Just wanted to make sure I do this right. I am making a new site require everyone to login, using their email address as the username. It seems I need to take these steps to get this to work with IC 5.4.0: 1. Set "UserDB indirect_login email" in catalog.cfg 2. Make sure the email column is a UNIQUE index 3. Upgrade UserDB.pm to latest CVS 4. Set "UserDB default username_email 1" and "UserDB default ignore_case 1" in catalog.cfg Does that look right? I want to be sure before upgrading UserDB.pm, because I have other catalogs on this installation which use the standard username method. Side note: according to: http://www.icdevgroup.org/pipermail/interchange-cvs/2006-July/ 006875.html it looks like users can't change their username (email). Is that still the case? Thanks! -- Josh Lavin Kingdom Design http://www.kingdomdesign.com/ From bob at nleaudio.com Fri Dec 29 13:11:26 2006 From: bob at nleaudio.com (Bob Puff@NLE) Date: Fri Dec 29 13:37:51 2006 Subject: [ic] Re: Dead 5.2 in RPC? In-Reply-To: <200612281700.kBSH0K2p020756@icdevgroup.org> References: <200612281700.kBSH0K2p020756@icdevgroup.org> Message-ID: <45955A4E.1030105@nleaudio.com> > Hi Bob, > > It's definitely MaxServers 0 that gets around the signaling issue when calling external programs. High traffic with MaxServers 0 is working wonderfully for us. It's used at FrozenCPU.com, Backcountry.com, Reliabemedical.com, any of the sites maintained by End Point are using that setup.saz > > Here's a link to the commit about using wget: > > http://www.icdevgroup.org/pipermail/interchange-cvs/2005-May/006341.html > > I'm not sure where the main thread is about this problem, but it's in the archives. Here is another post about the matter: > > http://www.icdevgroup.org/pipermail/interchange-users/2005-June/043376.html > > You may try searching for wget and Payment.pm or wget and Payment and see what turns up. > Hi Ron, Thanks for the leads! I've implemented the Payment.pm and AuthorizeNet.pm from a 5.4.1 on my 5.2 box, and set it back to high traffic with Maxservers set to 0. So far, so good. This was a big, ugly bug that put a lot of egg on my face. Too bad this wasn't addressed a long time ago. Bob From ron at endpoint.com Fri Dec 29 13:50:44 2006 From: ron at endpoint.com (Ron Phipps) Date: Fri Dec 29 14:19:06 2006 Subject: [ic] Re: Dead 5.2 in RPC? In-Reply-To: <45955A4E.1030105@nleaudio.com> References: <200612281700.kBSH0K2p020756@icdevgroup.org> <45955A4E.1030105@nleaudio.com> Message-ID: <45956384.5000500@endpoint.com> Bob Puff@NLE wrote: >> Hi Bob, >> >> It's definitely MaxServers 0 that gets around the signaling issue when calling external programs. High traffic with MaxServers 0 is working wonderfully for us. It's used at FrozenCPU.com, Backcountry.com, Reliabemedical.com, any of the sites maintained by End Point are using that setup.saz >> >> Here's a link to the commit about using wget: >> >> http://www.icdevgroup.org/pipermail/interchange-cvs/2005-May/006341.html >> >> I'm not sure where the main thread is about this problem, but it's in the archives. Here is another post about the matter: >> >> http://www.icdevgroup.org/pipermail/interchange-users/2005-June/043376.html >> >> You may try searching for wget and Payment.pm or wget and Payment and see what turns up. >> > > Hi Ron, > > Thanks for the leads! I've implemented the Payment.pm and AuthorizeNet.pm from a 5.4.1 on my 5.2 > box, and set it back to high traffic with Maxservers set to 0. So far, so good. > > This was a big, ugly bug that put a lot of egg on my face. Too bad this wasn't addressed a long > time ago. > > Bob No problem. I believe this was addressed as soon as reports turned up that it was an issue. I know the RPC/MaxServers 0 solution was addressed back in 2002. RPC/MaxServers 0 is stable in most installations, however it appears you have one of those installs where it acts up. The Payment.pm/wget fix was done in May 2005 shortly after people started to see the issue. Trust me I know how you feel, the mess I had to clean up after the Verisign double/triple charges issue was a pain, but in the end it helped solidify IC even more :) -- Ron Phipps End Point Corporation ron@endpoint.com From emailgrant at gmail.com Sun Dec 31 12:05:55 2006 From: emailgrant at gmail.com (Grant) Date: Sun Dec 31 12:06:12 2006 Subject: [ic] Re: Payment.pm bug fixed In-Reply-To: <49bf44f10612211756y146c0975y8890dea64eeadcd6@mail.gmail.com> References: <49bf44f10612211756y146c0975y8890dea64eeadcd6@mail.gmail.com> Message-ID: <49bf44f10612310905t731d9633s21196e15e25f82a@mail.gmail.com> > I've never been able to submit extra information along with my > Authorize.net transactions, except for the name and address. The > city, state, zip code, and country would never show up on the other > end. I'm finally able to submit all of the above information after > commenting out all of the sections in Payment.pm which contain > "billing_set". Here is a link to Payment.pm: > > http://www.icdevgroup.org/cgi-bin/cvsweb/~checkout~/interchange/lib/Vend/Payment.pm?rev=2.17;content-type=text%2Fplain;hideattic=0 > > Can anyone tell me what the billing_set stuff does? I'm using IC 5.2. Is anyone able to submit city, state, zip code, and country to Authorize.net with an unmodified Payment.pm? - Grant